10 ms·

Why on Earth people who aren't merely enthusiasts of "cool async JavaScript with V8" or those who began as a webdevs and knows nothing better than JS and PHP, c

Why on Earth people who aren't merely enthusiasts of "cool async JavaScript with V8" or those who began as a webdevs and knows nothing better than JS and PHP, could choose a single-threaded solution, which blocks the whole app if a single function blocks, and forces programmers to write spaghetti wrappers around asynchronous call-back hells in a non-functional but GC'ed language? I am really too stupid to get it. "Single language for a whole stack" is a pretty stupid Java-sque argument, a naive assumption that one single language is good for all kinds of tasks.

cmicali 12y ago
One argument for one language everywhere is the benefits you get from an "isomorphic" app (http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app...) Sharing code between client and server lets reduce duplication and use the same templating/rendering on both sides. Fits very well with complex single-page apps. That said, I'm not sure there are that many apps that really need this vs. the tradeoffs you have to make going all-in on JS and the complexity this can bring.
- JetSpiegel 12y ago
  Correct use of the scare quotes there.
- nwienert 12y ago
  What complexity does it bring? I'm writing apps from the ground up using React and I've found the isomorphic bits take <10 lines of code as long as you design for it from the start.
- codygman 12y ago
  Thanks for putting isomorphic in quotes.
  - magicalist 12y ago
    I don't know why it bothers me so much, but it really does. What happened to just saying that the same code is run on the client and server? Avoids the jargon, doesn't make math nerds mad, isn't that much longer, and says exactly what you mean.
matchu 12y ago
Node supports parallel processes (granted, not threads), promises are a nice alternative to nested callbacks, and Javascript supports basic functional style. You've named some legitimate challenges of Javascript, all of which have been addressed in some capacity.
truncate 12y ago
I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.
- nwienert 12y ago
  I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.
  - adamors 12y ago
    Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.
    - nwienert 12y ago
      Oh well, at this point we're moving into subjective opinion. But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it. And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading. I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional. [1] https://github.com/gaearon/react-hot-loader https://github.com/gaearon/react-hot-loader
WorldWideWayne 12y ago
It's not, but having a single language to glue together all of the other ones is a pretty good idea. That's what I use Node for. With the addition of Edge.js I can run any .NET language right in the same runtime as Javascript (or, run Node inside my .NET app).
CitizenKane 12y ago
It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js(https://github.com/cujojs/when https://github.com/cujojs/when), q (https://github.com/kriskowal/q https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird). Not to mention the Async library (https://github.com/caolan/async https://github.com/caolan/async) which is full of tools to help manage it. As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.
- jbergens 12y ago
  Actually I think that even a lot of CPU intensive tasks could run on Node. Split them into smaller tasks (which you probably have to do anyway if you want to use multiple threads with another language) and run those as promises. Of course js is bad for most numerical calculation but for some things it might work. Or combine it with Dart or Asm.js.
  - tracker1 12y ago
    You can also use multiple worker processes for your more intensive cpu tasks, keeping that out of your main loop altogether. Pooling and queue limits can prevent too many of those bound processes from running at once, and you can distribute workers across several systems.
- kxo 12y ago
  > Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution Here's the answer: Spawn $(nproc) more Node processes, use IPC if you need to. Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.
woah 12y ago
If you have callback hell, it is an expression of muddled thought. If you have broken your code up into small enough modules and functions, and you know which tasks depend on other tasks, you will not have callback hell. If you are unclear on the logic of your code, you can often make it work in a messy way with the "laundry list approach". This involves formulating a sequence of tasks that happens to work, without needing to understand the actual dependencies. Many synchronous languages facilitate a laundry list approach, as their inefficient blocking paradigm removes the need to formulate the laundry list as a sequence of nested callbacks. It's still messy code.
- gasping 12y ago
  > If you have callback hell, it is an expression of muddled thought. No. It's an indication that you're using a FOTM runtime environment. There's a reason why no production-ready runtime uses continous passing / callback models.
  - woah 12y ago
    I know a lot of people running node in production, and getting very high performance out of it. It may anger hacker news that such a thing is even possible, but there you have it.
  - kxo 12y ago
    Really? How do you suppose nginx does it? Or any of the other top-end (in requests/sec) webservers? Hint: they aren't utilizing green threading and/or a scheduler.
tracker1 12y ago
With node, you can run multiple processes per server... the challenges of inter-process communication really aren't any harder, and are very similar to when you have to scale to multiple systems anyway. As for blocking, if you are doing something that is blocking in your main event-loop, you're probably doing something wrong. Break it off into a req/res queue and let it flow. Regarding call-back hell... you have next-generation tooling like co/koa as well as ES6 Promise patterns you can use. Not to mention the async library. You can readily follow functional patterns in JS and Node... just because there is prototype based inheritance doesn't mean you need to use it, and most of the time, I don't. Also, Node itself isn't really single-threaded... the main event loop is, which is where your JS code runs. The underlying platform calls are running against a thread pool.
kxo 12y ago
> choose a single-threaded solution For stateless web requests (solving the C10x problem), this is not inherently bad for most applications. > which blocks the whole app if a single function blocks This is behavior you'll see in many other languages. Management of execution time is very prevalent in lower-level languages. The only languages not susceptible to this problem are high-level, preemption-capable, and possess some form of green threading/scheduler e.g. Erlang/Elixir. IMO, if you need to rely on a scheduler to help ensure that blocking doesn't occur in a disruptive fashion, you're in no position to deride those who "began as a webdevs and knows nothing better." > asynchronous call-back hells This is a matter of taste, opinion, and necessity. I personally hold the opinion that "callback hell" is a symptom of poor design, and properly managed callbacks are not unpleasant to work with (I may be subject to Stockholm Syndrome). Also, try implementing an equivalent non-blocking webserver around an event loop in a lower-level language and let me know what non-callback strategies you come up with for the coalescence of asynchronous events. As an aside, there are hundreds of different ways to improve or eliminate the composition of callbacks in JS: emulated coroutines via generators, C#-style implementations of async/await, promises, the list goes on. > non-functional but GC'ed language Which functional programming languages in common use aren't garbage collected? (again: in common use) Which other common, productive, high-level programming languages (often tasked for C10K web servers) aren't garbage collected? What does "non-functional but GC'ed" actually mean? What does the language's programming paradigm have to do with its memory management model in this context? > I am really too stupid to get it - People are productive and enjoy JavaScript. - Browsers, by and large, only run JavaScript code. - JavaScript on the server-side is a very capable, battle-tested building block for performant web software. - Admittedly: JavaScript is not a great language when compared to other modern programming languages. - Aforementioned opinionated gotchas aren't enough to dissuade communities from using JS.

cmicali 12y ago

One argument for one language everywhere is the benefits you get from an "isomorphic" app (http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app...) Sharing code between client and server lets reduce duplication and use the same templating/rendering on both sides. Fits very well with complex single-page apps. That said, I'm not sure there are that many apps that really need this vs. the tradeoffs you have to make going all-in on JS and the complexity this can bring.

JetSpiegel 12y ago
Correct use of the scare quotes there.
nwienert 12y ago
What complexity does it bring? I'm writing apps from the ground up using React and I've found the isomorphic bits take <10 lines of code as long as you design for it from the start.
codygman 12y ago
Thanks for putting isomorphic in quotes.
- magicalist 12y ago
  I don't know why it bothers me so much, but it really does. What happened to just saying that the same code is run on the client and server? Avoids the jargon, doesn't make math nerds mad, isn't that much longer, and says exactly what you mean.

matchu 12y ago

Node supports parallel processes (granted, not threads), promises are a nice alternative to nested callbacks, and Javascript supports basic functional style. You've named some legitimate challenges of Javascript, all of which have been addressed in some capacity.

truncate 12y ago

I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.

nwienert 12y ago
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.
- adamors 12y ago
  Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.
  - nwienert 12y ago
    Oh well, at this point we're moving into subjective opinion. But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it. And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading. I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional. [1] https://github.com/gaearon/react-hot-loader https://github.com/gaearon/react-hot-loader

WorldWideWayne 12y ago

It's not, but having a single language to glue together all of the other ones is a pretty good idea. That's what I use Node for. With the addition of Edge.js I can run any .NET language right in the same runtime as Javascript (or, run Node inside my .NET app).

CitizenKane 12y ago

It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js(https://github.com/cujojs/when https://github.com/cujojs/when), q (https://github.com/kriskowal/q https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird). Not to mention the Async library (https://github.com/caolan/async https://github.com/caolan/async) which is full of tools to help manage it. As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.

jbergens 12y ago
Actually I think that even a lot of CPU intensive tasks could run on Node. Split them into smaller tasks (which you probably have to do anyway if you want to use multiple threads with another language) and run those as promises. Of course js is bad for most numerical calculation but for some things it might work. Or combine it with Dart or Asm.js.
- tracker1 12y ago
  You can also use multiple worker processes for your more intensive cpu tasks, keeping that out of your main loop altogether. Pooling and queue limits can prevent too many of those bound processes from running at once, and you can distribute workers across several systems.
kxo 12y ago
> Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution Here's the answer: Spawn $(nproc) more Node processes, use IPC if you need to. Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.

woah 12y ago

If you have callback hell, it is an expression of muddled thought. If you have broken your code up into small enough modules and functions, and you know which tasks depend on other tasks, you will not have callback hell. If you are unclear on the logic of your code, you can often make it work in a messy way with the "laundry list approach". This involves formulating a sequence of tasks that happens to work, without needing to understand the actual dependencies. Many synchronous languages facilitate a laundry list approach, as their inefficient blocking paradigm removes the need to formulate the laundry list as a sequence of nested callbacks. It's still messy code.

gasping 12y ago
> If you have callback hell, it is an expression of muddled thought. No. It's an indication that you're using a FOTM runtime environment. There's a reason why no production-ready runtime uses continous passing / callback models.
- woah 12y ago
  I know a lot of people running node in production, and getting very high performance out of it. It may anger hacker news that such a thing is even possible, but there you have it.
- kxo 12y ago
  Really? How do you suppose nginx does it? Or any of the other top-end (in requests/sec) webservers? Hint: they aren't utilizing green threading and/or a scheduler.

tracker1 12y ago

With node, you can run multiple processes per server... the challenges of inter-process communication really aren't any harder, and are very similar to when you have to scale to multiple systems anyway. As for blocking, if you are doing something that is blocking in your main event-loop, you're probably doing something wrong. Break it off into a req/res queue and let it flow. Regarding call-back hell... you have next-generation tooling like co/koa as well as ES6 Promise patterns you can use. Not to mention the async library. You can readily follow functional patterns in JS and Node... just because there is prototype based inheritance doesn't mean you need to use it, and most of the time, I don't. Also, Node itself isn't really single-threaded... the main event loop is, which is where your JS code runs. The underlying platform calls are running against a thread pool.

kxo 12y ago

> choose a single-threaded solution For stateless web requests (solving the C10x problem), this is not inherently bad for most applications. > which blocks the whole app if a single function blocks This is behavior you'll see in many other languages. Management of execution time is very prevalent in lower-level languages. The only languages not susceptible to this problem are high-level, preemption-capable, and possess some form of green threading/scheduler e.g. Erlang/Elixir. IMO, if you need to rely on a scheduler to help ensure that blocking doesn't occur in a disruptive fashion, you're in no position to deride those who "began as a webdevs and knows nothing better." > asynchronous call-back hells This is a matter of taste, opinion, and necessity. I personally hold the opinion that "callback hell" is a symptom of poor design, and properly managed callbacks are not unpleasant to work with (I may be subject to Stockholm Syndrome). Also, try implementing an equivalent non-blocking webserver around an event loop in a lower-level language and let me know what non-callback strategies you come up with for the coalescence of asynchronous events. As an aside, there are hundreds of different ways to improve or eliminate the composition of callbacks in JS: emulated coroutines via generators, C#-style implementations of async/await, promises, the list goes on. > non-functional but GC'ed language Which functional programming languages in common use aren't garbage collected? (again: in common use) Which other common, productive, high-level programming languages (often tasked for C10K web servers) aren't garbage collected? What does "non-functional but GC'ed" actually mean? What does the language's programming paradigm have to do with its memory management model in this context? > I am really too stupid to get it - People are productive and enjoy JavaScript. - Browsers, by and large, only run JavaScript code. - JavaScript on the server-side is a very capable, battle-tested building block for performant web software. - Admittedly: JavaScript is not a great language when compared to other modern programming languages. - Aforementioned opinionated gotchas aren't enough to dissuade communities from using JS.