Longevity in JavaScript Frameworks • Hacker News Board

Re: Longevity in JavaScript Frameworks

#21

Post by atestu » Tue, Aug 11, 2015, 5:40 PM UTC

valeriob wrote: post #9

slasaus wrote: post #2

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

Re: Longevity in JavaScript Frameworks

#22

Post by macspoofing » Tue, Aug 11, 2015, 5:41 PM UTC

k__ wrote: post #20

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…

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.

Re: Longevity in JavaScript Frameworks

#23

Post by k__ » Tue, Aug 11, 2015, 5:49 PM UTC

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.

Re: Longevity in JavaScript Frameworks

#24

Post by k__ » Tue, Aug 11, 2015, 5:52 PM UTC

macspoofing wrote: post #22

k__ wrote: post #20

Earlier quoted context omitted.

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.

Re: Longevity in JavaScript Frameworks

#25

Post by evlapix » Tue, Aug 11, 2015, 5:55 PM UTC

matthewbauer wrote: post #19

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.

Re: Longevity in JavaScript Frameworks

#26

Post by moron4hire » Tue, Aug 11, 2015, 5:57 PM UTC

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.

Re: Longevity in JavaScript Frameworks

#27

Post by bigtunacan » Tue, Aug 11, 2015, 5:57 PM UTC

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.

Re: Longevity in JavaScript Frameworks

#28

Post by mattbrewsbytes » Tue, Aug 11, 2015, 5:58 PM UTC

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…

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.

Re: Longevity in JavaScript Frameworks

#29

Post by evlapix » Tue, Aug 11, 2015, 6:00 PM UTC

k__ wrote: post #24

macspoofing wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Longevity in JavaScript Frameworks

#30

Post by wvenable » Tue, Aug 11, 2015, 6:04 PM UTC

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…

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