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

While the JavaScript ecosystem does move insanely fast a lot of consulting companies need to have people with similar skill levels in a framework/etc. Which means you can't just switch frameworks every year (You can, however, create smaller teams with new technologies, so if a few of the guys learned React you can just make a React team with them as a base.

A big misconception I've seen is that a lot of JavaScript stuff disappears after a couple of years, while in reality a lot of Consulting companies are still recruiting people for jQuery positions (In my country, might be different in the US).

Sure, the new startups who are using all the newest coolness maybe won't touch jQuery and similar technologies with a 10 foot pole. That doesn't mean those technologies disappear.

It depends on your goals as a person. Personally I enjoy chasing the newest thing, learning is fun. Maybe when I become more jaded at re-learning stuff every year I'll move from that kind of ecosystem.

All in all, the advice I wish I could've told myself years ago is to invest a bit less time learning frameworks in depth and a bit more time learning JavaScript. JavaScript has a lot of pitfalls, but if you learn to navigate around those you are left with a very fun and powerful language. And most importantly, that knowledge is still gonna be relevant 3 years from now even if you are switching frameworks.

- Has no standard library. - Is used to automate host platforms that have either no standard framework or very little (e.g. Node on v8 doesn't have nothing but it's quite small). - Has no module/namespace system.

The effect of this is that immediately, anyone building anything in non-trivial has to make a decision about how to fill in things that would be covered in a standard library. I'm not even talking about fancy stuff, just the stuff supplied by underscore, lodash, etc. The choices are basically:

1) Write all the code yourself. This is an extremely low ROI option 2) Adopt a series of libraries and hope you can get them to work together 3) Adopt a framework, that by its nature, will be designed to use some sort of new pattern and this pattern will be expressed on top of whatever libraries the framework uses, so just draft behind that.

There aren't really many other mainstream systems where a language is used to specialize applications on a platform where this situation obtains. Windows, OS X, iOS, Android, even Java, come with enormous, enormous amounts of library code. Generally, this library code also pushes one fairly firmly towards certain design patterns.

Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows applications, and you took away everything but the lowest-level Windows APIs. I'm using Scheme because the Scheme standard outlines a remarkably small language that has nothing approaching a standard library.

We'd probably be in a similar situation. How do you do this? How much does adopting this or that library force you to do this or that? It's just not very common to have a situation where to do anything non-trivial, you need to either: - adopt an enormous amount of third party code (because the situation works at every level, each third-party solution will also not be built on a standard library ecosystem) - write an enormous amount of boilerplate code.

And further, the issue is exacerbated by the fact that js doesn't really have a standard module system, so even the approaches taken to fill these gaps are frequently non-compatible, or just choosing which system to use to manage modules often means replacing huge chunks of your application.

There are other reasons why JS the language is moving, all of the sudden: JS has had a lot of rough edges and all of the sudden a confluence of interest, capability, and technology has made it possible to sand down some of those edges.

But I think even if the ES process slows down, and we all agree that language-wise the features in the language are pretty good or something happens that freezes, we'll keep seeing lots of churn because of the interaction between every project being built on towers of third party code with far-reaching effects.

When Java, for instance, was released, the standard library it shipped with included: - a set of standard container classes: hashes, vectors, arrays, etc. - a rich set of real types (e.g. numbers that weren't insane, Objects for compatibility with the object system, primitive types in the language for performance) - a whole tree of calendar/date manipulation code - a standard way of connecting to SQL databases and all the code for that - a standard GUI-drawing and event-handling system - a big, rich set of APIs for handling IO of various kinds with different performance/complexity tradeoffs. - a concurrency api, threadpools, etc.

That's just a sample. And all of the bits worked together, and sort of implied patterns in how things should be built and used.

You could certainly replace anything, should you choose to, in your project (e.g. the calendar stuff really sucked), but the point is, there was a default, and there was a standard pattern for where and how to bring in new library code, and that new library code would in turn be built on as little third-party code as possible.

Look at an average iOS project's Podfile or Carthage file, Android project's Gradle file, and then look at a Node or browser js project's package.json. Then actually look in Pods and node_modules. The average amount of third party libs in a JS project is many orders of magnitude higher than in the others.

There are like, what, five or so competing implementations of Promises in javascript land? And they aren't mutually compatible always, so this means if you want to use non-ES6 babel-compiled Promises in your code, you have to: - choose a library - hope that other libraries and frameworks you use use the same style - add shims or something where they don't, or else switch out the library and framework.

This is just like...no one writing an Android app is like "which Runnables library are you using?". No one writing an iOS app is like "soo...the new GCD spec looks interesting, which GCD lib are you using for your project? Oh yeah how spec-complete is it? Does it work with AFNetworking?"

"Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc. Lodash’s modular methods are great for:

Iterating arrays, objects, & strings"

Iterating arrays, objects, & strings is something that most other languages have decent std lib support for, and so even your third-party libs will use the host language's affordances. In Javascript you have to ask these questions all the time.

For an environment that's as dynamic and open as Javascript, my POV is that one should be able to dive into library source code -- but that changes resulting from this should be an unusual circumstance, having to do with edge cases. If the normal situation is that you are always doing this, and it is always is flat-out basic debugging, then this is messed up.

The ability to dive into and debug everyone's source code should be considered a blessing. It's a great way to learn coding style and programming! It's one thing that was great about working in Smalltalk. However, the need to do so just to fix library bugs should be viewed as a symptom!

Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation.

I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.