After a year of using Node.js in production • Hacker News Board

Re: After a year of using Node.js in production

#81

Post by Touche » Mon, May 02, 2016, 11:21 PM UTC

sockgrant wrote: post #79

Touche wrote: post #39

Earlier quoted context omitted.

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

Can you elaborate?

Event streams are similar to Promises in that they provide a value for something that will happen in the future. In the case of event streams it is a value for an event. In the browser this might be a user clicking a button. This event can occur many times. It might never occur. Promises are values for something that will happen in the future, but only once.

Use Promises for things that happen once, event streams for things that happen 0 to many times.

Re: After a year of using Node.js in production

#82

Post by narrator » Mon, May 02, 2016, 11:22 PM UTC

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.

Re: After a year of using Node.js in production

#83

Post by firasd » Mon, May 02, 2016, 11:23 PM UTC

Silhouette wrote: post #56

firasd wrote: post #25

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…

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 l…

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

Re: After a year of using Node.js in production

#84

Post by nevi-me » Mon, May 02, 2016, 11:24 PM UTC

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.

Re: After a year of using Node.js in production

#85

Post by popmystack » Mon, May 02, 2016, 11:25 PM UTC

spion wrote: post #73

beders wrote: post #70

Earlier quoted context omitted.

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

You can write definition files for libraries. A lot of libraries already have such files: https://github.com/borisyankov/DefinitelyTyped If a particular library doesn't have one, you can write it yourself. In that case theres no need to model the entire library - you can only model the subset of functions / methods that you use.

Or what if, hear me out, everyone just did that thing from the start?

Re: After a year of using Node.js in production

#86

Post by Silhouette » Mon, May 02, 2016, 11:26 PM UTC

Touche wrote: post #67

Silhouette wrote: post #56

Earlier quoted context omitted.

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 l…

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

I respectfully disagree.

Dealing with shared state is not always easy when you're working with multiple threads. If you can't reasonably avoid that sharing because of the nature of your problem, and if your choice of language and tools only provide tools on the level of manual locking, then I agree that writing correct, thread-safe code has its challenges.

However, there are plenty of scenarios where you don't need much if any state to be shared between threads. That includes almost every example of JS promises or async/await that I've seen this evening while reading this discussion and the examples people are linking to.

There are also plenty of more sophisticated models for co-ordinating threads that do need to interact, from message passing to software transactional memory. These are hardly obscure ideas today, and I don't think anyone could reasonably argue that for example message passing makes things complicated but async/await/promises make things simple.

Re: After a year of using Node.js in production

#87

Post by spion » Mon, May 02, 2016, 11:27 PM UTC

firasd wrote: post #51

woah wrote: post #47

Earlier quoted context omitted.

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.

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…

If otherThings is unrelated, you could also do this:

    var username = getUsername();
    var resultSent = username.then(username => res.send("Hi "+username"))
    var otherThings = doOtherThings()
    return Promise.all([resultSent, otherThings])

Re: After a year of using Node.js in production

#88

Post by neckro23 » Mon, May 02, 2016, 11:29 PM UTC

narrator wrote: post #82

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

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

Re: After a year of using Node.js in production

#89

Post by dietrichepp » Mon, May 02, 2016, 11:29 PM UTC

narrator wrote: post #82

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

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?

Re: After a year of using Node.js in production

#90

Post by rhinoceraptor » Mon, May 02, 2016, 11:30 PM UTC

narrator wrote: post #82

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

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