4 ms·

JavaScript code is basically obsolete as soon as it is written... In that context 18 months might be a long time. Edit: I probably wasn't clear enough that I w

by jannes 8y ago

JavaScript code is basically obsolete as soon as it is written... In that context 18 months might be a long time. Edit: I probably wasn't clear enough that I was joking. Edit 2: I also found out that the LTS release should receive 30 months of maintenance. They say that end of life for node 10 will be April 2021.

scandox 8y ago
Well I have JS code that was written in 2005 that I know is still running in production. Even with Nodejs I have code running that is more than 6 years old happily doing useful stuff. So I'm not sure I understand your comment.
- jannes 8y ago
  I wasn't entirely serious. There is just a lot of churn in the library/framework space for JS. There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. If you don't use npm and only rely on the builtin node APIs this would not apply to you as much, though. On top of that there are always new language features being introduced to EcmaScript and implemented in V8. This means that if you're not using those latest features, some might say your code is outdated.
  - scandox 8y ago
    Yeah sorry sense of humour failure on my part
  - fenomas 8y ago
    > There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. Complaints like this always mystify me. Would things be better if what you describe wasn't the case?
  - adrianhel 8y ago
    There was a lot of churn in JS. Things have gotten pretty damn stable. I usually use Express(2010), Socket.io(2014) and React(2013) for new projects. The libraries that break with new versions are the ones that rely on exotic features.
qaq 8y ago
? I work on large enterprise app in node there is code that was written 5 years ago and still works fine with 0 changes so not sure "JavaScript code is basically obsolete as soon as it is written" is applicable on the server side.
- koolba 8y ago
  I’m a huge fan of Node.js, particularly in the enterprise, but I question your “0 changes...” claim. At the very least you’ll have to update dependencies to deal with breaks on their part due to upgrades.
  - nevi-me 8y ago
    As someone who has a fairly large codebase that's been largely untouched for 3-4 years, I'd disagree. Nothing has stopped me from updating some ancient dependencies. Perhaps we should make a difference between Node and semver-major library changes
  - qaq 8y ago
    Honestly I am not a big fan of Node but we do have huge subsystems written in node that have not been touched literally for that long.
  - Klathmon 8y ago
    it depends on how well engineered the application is, like anything. I've been working on react-native recently, and this is by far the most difficult "framework" (or system, or library, or whatever else you want to call it) i've ever had to work with regarding dependencies. Every. single. change. breaks. And it seems to have deep dependencies on exact versions of many other tools, and changing them causes all kinds of hell. It's awful, and it's what I see as "dependency hell". We are like 5 patch versions behind latest right now, but every other patch version between ours and current either won't build on one platform, won't start due to mismatched dependencies, requires an alpha version of react proper, or breaks all of our tests. But before that i've worked on at least a dozen mid-sized+ node and browser based projects, and i've never had major issues with upgrades. For the most part they work if you stay within patch or minor versions, and even major upgrades only really hurt if you are impacted by the breakage, which in my experience is pretty rare (just looking at one monorepo-style project that has about 150 direct dependencies, i would probably spend about 2 hours a month on keeping them up to date, and just for fun, i went back to a commit from 3 years ago just now, and it still installs and runs fine. If you stick to documented features, don't try to abuse or be clever with interfaces that aren't well defined, wrap any "iffy" libraries in your own interfaces to make switching or re-implementing them easier, and overall vet your deps a bit before installing them, it's pretty smooth sailing.
tobyhinloopen 8y ago
I think you're confused with javascript frameworks. Just vanilla NodeJS & "BrowserJS" is mostly backwards compatible. Old stuff that worked 10 years ago still mostly works fine. 2008 BrowserJS still works in today's browsers. 2012 NodeJS code still works today (look at this v0.10.48 NodeJS docs for example: https://nodejs.org/docs/latest-v0.10.x/api/http.html https://nodejs.org/docs/latest-v0.10.x/api/http.html )
tannhaeuser 8y ago
To the contrary, JavaScript is one of the most portable and backward-compatible languages of all time. Portability and long-term maintenance on node.js is excellent if you stick to long-term development practices (commonjs, es5) and few core packages such as express.js. The only weak spot I encountered were subtle changes in error handling such as removal of auto-cleaning of resources with domain.dispose() back in v0.12 or v4 or so, and the somewhat unclear deprecation status of exception domains or the error handling/cleanup story in general, resp.

by jannes 8y ago

scandox 8y ago

Well I have JS code that was written in 2005 that I know is still running in production. Even with Nodejs I have code running that is more than 6 years old happily doing useful stuff. So I'm not sure I understand your comment.

jannes 8y ago
I wasn't entirely serious. There is just a lot of churn in the library/framework space for JS. There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. If you don't use npm and only rely on the builtin node APIs this would not apply to you as much, though. On top of that there are always new language features being introduced to EcmaScript and implemented in V8. This means that if you're not using those latest features, some might say your code is outdated.
- scandox 8y ago
  Yeah sorry sense of humour failure on my part
- fenomas 8y ago
  > There are constantly people trying to invent "like X but better", where X can be absolutely anything in your JS workflow. Complaints like this always mystify me. Would things be better if what you describe wasn't the case?
- adrianhel 8y ago
  There was a lot of churn in JS. Things have gotten pretty damn stable. I usually use Express(2010), Socket.io(2014) and React(2013) for new projects. The libraries that break with new versions are the ones that rely on exotic features.

qaq 8y ago

? I work on large enterprise app in node there is code that was written 5 years ago and still works fine with 0 changes so not sure "JavaScript code is basically obsolete as soon as it is written" is applicable on the server side.

koolba 8y ago
I’m a huge fan of Node.js, particularly in the enterprise, but I question your “0 changes...” claim. At the very least you’ll have to update dependencies to deal with breaks on their part due to upgrades.
- nevi-me 8y ago
  As someone who has a fairly large codebase that's been largely untouched for 3-4 years, I'd disagree. Nothing has stopped me from updating some ancient dependencies. Perhaps we should make a difference between Node and semver-major library changes
- qaq 8y ago
  Honestly I am not a big fan of Node but we do have huge subsystems written in node that have not been touched literally for that long.
- Klathmon 8y ago
  it depends on how well engineered the application is, like anything. I've been working on react-native recently, and this is by far the most difficult "framework" (or system, or library, or whatever else you want to call it) i've ever had to work with regarding dependencies. Every. single. change. breaks. And it seems to have deep dependencies on exact versions of many other tools, and changing them causes all kinds of hell. It's awful, and it's what I see as "dependency hell". We are like 5 patch versions behind latest right now, but every other patch version between ours and current either won't build on one platform, won't start due to mismatched dependencies, requires an alpha version of react proper, or breaks all of our tests. But before that i've worked on at least a dozen mid-sized+ node and browser based projects, and i've never had major issues with upgrades. For the most part they work if you stay within patch or minor versions, and even major upgrades only really hurt if you are impacted by the breakage, which in my experience is pretty rare (just looking at one monorepo-style project that has about 150 direct dependencies, i would probably spend about 2 hours a month on keeping them up to date, and just for fun, i went back to a commit from 3 years ago just now, and it still installs and runs fine. If you stick to documented features, don't try to abuse or be clever with interfaces that aren't well defined, wrap any "iffy" libraries in your own interfaces to make switching or re-implementing them easier, and overall vet your deps a bit before installing them, it's pretty smooth sailing.

tobyhinloopen 8y ago

I think you're confused with javascript frameworks. Just vanilla NodeJS & "BrowserJS" is mostly backwards compatible. Old stuff that worked 10 years ago still mostly works fine. 2008 BrowserJS still works in today's browsers. 2012 NodeJS code still works today (look at this v0.10.48 NodeJS docs for example: https://nodejs.org/docs/latest-v0.10.x/api/http.html https://nodejs.org/docs/latest-v0.10.x/api/http.html )

tannhaeuser 8y ago

To the contrary, JavaScript is one of the most portable and backward-compatible languages of all time. Portability and long-term maintenance on node.js is excellent if you stick to long-term development practices (commonjs, es5) and few core packages such as express.js. The only weak spot I encountered were subtle changes in error handling such as removal of auto-cleaning of resources with domain.dispose() back in v0.12 or v4 or so, and the somewhat unclear deprecation status of exception domains or the error handling/cleanup story in general, resp.