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

Gotchas from Two Years with Node

segment.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: Gotchas from Two Years with Node

#91

Post by esailija »

toxicFork wrote: post #23
72deluxe wrote: post #21

Earlier quoted context omitted.

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

And you can do the same on node :)

not if you are using any kind of event emitters. These don't participate in any kind of flow but fire "error" events as side effect sneakily in the background, and if there is no listener on an event emitter for the "error" event, it will crash the server. And almost everything in core is an event emitter.

Also bonus points if the event emitter object is private to some module that doesn't expose it and doesn't attach an "error" event handler to it.

Re: Gotchas from Two Years with Node

#92

Post by thawkins »

pjmlp wrote: post #56
aikah wrote: post #41

Earlier quoted context omitted.

why? PHP/ruby/python are successful too in the server space. Javascript,especially ES6, isn't worse than the formers. Devs should know by now that the dumbest tool that is good enough has good chances of being successful today. All these tech won't replace enterprise techs, but enterprise dev is a tiny percentage of all devs outthere.

> PHP/ruby/python are successful too in the server space. Again, from the perspective of someone that worked in a startup using TCL for server applications, I also don't get it. Other than being attractive to developers without formal education, and after a certain scale it becomes too costly to re-write. The work we developed at that company teached me never to use a technology stack without a JIT or AOT compiler fo…

Node exists because it can, not because it should.

Re: Gotchas from Two Years with Node

#93

Post by xhrpost »

spion wrote: post #89

All these problems are solvable (streams by ditching built-in streams and replacing them with something decent, errors with promises + typescript, event loop blocking with a streaming JSON parser). But that still means that out of the box node is a pretty unsatisfying experience all around. It took us a year to arrive at the solutions above, and many prominent members of the community scoffed at a number of them. Som…

> "ditching built-in streams and replacing them with something decent"

What have you found sufficient for this?

Re: Gotchas from Two Years with Node

#94

Post by vezzy-fnord »

IndianAstronaut wrote: post #47
bontoJR wrote: post #33

Earlier quoted context omitted.

Great piece. In fact, this is another big topic. I can't image a bank switching technology in a such easy way for components that maybe are critical. A technology switch can have multiple sides, sometimes the success is way beyond expectations and the current implementation doesn't fit the real requirements, making the switch looking more to a success rather than a failure. On the opposite it's very common to have th…

The problem with older technologies is that their scaling capabilities are limited. My company is currently trying to use Microsoft's OLAP tool for data analysis when it should be using something more scalabke for the quantity of data we have.

I think you're wrongly equating "old" with more undesirable epithets like "enterprise" and "proprietary". There's a ton of old technologies that scale marvelously, and using software age is a heuristic as probably really poor when you should really be studying internal qualities.

Re: Gotchas from Two Years with Node

#95

Post by glibgil »

xhrpost wrote: post #93
spion wrote: post #89

All these problems are solvable (streams by ditching built-in streams and replacing them with something decent, errors with promises + typescript, event loop blocking with a streaming JSON parser). But that still means that out of the box node is a pretty unsatisfying experience all around. It took us a year to arrive at the solutions above, and many prominent members of the community scoffed at a number of them. Som…

> "ditching built-in streams and replacing them with something decent" What have you found sufficient for this?

They just told you: Bluebird and streams 3. Did you get bored and stop reading?

Re: Gotchas from Two Years with Node

#96

Post by Kiro »

OT but can someone explain this?

PHP: Starts reading from database, blocks everything else, returns data.

Node: Starts reading from database, lets it go and continues with other stuff until the data is ready and then returns it.

I understand it in theory but since Node is single-threaded, doesn't it need to use that thread for the database operations? Which means it's blocking the program until it's done anyway?

Re: Gotchas from Two Years with Node

#97

Post by bitg »

72deluxe wrote: post #21
toxicFork wrote: post #18

Earlier quoted context omitted.

Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

Yes you can do a global catch, but the error still happened, the functionality was faulty and you didn't handle it properly (you just showed the error, period).

Re: Gotchas from Two Years with Node

#98

Post by cpprototypes »

Node has a lot of flaws today. But, even with those flaws, it's very useful for quick prototyping (discipline is required here since it must be a true prototype which means throwing away the code) and command line scripting (for me, it has mostly replaced python for small scripting tasks). Using it in a production service is possible, but should be limited to simple services (not too much business logic and it should be IO heavy).

But there is a lot of potential in the future. ES6 greatly improves the Javascript language and it's possible ES7 or 8 will add types. If something like TypeScript becomes standard Javascript and async/await is added, the language will become a "serious" language for many developers.

I think the Node of the future will look nothing like the Node of today. When Javascript/Node gains these features, it has the potential to become a true server side language.

Re: Gotchas from Two Years with Node

#99

Post by taternuts »

Kiro wrote: post #96

OT but can someone explain this? PHP: Starts reading from database, blocks everything else, returns data. Node: Starts reading from database, lets it go and continues with other stuff until the data is ready and then returns it. I understand it in theory but since Node is single-threaded, doesn't it need to use that thread for the database operations? Which means it's blocking the program until it's done anyway?

I believe what happens is it registers the functions callback on the event-loop which it'll check the next time around to see if it's done, then pushes the work to be handled in a separate pool of threads that libuv manages. When it's done, the next event-loop tick or the next time around it will execute the callback with the results. This is how asynchronous functions work anyways, but some functions are actually synchronous functions such as JSON.stringify, so if you are doing a JSON.stringify on a huge JSON object, you're literally grinding everything to a halt until you're done doing that

Re: Gotchas from Two Years with Node

#100

Post by jmagoon »

pjmlp wrote: post #56
aikah wrote: post #41

Earlier quoted context omitted.

why? PHP/ruby/python are successful too in the server space. Javascript,especially ES6, isn't worse than the formers. Devs should know by now that the dumbest tool that is good enough has good chances of being successful today. All these tech won't replace enterprise techs, but enterprise dev is a tiny percentage of all devs outthere.

> PHP/ruby/python are successful too in the server space. Again, from the perspective of someone that worked in a startup using TCL for server applications, I also don't get it. Other than being attractive to developers without formal education, and after a certain scale it becomes too costly to re-write. The work we developed at that company teached me never to use a technology stack without a JIT or AOT compiler fo…

Seriously? You're saying that the only possible use case for ruby/python/php is "not being a computer scientist"?
Post reply on HN