Hacker News Reader

Comment by dschiptsov | Hacker News Reader

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.

View on HN

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.

One argument for one language everywhere is the benefits you get from an "isomorphic" app (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.

Correct use of the scare quotes there.

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.

Thanks for putting isomorphic in quotes.

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.

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), q (https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird). Not to mention the Async library (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.

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.

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.

> 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.

> 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.

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.

> 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.

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.

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.

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.

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.

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.

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

If you write very modular code with good test coverage, the odds of you needing to fire up a debugger are greatly reduced. Regardless of the language you choose.

Given JS has first-class functions, and many libraries to follow functional patterns. You can write very stable code, with almost no chance of side effects within a given function/context.

The problem is, that not everyone works on greenfield applications all the time. I never inherited modular, well tested javascript projects.

I did, on the other hand, have to take over cobbled together jQuery, Backbone and Coffeescript applications.

I think the real problem is that this has nothing to do with the article on hand.

Yahoo is writing a greenfield application, and they are avoiding exactly those problems by using React. So, literally your pain point is exactly what they are writing about avoiding, and yet you still comment on this article with the same anti-JS nonsense.

Facebook Flow or TypeScript - still weak.

On require/modules, that's a freaking mess.

Ambiguous/unexpected behavior... nothing fixes it.

To make matters worse, there's always the promise of some magical library or tool that's going to fix your problems, until you discover that it sucks, or that it is unmaintained, or that it doesn't interoperate with another library and then you're back to search between thousands of pieces of crap that do the same thing.

I remember the days when people were having boners over CoffeeScript. Boy, that was a bad move.

> Facebook Flow or TypeScript - still weak.

How is it weak?

Flow was released literally last week. I guess calling it weak is going too far, but people in this comment thread refer to it like it's age old tech.

I prefer straight JS over CoffeeScript/TypeScript/Flow etc...

I don't find require/modules to be too much of a mess.. unless you are using a lot of really large tool-chains with deep dependencies... npm dedupe helps point out problems there.

Breaking your logic into idempotent functional components without side effects as separate files/modules reduces a lot of what can be considered ambiguous or unexpected.

If you work with a functional flow, avoiding OO in JS as much as prudent, you can get a lot done without nearly as much confusion.

For now co/generators/promises get you really far along. In the future await/async will take it farther.

True, there's a plethora of JS tools someone can use. The problem is that they have to be discovered. And there's no standard. I found out about Browserify 2 days ago and realised all the problems it could have solved for me. Now I have to migrate the code I have to it.

JS ecosystem is confusing. See: https://news.ycombinator.com/item?id=7074307

Utilities should be a part of the language's "battery".

Ambiguous/Unexpected behaviour: I mean I can redirect you to the popular "Wat" talk. Moreover, isn't that the entire premise of "Javascript: The Good Parts" anyway?

Flow isn't mature enough yet, but even TypeScript eliminates pretty much the entire Wat talk.

Also, it compiles to CommonJS, which means it works well with both node and browserify.

Yes, we need a blessed, "batteries included" stack for JS made of components that play nicely together. Here is a nice list to get started with (IMO, ymmv)

  1. TypeScript or Flow
  2. React
  3. Promises: bluebird, when or p-promise
  4. Observables: rxjs or most (they play well with promises)
  5. immutable-js for immutable data structures
  6. lodash and/or Ramda.js
  7. browserify

Going to make a few points of contention...

1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules)

2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful.

3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise library, or native as available.

4. Observables are pretty evil... the whole flux architecture is to avoid direct observations in favor of a unidirectional data flow.. but that's more opinion.

5. completely agreed... immutable data flows work to prevent side effects. Even if you don't use these libraries, avoiding side effects is a big thing.

6. Also agreed, though you can usually get the parts you want without the weird deep dependency chains in lodash.

7. Agreed here, though webpack is interesting, imho it breaks too much with node's approach to includes, and doesn't work as well with reusing code on the server-side (imho).

Other things to look into include csp, streams, events and the gulp build tool.

Well, observables would just be used as a mechanism to implement a flux-like architecture or decouple various parts of your server-side codebase (making them open to extension). A bit like event emitters, but without the stringly typed event names. I don't think thats evil? [1]

Or they can also be used in place of asynchronous lists (like "object streams"). I find them handy for various tasks :)

Regarding es6-promise, its too minimal for my taste, and missing my favorite feature (provided by bluebird. when and p-promise): long stack traces on (possibly) unhandled errors, which are quite invaluable on the server side when debugging longer chains of events. p-promise has the additional advantage of being a relatively small library which is pretty awesome :)

[1]: example: flux implemented with rxjs: https://github.com/fdecampredon/react-rxjs-todomvc

I also agree with just about everything here, and thanks for the tip on es6-promise. I'll have to check it out.

I actually have this entire stack running without observables currently, and my goal is to build a variety of applications using it to really sort out the best techniques with it, and then open source it as a platform.

As for #7. I use webpack and love it. It does work wonderfully server side as well, you just have a build step with webpack that strips out anything you don't want for the server, and then have your server run that built file. Not perfect, but works well. It also avoids any need for gulp.

My only problem is with 3.

If you're already at the point where you are utilizing compilation, why not implement a compiler-level async/await solution (probably based off of a loop + a state machine, a la regenerator).

Even with generators we still need to yield something or await on something. C# awaits on Tasks, in JS Promises would be a logical choice. You definitely need a value though - you can't await for node style callback functions as they provide no value to yield (or otherwise pass to the runtime) between calling the function with a callback and your callback getting called.

Even so, lambdas, observables and some FP constructs such as map/reduce/filter/etc can potentially eliminate the need for imperative style code. There are also some semi-imperative solutions to certain problems that work okay [1]

Another advantage of functional code is that its easy to extend - adding a combinator that implements filtered (typed) catch for promises is a lot easier than implementing a language construct such as `catch (e if e.code == 404)` for generators.

  var only = (predicate, handler) => e => {
    if (predicate(e)) return handler(e) else throw e;
  }

  promise.catch(only(e => e.code == 404, e => {
    handle...
  }))

Here is another example (its a bit of an overkill though :)

https://github.com/spion/promise-streams/#example

[1]: https://gist.github.com/spion/8009559

don't you feel that if you a language's short coming is addressed by adding more of it in the form of duct tapes is problematic? I love javascript when it was doing simple things on the DOM, not trying to recreate the desktop in the browser, making it render across different devices and browsers, making it crawlable by running a headless qtwebkit process to serve pages that google can't see, using a slow and unstable document storage database often advertised with an old javascript engine requiring you to write chains of callbacks for even the simplest operations, all in the back of my mind believing that somehow all this complexity has helped me, why, look around everybody's doing it. This Java/PHP/Apache garbage that has worked well but didn't feel cool or fad enough? Let's kick it.

You assume everybody uses these tools... in unity, harmony, and applying the best practices (that are not established yet).

You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least.

I echoed other comments: JS ecosystem is unstable and confusing at the moment.

Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.

None of those overlap. NPM is used for build tools along with broccoli, and bower is used for application code. Ember cli packages them together.

I do these things. But will my neighbor do the same?

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.

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).

Reply on news.ycombinator.com