After a year of using Node.js in production

http://geekforbrains.com/post/after-a-year-of-nodejs-in-production

by 0xmohit • 10 years ago

320 238 10 years ago

mrgalaxy• 10 years ago

I have used Node.js in production for about 5 years now and I must agree with the sentiment that JavaScript is "Easy to learn, impossible to master". Yes, error handling is a little confusing at first but it stems from JavaScript's asynchronous nature which is naturally complex for the linear mind.

My personal sentiment is to just use Promises, like everywhere. ES7 async/await will really help with this too.

spion15• 10 years ago

Coming from other languages such as Python, Ruby or PHP you’d expect throwing and catching errors, or even returning an error from a function would be a straightforward way of handling errors. Not so with Node. Instead, you get to pass your errors around in your callbacks (or promises) - thats right, no throwing of exceptions.

Promises let you throw errors normally. They will propagate up the call stack in a similar manner. With bluebird, you will also get full stack traces in development mode and the performance penalty for that isn't too bad.

The last thing that I found frustrating was the lack of standards. Everyone seems to have their own idea of how the above points should be handled. Callbacks? Promises? Error handling? Build scripts?

Promises are in ES6 (i don't think it gets more standard than that) and have well defined semantics, including error handling, shared between libraries: https://promisesaplus.com/

I know that Bluebird's promisifyAll might seem like a bit of a hack, but just try it out. It works surprisingly well, and its really painstaikingly tuned for near-zero performance loss. It will probably be both less painful to do and more performant than any manual attempt to wrap a callback based API into a promise one.

lucaspiller• 10 years ago

Kind of related: One thing that has bit me a few times with promises is accidentally missing a return in the promise body. As such whatever called the promise just sits there forever, waiting for something that will never come. Is there a way in Bluebird to have it throw an exception or similar if the function executes without returning anything?

spion15• 10 years ago

Normally bluebird should produce this warning when that happens:

http://bluebirdjs.com/docs/warning-explanations.html#warning...

If it doesn't do that for your case then its likely that it needs some fixing - you should probably open an issue and we'll try to reproduce it...

Also, thenlint might work for you: https://www.npmjs.com/package/thenlint

Touche7• 10 years ago

I sort of don't understand your problem. If you forget to return a value won't the thing consuming the Promise just get undefined as the value (and perhaps throws an exception expecting the value to be something other than undefined)?

pjungwir• 10 years ago

I gave a talk about handling errors in Node a few years ago:

https://github.com/pjungwir/node-errors-talk

At the time the solution was "use domains", but I think domains are deprecated now. It was painful enough that I have stuck with Rails since then. I'm glad to hear that Promises are an improvement!

koolba• 10 years ago

Domains have been deprecated since at least 0.10. As of yet there's no replacement for them and all node apps should be using them. There's no other way to catch "But ... but ... that can't happen!" type errors.

0xmohit• 10 years ago

"A few years" is a very long time for a relatively new and evolving language.

Perhaps that is the reason that people have become more conscious of making _drastic_ changes -- rust and go are examples.

eldude3• 10 years ago

I train enterprise node.js for a living.

My recommendation is to just use songbird (which exposes the forthcoming promise API from core, built on bluebird), async/await and the async `trycatch` library so you don't have to worry about a 3rd party package's choice of asynchrony. It also comes with optional long stack traces.

o_____________o• 10 years ago

Songbird mixes promise into Function.prototype
Songbird adds promise to Object.prototype

Eek

eldude3• 10 years ago

Meh. Non-enumerable. You can opt instead for bluebird's promisifyAll when you require.

snappy1733• 10 years ago

async/await

in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.

eldude3• 10 years ago

EDIT: Oops, I misread the parent. You're right, async/await isn't easy to debug, but it's getting better, and it's a tradeoff. For now, I recommend debugging the compiled code (using generators) without source maps to avoid some of the quirks of source maps. In my experience, the tradeoff is worth it for new node.js developers because it offloads the asynchrony contract (e.g., calling a callback OAOO) to the language.

raarts• 10 years ago

When I initially encountered event -based processing (libevent in C), those callbacks were indeed difficult to wrap my mind around. But I learned to structure the code in the editor, keeping everything together which made it manageable. I 've worked with node for a couple of months now, and I find promises to be more confusing, because it obfuscates the callback in my mind, and makes it look like ordinary function calls.

esailija2• 10 years ago

async/await is tiny amount of sugar over generators and promises (virtually the only thing that changes is `yield` -> `await` and `function*` -> `async function`), not callbacks.

kcorbitt• 10 years ago

I've spent a lot of time writing Javascript on the front-end in the last year using both React and React Native. I've found the React ecosystem to be a sane, productive and enjoyable development environment.

Interested in sharing more model logic between our front- and backends, I also investigated writing some new backend features using Node (we're currently developing with Rails). But after days of research and playing around with the available options, I came to a conclusion similar to Gavin's -- any reasonably complex backend requires you to either roll your own everything, or try to cobble together literally hundreds of tiny dependencies that weren't built to go together, and then somehow keep track of all of their regressions and breaking changes.

Node's fantastic performance and unique ability to share logic between client and server are enticing, but I just don't trust the community and "best practices" around it enough to bet the farm on it for now.

wrong_variable2• 10 years ago

The same problems you cite for node.js are the reasons why a lot of devs love node.js.

Its much easier to do your own research and find the best module to solve a particular problem you are having then to shoehorn into some larger monolithic framework.

Also its a lot more fundamental then that - Node.js has prolly the fastest iteration cycle for any platform out there since its so easy to create your own module - it leads to some sort of Cambrian explosion of innovation and experimentation.

EDIT:

Also OP seems to think callback hell and async programming is bad. The important thing is those things are problems for python/.... too !

Its just that python doesn't have a good programming model to even begin to address those concerns.

JavaScript at-least tries to say - "hey this is a problem we need to deal with - concurrency is a issues we all face "

So when devs complain about callback hell - its just that they have never tried to use python to do async in a neat way.

empthought2• 10 years ago

python doesn't have a good programming model to even begin to address those concerns

This isn't even close to true. Anything JavaScript has to express logic in the face of asynchrony, Python has too. There are a half-dozen asynchronous web servers written in Python.

There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program, and threads/OS processes are good enough for basically everything except HTTP servers with absurd numbers of concurrent connections.

Someone• 10 years ago

That Cambrian explosion is fun when you are programming, but if you are writing a product, you will want to make sure you don't pick a dinosaurus or trilobite to build it on.

wizard_class• 10 years ago

doesnt node support modules? thats a way to avoid callback hell

fredrb2• 10 years ago

How so?

JabavuAdams• 10 years ago

Thanks for this. The Node / Javascript ecosystem just seems like one I don't want to be a part of.

I feel so lucky to have avoided the whole disgusting web stack.

bdcravens• 10 years ago

Like the author said, Node isn't a great fit for certain apps. It sounds like yours is one of them.

joshmanders5• 10 years ago

These types of articles make me laugh. Typically a dev with many many years experience with one language, learned all it's quirks, standards, etc decides to try Node.js because it's the "new hot fun toy", and expect it to work like their old language, and realize that is not how it works, doesn't know where to find what and fails real hard to realize that JavaScript in general is in a huge influx of updating at this moment, which by nature propagates to Node.js.

The end result is they get frustrated and go back to their old language.

eva1984• 10 years ago

Yeah, so some js devs might need to stop overselling javascript to everyone, pretending it is the one language that people are waiting for years...Just saying.

joshmanders5• 10 years ago

You should try to surround yourself with developers who don't have such attitudes. I am a fan of JavaScript, I love Node.js and I will often times suggest it to newbies. But I don't pretend it's the be all/end all of languages. Just like any other language it has its strengths and weaknesses. It's up to you to decide if it's the right choice for you.

eagsalazar22• 10 years ago

Strawman.

dualogy• 10 years ago

JavaScript in general is in a huge influx of updating at this moment

Isn't that the case basically all the time? Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end..

joshmanders5• 10 years ago

Isn't that the case basically all the time?

No, ES5 to ES2015 is a HUGE leap. ES2015 to ES2016 is a very minor jump as it only adds 2 new things to the spec.

Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end..

And honestly, that is not my job to tell you not to do. If you want to avoid Node.js go ahead. I feel Java is something I should avoid at all costs. Doesn't make Java any worse or better. Same with Node.js.

beders10• 10 years ago

You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js.

Others don't have that luxury and just can't afford that.

And if your software needs to be around for more than 5 years, you want to keep your costs low.

How long would it take you to find a bug given a stack trace from a Node API with close to no clue which part part of your app registered that callback that isn't called because of the error?

Chances are, you don't even measure the time spent in code archeology as I like to call it. The time probably is not significant right now as you kinda know your way around your code base...yet.

joshmanders5• 10 years ago

You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js.

I've been using the same tools for the last 7 months outside of switching from Angular 1.5 to React because I'm not a fan of Angular 2.0.

Others don't have that luxury and just can't afford that.

Then don't? What is this sense of needing to change everything because something else comes out, that developers have?

If your current toolset works, why change it? Why rewrite a monolithic app in another fancy language or tool just because someone wrote a blog post boasting about that new tool/language?

eknkc• 10 years ago

TLDR;

Author actually wants to use Python. Used Node.JS regardless, for whatever reason.. It did not work the way Python works. Author is frustrated. Complains that JavaScript is not Python.

fredrb2• 10 years ago

This. You can't apply some other language paradigms in every programming language just because it's the only thing you know how to do.

paulddraper4• 10 years ago

I love Python and hate JS as much as the next guy. But complaining that JS idioms do errors differently than Python idioms is stupid.

It's like saying

"JS is stupid because people use braces and whitespace to denote flow control"

Adopt the paradigm and see how well the technology fits it

vacri• 10 years ago

Small company ops guy here - a bit over a year ago, I used to joke with my devs, asking them "So, what's this month's recommended way of installing node?". More recently we've been experiencing dependency hell, which is exacerbated by our small team not having enough time to upgrade to the latest LTS release. Node is definitely a language that you have to manage. It doesn't sit in the background and let you get on with writing stuff.

Is it the right tool for X or Y? I can't say, I'm not a dev. But it does require a lot of hand-holding and keeping current with the zeitgeist.

deedubaya3• 10 years ago

For all the comments on here about how unfair the author was, there sure is minimal feedback on the problems they highlighted.

snappy1733• 10 years ago

the feedback is: stop expecting javascript to act like python

deedubaya3• 10 years ago

How productive!

q3k• 10 years ago

What does that even mean? What behaviors are you talking about?

SiVal• 10 years ago

Really, just learn to use callbacks properly. Well, wait, actually, you should skip that and start getting used to using promises instead--a big improvement. Well, I mean, until next version is ready, and we can start using async/await...until wasm makes better thought-out languages available.

Despite the sounds of this, I do like the idea of having an experimental platform with which to gain experience using wildly different approaches to the wildly changing world of web apps. I don't take it for granted that old language concepts will turn out to be the most useful for the web platform.

So, I'm okay building a website for the PTA or ceramics club with this, and I'm very interested in the experiences of others using a wide variety of technologies and approaches, but I'm not sure Node.js would be a sensible foundation to build a business on.

Touche7• 10 years ago

A lot of this is residual effects of the (slow) evolution of JavaScript. It was thrust into the spotlight missing a lot of features and these features have only recently been fixed by the language itself.

But Node has been around since 2009. 2009 JavaScript was missing a lot of features. It was basically a runtime only advanced users should use. The Node maintainers had to make a lot of decisions that now conflict (to some degree) with fixes that have come later to the language. They chose their callback style; now we have Promises. They chose to throw in methods rather than return an error in the callback (this makes it awkward to use fs with Promises without a wrapper library). They chose to implement their version of CommonJS, now we have the .mjs issue arise.

firasd4• 10 years ago

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used.

The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass the next thing to do to the callback of the query? That can't be right.

Interesting article I found: "Async/Await: The Hero JavaScript Deserved" https://www.twilio.com/blog/2015/10/asyncawait-the-hero-java...

sockgrant2• 10 years ago

Agreed. Checkout RxJS to hold you over while you're in Javascript land.

Touche7• 10 years ago

Please don't use event streams for handling asynchronous code, that's not what it's for.

zxv• 10 years ago

Yes, I too find callbacks an obstacle to readability, among other things.

If one uses mongodb (popular on node.js), and one needs multiple queries to 'join' several documents, the cascade of callbacks is an obstacle to readability, let alone debugging.

mikeryan2• 10 years ago

If you're writing a cascade of callbacks then just use promises. There's no reason to be needing to cascade callbacks pretty much all libraries now support promises and the rest can be promisified.

I'm not calling it a Panacea but Promises are idiomatic Node Javascript now and there's almost no reason for mutliple levels of nested callbacks anymore.

woah• 10 years ago

Callbacks are ugly, but are probably the semantically simplest way to handle asynchronicity. Promises are ugly too, but are semantically the same thing as async/await. I agree that promises and callbacks are not pleasing to the eye, but they are completely logical ways to do things.

firasd4• 10 years ago

So in PHP, you would go (I haven't tested these snippets, just writing them out here):

  $username = get_username();
  echo "Hi, ".$username;
  do_other_things();

In Node, using promises, you have to write:

  get_username().then(function(username) {
    return res.send("Hi "+username");
  }).then(function() {
    do_other_things();
  })

And if you're using regular callbacks, forget it: you'd have to nest do_other_things in the callback of get_username(!). It just makes things very awkward.

I understand what you mean about sync vs async calls. I won't pretend I have a better solution. I don't mean to say callbacks are illogical, just a bad way to write programs. So maybe not 'wrong in concept', I can concede that. But I think async/await can make things more readable again, i.e.:

  var username = await get_username();
  /* carry on... */

Silhouette11• 10 years ago

I find that JS often seems to tie programmers in the most extraordinary knots just to implement even quite simple logic, because of the single-threaded nature of the language.

In the programming model used by most other mainstream languages today, if you've got some work to do that interacts with some external system and might take a while, you'd probably start another thread for that task. You'd write the required logic in the usual linear fashion, and just let the thread block if and when it needs to. Modelling this using fork/join semantics and techniques to co-ordinate access to shared resources from different threads are reasonably well understood ideas.

Because there is no general support for concurrency and parallelism in JS, you only get one thread, and so in most cases you can't afford to ever block it. Consequently, you get this highly asynchronous style that feels like writing everything manually in continuation passing style, just so you can carry on with something else instead of waiting. That in turn leads to callback hell, where you start to lose cohesion and locality in your code, even though usually you're still just trying to represent a simple, linear sequence of operations.

Async/await help to bring that cohesion and locality back by writing code in a style that is closer to the natural linear behaviour it is modelling. However, even those feel a bit like papering over the cracks in some cases. Async/await kinda sorta give us some simple fork/join semantics, but as the blog post linked from the parent shows, we have a lot of promise-based details remaining underneath.

Fundamentally, the problem seems to be that JS is increasingly being used to deal with concurrent behaviours, but it lacks an execution model and language tools to describe that behaviour in a natural, systematic way as most other widely used languages can. Being strictly single-threaded avoided all the synchronisation problems in the early days, when the most you had to worry about was a couple of different browser events firing close together and it was helpful to know the handler for one would complete before anything else started happening. I'm not sure it's still a plus point now that we're trying to use JS for much more demanding concurrent systems, though.

Touche7• 10 years ago

Modelling this using fork/join semantics and techniques to co-ordinate access to shared resources from different threads are reasonably well understood ideas.

Writing thread-safe code is anything but easy in languages that support threads.

firasd4• 10 years ago

You might like this article: https://medium.com/@theflapjack103/the-way-of-the-gopher-669...

ralusek• 10 years ago

I feel like I'm taking crazy pills. "Async situation needs to settle down"...? "Completely unacceptable to write code with promises"?

Look at the following code: https://paste.ee/r/LJnhg

I have function requestFromService and another readFromDB. On a single thread, I issue one request to a service and one to the database server, and you think it makes sense for the thread to just wait around? In javascript, the second I issue those two requests, the thread is available to now serve the next incoming request or do literally anything else while those services take as long or as little as they need.

The code itself could not be more clear as to what will happen, except for maybe the syntax Promise.join(), which was only there to illustrate how easy it is to do concurrent, asynchronous tasks.

You don't have to think twice about what to do while those requests carry out, and it's not like you had to write your code in a complex manner to take advantage of the asynchronous nature of JS, it just inherently works that way. Maybe I have gone and served 5 more requests while the db server was responding, and I didn't have to even be aware of the concurrency whatsoever.

firasd4• 10 years ago

I'm not disputing the architectural choices behind Node's async model. I'm talking about syntax. It's cool that you can process multiple promises at the same time, but most of the time I need one promise to complete before continuing. In those cases the way it inverts regular code flow is very unnatural. Like I said, I think more support/usage of 'await' will help.

mrmondo• 10 years ago

We couldn't even stand 6 months let alone a year. Broken pack depts make it hard to CI, poor performance, memory leaks, huge docker base images due to deps, lots of single cpu only tasks that were too hard to scale out, an ugly language compared to ruby or Python and on top of all that how poor the package management with NPM has been. We've just ditched it and gone back to Python/Django/flask and ruby for the ops tooling.

Wintamute4• 10 years ago

You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts!

Although couched as a criticism this is actually the community fixing itself. The evolution from Grunt > Gulp > npm scripts is movement away from needless complexity towards simplicity. Npm scripts are effectively just Bash commands that build and manage your project, which sometimes employ small, unixy tools written in Node.

This self correction was pretty quick, it happened within a few years.

Unfortunately, there isn’t any one “standard” (like everything else in Javascript) for implementing or using Promises.

Yes there is. It's called the Promises/A+ spec, and its built into ES6.

Touche7• 10 years ago

NPM scripts are just a different problem. See:

https://twitter.com/sindresorhus/status/724259780676575232?l...

https://github.com/ReactiveX/rxjs/blob/a3ec89605a24a6f54e577...

Already people are coming up with new "solutions" to this problem that looks more like Grunt. It's a repetitive circle. Personally I just use Make.

Wintamute4• 10 years ago

So somebody found a project somewhere on the internet with an exceptionally complicated build process, and you use it to say npm scripts are broken? Sorry, that's absurd. Looking at that particular build process, I don't think a Makefile could have been crafted to make it much simpler or smaller. In that example, the problem lies with the complexity of what they're having to do, not the tool.

Npm scripts are really just shell scripting, which means all the real progress happens in the unixy Node tools that do the heavy lifting, where it should be. It's a future proof and scalable approach for the vast majority of projects imo.

spion15• 10 years ago

That actually looks better than most Gruntfiles I've seen.

beders10• 10 years ago

And someone needs to pay for the overhead of 'community fixing itself'.

And the Promise/A+ spec is so bare-bones, it is laughable. And the actual issue is that not every module is embracing it yet.

Sure, it will all be fixed. For freeeee :)

Wintamute4• 10 years ago

Whether the Promise/A+ spec is bare bones or not doesn't matter, the reference implementation is the ES6 native Promise, which is part of Node and now natively in browsers too. This is concretely what a promise _is_, use a different sort of promise at your peril.

sb8244• 10 years ago

I mused on similar things after getting a very small project shipped. It is based on my experience with Node, Ruby, and Node as of 4 years ago (when I first learned it).

https://medium.com/@yoooodaaaa/reflections-on-node-698abecce...

bricss• 10 years ago

Author plz, uninstall Node.js, use your so lovely Python and don't make people concerned.

tobltobs2• 10 years ago

Because being concerned is a bad thing?

tylerlh3• 10 years ago

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application.

There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all-be-all and you might find yourself much happier and more productive. Of course, YMMV.

oceanstone• 10 years ago

There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best

Well said.

By the way, what is Netflix's take on Promises vs RxJS?

ZoeZoeBee• 10 years ago

I'm pretty sure Netflix is in the Observables camp, as Ben Lesh over at Netflix is RxJs

tylerlh3• 10 years ago

One of the core tenets of the Netflix culture is "Freedom & Responsibility". In this context it means that each team is free to make calls like that as they see fit. Promises, Observables, Generators, Callbacks -- it's up to your team to determine what makes the most sense.

That said, we do make heavy use of Rx on the API layer (RxJava/RxGroovy). My team isn't currently using RxJs, but I expect that to change in the future. There are a lot of Observable fans here :)

zamalek2• 10 years ago

By the way, what is Netflix's take on Promises vs RxJS?

We've been doing tons of research into the Netflix methodology and teams are highly compartmentalized (albeit communicate richly). This means that when you ask "What do you do at Netflix?" you should really be asking "What does team X do at Netflix?" or "Does any team at Netflix do X?"

For instance, unless things have changed or I have the story wrong, JVM is used for the streaming because that's the tool which that team chose. The other teams merely communicate with it over an API (regardless of client language).

pedalpete• 10 years ago

I think the 'big application' bit is what challenges many people. From what I understand, Netflix is essential a huge group of micro-services, and I 'think' this is where Node.js shines.

What are your thoughts on that? When you're developing a service at Netflix, does it feel like you're building a single large application? Does the mentality of micro-services change how you approach code and therefore the validity of the original posts arguments?

Scarbutt• 10 years ago

He said they write services with the JVM, nodejs just for the frontend, at their scale I doubt they will change from the JVM to nodejs for services.

uptownJimmy3• 10 years ago

Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this:

1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical.

2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications.

3. I think the kinds of devs that work at, say, Netflix are often the kinds of devs that can do amazing things with almost any dev stack, but that leads directly to my last point:

4. I think that most junior devs are making a tactical mistake with their growth, and with their careers, when they choose Node for their first forays into Web app development. The relative chaos and churn, and questionable suitability of Node for many-maybe-most use cases, make Node more trouble than it is worth for someone still struggling to make sense of the basics.

kansface• 10 years ago

2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications.

All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Moving from django to twisted is probably just as hard as django to Node. 9/10s of the python ecosystem assume synchronous code so you end up with threads, processes, and callbacks.

MichaelGG4• 10 years ago

How big is the Netflix webapp, though? There's what, 5 or 6 main content "views", then around 20 user-editable forms? Plus the help site. Am I viewing this incorrectly? It doesn't just doesn't feel like Netflix is a large app from the UI perspective - maybe that's just good design.

Hope this doesn't come off as "I could do this in a weekend", just questioning how big the actual webapp is.

tylerlh3• 10 years ago

I believe you would be surprised were you to look under the hood.

There are a number of different "UI areas" in Netflix.com -- homepage, titles, signup (multiple flavors of this, depending on how you're signing up), onboarding, member browsing/viewing experiences, account management, numerous partner integrations, etc... not to mention all the work that goes into per-user customization, AB testing, and internationalization.

No offense taken on the question. IMO, if you look at the site and view it as simple then we've done our job correctly. :)

lenkite• 10 years ago

If I am not wrong, Netflix folks make heavy use of 'stream based programming' using RxJs. This greatly simplifies a lot of the standard problems faced in JS - like callback hell and error handling, if one adopts it consistently across the stack. Not many folks have discovered this as yet.

clessg• 10 years ago

For web applications, I've been very happy with the up-and-coming Phoenix[0], a framework for the Elixir language.

Very well-designed and thought-out, fast, productive. Leans functional and immutable rather than object-oriented and mutable. It's kind of like Rails but without most of the problems.

[0] http://www.phoenixframework.org/

deedubaya3• 10 years ago

I've found Elixir to be a delightful language with very palatable syntax compared to ruby. It has been a really enjoyable transition, with some vague reminders of the parts I really like about JavaScript.

Chris911• 10 years ago

Most of the problems described in the articles can be solved by simply using promises. Error handling is centralized in your chain and any function can throw and just like Python or Ruby you can catch anywhere you want. As for consistency between callbacks, promises and generators, just pick one. We switched from callbacks to promises and it was a great move. Error handling greatly improved and the code looks a lot nicer. No more callbacks hell. Ever.

We switched our backend from Python to Node almost 2 years ago now and it was a great decision for us. If you handle a code base that deals with a lot of async requests Node is definitely a top contender.

cyberpanther• 10 years ago

I think by reading the comments here and the article, its apparent that Node.js just isn't as mature yet. If you know what you're doing, it can be great, but for the noobs the right way to do things is not easily apparent. Couple this with the huge choice in libraries and frameworks, makes Node.js harder for now. I think the base is good though and given more time it will become more easy to wield. This is typical of any new tool. And yes Node.js has been around the block for a while, but it is still newish compared to Python, Ruby, PHP, etc. So you're going to pay a new adopter tax still.

billmalarky• 10 years ago

Just FYI, the Koa framework makes node sane again.

Callback hell and error handling are no longer issues in node if you just embrace generators or async/await.

We use Koa in production and serve billions of requests just fine.

If I had to go back to Express I'd say no.

beders10• 10 years ago

Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;)

I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again.

The software industry is in a sorry state.

Unless you are a very disciplined team with a very strong sense of writing modular code, don't use Node.js for any larger project. And even then, the single-most useful function in an IDE 'Show Call Hierarchy' will never be available when using a dynamically typed language.

That is not an issue for smaller projects. However, long before you even get close to the the million lines of code project size, your tools will fail you. Your debugging/refactoring times will explode and adding a new feature will seem unsurmountable.

Instead, let's just re-write everything from scratch because the cool hipster that wrote your backend a year ago has left for greener pastures...

I won't even try to guess the amount of technical debt produced with Node.js and the likes each day in the bay area.

And, yes, I just used Node.js to write a Slack-bot. It was fun, took me two hours and got me up and running quickly. That's the beauty of it. Just be aware of the dangers.

spion15• 10 years ago

With node, at least you have the option to easily migrate to TypeScript and get excellent tooling.

beders10• 10 years ago

if all the libraries you are using are as well...maybe.

Silhouette11• 10 years ago

Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again.

If only that were true! I think the JS (and more generally web development) ecosystem today is more a case of those who do not learn from history being doomed to repeat it. The thing is, if you actually are Google or Facebook or Microsoft or Mozilla or Apple, you can throw huge amounts of resources at problems and produce sufficiently useful solutions regardless, and then you can do the same again a few months later if you need to. These are the kinds of organisations that set the tone for the whole community because of their sheer size and influence. However, their goals are not necessarily aligned with the rest of the web development community, nor will their approach necessarily work well for someone else.

beders10• 10 years ago

I think I didn't express myself correctly. Younger engineers are ignoring lessons learned and are thus forced to learn them again :)

auvrw2• 10 years ago

maybe i haven't read this thread closely enough ... the parent to this post mentions "lessons of the past" and its parent mentions typed languages, so uh, what lessons are being discussed here? certainty not "the past teaches that typed languages are best," b/c lisp

athenot• 10 years ago

Those are all very valid points.

However, having witnessed (different shapes of) the wheel being reinvented over the past 2 decades, my take is slightly different: each language/environment has its strengths. If you have the luxury of having a senior team that's decently versed in several environments, then you can have your cake and eat it too: for each tool, micro-service, component... use the right language for that. Then tie it all together on the network. Since the system as a whole is likely to be a network product anyways, embrace it to your advantage.

Joe Armstrong wrote a good post[1] about connecting programs a few months ago, that's quite relevant.

Node.js is a great environment for many microservices. Got a task to do which is 80% done in some npm module? Make a node.js service around it. Same idea for Perl & CPAN, C libs, Java tools, etc.

[1] http://joearms.github.io/2016/01/28/A-Badass-Way-To-Connect-...

encoderer• 10 years ago

I've worked in three million+ loc codebases, in PHP, Python and Java. I don't share your opinion that you need static types in these circumstances. You need discipline, modularity, and most importantly you need to have been blessed with gardeners and maintainers throughout the life of a project and not just after a mess has already taken hold.

Klathmon4• 10 years ago

Damn sorry I accidentally downvoted you on mobile... I really wish HN would fix that.

beders10• 10 years ago

Did you read what I wrote? I already said that you need a disciplined team. Good luck keeping that team together for years to come. Not sure if you are disputing the fact that keeping code around is a challenge, or not.

spion15• 10 years ago

The main problem with most typed languages is basically that types are nominal by default.

What I want is free-form records and structural types by default, nominal types only when necessary. I get more than half of that with TypeScript (it does lack nominal types but there are ways to get around that), and honestly its the half I prefer having.

majewsky• 10 years ago

Most serious statically-typed languages have some sort of "anything" type where you can check the actual value type at runtime using some sort of reflection. For example, the direct Golang equivalent of a Javascript object is a map[string]interface{}.

MBCook• 10 years ago

A lot of the Node issues seems to be due to the fact that it's a very new language. Sure JS has been around for a long time but the problem domain was small and very different from what Node is trying to achieve. Couple that with some issues other languages don't have (JS's standard library is quite thin) and I'm not surprised at these issues. I felt bits of this playing with Clojure and Go when they were new.

I imagine a lot of these issues will settle down in the next few years as one or two sets of conventions become de facto standards.

mpweiher2• 10 years ago

And even then, the single-most useful function in an IDE
'Show Call Hierarchy' will never be available when
using a dynamically typed language.

True when "never" = "40 years ago". Smalltalk IDEs have had features for displaying call hierarchies statically and dynamically since essentially forever. And of course, in a dynamic environment the IDE vs. program distinction doesn't matter, so if you want to really know what's going on, just insert a self halt. and check in the debugger.

Smalltalk also introduced automatic refactoring, another canard of the "impossible to do in a dynamic language" variety. Really weird when "impossible in" = "invented there".

Yes, we can talk about how static type information can make some of this easier, but it also makes other parts harder (and the RB guys did talk about this, so the information is out there).

Please: if you want to diss JavaScript, diss JavaScript, don't say "dynamic languages". If you want to diss dynamic languages (please do!), inform yourself first.

beders10• 10 years ago

If your IDE is your runtime environment. Sure.

I've started with Allegro Common Lisp, so i kinda know a thing or two about that.

The success of Smalltalk then speaks for itself?

dustinlakin• 10 years ago

I think the switch to an async back-end can be more initial work than many expect. It may take some time to feel as productive, but promises become powerful and became a game changer for me over my previous work with callbacks. Error handling also becomes manageable.

What I really enjoy is jumping into new community and getting to work with tools that have built. Choosing the right ones can make or break an experience. I personally enjoyed working with Express and Bookshelf.js/Knex.

I appreciate the authors perspective, but I also don't think this should deter anyone from trying out Node. I personally have no overwhelming preference to using a Python or Javascript stack.

xentronium• 10 years ago

Bookshelf.js/Knex

After ruby orms, Bookshelf felt very, very underdeveloped. Anything I tried to do beyond "hello world" only brought me pain, especially dealing with associations, but honestly just about everything. I guess I've been spoiled, but getting anything done in express/bookshelf combo seemed like a chore.

silviogutierrez• 10 years ago

Same experience as the author. Tons of reinventing the wheel, and hundreds of dependencies.

The majority of established companies that say they use Node in production are doing so as a fancy proxy. All the "serious" stuff is done on backend services written in other languages.

Moreover, asynchrony is a concept far more advanced than most people think.

We will likely continue to leverage Node as a fancy proxy. Adding Typescript will only help. But it's likely that as Node grows into a mature platform, other platforms will continue to fill in the gaps that Node filled.

See for example Node constantly adding [foo]Sync versions of methods, while Python adds first class sync support.

hasenj• 10 years ago

Everyone and their aunt wants to publish an npm module. That's why you get a ton of badly written poorly thought-out packages.

peterashford• 10 years ago

I think the basic problem is that JS is not the right solution for every task but for the web, it's often the only tool available.

I had similar experiences to the OP. I had lots of code written in JS that I was happy with to some extent, but all of it would have been easier / cleaner / more maintainable in a less crap language.

nodesocket• 10 years ago

I prefer to just use async (https://github.com/caolan/async) for all control and error flow. Namely async.auto() can do almost any crazy flow.

narrator2• 10 years ago

I'm using NodeJS on a pretty big project.

Things I like:

* Async libraries make it easy to make things high performance.

* I like Sequelize as an ORM, once I figured out how the async everything works.

* The testing support is pretty good, both mocha and e2e testing using selenium

* The angular-fullstack generator was really helpful for getting started and setting up the deploy to Heroku.

* everything is open source. If I get confused with what a library is doing while I'm debugging I can just stick a print in the lib temporarily.

Things I don't like:

* "undefined is not a function". When something goes wrong. This is the error I get 80% of the time.

* async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere

* There's a bit of a learning curve with promises.

* Needs a lot more automated testing than a really strongly typed language like Scala.

* Single Threaded. I know how to program using threads, so I view this as a disadvantage.

* No types. I have a lot of type checking asserts at the beginning of dao functions.

If I did it all again and my teammates would oblige, I would have probably chosen Play/Scala. I actually reimplemnted things from a Play/Scala project I did a while back (login/signup/forgot password/confirm account) and it took less time in Play/Scala, even without passportJS and friends. I have about a years worth of experience learning Scala before I started that project, so it would probably take longer for a new Scala developer.

neckro23• 10 years ago

* async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere

There's no need for that:

    process.on('unhandledRejection', err => console.trace(err))

dietrichepp• 10 years ago

The async stuff is not really any better performing than e.g. async in C#, which is mature, easy to debug, and has been around a while.

I don't know why people keep saying node.js is "high performance", the numbers I've seen basically put it in the same ballpark as similarly architected apps in other languages, as long as the other language has a reasonably performant toolchain. Perhaps people are used to old Ruby on Rails performance problems?

rhinoceraptor2• 10 years ago

async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere

Huh? That's not how async errors work in Node. Try/Catch is not async, the catch block will not magically transfer to your callback function.

You check for the error as the first parameter in your callback, that's the standard way of error handling. Throwing errors in Node is considered by most to be an anti-pattern.

narrator2• 10 years ago

That's nice in theory, but third party libraries may throw exceptions if unexpected things happen at runtime. You'd still have to put the try catch block there and call the callback in the catch block everywhere.

spriggan33• 10 years ago

* I like Sequelize as an ORM, once I figured out how the async everything works.

Sequelize is painfully slow unfortunately, I don't mean a bit slow like most ORMs I mean really really slow. It shouldn't be used in production.

bschwindHN2• 10 years ago

Not to mention it's flaky on even producing correct queries. Sequelize was hell for me and I'm glad to not be using it anymore.

nevi-me• 10 years ago

Been on Node and Mongo for 4 years now. Both have worked well for me.

JS has evolved a lot in the past few years, and with it came all the new shiny tools that left us confused.

I think a year was too short for the author. Sounds like they were chasing after every cool thing to make life easy.

Error handling is a pain yea, I've seen amateur folk try catch this and that, I think that lends itself to being terrible.

One of the things I appreciate the most about JS is JSON. Crafting tens of classes in Java irritates me. I find Python sometimes tricky also when dealing with structs VA lists.

I've always stuck to the basics when I was learning how to JavaScript with Node. I used only callbacks for 2 years until I understood what my code was doing. Granted, I'd have spaghetti at the end of complex async queries, but I understood what was going on. I moved to caolan::async and have been using async whenever necessary. I barely use promises as I got confused by the early adoption craze.

I learnt how to use Backbonejs, and a bit of Angular+React+Ember, but I found myself comfortable using vanilla JavaScript. Only thing I use is Underscore templates. I know I could benefit from shadow DOMs etc, but I'm content where I am.

I think a good way to learn is to take things at bite sized chunks. I've started using RxJS recently, and I'm loving it! I'll keep using JS as my primary tool, but I'm slowly moving to Kotlin.

jrapdx3• 10 years ago

Can't fully agree with the article re: using nodejs in production. A couple of years ago I decided to use nodejs for a rewrite of a web/database app that had gotten to be complex and hard to maintain.

As so often said, it was true for me that the abundance of modules and choices in node was at first very confusing.

I eventually figured out that keeping things as simple as possible was my best approach. What I came up was a server relying on very few module dependencies and written using consistent if not so elegant components. Sure it's kind of verbose and far from totally DRY but fairly easy to understand, modify and extend.

Key issue was node's "callback hell" style of async programming. Of course, it's not just node, other languages (Scheme, FP, etc.) can be mind-bending in a similar way.

The callback "inside-out" locality inversion was initially hard to grasp, but once I caught on it was possible to get the server working the way I needed it to. The more recent development of promises, etc., certainly provides reasonable ways to reduce the high barriers implicated in using the nodejs style of async programming.

zyxley• 10 years ago

Callbacks definitely become much, much less of a problem once you can turn everything into promises.

placebo2• 10 years ago

I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this language sucks". I think there are a few reasons for this: 1) Even after all these years, I'm still passionate and excited at the ability to sculpt logic, regardless of the "material" I need to use. 2) A "keep it simple" approach - no way to overemphasise this. Know the advantages and limitations of the language and stick to what works. Keeping things simple should be like a fractal - existing at all levels of abstraction. 3) I'm very wary of hype. New, shiny and trendy does not necessarily mean better, especially when the hype is in conflict with keeping things simple. I find that when you understand the playing field, mark the areas to avoid and keep things as simple as possible, the elegance of the design and implementation usually makes the advantage of language X over Y insignificant, and I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it.

stormbeta• 10 years ago

The article doesn't appear to be blaming Javascript as a language, but rather the Node.js ecosystem as a server platform.

Not all tools are appropriate for all niches. The author made it clear they don't have an issue with Javascript as a whole or even with Node.js necessarily, but rather the use of Node.js as a major server platform or as a platform for large applications.

qwer• 10 years ago

All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.

eksemplar• 10 years ago

I didn't get the impression he hated the language or even the node.js ecosystem. Love or hate for languages have no real place in production. I work at a place with 5000 employees and I sometimes work with technologies I'm not fond of because they are the right choice for the job.

Things like long term support, stability and security rate in how mature different technologies are for production. Considering a lot of the problems the author ran into with node.js aren't secret, I think he might actually have liked it quite a bit to go on to try it in production for a full year.

_yosefk• 10 years ago

Keeping it simple works wonders but you can't do it alone. A language with a culture of making things complex so as to achieve some standard of perfection, and/or with many developers simply not knowing how to stay out of trouble and not being able to tell what's fragile and what's trustworthy, will make it harder to "keep it simple."

I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.

pron• 10 years ago

No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job.

[1]: At least, not for long.

[2]: created in the past thirty/forty years

morgante• 10 years ago

C++ is 30 years old and it certainly has made interesting projects horrible.

dunkelheit• 10 years ago

You are a lucky person if you have used so many languages and never missed a thing in a language you are using at the moment that is readily available in some other language you have used in the past and that would make everything so much simpler!

For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand.

Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.

astrobe_• 10 years ago

I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it.

Sure. If you're a good novelist you can write something great even on a keyboard with a broken 'e' key (btw, your 'I' key is about to break; you should replace it asap).

But novelists don't have deadlines and when the novel is done, they usually don't take reader requests to change this or that part of the story.

"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

teh_klev• 10 years ago

But novelists don't have deadlines and when the novel is done

I hate to "well actually" you :) , but a great number of authors have contracts that demand one or two novels a year over a fixed period of time. I know Iain Banks did with his publisher, he mentioned it at a one of his readings of a new but yet unpublished novel I was lucky to attend back in 2007'ish.

they usually don't take reader requests to change this or that part of the story.

Even well known authors are reigned in by their editors and proof readers, and sometimes things have to be changed.

placebo2• 10 years ago

(btw, your 'I' key is about to break; you should replace it asap).

haha - touché, point taken :-)

Deadlines seem like a great excuse for compromising quality. Sure, life is complicated, the boss is demanding, the mortgage has to be paid, the children need to be supported etc. etc. but compromising quality and enthusiasm (they usually are correlated) because of the "terror" of a deadline will just leave you at the mercy of the next "terror", only this time you'll even have even less enthusiasm to fix the spaghetti. Doesn't sound like an enjoyable existence.

Of course, very few people have the privilege of never having to compromise, but it's never black or white and there are many more degrees of freedom to choose the path with more quality than are implied.

"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

The "area to avoid" in the review is Node.js and considering that large and impressive projects have been written in it, it seems that this is another case of throwing the baby out with the bathwater.

AhmadH• 10 years ago

It's more like hundreds of thousands of writing teams from different cultures and levels of experience sprung up to write collaborative epics in Latin because it had suddenly become cool to do so while bringing the language to the modern world by inventing a new vocabulary and arguing on the correct pronunciation of everything.

Clobbersmith• 10 years ago

We use NodeJS pretty extensively at Yahoo for both front end and back end services and it works well. While some of the complaints are valid, it's not worth flipping tables over.

Promises are standard in ES6 and it is "the way" to handle errors. At least if you want to stay sane.

santoshalper• 10 years ago

Node.js, meteor, et al. is a great example of what happens when you let inexperienced developers design a platform and run an ecosystem. Almost every ounce of focus in this community goes to increasing developer productivity. Operational concerns like scalability, security, monitoring, are given the bare minimum of focus. In many years of programming in many languages on many platforms I have never seen a worse platform and ecosystem than Node.js in a very popular language (obviously some obscure languages hardly have anything built around them at all).

I really think it is setting the programming world back a lot. Not to mention what a thoroughly shitty language JavaScript is. Being able to code your web app in one language is a neat trick, and the ability to talk back and forth between client and server so seamlessly does kind of feel like magic, but otherwise, this is a meaningfully worse language/platform that Visual Basic.

programmarchy• 10 years ago

Never had the problems with Node described in the article. Node forces thinking about modularity and composition though, which I'd wager is what the author is actually struggling with. Write functions that do one thing and they're pretty easy to compose, even if they're asynchronous. It's really not hard to debug what went wrong in the stack trace when you name your functions.

And I think exception handling is much worse than passing errors up through callbacks. It forces you to think about edge cases. Not sure how python handles this, but I can't tell you how many times I've seen Java or C# code swallow exceptions which is much harder to debug IMO.

People really seem to have a problem with there not being "the one true path" in Javascript, but it's not something that gives me much anxiety. Javascript is incredibly moldable, which is part of what makes it so powerful.

emilong• 10 years ago

I've been using Node in production for a few months now, having come from Ruby (Rails & Sinatra) immediately before, but having used JavaEE and PHP before that. I find it... fine.

For error handling, bluebird's typed error catching (http://bluebirdjs.com/docs/api/catch.html) is working well for me and I'm finding it analogous to my experiences with Java and Ruby.

I'm rather used to using ORMs as well and I use Bookshelf (http://bookshelfjs.org) on top of Postgres for this as well. It definitely has room to grow, but it's also fine.

I've also gained a dependency injection container (Bottle.js, see my write up here: https://blog.boldlisting.com/declarative-dependencies-for-un...), which I sorely missed in my Rails days and which gives a lot of structure to the application.

I think the biggest concerns on which I'd agree with the author are the pace of the community and lack of agreement on things which are well-decided in other, more well-established development environments.

That being said, there's huge potential with Node because of that. There are more coders in the world than ever (I'm assuming) and Javascript is a great low barrier to entry language that encourages people to explore various runtimes. In 20+ years of coding, I've not seen this level of excitement and engagement in a development environment. While it may be rocky for another few years yet, I suspect we'll end up with a very productive platform, simply because of the amount of involvement. Of course, it's totally understandable to want to wait for that before jumping in. :)

As a relatively new Node developer, I'm much more concerned about the single-threaded nature than the development environment, but so far even that hasn't been a problem.

EdSharkey• 10 years ago

In my opinion, JavaScript is a toy language. Looking at it, and the Node.js ecosystem by-extension, that way has really helped me be effective with it.

Tooling has never been more important to my productivity with a language as it has been with JS. I constantly search for tools to paper over the warts and potholes.

jv22222• 10 years ago

Uber has done pretty well using node as their core dispatch architecture.

jtchang• 10 years ago

Node is one of those platforms that makes me shudder every time I go looking for solid best practices. It seems to change every 3 months. It's scary (and cool) how fast things are changing.

jondubois• 10 years ago

- The dependency instability can be avoided by specifying specific versions of your dependencies inside your package.json.

- The fact that the ecosystem is evolving quickly is a good thing. Node.js is still one of the fastest growing software development platforms according to Google trends so you should expect it to change faster than other ecosystems.

- ORMs suck (in every language) - They always sucked; ORMs are a massive hack intended to fix the impedence mismatch between relational DBs and RESTful APIs. If you used a NoSQL DB with Node.js (such as RethinkDB), your life would be much easier. Nobody in the Node.js community except your grandma cares about ORMs because they're considered legacy technology. If you don't like it, then you can stick to your COBOL and Oracle database.

- Node.js lets you choose how you want to handle errors. JavaScript offers an Error class which exposes a name property (which you can overwrite for each error type) and you can also attach custom properties to Error objects (to carry back more detailed info specific to each Error type). JavaScript is really easy to serialize/deserialize so you can even design your error handling system to be isomorphic (same error handling on the client/browser and server). I really enjoy error handling in Node.js/JavaScript - You just have to put some thought into it.

- The way of writing async logic is changing. The fact that Node.js is keeping up is a good thing. There is no single right way to handle async logic. Most well-maintained libraries will keep slowly evolving to use the newer features of the language but it's mostly backwards compatible (many libraries support both callbacks and promises).

- The standards are not bad; they're evolving and you can choose your own styleguides for your projects. Most JS developers will adapt to new styleguides as they move between companies/projects.

flamethroeaway• 10 years ago

Is package.json webscale?

z3t4• 10 years ago

I think the problem is they chased the latest and greatest.

tips: Always throw errors! Use named functions!

Corrado2• 10 years ago

I agree with this article and find the Node.js community, and to a lesser extent Javascript itself, exhausting. It seems like every 2 minutes there is a "more" proper way to do something, which tells me that the architecture is not yet mature, even though it's pretty old by now.

On a related note, it seems like every time you find something that doesn't quite work correctly or conveniently in Node.js there is a "fix". Don't like callbacks? Force Node.js to look more like other "normal" code and use Promises. Having trouble getting Node.js to concentrate on one thing at a time? Force Node.js to look more like other "normal" languages and use the "async" library. And it just goes on and on and on. If I have to use all of these other pieces and parts to be productive in Node.js I may as well just use some other language.

I really wanted to like and use Node.js, but Javascript and the community are holding it back.

eagsalazar22• 10 years ago

Yes, the Javascript world is quickly evolving both on the front end and backend, and of course that can be exhausting but I have to disagree with both conclusions that (a) this means the tech is immature, and (b) the community's readiness to make changes is "holding it back".

The js world is very unique in its ability to evolve quickly and things have improved massively over the last few years. Now, apart from the churn itself and precisely because of that rapid evolution, front end and backend development in javascript is amazing compared to most other options (especially on the front end). So while you do have to be realistic about the cost of the evolving ecosystem, it is just a tradeoff for rapid progress, not a flaw.

If you crave stability, agreed, this rollercoaster probably isn't your ride. But the evolution of node, the emergence of react/redux, es6, etc is amazing and beautiful IMO and I'm totally enjoying every bit of it compared to the staid mediocrity of my Rails, C/C++, and Java history.

rimantas• 10 years ago

The problem I see that in this case "evolving" looks suspiciously like running in circles without going anywhere.

Corrado2• 10 years ago

I'm not saying that Node.js is bad and shouldn't be used. Rails was in the exact same boat several years ago; everything was changing so quickly that new people on the scene had to work pretty hard to keep up. Being on the other side of that process with Node.js, I can now understand the Rails newbie's frustration. :)

If you are comfortable with the constant change and evolution in a platform/language/framework, then by all means continue to use it. Just don't disparage people that come forward and point out the pains they have and say that everything is fine. Just my $0.02.

Kequc2• 10 years ago

I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe.

As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use something else.

For all of its pitfalls and annoyances, javascript is too powerful a language to ignore. Asynchronous operations and streams are just too good. They are difficult to balance but once mastered you can really do a lot with them.

My recommendation would be to skip libraries where possible. Use raw ES6, or Typescript. Something javascript has been suffering from for a long time is bloat from external libraries. You don't really need to use them, especially now that the language has more or less settled down.

All of the best libraries were used to normalise things and that's not really needed anymore.

MichaelGG4• 10 years ago

How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?

gedrap• 10 years ago

The only clear, objective advantage of using nodejs is that if your application is I/O heavy (e.g. tons of sql queries which can be executed in parallel), nodejs event system is helpful and everything you need is pretty much out of the box. Other thing... it largely depends on personal taste and a matter of convention.

Reading his "Why I’m switching from Python to Node.js", doesn't seem like he was having an issue with that. And I don't really buy into the "same language everywhere" argument because come on, how hard is it to learn python, ruby, etc enough so that you can be productive? Not hard at all, unless you have hundreds of cubicles filled with drones.

Anyway, it's good to see that he made some reasonable conclusions after the experiment. That's a good sign :)

MichaelGG4• 10 years ago

Same language, in theory, is great. Reuse structure definitions. Reuse rendering logic or even validation logic (perform checks on both, but make it easy to get into client-side). In general, keeping things "in sync".

Also can make it easier to write in SPA style but offload rendering to the server when you need it (particularly first-page or reloads).

Whether or not tooling is good enough to allow this (either with JS or compilers) is another issue.

spriggan33• 10 years ago

The biggest problem is dealing with callbacks (and yes even promises use callbacks , and generators need to be wrapped in a cor-routine framework in order to work as cor-routines ).

I want to write a quick script doing some busy work , I now have to think about synchronicity even though the script does not need to be non blocking. Of course in these circumstances, I want to move back to Ruby or Python, which actually let me code the thing I want to code without forcing callbacks on me.

So when you have to do 20 i/o operations in sequence, using nodejs becomes really tedious.

ldehaan2• 10 years ago

From reading the comments there are Still a lot of misconceptions about Js.

javascript is not new, it's been around since before most of the web devs out there started working in computers.

nodejs supports multiple CPUs.

nodejs is stable.

JavaScript is retarded fast, and it's not c or c++ or any Compiled language, and shouldn't be compared to them because that's unhelpful as a measure.

it is the only language for the web which enables you to work in the same language on both fronts.

frameworks aren't JavaScript.

nodejs isn't JavaScript.

JavaScript is so flexible that it can be changed to suit the needs of those writing it, so much so that you get whole new dsl's like typescript.

there are more conversations on the internet about JavaScript than any other language being used today.

oh and nothing scales if you don't know how to write scalable software, that's on you, not the language.

tempodox• 10 years ago

I find this a valid assessment of Node and JS.

kartickv• 10 years ago

If this article is true, it paints a concerning picture. I don't want to research libraries, understand the pros and cons of them, run into problems, then switch to another library, and so on. I want there to be a default that works out of the box for the majority of use cases. There can be alternatives, as long as there's a default that works out of the box for most people and most use cases.

bschwindHN2• 10 years ago

Interesting analysis. I just finished a year of using Node for implementing an HTTP API and a chat server, and found it to be actually pretty pleasant. I'm not chasing the latest and greatest things, there's no ES6, no ORM, and I'm on an older version of Node. But it works and has actually been quite stable! The things I've missed are static type checking at compile time, and execution speed (which is less of an issue when you're talking with databases all the time). I'd be happy to write in more detail if anyone has any questions, but I found I had the opposite experience of this author. The situation makes all the difference though.

paulftw• 10 years ago

A year ago one of the reasons to leave Python was poor MongoDB & JSON support, 12 months later the same author complains about the lack of a decent SQL ORM library in js <scratching my head/>

while JS is far from perfect, his problem was he was a little bit ahead of time- babel, standard promises & sequelize solve most of the problems. I think Python is still superior for serverside, but JS isn't as bad as portrayed in this post, if you slowdown for a couple of weeks to learn how to use it properly (just like any other popular language or framework).

igl• 10 years ago

Async-functions are the answer to all his problems. I generally agree on his conclusion though: Do small things, don't build big systems.

I hate that JS trys to be this OO-FP hybrid. Jack of all trades, master of none.

tonyjstark• 10 years ago

This article definitely matches with my experience. I did two not all too complicated projects on the side with Node.js and the the first steps where so easy that it completely convinced me to go with it. After a while I tried to dig deeper and went to meetups to see whether I do things right as in a community accepted way and if I use the right tools and so on. Since then I refer to the Nodejs community as the most hipster programmer community I've ever seen. As soon as a framework was getting near a 1.0 version nobody wanted to use it anymore, experimental features were used in production code, it was horrifying. For me that ended this endeavour, I just could not keep up with the pace. I always wondered if it would be different if I would have worked full-time on Nodejs projects.

btomar• 10 years ago

Though I agree with what you all explained with the big issues with NodeJS, you have to understand its not all of Javascript. Its only server side JS. The creators have clarified, for heavy CPU intensive services, go away from NodeJS. As far as frontend is concerned, AngularJS and React are just sugar candy for user interaction and structure. Node filled the gap with an async network application in pure JS without the heaviness of Python or traditional languages. It is a hack as in every day people are finding new ways to use NodeJS but I agree, there has to be best practices and less boilerplate (plus less silly npm packages for trivial JS tasks).

throwanem• 10 years ago

tl;dr: "I really miss Python's bondage and discipline, so I'm going back to it, and I'm going to hate on Node on my way out because I genuinely can't wrap my head around the idea of a paradigm other than the one with which I'm familiar and comfortable."

It's not even about Node. It's about anything that isn't Python, and doesn't have the Python community's strong "there is exactly one way to do it" tradition. I'm glad OP has realized that's what works for him. It's a shame he lacks the perspective to understand that it's about him.

velox_io• 10 years ago

There's a very fine line between between removing too much essential complexity, and leaving programmers with too many limitations. Or the other end where the language overhead overshadows the original task at hand.

For instance multithreading should be handled by languages and frameworks 99.9% of the time. Take reading a file (something that should be handled by the language/ framework). Read it asynchronously, structure any dependant code clearly (which JavaScript does pretty well), if any problems are detected they display/ log the appropriate error. You shouldn't be kneck-deep in callbacks.

co_dh• 10 years ago

welcome back :)

swivelmaster• 10 years ago

This articulates my fears around switching to node very clearly. I've played with it in the past and felt like it would become too difficult to manage with a large project and lots of contributors.

arisAlexis• 10 years ago

Using babel without async await is a mistake IMO should solve almost all your problems and errors. Also the main argument for using js in the back end is that you have the same team working in the front-end too and in any case in the same langage.

After a year of using Node.js in production

Related Stories