Live data from Hacker News

Longevity in JavaScript Frameworks

blog.bitovi.com

1–10 of 58 posts

Re: Longevity in JavaScript Frameworks

#4
The only thing you lose from a non-evolving framework is the new features and bug-fixes they provide. You can fork it and fix the bugs yourselves, and losing the new features is kind of whatever - it had enough to convince you to use it in the first place.

As long as you're using the best tool for the job you have now, you'll probably be fine.

Re: Longevity in JavaScript Frameworks

#5
/aside Is most adoption of new frameworks due to old developers switching, or new developers entering the market?

JS frameworks are the Drosophila of software, which is surely partly due to the accessibility and popularity of JS, its flexibility and flaws, and also of course that the problem frameworks solve gets better understood and then changes, and the solutions improve. But perhaps also, JS developers themselves are the Drosophila of software developers, quickly entering and exiting the JS field. In many fields, new blood drives adoption.

Re: Longevity in JavaScript Frameworks

#6
post #3

Bottom line: consider jQuery before any fancy hot XXX.js framework

Consider vanilla JS before jQuery. ;)

Frameworks are useful abstractions for getting a product shipped in a reasonable timeframe. At some point, in your growth as a developer, you should understand how to implement things in your language of choice from first principles. However, "ship it" is not necessarily a conducive mantra to learning the intricacies of a language, design patterns, et cetera.

On top of that, it's really damn hard to find good engineers who can work from first principles that aren't already in highly-paid, competitive positions. This is why frameworks flourish. They substantially lower the barrier to entry for creating product.

Re: Longevity in JavaScript Frameworks

#8
post #3

Bottom line: consider jQuery before any fancy hot XXX.js framework

Consider vanilla JS before jQuery. ;) Frameworks are useful abstractions for getting a product shipped in a reasonable timeframe. At some point, in your growth as a developer, you should understand how to implement things in your language of choice from first principles. However, "ship it" is not necessarily a conducive mantra to learning the intricacies of a language, design patterns, et cetera. On top of that, it's…

> They substantially lower the barrier to entry for creating product.

It goes further than this: a good framework can lower the barrier to writing maintainable, modular code. Sometimes people just need a nudge to follow good practices.

Re: Longevity in JavaScript Frameworks

#9
post #2

It ends up a bit commercially, but they still make a valid point I think.

I agree and i would add that betting on a framework is a huge risk, relying on a library is far less dangerous. In the comparison there are some of both so the example are a bit misleading. For example to my knowledge knockout is far from stagnating, it does 1 thing only and it does it well, you can easy replace it incrementally in any application.

Re: Longevity in JavaScript Frameworks

#10
As a counterpoint: is your JS webapp really going to live, in its current form, for 5 years? Experience has taught me that there have been enough shifts - to mobile, especially - that betting in the long term like this might not be worth it. If you've structured your app well, the front-end JS is separated from the backend APIs, etc. etc. - a rewrite of that is not a rewrite of the entire app. So if React speeds your site up by a factor of whatever, go for it.

In any case, even if it is, surely an older framework is fine? I see Backbone in the "slow or stagnated innovation" part of the chart - it isn't broken. It works fine. Seems confusing to simultaneously complain about the web framework "industry" moving too fast, and individual frameworks moving too slow.

Post reply on HN