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

41–50 of 58 posts

Re: Longevity in JavaScript Frameworks

#41

Post by volaski »

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.

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

Re: Longevity in JavaScript Frameworks

#42

Post by aikah »

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

Re: Longevity in JavaScript Frameworks

#43

Post by evlapix »

LukeB_UK wrote: post #40

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

> 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

Re: Longevity in JavaScript Frameworks

#45

Post by lyschoening »

aikah wrote: post #38
lyschoening wrote: post #35

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…

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

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

Re: Longevity in JavaScript Frameworks

#46

Post by mtberatwork »

sanderjd wrote: post #16
untog wrote: post #10

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…

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.

Re: Longevity in JavaScript Frameworks

#47

Post by evlapix »

volaski wrote: post #41
evlapix wrote: post #33

Earlier quoted context omitted.

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.

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

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?

Re: Longevity in JavaScript Frameworks

#48

Post by moschel »

LukeB_UK wrote: post #40

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

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.

Re: Longevity in JavaScript Frameworks

#49

Post by volaski »

evlapix wrote: post #47
volaski wrote: post #41

Earlier quoted context omitted.

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

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.

Re: Longevity in JavaScript Frameworks

#50

Post by EGreg »

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.

So has Ember and many others.
Post reply on HN