Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Longevity in JavaScript Frameworks

blog.bitovi.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Longevity in JavaScript Frameworks

#51

Post by bigtunacan »

evlapix wrote: post #33
bigtunacan wrote: post #27

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.

Yes, and I think we do a decent job of highlighting why. Backbone/Knockout may be well maintained but their scope is fixed. CanJS has gone from the times of $.widget() to while maintaining backward compatibility.

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.

Re: Longevity in JavaScript Frameworks

#52

Post by 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 ``

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

Re: Longevity in JavaScript Frameworks

#54

Post by joshontheweb »

aikah wrote: post #42
bigtunacan wrote: post #27

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.

> 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 h…

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.

Re: Longevity in JavaScript Frameworks

#55

Post by coldtea »

joshontheweb wrote: post #54
aikah wrote: post #42

Earlier quoted context omitted.

> 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 h…

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.

Re: Longevity in JavaScript Frameworks

#56

Post by wvenable »

untog wrote: post #37
wvenable wrote: post #30

Earlier quoted context omitted.

> is your JS webapp really going to live, in its current form, for 5 years? Pretty much yes. Almost every single large web app I've ever written is still in use. And many of them are sort of frozen in time with whatever technology and techniques were popular at the time. There is no financial reason to rewrite them. Some have gone through major technological shifts (but not rewrites) if I bet on the wrong technology…

I suspect this depends on what area you work in. If you're making corporate webapps, they'll stick around for a long time (hell, they probably still need to support IE7) but if you're consumer facing, things like mobile would be far more likely to require a rewrite. (for the record, I'm not 20 years old either. However, an decade old C# desktop app I wrote back when I was is still in use at an old corporate workplace…

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.

Re: Longevity in JavaScript Frameworks

#57

Post by mattbrewsbytes »

untog wrote: post #39
mattbrewsbytes wrote: post #28

Earlier quoted context omitted.

Everything still reduces to the lowest common denominator, HTTP. How often does that change, like every 5-10 years? Front end or back end still need to communicate over HTTP and display in browsers. Your end users don't care what framework is used or if it is popular. They just want a usable and probably cheap site/application.

Everything still reduces to the lowest common denominator, HTTP. It doesn't really. Both native apps and webapps use HTTP, but you'd struggle to find too many similarity in those implementations that you could reduce down.

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.

Re: Longevity in JavaScript Frameworks

#58

Post by joshontheweb »

coldtea wrote: post #55
joshontheweb wrote: post #54

Earlier quoted context omitted.

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.

I'd call it feature complete and stable.
Post reply on HN