6 ms·

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 mo

by untog 11y ago

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.

TomSawyer 11y ago
"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."
- Silhouette 11y ago
  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.
sanderjd 11y ago
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.
- mtberatwork 11y ago
  > 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.
k__ 11y ago
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.
- macspoofing 11y ago
  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.
  - k__ 11y ago
    Isn't it possible to do this incremental? FB has done it and I didn't feel a thing, besides some disappearing bugs.
    - evlapix 11y ago
      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.
matt_s 11y ago
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.
- untog 11y ago
  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.
  - matt_s 11y ago
    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.
wvenable 11y ago
> 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 11y ago
  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 11y ago
    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.
Silhouette 11y ago
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.

by untog 11y ago

TomSawyer 11y ago

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

Silhouette 11y ago
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.

sanderjd 11y ago

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.

mtberatwork 11y ago
> 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.

k__ 11y ago

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.

macspoofing 11y ago
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.
- k__ 11y ago
  Isn't it possible to do this incremental? FB has done it and I didn't feel a thing, besides some disappearing bugs.
  - evlapix 11y ago
    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.

matt_s 11y ago

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.

untog 11y ago
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.
- matt_s 11y ago
  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.

wvenable 11y ago

> 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 11y ago
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 11y ago
  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.

Silhouette 11y ago

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.