10 ms·

While there was some hype about Node, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with 0.12 and then

While there was some hype about Node, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with 0.12 and then 1.0 coming quite soon. While I tried getting into Go, and initially didn't like it but wanted to like it. Seems like the more I read about it, the more I get into it, the less I like it. Which kinda sucks, Go seems like a powerful platform.

octo_t 13y ago
people said/saying the same thing about ruby/RoR too. "While there was some hype about Rails, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with Ruby 2.0 and then Rails 4.0 coming quite soon." is a thing someone could have easily said on this site in January 2013.
- rtpg 13y ago
  Isn't this still pretty true? I've seen a lot of job offers for RoR (granted, when looking in Japan it might be biased). Just because it's not Java-sized doesn't mean the community isn't there.
- rpedela 13y ago
  Yeah, but Node.js actually has a valid use-case: code that needs to be non-blocking. Most of the time, you want web servers to behave that way. Yes you can do that in other languages/frameworks, but Node.js is the only one with an ecosystem where most modules are also non-blocking by default. If you look at the languages/frameworks that have survived their initial hype, it is almost always ones where there is a use-case that the language/framework uniquely solves well. C/C++: Easier than most of the other low-level languages. Used when performance and/or memory management are critical: kernel, database, embedded system, etc. BASH: Dammit, I just need a script that executes five commands in a row! PYTHON: A scripting language that properly handles gigantic numbers and seamlessly integrates with R. The scientists love it! And the list goes on. Of course those languages have other use cases, but the point is that they all have at least one use case that they are the best at. However only time will tell if Node.js ends up being the non-blocking scripting language or something else will take its place.
  - asdasf 13y ago
    What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actually caring about concurrency like erlang and haskell have forever, node is a throwback to the error prone and convoluted event loops of C. Go is far better for the very use case you think node excels at.
    - rdtsc 13y ago
      I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.
    - rpedela 13y ago
      Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.
- general_failure 13y ago
  So you are saying ror was a fad? Honest question
epo 13y ago
Oh please. Come back in 10 or 20 years time and say it is not a fad. Technology cycles are getting so compressed that everything is a fad now. The whole thing being fuelled by the immature and inexperienced who know nothing about the past and consequently think they have nothing to learn from it.
- threeseed 13y ago
  Our industry could really do without this type of condescending, unhelpful attitude. Big deal. Concepts are being repeated and technology stacks are stealing ideas from one another. Remind me again how that is a bad thing ? The fact is that there is no perfect solution to every problem.
  - deleted 13y ago
    [deleted]
  - Peaker 13y ago
    Concepts and good ideas being repeated and stolen is great! However, the problem is repeating mistakes. Go's nullability, lack of generics, ... Node doing manual CPS where past work (e.g: Haskell) does non-blocking IO without forcing manual CPS on the programmer. It would be nice if we learned not to repeat past mistakes...
    - jaegerpicker 13y ago
      The problem lies in that not everyone agrees on what are mistakes and what isn't. I know a lot of go programmers who do not want generics. Many also disagree that manual CPS is a mistake.
      - Peaker 13y ago
        I think the majority of people who disagree that nullability everywhere is a mistake, as an example, are people who've only ever used languages that had that bug.
- 13y ago
CmonDev 13y ago
Here is some Node.js anti-hype: http://pages.citebite.com/b2x0j8q1megb http://pages.citebite.com/b2x0j8q1megb
- nakkiel 13y ago
  The best part of it: if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put Rasmus Lerdorf to shame }
  - Touche 13y ago
    No one does that any more. if(my_var != null) { }
    - snarkyturtle 13y ago
      Or they just use lodash/underscore which takes care of it for you.
      - Touche 13y ago
        Using a library to avoid typing !=null seems like overkill.
        snarkyturtle 13y ago
        It's more for handling all those js quirks with equality, though yeah if it's your var, you'll probably be fine with != null (though jshint probably won't like it)
- wcummings 13y ago
  I'm not a huge node fan, but these are some weak criticisms. Not sure "CGI" is really appropriate for all tasks.
  - rdtsc 13y ago

octo_t 13y ago

people said/saying the same thing about ruby/RoR too. "While there was some hype about Rails, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with Ruby 2.0 and then Rails 4.0 coming quite soon." is a thing someone could have easily said on this site in January 2013.

rtpg 13y ago
Isn't this still pretty true? I've seen a lot of job offers for RoR (granted, when looking in Japan it might be biased). Just because it's not Java-sized doesn't mean the community isn't there.
rpedela 13y ago
Yeah, but Node.js actually has a valid use-case: code that needs to be non-blocking. Most of the time, you want web servers to behave that way. Yes you can do that in other languages/frameworks, but Node.js is the only one with an ecosystem where most modules are also non-blocking by default. If you look at the languages/frameworks that have survived their initial hype, it is almost always ones where there is a use-case that the language/framework uniquely solves well. C/C++: Easier than most of the other low-level languages. Used when performance and/or memory management are critical: kernel, database, embedded system, etc. BASH: Dammit, I just need a script that executes five commands in a row! PYTHON: A scripting language that properly handles gigantic numbers and seamlessly integrates with R. The scientists love it! And the list goes on. Of course those languages have other use cases, but the point is that they all have at least one use case that they are the best at. However only time will tell if Node.js ends up being the non-blocking scripting language or something else will take its place.
- asdasf 13y ago
  What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actually caring about concurrency like erlang and haskell have forever, node is a throwback to the error prone and convoluted event loops of C. Go is far better for the very use case you think node excels at.
  - rdtsc 13y ago
    I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.
  - rpedela 13y ago
    Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.
general_failure 13y ago
So you are saying ror was a fad? Honest question

epo 13y ago

Oh please. Come back in 10 or 20 years time and say it is not a fad. Technology cycles are getting so compressed that everything is a fad now. The whole thing being fuelled by the immature and inexperienced who know nothing about the past and consequently think they have nothing to learn from it.

threeseed 13y ago
Our industry could really do without this type of condescending, unhelpful attitude. Big deal. Concepts are being repeated and technology stacks are stealing ideas from one another. Remind me again how that is a bad thing ? The fact is that there is no perfect solution to every problem.
- deleted 13y ago
  [deleted]
- Peaker 13y ago
  Concepts and good ideas being repeated and stolen is great! However, the problem is repeating mistakes. Go's nullability, lack of generics, ... Node doing manual CPS where past work (e.g: Haskell) does non-blocking IO without forcing manual CPS on the programmer. It would be nice if we learned not to repeat past mistakes...
  - jaegerpicker 13y ago
    The problem lies in that not everyone agrees on what are mistakes and what isn't. I know a lot of go programmers who do not want generics. Many also disagree that manual CPS is a mistake.
    - Peaker 13y ago
      I think the majority of people who disagree that nullability everywhere is a mistake, as an example, are people who've only ever used languages that had that bug.
13y ago

CmonDev 13y ago

Here is some Node.js anti-hype: http://pages.citebite.com/b2x0j8q1megb http://pages.citebite.com/b2x0j8q1megb

nakkiel 13y ago
The best part of it: if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put Rasmus Lerdorf to shame }
- Touche 13y ago
  No one does that any more. if(my_var != null) { }
  - snarkyturtle 13y ago
    Or they just use lodash/underscore which takes care of it for you.
    - Touche 13y ago
      Using a library to avoid typing !=null seems like overkill.
      - snarkyturtle 13y ago
        It's more for handling all those js quirks with equality, though yeah if it's your var, you'll probably be fine with != null (though jshint probably won't like it)
wcummings 13y ago
I'm not a huge node fan, but these are some weak criticisms. Not sure "CGI" is really appropriate for all tasks.
- rdtsc 13y ago