4 ms·

Is Node.js declining already?

63 points by bemmu 11y ago

spoiledtechie 11y ago
Its nice to see the rise and inevitable fall of languages. It just shows how its good to use the fundamental pr stable languages over the hip ones. The hips ones cause you to pick up, put down, rinse and repeat. The fundamentals only build on top of experience. So I am happy to build up rather than rinse and repeat just because I already have to keep up with the technology space.
- bryanlarsen 11y ago
  Node.js is not a language. Node.js may be declining, but Javascript is not going anywhere anytime soon.
- cprogrammer1101 11y ago
  Absolutely. I sat out the Ruby/Rails hype cycle and am none the worse for it. Life is too short to waste time learning ephemeral tech like Ruby, Node.js, or MongoDB. When considering whether to learn a new language or platform, I ask myself, how long have people been using this, and how long will people likely continue to use it? As a result, I know C, Common Lisp/Elisp, UNIX/POSIX, and a relational database or two very, very well. I suspect I'd be much less happy if I had instead spent time learning how to build single-threaded JavaScript web apps that rely, in 2015, on cooperative multitasking, let alone doing so with other hipster programmers who actually think it's a good idea.
  - nwmcsween 11y ago
    Eh I disagree learning new languages can make you think in different ways. I know Ruby, Shell, C, Javascript and some OCaml and Haskell, each have taught me something that I apply to others.
    - cprogrammer1101 11y ago
      Ruby doesn't teach you anything if you already know Lisp + CLOS or Smalltalk.
  - freyr 11y ago
    I never bothered learning a newfangled, flavor-of-the-week language like C. As a result, I'm an expert in COBOL and Fortran. I suspect I'm much happier not knowing C.
    - cprogrammer1101 11y ago
      You know, you're right; there's no such thing as an ephemeral language or platform. Why, look at all new projects started every day in QBasic, Tcl, or Turbo Pascal. I'm sure people will be building stuff with Ruby forty years from now.
  - weeksie 11y ago
    The Ruby/Rails hype cycle started like ten years ago. Rails is one of the most widely used web app frameworks in the market. Ruby's been around for twenty-odd years and has gone from being a niche scripting language to one that's used to power an outrageous amount of big applications. It's not a pissing contest by any means, but calling Ruby and Rails a hype cycle is just inaccurate.
bryanlarsen 11y ago
It's not the cool new thing anymore, but it's definitely not going to go away. Its killer feature is that the same code can run on the client and the server. Not a big deal for most apps, but very important for some. Also, ES6 & ES7 make callback-heavy Javascript so much more pleasant to program in. That addresses Node's main pain point.
- duaneb 11y ago
  > That addresses Node's main pain point. You mean being single threaded?
  - supster 11y ago
    Well the call back hell which is a consequence of the event loop paradigm which is in turn due to being single threaded. But callbacks aren't a big deal with the intro of native Promises in ES6. And a lot of people (me included) find the event driven paradigm very useful for simple REST backends serving mobile apps.
    - freyr 11y ago
      I feel like if you make an effort to avoid callback hell, you can prevent it fairly easily. I don't know if I'm not writing complicated enough code, or everyone else is just bad at JavaScript.
  - bryanlarsen 11y ago
    Node's event driven design is also called "co-operative multi-threading", and is more efficient than OS threading. It is annoying that you have to use multiple processes or Web Workers to use more than one core, but that is far from being the main pain point.
    - stevewepay 11y ago
      >Node's event driven design is also called "co-operative multi-threading" I think you mean multi-tasking, not multi-threading. And isn't cooperative multi-tasking the Windows 3.1 model on DOS? Not sure how cooperative multitasking is better than OS threading. And am I mistaken, or is Node.js the same thing as Windows programming model from 1990 repackaged in Javascript? Windows programs have single message loop, and Windows events and you write callbacks that handle those particular events, like when a mouse clicks, when it moves, etc.
ourmandave 11y ago
My favorite line is the last line. A week is a long time in JavaScript.
deleted 11y ago
[deleted]
leeleelee 11y ago
I like to use python, flask, gunicorn, and nginx for back end apis. Now that I've been doing so much front end javascript programming, I'm looking into Node just because I'm way less efficient at writing python and more efficient at writing javascript nowadays. At least that's my personal decision criteria.
joeyspn 11y ago
In short, NO... Here's the proof: https://www.google.com/trends/explore#q=nodejs https://www.google.com/trends/explore#q=nodejs
- arbuge 11y ago
  PHP, on the other hand, seems to have been in a decline which has finally levelled out. https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt=q&tz= https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt... Note that this is on the same scale as node, which is no longer visible hugging the x-axis...
  - joeyspn 11y ago
    Well, not really a fair comparison... Javascript is also going down... https://www.google.com/trends/explore#q=php%2C%20javascript&cmpt=q&tz= https://www.google.com/trends/explore#q=php%2C%20javascript&... But like node, laravel is also on fire... https://www.google.com/trends/explore#q=nodejs%2C%20laravel https://www.google.com/trends/explore#q=nodejs%2C%20laravel
- bryanlarsen 11y ago
  But is that a lagging indicator? Peak manpower for a successful project comes well after a project starts. Node.js was hip a couple of years ago, and lots of projects got started using it, so it wouldn't be surprising if lots of people are being exposed to Node because they've been added to these projects. In the HN echo chamber, hip projects have moved on to Go micro-services. Outside the HN echo chamber, Rails is still hip.
- z1mm32m4n 11y ago
  Wow, I did not realize the difference in search volume of PHP vs nodejs.
  - babby 11y ago
    Thing is that node can be searched by "node" "nodejs" "node.js" thus the results will always be skewed by a single term like "PHP". When you think about it, PHP is not as high as you would expect in comparison.
aikah 11y ago
Nodejs is an excellent tool for front-end integration testing and asset pipelines that depend on js(LESS,coffeescript,babel and co). On the other, on the server, you can read many stories of startup that started with NodeJs and ended up with Go. NodeJs doesn't have any concurrency capability. Sure you can fork, but then you need a message queue for interprocess communication. And frankly while javascript's getting better, some people are a bit sick of dynamically typed languages and prefer static typed languages. How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable.
- LocalPCGuy 11y ago
  > How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable. If written correctly, neither of those questions should be an issue. 1) JS devs shouldn't have "large" JavaScript source files, like most good programs, they should be broken into small, concise pieces. 2) JS devs shouldn't use "ninja tricks" or other BS, they should write for the next person that reads the code, again, like any language. Yes, a lot of people still write bad JavaScript, but that is on them, not the language. It is pretty simple to write bery readable JavaScript if you so choose.
  - WorldWideWayne 11y ago
    The language and the environment are certainly at fault to a high degree due to the lack of standards. 1) Breaking JS up into small files actually makes it less readable because then you have to guess at the context that the JS is running in. Without static typing, it's impossible to reason about certain blocks of code without going to find blocks of code that exist in other files and so on... 2) JS devs have to use ninja tricks because without a strong standard library they have to keep reinventing the wheels that should have been included. There is no standard for how to write readable Javascript and there is too much flexibility. Isaacs, of Node.js fame, writes horribly unreadable code IMO due to the fact that he does not use semi-colons and he tends to put punctuation on the left. However, he swears by the fact that it's more readable...to him.
swang 11y ago
Remember when rails was a fad and no one was going to use it after the hype died down and nodejs became king? Oh those "hipsters"!!!
jeswin 11y ago
Node.JS's future is intricately tied to JavaScript the language itself and IMO we are still in the early days of Node.JS. The success of a language isn't about excelling individually at expressiveness, type-safety, widespread distribution, performance, tooling or ease-of-use; but about finding that sweet spot. JS is that compromise. I'll just list the strengths of Node and JS in general, in no particular order: - JavaScript was called "Java"Script for marketing. But the funny thing is that it has become the true "Write Once, Run Anywhere" alternative to Java. Including phones without installing additional software. And projects like React Native will take JS outside the browser into native apps. - JS has a monopoly in the browser. To build any web-app, you/team need to know JavaScript anyway. Having to use only one language is an advantage for many companies. For larger IT companies, this also dramatically cuts down their training expenses. - Very active community, perhaps the most active of any language ecosystem. What's remarkable is that the key people in standards and implementation bodies aren't operating on mailing lists alone, but work closely with product teams in their own companies and interact with the rest of the (very large) community through forums and social media. This has resulted in excellent prioritization of features and an active feedback loop. Also, peaking at a time when collaborating coding (GitHub) matured helped. (1) - NPM and Packages. There's a package for everything. We often hear people complaining about hundreds of npm packages downloaded per install. That's also the strength of NPM. Packages range from monolithic to tiny 20-line functions. The fine grained granularity of packages makes it a simple, anytime-revocable decision. - JS is a very expressive language like most dynamic languages are, but the years of performance wars by browser vendors have given it a significant lead. - Tooling is excellent. There even plenty of academic-style research going on, like FaceBook's Flow. - You could compile other languages down to JS. You can compile Doom to JS and play it inside a browser. (However, JS will retain that native-support advantage.) - ECMAScript 2015 fixes the big issues with JS. We can treat it like an entirely new language, and in time we can forget the good parts/bad parts discussion. - JS isn't trying to shoehorn performance into its expressive style. If you're using JS for performance critical work, you will be forced to use data-structures specifically designed for performance. If you need to operate at native-code levels of performance, you'd have to write code differently from the usual expressive and dynamic style. That's a fine compromise, it doesn't have to tread over the neither-here-nor-there territory. Also, pragmatic parallelism is coming (https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...). And perhaps the most important one: Wikipedia took off because it made collaboratively editing documents easy and doable with just the browser. If it required downloading and installing additional tools, it may have never achieved the same success. Now, the future will have more people who know programming than ever before. Like writing articles, they might build apps together. The true USP of JS isn't that it runs everywhere, but that browser vendors have shipped billions of debuggers. (1) Not saying other languages don't have vibrant, active communities.
JDDunn9 11y ago
Worth noting this was not the most voted answer. http://www.quora.com/Is-Node-js-declining-already http://www.quora.com/Is-Node-js-declining-already
mixmastamyk 11y ago
Could someone unpack and explain this answer snippet a bit? I personally do not believe that Node is a viable platform for building multi-user server logic. Node is great for asynchronicity, but that shouldn't be confused with concurrency* which is really what you want in those scenarios (I can write a list of things Node doesn't do well for building safe backend systems, but that's one example). The Node platform is very good for single-user applications (games, web apps, command line tools, "browserified" apps, Node+browser containers), but I think a lot of people will come to regret using it for bigger back-ends. A company I work with occasionally is building a backend and client system in node+mongo, and I wonder if it is a good idea. The backend will be an app catalog of sorts, while the client will run these apps, which will animate stuff in a browser. I've read lots of warnings about mongo, and now this. I'm torn about these choices, I've tried and liked them, but am a bit out of my element as primarily a python/c developer.
- ddebernardy 11y ago
  These articles on Node unpack the point to some extent: - http://stackoverflow.com/q/22644328/417194 http://stackoverflow.com/q/22644328/417194 - http://www.future-processing.pl/blog/on-problems-with-threads-in-node-js/ http://www.future-processing.pl/blog/on-problems-with-thread... - http://web.archive.org/web/20120911094357/http://dev.hasenj.org/post/31042963934/nodejs-hate http://web.archive.org/web/20120911094357/http://dev.hasenj.... - https://news.ycombinator.com/item?id=4495101 https://news.ycombinator.com/item?id=4495101
Lazare 11y ago
Node.js (ie server-side Javascript) will live and die with client-side Javascript. Right now we seem to be in a client-side JS boom. New frameworks are being written, adoption is up, React and friends are getting tons of buzz, build tools like webpack or transpilers like babel are making developer lives easier, NPM is seeing tons of traffic (much of it supporting client-side development, either directly or indirectly), we're starting to routinely prerender SPAs on the server, etc., And it all runs on node.js. (Good luck writing a serious React app without some node.js processes running at some point.) So I'd say we've yet to see peak node.js; it's still increasing in usage, and will likely do so for some time. Now, some people made some wild claims about node.js being the BEST EVER SERVER FRAMEWORK, with super amazing webscale performance. That was nonsense and lies. Node.js was never going going to sweep the world and be the One True Framework for writing servers in, and that's becoming increasingly apparent. It's not a terrible choice, but then, neither is Rails. Or C#. Or Python. Or hell, PHP. And people are going to keep writing servers in all of those languages and frameworks. If you listen to the hype, we went from Node.js being the BEST FOR PERFORMANCE to, I dunno, golang or something. And going from being the BEST to not even being talked about probably feels like a real decline. In the real world, Node.js went from a new and little used niche technology, to a slightly less new and very broadly used niche technology. That's not a decline at all.
- bradleyland 11y ago
  Great comment, and worth noting that many technologies go through this cycle. Those old enough to remember might note that once upon a time, Java was going to "change the world". Anyone who got their start in technology after 2000 really cannot appreciate how head over heels the tech world was over Java. Fast forward to today and the concept seems inconceivable. Java, a game changer? Oh yeah, majorly. If you stick around long enough, you see this play out over and over again. You learn not to get too worried over a lull in attention paid to your tools of choice.
ziles88 11y ago
You see waves of technology adoption based a lot on language barriers. We're seeing this with Larval right now in India/SE-Asia, we've seen it with VB6, then .NET into Russia/South-America, and we're just starting to see node.js picking up in China. People forget, documentation needs to be written, interpreted, then passed down through different channels, like programming communities, schools, person 2 person. This can take 4 years+. As soon as English speakers have mastered it, China is just starting to for example. Node is here to stay, and it's already at a point with decent enterprise adoption, meaning it's going to take a lot of money and time to reverse the trend.

63 points by bemmu 11y ago

Its nice to see the rise and inevitable fall of languages. It just shows how its good to use the fundamental pr stable languages over the hip ones. The hips ones cause you to pick up, put down, rinse and repeat. The fundamentals only build on top of experience. So I am happy to build up rather than rinse and repeat just because I already have to keep up with the technology space.

bryanlarsen 11y ago
Node.js is not a language. Node.js may be declining, but Javascript is not going anywhere anytime soon.
cprogrammer1101 11y ago
Absolutely. I sat out the Ruby/Rails hype cycle and am none the worse for it. Life is too short to waste time learning ephemeral tech like Ruby, Node.js, or MongoDB. When considering whether to learn a new language or platform, I ask myself, how long have people been using this, and how long will people likely continue to use it? As a result, I know C, Common Lisp/Elisp, UNIX/POSIX, and a relational database or two very, very well. I suspect I'd be much less happy if I had instead spent time learning how to build single-threaded JavaScript web apps that rely, in 2015, on cooperative multitasking, let alone doing so with other hipster programmers who actually think it's a good idea.
- nwmcsween 11y ago
  Eh I disagree learning new languages can make you think in different ways. I know Ruby, Shell, C, Javascript and some OCaml and Haskell, each have taught me something that I apply to others.
  - cprogrammer1101 11y ago
    Ruby doesn't teach you anything if you already know Lisp + CLOS or Smalltalk.
- freyr 11y ago
  I never bothered learning a newfangled, flavor-of-the-week language like C. As a result, I'm an expert in COBOL and Fortran. I suspect I'm much happier not knowing C.
  - cprogrammer1101 11y ago
    You know, you're right; there's no such thing as an ephemeral language or platform. Why, look at all new projects started every day in QBasic, Tcl, or Turbo Pascal. I'm sure people will be building stuff with Ruby forty years from now.
- weeksie 11y ago
  The Ruby/Rails hype cycle started like ten years ago. Rails is one of the most widely used web app frameworks in the market. Ruby's been around for twenty-odd years and has gone from being a niche scripting language to one that's used to power an outrageous amount of big applications. It's not a pissing contest by any means, but calling Ruby and Rails a hype cycle is just inaccurate.

bryanlarsen 11y ago

It's not the cool new thing anymore, but it's definitely not going to go away. Its killer feature is that the same code can run on the client and the server. Not a big deal for most apps, but very important for some. Also, ES6 & ES7 make callback-heavy Javascript so much more pleasant to program in. That addresses Node's main pain point.

duaneb 11y ago
> That addresses Node's main pain point. You mean being single threaded?
- supster 11y ago
  Well the call back hell which is a consequence of the event loop paradigm which is in turn due to being single threaded. But callbacks aren't a big deal with the intro of native Promises in ES6. And a lot of people (me included) find the event driven paradigm very useful for simple REST backends serving mobile apps.
  - freyr 11y ago
    I feel like if you make an effort to avoid callback hell, you can prevent it fairly easily. I don't know if I'm not writing complicated enough code, or everyone else is just bad at JavaScript.
- bryanlarsen 11y ago
  Node's event driven design is also called "co-operative multi-threading", and is more efficient than OS threading. It is annoying that you have to use multiple processes or Web Workers to use more than one core, but that is far from being the main pain point.
  - stevewepay 11y ago
    >Node's event driven design is also called "co-operative multi-threading" I think you mean multi-tasking, not multi-threading. And isn't cooperative multi-tasking the Windows 3.1 model on DOS? Not sure how cooperative multitasking is better than OS threading. And am I mistaken, or is Node.js the same thing as Windows programming model from 1990 repackaged in Javascript? Windows programs have single message loop, and Windows events and you write callbacks that handle those particular events, like when a mouse clicks, when it moves, etc.

ourmandave 11y ago

My favorite line is the last line. A week is a long time in JavaScript.

deleted 11y ago

[deleted]

leeleelee 11y ago

I like to use python, flask, gunicorn, and nginx for back end apis. Now that I've been doing so much front end javascript programming, I'm looking into Node just because I'm way less efficient at writing python and more efficient at writing javascript nowadays. At least that's my personal decision criteria.

joeyspn 11y ago

In short, NO... Here's the proof: https://www.google.com/trends/explore#q=nodejs https://www.google.com/trends/explore#q=nodejs

arbuge 11y ago
PHP, on the other hand, seems to have been in a decline which has finally levelled out. https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt=q&tz= https://www.google.com/trends/explore#q=nodejs%2C%20php&cmpt... Note that this is on the same scale as node, which is no longer visible hugging the x-axis...
- joeyspn 11y ago
  Well, not really a fair comparison... Javascript is also going down... https://www.google.com/trends/explore#q=php%2C%20javascript&cmpt=q&tz= https://www.google.com/trends/explore#q=php%2C%20javascript&... But like node, laravel is also on fire... https://www.google.com/trends/explore#q=nodejs%2C%20laravel https://www.google.com/trends/explore#q=nodejs%2C%20laravel
bryanlarsen 11y ago
But is that a lagging indicator? Peak manpower for a successful project comes well after a project starts. Node.js was hip a couple of years ago, and lots of projects got started using it, so it wouldn't be surprising if lots of people are being exposed to Node because they've been added to these projects. In the HN echo chamber, hip projects have moved on to Go micro-services. Outside the HN echo chamber, Rails is still hip.
z1mm32m4n 11y ago
Wow, I did not realize the difference in search volume of PHP vs nodejs.
- babby 11y ago
  Thing is that node can be searched by "node" "nodejs" "node.js" thus the results will always be skewed by a single term like "PHP". When you think about it, PHP is not as high as you would expect in comparison.

aikah 11y ago

Nodejs is an excellent tool for front-end integration testing and asset pipelines that depend on js(LESS,coffeescript,babel and co). On the other, on the server, you can read many stories of startup that started with NodeJs and ended up with Go. NodeJs doesn't have any concurrency capability. Sure you can fork, but then you need a message queue for interprocess communication. And frankly while javascript's getting better, some people are a bit sick of dynamically typed languages and prefer static typed languages. How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable.

LocalPCGuy 11y ago
> How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable. If written correctly, neither of those questions should be an issue. 1) JS devs shouldn't have "large" JavaScript source files, like most good programs, they should be broken into small, concise pieces. 2) JS devs shouldn't use "ninja tricks" or other BS, they should write for the next person that reads the code, again, like any language. Yes, a lot of people still write bad JavaScript, but that is on them, not the language. It is pretty simple to write bery readable JavaScript if you so choose.
- WorldWideWayne 11y ago
  The language and the environment are certainly at fault to a high degree due to the lack of standards. 1) Breaking JS up into small files actually makes it less readable because then you have to guess at the context that the JS is running in. Without static typing, it's impossible to reason about certain blocks of code without going to find blocks of code that exist in other files and so on... 2) JS devs have to use ninja tricks because without a strong standard library they have to keep reinventing the wheels that should have been included. There is no standard for how to write readable Javascript and there is too much flexibility. Isaacs, of Node.js fame, writes horribly unreadable code IMO due to the fact that he does not use semi-colons and he tends to put punctuation on the left. However, he swears by the fact that it's more readable...to him.

swang 11y ago

Remember when rails was a fad and no one was going to use it after the hype died down and nodejs became king? Oh those "hipsters"!!!

jeswin 11y ago

Node.JS's future is intricately tied to JavaScript the language itself and IMO we are still in the early days of Node.JS. The success of a language isn't about excelling individually at expressiveness, type-safety, widespread distribution, performance, tooling or ease-of-use; but about finding that sweet spot. JS is that compromise. I'll just list the strengths of Node and JS in general, in no particular order: - JavaScript was called "Java"Script for marketing. But the funny thing is that it has become the true "Write Once, Run Anywhere" alternative to Java. Including phones without installing additional software. And projects like React Native will take JS outside the browser into native apps. - JS has a monopoly in the browser. To build any web-app, you/team need to know JavaScript anyway. Having to use only one language is an advantage for many companies. For larger IT companies, this also dramatically cuts down their training expenses. - Very active community, perhaps the most active of any language ecosystem. What's remarkable is that the key people in standards and implementation bodies aren't operating on mailing lists alone, but work closely with product teams in their own companies and interact with the rest of the (very large) community through forums and social media. This has resulted in excellent prioritization of features and an active feedback loop. Also, peaking at a time when collaborating coding (GitHub) matured helped. (1) - NPM and Packages. There's a package for everything. We often hear people complaining about hundreds of npm packages downloaded per install. That's also the strength of NPM. Packages range from monolithic to tiny 20-line functions. The fine grained granularity of packages makes it a simple, anytime-revocable decision. - JS is a very expressive language like most dynamic languages are, but the years of performance wars by browser vendors have given it a significant lead. - Tooling is excellent. There even plenty of academic-style research going on, like FaceBook's Flow. - You could compile other languages down to JS. You can compile Doom to JS and play it inside a browser. (However, JS will retain that native-support advantage.) - ECMAScript 2015 fixes the big issues with JS. We can treat it like an entirely new language, and in time we can forget the good parts/bad parts discussion. - JS isn't trying to shoehorn performance into its expressive style. If you're using JS for performance critical work, you will be forced to use data-structures specifically designed for performance. If you need to operate at native-code levels of performance, you'd have to write code differently from the usual expressive and dynamic style. That's a fine compromise, it doesn't have to tread over the neither-here-nor-there territory. Also, pragmatic parallelism is coming (https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...). And perhaps the most important one: Wikipedia took off because it made collaboratively editing documents easy and doable with just the browser. If it required downloading and installing additional tools, it may have never achieved the same success. Now, the future will have more people who know programming than ever before. Like writing articles, they might build apps together. The true USP of JS isn't that it runs everywhere, but that browser vendors have shipped billions of debuggers. (1) Not saying other languages don't have vibrant, active communities.

JDDunn9 11y ago

Worth noting this was not the most voted answer. http://www.quora.com/Is-Node-js-declining-already http://www.quora.com/Is-Node-js-declining-already

mixmastamyk 11y ago

Could someone unpack and explain this answer snippet a bit? I personally do not believe that Node is a viable platform for building multi-user server logic. Node is great for asynchronicity, but that shouldn't be confused with concurrency* which is really what you want in those scenarios (I can write a list of things Node doesn't do well for building safe backend systems, but that's one example). The Node platform is very good for single-user applications (games, web apps, command line tools, "browserified" apps, Node+browser containers), but I think a lot of people will come to regret using it for bigger back-ends. A company I work with occasionally is building a backend and client system in node+mongo, and I wonder if it is a good idea. The backend will be an app catalog of sorts, while the client will run these apps, which will animate stuff in a browser. I've read lots of warnings about mongo, and now this. I'm torn about these choices, I've tried and liked them, but am a bit out of my element as primarily a python/c developer.

ddebernardy 11y ago
These articles on Node unpack the point to some extent: - http://stackoverflow.com/q/22644328/417194 http://stackoverflow.com/q/22644328/417194 - http://www.future-processing.pl/blog/on-problems-with-threads-in-node-js/ http://www.future-processing.pl/blog/on-problems-with-thread... - http://web.archive.org/web/20120911094357/http://dev.hasenj.org/post/31042963934/nodejs-hate http://web.archive.org/web/20120911094357/http://dev.hasenj.... - https://news.ycombinator.com/item?id=4495101 https://news.ycombinator.com/item?id=4495101

Lazare 11y ago

Node.js (ie server-side Javascript) will live and die with client-side Javascript. Right now we seem to be in a client-side JS boom. New frameworks are being written, adoption is up, React and friends are getting tons of buzz, build tools like webpack or transpilers like babel are making developer lives easier, NPM is seeing tons of traffic (much of it supporting client-side development, either directly or indirectly), we're starting to routinely prerender SPAs on the server, etc., And it all runs on node.js. (Good luck writing a serious React app without some node.js processes running at some point.) So I'd say we've yet to see peak node.js; it's still increasing in usage, and will likely do so for some time. Now, some people made some wild claims about node.js being the BEST EVER SERVER FRAMEWORK, with super amazing webscale performance. That was nonsense and lies. Node.js was never going going to sweep the world and be the One True Framework for writing servers in, and that's becoming increasingly apparent. It's not a terrible choice, but then, neither is Rails. Or C#. Or Python. Or hell, PHP. And people are going to keep writing servers in all of those languages and frameworks. If you listen to the hype, we went from Node.js being the BEST FOR PERFORMANCE to, I dunno, golang or something. And going from being the BEST to not even being talked about probably feels like a real decline. In the real world, Node.js went from a new and little used niche technology, to a slightly less new and very broadly used niche technology. That's not a decline at all.

bradleyland 11y ago
Great comment, and worth noting that many technologies go through this cycle. Those old enough to remember might note that once upon a time, Java was going to "change the world". Anyone who got their start in technology after 2000 really cannot appreciate how head over heels the tech world was over Java. Fast forward to today and the concept seems inconceivable. Java, a game changer? Oh yeah, majorly. If you stick around long enough, you see this play out over and over again. You learn not to get too worried over a lull in attention paid to your tools of choice.

ziles88 11y ago

You see waves of technology adoption based a lot on language barriers. We're seeing this with Larval right now in India/SE-Asia, we've seen it with VB6, then .NET into Russia/South-America, and we're just starting to see node.js picking up in China. People forget, documentation needs to be written, interpreted, then passed down through different channels, like programming communities, schools, person 2 person. This can take 4 years+. As soon as English speakers have mastered it, China is just starting to for example. Node is here to stay, and it's already at a point with decent enterprise adoption, meaning it's going to take a lot of money and time to reverse the trend.