Longevity in JavaScript Frameworks(blog.bitovi.com)
blog.bitovi.com
Longevity in JavaScript Frameworks
http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/
57 comments
> Backbone and Knockout are continually maintained
I don't know for Knockout but Backbone is a zombie. His creator basically says no to any new feature and has very little time to manage the project anyway. See the commit logs for this year ,they are merely "cosmetic". A lot of things could be fixed or added -- a better router(with states and sub states) , composite views , composite models that do not need verbose hand plumbing -- without even breaking backward compatibility , but there is no plan to add anything significant to the core.
I Never tried CanJS though , It looks like an interesting alternative to Backbone.
I don't know for Knockout but Backbone is a zombie. His creator basically says no to any new feature and has very little time to manage the project anyway. See the commit logs for this year ,they are merely "cosmetic". A lot of things could be fixed or added -- a better router(with states and sub states) , composite views , composite models that do not need verbose hand plumbing -- without even breaking backward compatibility , but there is no plan to add anything significant to the core.
I Never tried CanJS though , It looks like an interesting alternative to Backbone.
This is by design. If you want a framework with lots of these features, they exist. Backbone is intended to be a spartan framework for developers who like that. It is very easy to extend or override whatever functionality you want since it is very small and easy to understand. Continuous feature bloat would ruin it.
>This is by design.
Yes, but it's still stagnation.
Yes, but it's still stagnation.
I'd call it feature complete and stable.
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.
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.
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
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?
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.
The article comes across as very biased. Also; the article was posted by Matthew, a pretty significant contributor to CanJS, but this was not disclosed in the submission.
It wasn't until I was 3/4ths of the way through the article that I even caught on that Bitovi is the company that created CanJS since it is not a framework I have personally used or am all that familiar with.
From your own article you highlight these 3 points as describing "longevity"
1) Trust. (The framework shouldn’t break backwards compatibility.)
2) Consistent innovation
3) Proven Track Record
Both Knockout & Backbone have clearly demonstrated both points 1 & 3. Point 2 is dubious at best since depending on your definition of consistent innovation you may well break Point 1 - Trust.
Consistent innovation is also, IMHO, not a necessity of longevity. If I need to turn a screw I need a screwdriver. Tomorrow a screwdriver will still work; maybe it's a faster battery charged screwdriver, but it is essentially the same tool solving the same problem. KnockoutJS is a tool that still solves the same problem.
It wasn't until I was 3/4ths of the way through the article that I even caught on that Bitovi is the company that created CanJS since it is not a framework I have personally used or am all that familiar with.
From your own article you highlight these 3 points as describing "longevity"
1) Trust. (The framework shouldn’t break backwards compatibility.)
2) Consistent innovation
3) Proven Track Record
Both Knockout & Backbone have clearly demonstrated both points 1 & 3. Point 2 is dubious at best since depending on your definition of consistent innovation you may well break Point 1 - Trust.
Consistent innovation is also, IMHO, not a necessity of longevity. If I need to turn a screw I need a screwdriver. Tomorrow a screwdriver will still work; maybe it's a faster battery charged screwdriver, but it is essentially the same tool solving the same problem. KnockoutJS is a tool that still solves the same problem.
So has Ember and many others.
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.
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.
> 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.
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.
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)
(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)
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.
I do corporate web applications now and there is a lot of pressure to support modern browsers and mobile.
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.
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.
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.
> 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.
I suppose this might be the case for incredibly basic CRUD apps or your personal blog, but the server side is generally where the bulk of the complexity resides, especially in data heavy applications. Good "backend APIs" that you interface with and don't find very novel, are in fact taking care of the complexities for you.
I suppose this might be the case for incredibly basic CRUD apps or your personal blog, but the server side is generally where the bulk of the complexity resides, especially in data heavy applications. Good "backend APIs" that you interface with and don't find very novel, are in fact taking care of the complexities for you.
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.
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.
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.
What is a native JavaScript app? Isn't that still a web app running in a browser? I don't know of any client/server types of solutions with JavaScript as the client by itself.
Coming from vanilla JS to ExtJS to Ember to React I can also say, that the frameworks also improved development speed. So reimplementing an app isn't that big of a problem.
If you're running a dinky site, then no, it isn't a problem. If you, on the other hand, you have thousands of lines of front-end code, moving frameworks is not feasible.
Isn't it possible to do this incremental?
FB has done it and I didn't feel a thing, besides some disappearing bugs.
FB has done it and I didn't feel a thing, besides some disappearing bugs.
I don't think FB is a fair comparison. They are a mature company that operates at incredible scale.
Addendum: The intended audience for this article will not share these same properties.
Addendum: The intended audience for this article will not share these same properties.
"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. 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.
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.
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.
>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.
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.
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.
> 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
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
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.
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.
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.
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.
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.
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.
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.
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.
Server is unreachable; archived version: https://archive.is/i8t9w
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.
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).
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.
As long as you're using the best tool for the job you have now, you'll probably be fine.
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.
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.
/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.
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.
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.
One rule of thumb I've heard is that you should incorporate at most one "new" piece of tech into any given project.
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.
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.
> 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 ?
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 ?
> 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.
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.
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/, while still providing a backwards compatible version: 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... Open QA will be at approx. 12:45 CST.
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/, while still providing a backwards compatible version: 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... Open QA will be at approx. 12:45 CST.
The real lesson is that you should be using modular frameworks, not monolithic ones.
ExtJS dates back to 2006 -- not 2009. It had a good run of ~9 years.
- former employee
- former employee
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.
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.
> 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.
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.
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. :)
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. :)
e.g. Angular
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.