I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.
Mind sharing why you consider node.js and other server-side javascript tools irrational?
Ask HN: Why is everything in JavaScript changing so fast?
11–20 of 303 posts
Re: Ask HN: Why is everything in JavaScript changing so fast?
#12This is appropriate because websites and web apps are more complicated than ever before, and face the same challenges that traditional enterprise software faces: large codebases that stay around for a long time and need to be maintained and refactored, integration with various APIs, asynchronous communication, separation of concerns, separation of model and view, business logic, test coverage, development of different parts of the application by different parts of the engineering team, etc.
At some point, the benefits a framework provides outweigh the time it takes to adopt and learn the framework. A framework provides an overall way of doing things that gives structure to the project and makes a lot of the challenges I mentioned easier to deal with. Frameworks significantly reduce the number of "how do I implement this feature?" questions that are bound to arise, by providing a standardized way of doing things. They make it easier for teams to collaborate, because the codebase is relatively consistent and engineers aren't constantly dealing with other team members' idiosyncratic code. (Yes, that means there is less room for individual creativity and expression, and it makes programmers interchangeable to some extent. Welcome to the world of business.)
So, why are there so many more JavaScript frameworks than Java frameworks? I suspect it has to do with the low barrier to entry of programming in JavaScript as compared to Java. I also think that dissatisfaction with whatever frameworks are current is a major driver behind the creation of new frameworks. (I suspect that a lot of the dissatisfaction with the current frameworks is misdirected and is really due to the nature of JavaScript as a language, and TypeScript is an example of an explicit reaction to that).
Another reason for the proliferation of frameworks is that the playing field keeps changing. Most recently, it has been smartphones and social media that have revolutionized the way people use the web. Before that, it was streaming video and "Web 2.0." Whatever the next big thing is, I'm sure it will inspire a new flurry of new web development frameworks.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#13I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.
Mind sharing why you consider node.js and other server-side javascript tools irrational?
Re: Ask HN: Why is everything in JavaScript changing so fast?
#14Relatively recently the standardisation, improvement of the language itself, real origin policy, common frameworks and finally npm released whatever was holding it back. It shot out from the rubber band and it's trying to catch up in months where other languages had years to find the way. You may notice that even though a lot is changing, not much is really new. Async existed before, so did dynamic languages, so did MVC, so did immediate mode UI, so did many other things. Js is now going through all of those ideas quickly because the path is known and clear. It will slow down though. There's only so many paradigms that we know. At some point people will run out of easy ideas and will have to start slow experimentation just like all the others.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#15I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.
Mind sharing why you consider node.js and other server-side javascript tools irrational?
Re: Ask HN: Why is everything in JavaScript changing so fast?
#16Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined.
Most of the top repositories on GitHub are JavaScript too: https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...
Demand for JS developers is growing too, as websites become more complex, Node.js becomes more popular on the backend, and frameworks like React Native (more popular than any other iOS or Android library on github) start to pick up mobile developers.
JavaScript performance is also starting to be significantly better than the other scripting languages, e.g. https://www.quora.com/Is-JavaScript-v8-faster-than-Python . Not because of anything inherent about JavaScript, more that it's worth a lot of investment from big companies in JS performance.
Basically, it's not just the number of frameworks. Everything about JavaScript is taking off right now, and leading to a network effect where all the other aspects get boosted too. Sort of funny to have this happen twenty years after its invention.
Re: Ask HN: Why is everything in JavaScript changing so fast?
#17Re: Ask HN: Why is everything in JavaScript changing so fast?
#18Re: Ask HN: Why is everything in JavaScript changing so fast?
#19I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.
https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
Re: Ask HN: Why is everything in JavaScript changing so fast?
#20I've wondered the same thing. My guess is that it's because node is still pretty new, whereas most other popular languages have been around for a while and the "right" way to do things has already reached some consensus.
I wonder id its worth to learn all those cutting edge libraries now, because whatever code I write today maybe outdated next month and I'll have to learn yet another framework/library/syntax etc.
If you want your code to work in the future, you are ultimately responsible for your code and all of its dependencies. The less code, the better. (Although some libraries have earned a track record of dependability, projects and companies may be abandoned and you may need to pick up the slack)