Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After a year of using Node.js in production

geekforbrains.com

Post reply on HN
Print view View original

121–130 of 248 posts

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

#121

Post by empthought »

wrong_variable wrote: post #18
kcorbitt wrote: post #5

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

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…

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

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

#122

Post by lmeyerov »

rescripting wrote: post #102
Touche wrote: post #81

Earlier quoted context omitted.

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

I'm not sure I'm seeing your argument against using promises over observables for single events. Observables are a superset of promises, sure, but you can map them into situations where you'd use promises and then still have the flexibility of observables and all their operators. along with this you get the consistency of using the same async paradigm everywhere. I find you run into trouble when you start mixing them…

Yep. We used to do both, but that was convoluted, so only Rx now.

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

#123

Post by tomc1985 »

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…

It's not so much because of promises, its because sync IO blocks the GUI thread, so you have to write callbacks somehow. Pick your poison.

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

#124

Post by lobster_johnson »

spion wrote: post #60
koolba wrote: post #45

Earlier quoted context omitted.

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.

There is no replacement because they're a fundamentally broken idea. They require the following to happen, in that order: * V8 needs to optimize try-finally * Node core needs to add try-finally at every single place where callbacks are invoked and make sure all state and resource cleanup is properly done to support domains * Popular libraries need to also add try-finally handlers for the above. As to why this is a pr…

Domains are used for another reason: To emulate thread-local variables. I hope that support is not going away, because it's really handy.

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

#125

Post by girvo »

ctide wrote: post #112
qwer wrote: post #110

Earlier quoted context omitted.

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

Not really. These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray…

> No one (at least, no one I know) is installing node modules like isArray to use in the browser.

Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.

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

#126

Post by programmarchy »

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.

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

#127

Post by emilong »

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.

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

#128

Post by mikeryan »

Akkuma wrote: post #104
ZoeZoeBee wrote: post #95

Earlier quoted context omitted.

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

I watched one of the recent Netflix engineering videos where they moved to a customized version of React and I could have sworn in that talk they actually moved away from Observables[1]. What was confusing is that the other talked released at the same time they talk about enhancing RxJS. [1]: https://youtu.be/5sETJs2_jwo?t=5m32s

A friend of mine runs some UI engineering at Netflix from talking to him reactive JavaScript is still heavily used.

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

#129

Post by EdSharkey »

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.

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

#130

Post by Akkuma »

mikeryan wrote: post #128
Akkuma wrote: post #104

Earlier quoted context omitted.

I watched one of the recent Netflix engineering videos where they moved to a customized version of React and I could have sworn in that talk they actually moved away from Observables[1]. What was confusing is that the other talked released at the same time they talk about enhancing RxJS. [1]: https://youtu.be/5sETJs2_jwo?t=5m32s

A friend of mine runs some UI engineering at Netflix from talking to him reactive JavaScript is still heavily used.

I'm sure it is still heavily used, but it looks like there are two very opposing views with one going so far as completely removing it.
Post reply on HN