The Dojo toolkit has been around since 2005. If you only count stable releases then it still beats Javascript MVC as JSMVC 1.0 was released in early 2008 and Dojo 1.0 was released in November of 2007.
Longevity in JavaScript Frameworks
31–40 of 58 posts
Re: Longevity in JavaScript Frameworks
#32As 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…
As a counterpoint: is your JS webapp really going to live, in its current form, for 5 years?
Sure, because things like intranets and embedded UIs exist.
I have no hard data on whether these categories, which frequently involve developments that will be deployed once and run indefinitely or with only occasional upgrades, are a larger part of the industry than hosted web apps. However, I would be extremely surprised if the kind of project we discuss all the time on HN and some people here work on in SV is anywhere near representative of the web development industry as a whole.
Re: Longevity in JavaScript Frameworks
#33Creators of CanJS think you should use CanJS. Honestly; I have a hard time taking this article seriously when they put Backbone & Knockout into the "stagnation" category, but CANjs into the "safe bet" area. Both Backbone and Knockout are continually maintained and have done a good job with backwards compatibility.
Yes, and I think we do a decent job of highlighting why.
Backbone/Knockout may be well maintained but their scope is fixed. CanJS has gone from the times of $.widget() to while maintaining backward compatibility.
Re: Longevity in JavaScript Frameworks
#34As 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…
"Continued innovation matters more than the current set of features." I think it's taken as a given that your app won't be sitting still for five years. The point of the longevity argument is that you won't have to rewrite regularly so your app will have a chance to make it to five years. Check out the team velocity chart under "Making a Good Bet."
I think it's taken as a given that your app won't be sitting still for five years.
Many, many web apps will do exactly that, just as many businesses are still getting work done with desktop software that is several years old. But in the world of web, browsers now break functionality all the time and vulnerabilities are found with alarming frequency, so the ability to update front-end code to at least maintain compatibility and security is often important, even if it's otherwise working fine and needing little new development.
Re: Longevity in JavaScript Frameworks
#35The good news is that with ES6/7 and the advent (hopefully) of web components, frameworks lose some of their significance. As things are now, what you need from a framework is a good router and a template engine as glue for the components. Most of the logic can be made portable.
There's of course still some work to be done on reusability of UI components — seeing as Angular, React, and Aurelia are each building their own Material Design implementation.
Re: Longevity in JavaScript Frameworks
#36Javascript frameworks have the same problem that PHP frameworks have: the language is built for the problem they are trying to solve so it's easy to invent new ways to do it. That leads to option saturation and people creating solutions to address the drawback they found in another approach.
That's the reason I have a REALLY hard time committing to any Javascript framework with more than a passing learning curve or a set of rules that wants your whole application to follow (and marry).
For that reason, I'd generally stuck with just using jQuery until I was introduced to React. React seems to go at the problem from a "realistic use" perspective that flows well with small reusable components without requiring full marriage to use it. It's the most well thought out one that I've seen.
That said, I'm going to continue being a skeptical curmudgeon.
Re: Longevity in JavaScript Frameworks
#37As 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…
> is your JS webapp really going to live, in its current form, for 5 years? Pretty much yes. Almost every single large web app I've ever written is still in use. And many of them are sort of frozen in time with whatever technology and techniques were popular at the time. There is no financial reason to rewrite them. Some have gone through major technological shifts (but not rewrites) if I bet on the wrong technology…
I suspect this depends on what area you work in. If you're making corporate webapps, they'll stick around for a long time (hell, they probably still need to support IE7) but if you're consumer facing, things like mobile would be far more likely to require a rewrite.
(for the record, I'm not 20 years old either. However, an decade old C# desktop app I wrote back when I was is still in use at an old corporate workplace)
Re: Longevity in JavaScript Frameworks
#38The good news is that with ES6/7 and the advent (hopefully) of web components, frameworks lose some of their significance. As things are now, what you need from a framework is a good router and a template engine as glue for the components. Most of the logic can be made portable. There's of course still some work to be done on reusability of UI components — seeing as Angular, React, and Aurelia are each building their…
> frameworks lose some of their significance
no they wont, see server side languages. There will be dozens of frameworks for ES6/7 ... why do you think AngularJS and co get rewritten from scratch using some ES6/7 dialect ? You can argue AngularJS will be a set of decoupled libs, that wont be the case for what matters, the view.
> There's of course still some work to be done on reusability of UI components — seeing as Angular, React, and Aurelia are each building their own Material Design implementation.
Not sure why you're talking about material design, and why it matters when it's some vague UX spec produced by Google. Did you mean webcomponents ?
Re: Longevity in JavaScript Frameworks
#39As 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…
Everything still reduces to the lowest common denominator, HTTP. How often does that change, like every 5-10 years? Front end or back end still need to communicate over HTTP and display in browsers. Your end users don't care what framework is used or if it is popular. They just want a usable and probably cheap site/application.
Everything still reduces to the lowest common denominator, HTTP.
It doesn't really. Both native apps and webapps use HTTP, but you'd struggle to find too many similarity in those implementations that you could reduce down.
Re: Longevity in JavaScript Frameworks
#40I don't know how Bitovi can bash other frameworks for breaking compatability on major versions, when they completely changed the concepts of JMVC in version 3.3. They also stagnated for 2 years between version 3.2 and 3.3.
>If your project chose JavaScriptMVC in 2007, you would have made a wise decision, giving your team an upgrade path to a modern application for the past 8.5 years.
This is kinda funny to me because I know it's untrue. The product I work on in my day job is based on JMVC 3.2 and we can't upgrade to 3.3 because of the size of our app and the amount of refactoring work that would need to be done to make it work with the new concepts.