Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

201–210 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#201

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other commun…

> We're still waiting for the Ruby on Rails of frontend development.

Well, there are the people who have moved on to React and are raving about it, and then there are the really hip people who have moved on to Elm from React and are raving about that: http://elm-lang.org/

Re: Ask HN: Why is everything in JavaScript changing so fast?

#202
post #47
post #29

Earlier quoted context omitted.

Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript. In JavaScript you rarely see getters and setters, as you do not need any…

You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take…

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...)

Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code)

We have bigger problems (not that JS really addresses them, either).

Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.

Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.

Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)

Re: Ask HN: Why is everything in JavaScript changing so fast?

#203

Earlier quoted context omitted.

Plenty of people (including me) took one or two looks at RoR and dismissed it, too. I don't think it was the slam-dunk you're making it out to be. React seems to be doing pretty well these days, but it is too soon to say if it is going to dominate the field.

On the contrary; Rails was a massive innovation because it proved that opinionated, reasonable defaults ("convention over configuration") is how most people actually want to write software. For a CRUD app, Rails was a shining beacon of light, because it allowed you to crank one out in mere hours, instead of days of fiddling with repetitive glue code that you would've had to write instead in literally any other web fr…

> how most people actually want to write software.

[citation needed]

Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light.

JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you just aren't familiar with what's out there.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#204

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

Having been a programmer for the past 18 years, I can say that JavaScript definitely suffers from "rock star" syndrome. There are great people in every programming community... and JavaScript is no exception. But never have I seen a community so plagued by the conference speaker, twitter famous types. (The types that refer to people not in their perceived realm of popularity as "filthy randos") It's incredibly toxic.…

Some ppl simply are rock stars. They are better than everyone else at the whole open-source lifecycle. They know how to do the marketing, manage scope, ship features, manage issues, etc.

To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#205
JavaScript was originally a way to create interactive webpages, but because it broke or replicated MVC, became the backend too.

The variety of backend requirements, and the flexibility of UX, led people to solve many individual workflow bottlenecks or generalize to any/many.

Then so, like the English language, exploded to the simple-->jargon range of overloaded usage and niche comprehension, very quickly fragmenting, but universally powerful.

Developing a framework as a startup for a particular use case may take more time than prototyping on an existing framework--this is why the prototype should be discarded, and a critique of how open source/reusable code has always been a source of technical debt apart from the rare, shining outliers.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#206
post #47

Earlier quoted context omitted.

You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take…

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does genera…

I mostly agree, types are nice but they should not clutter code like in C++ or C.

If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.

For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.

Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.

Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.

Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#207
post #204

Earlier quoted context omitted.

Having been a programmer for the past 18 years, I can say that JavaScript definitely suffers from "rock star" syndrome. There are great people in every programming community... and JavaScript is no exception. But never have I seen a community so plagued by the conference speaker, twitter famous types. (The types that refer to people not in their perceived realm of popularity as "filthy randos") It's incredibly toxic.…

Some ppl simply are rock stars. They are better than everyone else at the whole open-source lifecycle. They know how to do the marketing, manage scope, ship features, manage issues, etc. To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.

Well, the thing is that in JS community there are tons of rock starts who basically do simple stuff (which was done 100 times before them), but only after their presentations it goes crazy. People retweet them, use as a credible source, etc. Also, there are a lot of people who are very opinionated and just push it and by this become famous in JS land.

Yeah, that's true, that they invest a lot of personal time in this stuff, and they do a very good job in balancing, but the problem is that people trust them in important questions like performance even despite the fact many of them don't know CS basics properly (like data structures, etc).

I don't want to say all of them are this way, there are some well-educated people who definitely know a lot and deserve all of this. But as it was mentioned earlier, a lot of them are just 22 years old hip guys who released something what became mainstream/were involved in it and became ambassadors.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#209
post #204

Earlier quoted context omitted.

Having been a programmer for the past 18 years, I can say that JavaScript definitely suffers from "rock star" syndrome. There are great people in every programming community... and JavaScript is no exception. But never have I seen a community so plagued by the conference speaker, twitter famous types. (The types that refer to people not in their perceived realm of popularity as "filthy randos") It's incredibly toxic.…

Some ppl simply are rock stars. They are better than everyone else at the whole open-source lifecycle. They know how to do the marketing, manage scope, ship features, manage issues, etc. To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.

> I think rock stars earn their status.

I think that's mostly bunk. For every rockstar there's 100 equally talented individuals who will never get recognition because they were not in the right place at the right time.

Rockstars are incredibly lucky.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#210

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

> Also, the barrier is low, and therefore we have a lot of complex websites built by novices, running in development mode in the actual production. I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging. Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures…

My first "serious" programming language was JavaScript, and I didn't know a lot of basic stuff for a long time – because it is considered normal in JS community! Nowadays we have node.js, so you have to know at least a bit about your terminal, how to run server, kill processes and other everyday stuff, but back in the days it was unnecessary.

And this is not a single story; I've also interviewed some people and for some reason my experience is that JS has very low entry barrier.

Yes, with tail recursion we'll have almost full FP (only pattern matching is missing), but it doesn't mean that every novice will go and study them right after landing – in fact, the opposite, because there are much more tutorials about OOP JS.

Post reply on HN