13 ms·

Longevity in JavaScript Frameworks

63 points by MatthewPhillips 11y ago

slasaus 11y ago
It ends up a bit commercially, but they still make a valid point I think.
- valeriob 11y ago
  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.
  - atestu 11y ago
    I completely agree with you on knockout. All versions are backwards compatible, just change the version number and you can enjoy the new features, I'm very happy I went with ko over angular (of course angular does more things so it's not a fair comparison, but things I do not need).
AnonNo15 11y ago
Bottom line: consider jQuery before any fancy hot XXX.js framework
- keithwhor 11y ago
  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.
  - slippyt 11y ago
    > 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.
    - keithwhor 11y ago
      Yeah, but this can be a crapshoot. ;) Many JS frameworks enforce their own brand of modularity (complete with boilerplate) that isn't transferrable to other projects, frameworks or languages. They don't necessarily teach you how to write modular code in general, just how to write modules within their architecture. There's a difference. Edit: Not to say there isn't value in introducing a newbie developer to modules. Just not all frameworks are created equal. :)
      - hughw 11y ago
        e.g. Angular
ThrustVectoring 11y ago
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.
- slippyt 11y ago
  You can rewrite an app instead of maintaining it for years, in which case choosing a non-evolving framework is perfectly fine. Over time, this approach doesn't fit very well into an agile development methodology. Choosing a non-evolving framework almost guarantees that your app will become a "legacy" app one day.
hyperpallium 11y ago
/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.
candu 11y ago
Also worth noting: the same insight is valid w.r.t. languages, databases, etc. One rule of thumb I've heard is that you should incorporate at most one "new" piece of tech into any given project.
untog 11y ago
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.
- TomSawyer 11y ago
  "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."
  - Silhouette 11y ago
    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.
- sanderjd 11y ago
  I don't think "the backend APIs, etc. etc." are typically the things with longevity, either, as very few of them do much of anything with real novelty or complexity. It's the customer relationships, brand awareness, domain expertise, and operational investments that last. Expect to change all code frequently, and focus on building a strong business for that code to serve.
coo1k 11y ago
On an unrelated note, your page took 1.2 minutes to load completely. And I have very fast internet connection.
- moschel 11y ago
  Sorry about that, having some blog issues due to a lot of load today. It will be back up in the next 20 minutes.
kngl 11y ago
Server is unreachable; archived version: https://archive.is/i8t9w https://archive.is/i8t9w
matthewbauer 11y ago
Why do frameworks need to innovate? I'd much rather have a framework that releases fixes than one that "innovates often". Frameworks should start out innovative and slow down. Things change too fast to expect an "innovative framework" to be backwards compatable.
- evlapix 11y ago
  It's fair to have compromised your expectations of frameworks - since there aren't many that have been around for long - but Bitovi and its clients have not. Our libraries are both backward compatible and constantly innovating.
k__ 11y ago
I really hope React plays out better than Angular. And with FB using it for their web and mobile apps, it seems a good bet. Angular and Ember seem to move into the React direction, which lets React shine even more. I was forced to switch from ExtJS to Ember to React, so I don't mind learning another framework in the next years. But it would be nice if I could work with my React skills for 5 or more, haha.
moron4hire 11y ago
There is a tendency on HN to only consider product- or service-oriented software development. That's fine, I understand that tendency, it's kind of what we all want to do. But there is a LOT more consultoware in the world. And a lot of it runs in the browser on corporate intranets, where IF it ever gets updates past the first year after release, it will probably be by a completely different team. And by different team, that could either mean a completely different consulting company, or a completely different set of developers in the original company [0]. I know for a fact that there is JS code that I have written that has been in use, unchanged, for 10 years. That's not to say that I wrote amazing code. I didn't write anything good 10 years ago (and probably don't 10 years later, but that's a different issue). That code got written, the system got installed, and nobody ever went back to change anything in it. I'm sure the database server crashes once every two days and they just have a policy to reset the server every morning. So yes, you absolutely can expect code you write to last for 5+ years. [0] And that could be be either because the consulting company moves their A-Team around on new projects and puts their B- and C-Teams on long-term-support, or it could be because the company perpetually assigns teams to projects, and bored developers quit to new companies.
bigtunacan 11y ago
<TL; DR;> Creators 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.
- evlapix 11y ago
  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 <app-component> while maintaining backward compatibility.
  - volaski 11y ago
    Just the fact that this is a blatant advertorial makes it hard for anyone to take your article seriously. Your arguments are valid and I admire your research but your presentation discounted all the value you provided with your article. If I were you I would have left out your attempt to "sell" your project and just mention it briefly at the end. If people actually agree with you, they would have been interested anyway. But as soon as you started talking about CanJS the credibility fell to 0
    - evlapix 11y ago
      Thank you, I get the sense that you're not trying to be overly negative. But I'm also slightly confused. If you can't gain credibility with valid arguments and research, how else can you?
      - volaski 11y ago
        The article as is right now, won't be shared as much as could have been if it had objective tone. What I've seen a lot of people do is make a useful and objective argument about what the message they're trying to convey and then maybe at the end mention their message briefly. That's how people build credibility. Check out all "Crunch Network" posts on TechCrunch. Even though most of the writers behind those articles do have agenda (they all have some stakes in the subject matter), a lot of those articles are useful. Since the content is useful, a lot of people share them and there's no lost credibility.
iamthepieman 11y ago
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.
lyschoening 11y ago
The 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.
- aikah 11y ago
  > 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 ?
  - lyschoening 11y ago
    > There will be dozens of frameworks for ES6/7 Sure, but you don't have to have all your application logic written using a framework-specific class factory, linked through a framework-specific module system. That means code will be more portable. > Not sure why you're talking about material design, and why it matters when it's some vague UX spec produced by Google. It's a very precise UI specification, so theoretically a single implementation would be enough. I am just saying that there is no universally compatible Web Component package format in wide use yet.
brightball 11y ago
Javascript 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.
LukeB_UK 11y ago
I 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.
- evlapix 11y ago
  > 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. While it may be a large undertaking for your organization, I wouldn't consider any of these to be irrational changes in API from 3.2 to 3.3: http://www.javascriptmvc.com/docs/done.html http://www.javascriptmvc.com/docs/done.html
- moschel 11y ago
  Changing concepts is natural as best practices evolve. 3.3 introduced live binding, but it didn't break any of the older ways of writing apps. 3.2 to 3.3 is actually mostly syntax changes that are documented in the guide linked in the other comment. What specifically is preventing you from upgrading? If you want any help or tips, please reach out and we'll gladly help you or give some pointers.
joepie91_ 11y ago
The real lesson is that you should be using modular frameworks, not monolithic ones.
justinbmeyer 11y ago
As the lead author of JMVC, CanJS, StealJS, etc, let me try to address some of the criticisms of this article. I didn't write it, but I reviewed it. Yes, this is a blatant advertisement. We worked hard on these open source project, believe they are great, and were trying to argue for their use from a commonly overlooked perspective. It should surprise no one that an article on our site advocates for one of our open source projects. I don't think arguing for something you benefit from should disqualify the argument. Instead, it should make any claims we make fall under more intense scrutiny. Now about longevity, there really isn't a fair comparison. JavaScriptMVC is far older then Backbone, Knockout, Angular and React. They, for the most part, haven't even had to evolve. Their technology is, for the most part, still pretty modern. We'll see how they do. Here's how JavaScriptMVC evolved: JavaScriptMVC started on PrototypeJS. It did almost everything a Backbone + RequireJS + Karma + DocJS setup does today. Except much worse! It used: - PrototypeJS (jQuery had only first released) - RhinoJS (the only viable server-side JS runtime) - EJS for templates like `<%= foo %>` - Steal syntax for loading scripts `steal(dependencies)` - Selenium for test driving It had the only working "event delegation" system. This was one of its big features. It also had: - basic modeling - basic routing Since that time, we've probably done more then anyone else to adapt and evolve the tools and technology so a reasonable person could upgrade. Some of my favorite highlights: 1. We updated StealJS to support AMD/CJS/ES6 syntaxes while still supporting the old steal syntax. We also migrated its build system from RhinoJS to NodeJS. 2. We swapped out Prototype for a compatibility layer that runs on jQuery / Zepto / Dojo / Mootools / YUI 3. I helped jQuery add event delegation so we could drop it from JMVC in jQuery 1.4. 4. We added live-binding EJS templates. 5. We added live-binding Handlebars-like templates. And then re-wrote that again to be 2x faster. 6. We added custom elements, two-way bindings. 7. I'm currently rewriting how we do data-connection: http://connect.canjs.com/ http://connect.canjs.com/, while still providing a backwards compatible version: http://connect.canjs.com/doc/can-connect%7Ccan%7Cmodel.html http://connect.canjs.com/doc/can-connect%7Ccan%7Cmodel.html 8. Live-reload technology 9. A progressive bundling algorithm. 10. Migrated documentjs from Rhino to NodeJS, make it support multi-versioned docs. If this article had come out 3-4 weeks from now you'll see we added: 1. Server-side rendering (Isomorphic / Universal JavaScript) 2. Worker-thread rendering with virtual dom merges. We started when JavaScript was in its infancy and managed to evolve our tools and technology to keep pace with innovation constantly happening in our space. I really don't think there's another project that's undergone such a transformation. When Angular was released, people thought putting click handlers back in a template was silly. Same with React's Virtual DOM approach. Those things have turned out to be great. We've added them (or are just about to). We've tried to keep changes as small as possible between major versions. I think we've walked the line well between change and backwards compatibility. So in the end, we're very proud of these accomplishments. We believe they are unique and mean something. That's what this article was about. Btw, I give a free weekly JS training tomorrow. Its got open Q+A at the end if anyone wants to discuss more, you can join it here: https://plus.google.com/u/1/b/117481170193954630503/events/ceruatammm7f10roacto41borkc https://plus.google.com/u/1/b/117481170193954630503/events/c... Open QA will be at approx. 12:45 CST.
christocracy 11y ago
ExtJS dates back to 2006 -- not 2009. It had a good run of ~9 years. - former employee

slasaus 11y ago

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

valeriob 11y ago
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.
- atestu 11y ago
  I completely agree with you on knockout. All versions are backwards compatible, just change the version number and you can enjoy the new features, I'm very happy I went with ko over angular (of course angular does more things so it's not a fair comparison, but things I do not need).

AnonNo15 11y ago

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

keithwhor 11y ago
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.
- slippyt 11y ago
  > 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.
  - keithwhor 11y ago
    Yeah, but this can be a crapshoot. ;) Many JS frameworks enforce their own brand of modularity (complete with boilerplate) that isn't transferrable to other projects, frameworks or languages. They don't necessarily teach you how to write modular code in general, just how to write modules within their architecture. There's a difference. Edit: Not to say there isn't value in introducing a newbie developer to modules. Just not all frameworks are created equal. :)
    - hughw 11y ago
      e.g. Angular

ThrustVectoring 11y ago

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.

slippyt 11y ago
You can rewrite an app instead of maintaining it for years, in which case choosing a non-evolving framework is perfectly fine. Over time, this approach doesn't fit very well into an agile development methodology. Choosing a non-evolving framework almost guarantees that your app will become a "legacy" app one day.

hyperpallium 11y ago

/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.

candu 11y ago

Also worth noting: the same insight is valid w.r.t. languages, databases, etc. One rule of thumb I've heard is that you should incorporate at most one "new" piece of tech into any given project.

untog 11y ago

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.

TomSawyer 11y ago
"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."
- Silhouette 11y ago
  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.
sanderjd 11y ago
I don't think "the backend APIs, etc. etc." are typically the things with longevity, either, as very few of them do much of anything with real novelty or complexity. It's the customer relationships, brand awareness, domain expertise, and operational investments that last. Expect to change all code frequently, and focus on building a strong business for that code to serve.

coo1k 11y ago

On an unrelated note, your page took 1.2 minutes to load completely. And I have very fast internet connection.

moschel 11y ago
Sorry about that, having some blog issues due to a lot of load today. It will be back up in the next 20 minutes.

kngl 11y ago

Server is unreachable; archived version: https://archive.is/i8t9w https://archive.is/i8t9w

matthewbauer 11y ago

Why do frameworks need to innovate? I'd much rather have a framework that releases fixes than one that "innovates often". Frameworks should start out innovative and slow down. Things change too fast to expect an "innovative framework" to be backwards compatable.

evlapix 11y ago
It's fair to have compromised your expectations of frameworks - since there aren't many that have been around for long - but Bitovi and its clients have not. Our libraries are both backward compatible and constantly innovating.

k__ 11y ago

I really hope React plays out better than Angular. And with FB using it for their web and mobile apps, it seems a good bet. Angular and Ember seem to move into the React direction, which lets React shine even more. I was forced to switch from ExtJS to Ember to React, so I don't mind learning another framework in the next years. But it would be nice if I could work with my React skills for 5 or more, haha.

moron4hire 11y ago

There is a tendency on HN to only consider product- or service-oriented software development. That's fine, I understand that tendency, it's kind of what we all want to do. But there is a LOT more consultoware in the world. And a lot of it runs in the browser on corporate intranets, where IF it ever gets updates past the first year after release, it will probably be by a completely different team. And by different team, that could either mean a completely different consulting company, or a completely different set of developers in the original company [0]. I know for a fact that there is JS code that I have written that has been in use, unchanged, for 10 years. That's not to say that I wrote amazing code. I didn't write anything good 10 years ago (and probably don't 10 years later, but that's a different issue). That code got written, the system got installed, and nobody ever went back to change anything in it. I'm sure the database server crashes once every two days and they just have a policy to reset the server every morning. So yes, you absolutely can expect code you write to last for 5+ years. [0] And that could be be either because the consulting company moves their A-Team around on new projects and puts their B- and C-Teams on long-term-support, or it could be because the company perpetually assigns teams to projects, and bored developers quit to new companies.

bigtunacan 11y ago

<TL; DR;> Creators 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.

evlapix 11y ago
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 <app-component> while maintaining backward compatibility.
- volaski 11y ago
  Just the fact that this is a blatant advertorial makes it hard for anyone to take your article seriously. Your arguments are valid and I admire your research but your presentation discounted all the value you provided with your article. If I were you I would have left out your attempt to "sell" your project and just mention it briefly at the end. If people actually agree with you, they would have been interested anyway. But as soon as you started talking about CanJS the credibility fell to 0
  - evlapix 11y ago
    Thank you, I get the sense that you're not trying to be overly negative. But I'm also slightly confused. If you can't gain credibility with valid arguments and research, how else can you?
    - volaski 11y ago
      The article as is right now, won't be shared as much as could have been if it had objective tone. What I've seen a lot of people do is make a useful and objective argument about what the message they're trying to convey and then maybe at the end mention their message briefly. That's how people build credibility. Check out all "Crunch Network" posts on TechCrunch. Even though most of the writers behind those articles do have agenda (they all have some stakes in the subject matter), a lot of those articles are useful. Since the content is useful, a lot of people share them and there's no lost credibility.

iamthepieman 11y ago

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.

lyschoening 11y ago

The 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.

aikah 11y ago
> 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 ?
- lyschoening 11y ago
  > There will be dozens of frameworks for ES6/7 Sure, but you don't have to have all your application logic written using a framework-specific class factory, linked through a framework-specific module system. That means code will be more portable. > Not sure why you're talking about material design, and why it matters when it's some vague UX spec produced by Google. It's a very precise UI specification, so theoretically a single implementation would be enough. I am just saying that there is no universally compatible Web Component package format in wide use yet.

brightball 11y ago

Javascript 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.

LukeB_UK 11y ago

I 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.

evlapix 11y ago
> 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. While it may be a large undertaking for your organization, I wouldn't consider any of these to be irrational changes in API from 3.2 to 3.3: http://www.javascriptmvc.com/docs/done.html http://www.javascriptmvc.com/docs/done.html
moschel 11y ago
Changing concepts is natural as best practices evolve. 3.3 introduced live binding, but it didn't break any of the older ways of writing apps. 3.2 to 3.3 is actually mostly syntax changes that are documented in the guide linked in the other comment. What specifically is preventing you from upgrading? If you want any help or tips, please reach out and we'll gladly help you or give some pointers.

joepie91_ 11y ago

The real lesson is that you should be using modular frameworks, not monolithic ones.

justinbmeyer 11y ago

As the lead author of JMVC, CanJS, StealJS, etc, let me try to address some of the criticisms of this article. I didn't write it, but I reviewed it. Yes, this is a blatant advertisement. We worked hard on these open source project, believe they are great, and were trying to argue for their use from a commonly overlooked perspective. It should surprise no one that an article on our site advocates for one of our open source projects. I don't think arguing for something you benefit from should disqualify the argument. Instead, it should make any claims we make fall under more intense scrutiny. Now about longevity, there really isn't a fair comparison. JavaScriptMVC is far older then Backbone, Knockout, Angular and React. They, for the most part, haven't even had to evolve. Their technology is, for the most part, still pretty modern. We'll see how they do. Here's how JavaScriptMVC evolved: JavaScriptMVC started on PrototypeJS. It did almost everything a Backbone + RequireJS + Karma + DocJS setup does today. Except much worse! It used: - PrototypeJS (jQuery had only first released) - RhinoJS (the only viable server-side JS runtime) - EJS for templates like `<%= foo %>` - Steal syntax for loading scripts `steal(dependencies)` - Selenium for test driving It had the only working "event delegation" system. This was one of its big features. It also had: - basic modeling - basic routing Since that time, we've probably done more then anyone else to adapt and evolve the tools and technology so a reasonable person could upgrade. Some of my favorite highlights: 1. We updated StealJS to support AMD/CJS/ES6 syntaxes while still supporting the old steal syntax. We also migrated its build system from RhinoJS to NodeJS. 2. We swapped out Prototype for a compatibility layer that runs on jQuery / Zepto / Dojo / Mootools / YUI 3. I helped jQuery add event delegation so we could drop it from JMVC in jQuery 1.4. 4. We added live-binding EJS templates. 5. We added live-binding Handlebars-like templates. And then re-wrote that again to be 2x faster. 6. We added custom elements, two-way bindings. 7. I'm currently rewriting how we do data-connection: http://connect.canjs.com/ http://connect.canjs.com/, while still providing a backwards compatible version: http://connect.canjs.com/doc/can-connect%7Ccan%7Cmodel.html http://connect.canjs.com/doc/can-connect%7Ccan%7Cmodel.html 8. Live-reload technology 9. A progressive bundling algorithm. 10. Migrated documentjs from Rhino to NodeJS, make it support multi-versioned docs. If this article had come out 3-4 weeks from now you'll see we added: 1. Server-side rendering (Isomorphic / Universal JavaScript) 2. Worker-thread rendering with virtual dom merges. We started when JavaScript was in its infancy and managed to evolve our tools and technology to keep pace with innovation constantly happening in our space. I really don't think there's another project that's undergone such a transformation. When Angular was released, people thought putting click handlers back in a template was silly. Same with React's Virtual DOM approach. Those things have turned out to be great. We've added them (or are just about to). We've tried to keep changes as small as possible between major versions. I think we've walked the line well between change and backwards compatibility. So in the end, we're very proud of these accomplishments. We believe they are unique and mean something. That's what this article was about. Btw, I give a free weekly JS training tomorrow. Its got open Q+A at the end if anyone wants to discuss more, you can join it here: https://plus.google.com/u/1/b/117481170193954630503/events/ceruatammm7f10roacto41borkc https://plus.google.com/u/1/b/117481170193954630503/events/c... Open QA will be at approx. 12:45 CST.

christocracy 11y ago

ExtJS dates back to 2006 -- not 2009. It had a good run of ~9 years. - former employee