Hacker News Reader

Comment by macspoofing | Hacker News Reader

>How many more ways of reinventing basic programming-language design is the JS community going to come up with before we realize that the emperor has no clothes?

Yes, JS was a rushed language that was then left to rot for 15-odd years. Unfortunately it's the language that powers the web, runs everywhere, and (along with HTML/CSS) is the only thing that all the big guys agree on.

It's getting better but it is what it is.

View on HN

Yes. JS runs everywhere that a modern browser runs and powers the web's client side.

Those are excellent reasons to use javascript to power your web applications client side as opposed to say Flash or ActiveX.

However, those have absolutely no bearing on writing your server code in JS.

The only reason to run JS on your server is so you can write the server side and client side in the same language. That's a debatable reason for running JS on your server.

Node incredible scalability around IO is also provided by a host of other not rushed and left to rot languages. Erlang, Go, C++, even Java has libraries for it.

When it comes to server side you can make a pretty good argument that the "emperor has no clothes".

Hardly the only reason. Look at something like Meteor, which is running not only the same language client and server side, but there is a large overlap in the actual code as well, which makes a ton of sense to me. For instance, you can run the actual, same, validation code against a form and before the data is inserted into the DB.

You're underestimating NPM and the community of modules around it. Node is well-rounded, and it's capable of handling most programming tasks. I use it to write utility scripts, which it's pretty good at. When I make a service, Express is a nice DSL-like framework.

It gets lots of stuff done, so I'd say it's pretty well-clothed.

Clojure/java also have lots of libraries and tools around them, as well as proper promises (where you can block and wait if you want), channels/goroutines, futures, threads, agents, reducers, etc. Erlang / Haskell / even Go are saner languages with better concurrency stories.

I guess there's something to be said for not having to learn more than one language. Probably something vulgar.

No I'm really not. NPM is a good package manager. I'm sure it has good modules as well. But NPM isn't the only package manager out there. Other languages have excellent package managers too. Clojars, CPAN, Ruby Gems, even erlang has a package manager now.

Those are minimum reqs for a language and community. They aren't differentiators. Aside from their absence being a negative indicator.

NPM is awesome, just the modules aren't. They are of poor quality, rushed, and often than not, left to rot (because people have moved on to newer shiny APIs).

There are only a few high-quality-working-and-well-documented modules.

If I am building an HTTP(S) API server that is I/O heavy (which many are), I will pick Node every time until something else comes along to replace it. That is what Node is specifically designed for and does it well. What is really great is that almost all non-trivial Node modules are also async, support streams, etc. I don't have to add a bunch of wrapper code to make some module/library behave async which I have to do in many of the other popular languages (C++, Java, Python, etc). Now is Node the best for everything? Nope, definitely not.

I do agree with you that being able to share code between client and server is a poor argument. It is a rare case in my experience where anything but the most trivial JS code can be shared between client and server.

    If I am building an HTTP(S) API server that is I/O heavy
    (which many are), I will pick Node every time until
    something else comes along to replace it.

This is exactly what I'm talking about. There were languages/frameworks that beat node already out there before Node came along. It mystifies me why people think there weren't. Again the only motivation that actually makes any kind of sense for creating Node is shared code between client and server.

Yes. I am well aware of how to build an HTTP API server in many other languages. I have been doing this sort of thing for ~15 years which doesn't make me right, just experienced. The problem with most of those languages and frameworks is that as soon as you need something outside of that framework or core language, it is uncommon that the library is setup for async I/O, streaming, etc. You end up writing a lot of wrapper and/or glue code to string everything together. Or worse you find an amazing library, but because of its design it is difficult to make it do what you want so you resort to reinventing the wheel albeit poorly. Because of the nature of Node and its module ecosystem, much of that problem is solved.

It isn't about using Node because it is cool or I like Javascript (which I hate BTW). It is about accomplishing my goal of an efficient HTTP API server much more quickly with Node than any of the other languages/frameworks that have come before. In my opinion, this is the niche Node does the best and if I have the choice I will choose it until another language/framework comes along to beat it.

every async io framework I've come across has something like runInThread(), which returns a callback.

e.g. http://twistedmatrix.com/documents/10.1.0/core/howto/threadi...

not really much boilerplate...

True, but now threads are involved. Which is totally fine and might be preferable depending on the use case. But for I/O specifically, utilizing select/poll/etc is usually faster, less memory overhead, and you don't need to add the complexity of threads. Like everything it depends on the use case. In my experience, threads are preferable when the API server does a lot of CPU work. But for I/O, select/poll/etc is usually preferable. It just depends.

Node (and Javascript) is definitely missing proper support for threads which is a negative.

Having a naked emperor on the server is a diplomatic concession to the fact that there is also a naked emperor on the client. There's nothing anybody can do to put clothes on the Emperor of the Client, while you can dress your Emperor of the server any way you want.

Which reminds me, wasn't ECMAScript 6 supposed to be finalised in December[1]?

1: http://en.wikipedia.org/wiki/ECMAScript#ECMAScript_Harmony_....

The target date for ES6 has slipped to December 2014:

https://github.com/rwaldron/tc39-notes/blob/48c5d285bf8bf0c4...

Reply on news.ycombinator.com