
Longevity in JavaScript Frameworks - MatthewPhillips
http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/
======
bigtunacan
<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
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
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
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
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.

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

~~~
wvenable
> 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 for that project.

When I was 20 years old, 5 years seemed a long time and would have never
expected any of my software to be in constant use 15 to 20 years later.

~~~
untog
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)

~~~
wvenable
All my early work was in consumer web sites and applications. One of my oldest
sites is a popular consumer/professional news and review site in a popular
niche. There have been several failed attempts at a redesign over the years
but it still chugs along and makes money. Absolutely no attempt has ever been
made to make it work on mobile and that would definitely be a design
requirement now. The back-end even has a nifty Ajax-like component that should
still work in _Netscape 4_.

I do corporate web applications now and there is a lot of pressure to support
modern browsers and mobile.

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

~~~
moschel
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.

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

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

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

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

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

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

------
kngl
Server is unreachable; archived version:
[https://archive.is/i8t9w](https://archive.is/i8t9w)

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

~~~
valeriob
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
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).

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

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

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

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

------
justinbmeyer
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/c...](https://plus.google.com/u/1/b/117481170193954630503/events/ceruatammm7f10roacto41borkc)
Open QA will be at approx. 12:45 CST.

------
joepie91_
The _real_ lesson is that you should be using modular frameworks, not
monolithic ones.

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

\- former employee

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

~~~
keithwhor
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
> 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
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
e.g. Angular

