5 ms·

> Things haven’t settled down long enough for curriculums and guides to gel and mature, and for best practices to become authoritative for more than a few month

> Things haven’t settled down long enough for curriculums and guides to gel and mature, and for best practices to become authoritative for more than a few months... When you’re working with an ancient language like PHP, you Google a question or problem, and almost 100% of the time you will find a 5-year-old Stack Overflow answer that solves it... Not so much with modern JavaScript OK, so everything's changing all the time, everything you Google will be out of date, but it's worth it because... why, exactly? Node doesn't block on IO. OK, cool. But the Erlang VM doesn't block on IO, either, AND it's not single threaded, so you can actually do parallel computation if you need to. JS has a lot of raw speed these days. OK, cool. But raw speed is generally less important than good algorithms and parallelism, and if we really need raw speed in other languages, we can generally call out to C or something. Rust has a unique value proposition: safety and speed. Erlang/Elixir have one: supervision and easy parallelism. Ruby has one: well-worn tools for web development. I don't understand the value proposition for Javascript on the server, other than "hey, you already know Javascript, right?", to which the answer is "LOL I thought I did but apparently everything I know is wrong all the time". I think I'm going to sit out the Javascript frenzy until it's all very stable and Googling gets me answers that aren't So Last Week. And maybe we'll be writing Rust for browsers via WebAssembly by then, anyway.

nostrademons 10y ago
The value proposition is "You can use the same code on both the server and client" (in addition to "You already know Javascript"). That's a really big advantage in some cases. Think of collaborative editing (where you need to apply operational transforms on all clients + the server), or form validation, or game replay, or anything where you want to give real-time feedback to the user while also validating those operations on the server. If all you're doing is throwing HTML templates on top of CRUD results, then yeah, Node.js doesn't get you much. But there are other problem domains where you're basically forced into it. My first startup (WYSIWYG casual game creation) would've been much easier if Node had existed when I was working on it; I spent a ridiculous amount of time writing polyglot Javascript/Actionscript runtime libraries and server-side compilers that would spit back a blob of Javascript in an AJAX request.
- imron 10y ago
  > That's a really big advantage in some cases That will mostly disappear with WebAssembly, and then we can finally start using sane languages for front-end web development.
- romaniv 10y ago
  >The value proposition is "You can use the same code on both the server and client" With differences in standard libraries, environment specifics and even language features available, I think a far more accurate statement would be "you can sometimes use some code on both the server and client".
arvinsim 10y ago
I can relate. I have been working on the front endfor 8 years. I don't understand why people would want it for the back end when better alternatives exist.

nostrademons 10y ago

The value proposition is "You can use the same code on both the server and client" (in addition to "You already know Javascript"). That's a really big advantage in some cases. Think of collaborative editing (where you need to apply operational transforms on all clients + the server), or form validation, or game replay, or anything where you want to give real-time feedback to the user while also validating those operations on the server. If all you're doing is throwing HTML templates on top of CRUD results, then yeah, Node.js doesn't get you much. But there are other problem domains where you're basically forced into it. My first startup (WYSIWYG casual game creation) would've been much easier if Node had existed when I was working on it; I spent a ridiculous amount of time writing polyglot Javascript/Actionscript runtime libraries and server-side compilers that would spit back a blob of Javascript in an AJAX request.

imron 10y ago
> That's a really big advantage in some cases That will mostly disappear with WebAssembly, and then we can finally start using sane languages for front-end web development.
romaniv 10y ago
>The value proposition is "You can use the same code on both the server and client" With differences in standard libraries, environment specifics and even language features available, I think a far more accurate statement would be "you can sometimes use some code on both the server and client".

arvinsim 10y ago

I can relate. I have been working on the front endfor 8 years. I don't understand why people would want it for the back end when better alternatives exist.