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

101–110 of 248 posts

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

#101

Post by Scarbutt »

pedalpete wrote: post #93
tylerlh wrote: post #40

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…

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

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.

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

#102

Post by rescripting »

Touche wrote: post #81
sockgrant wrote: post #79

Earlier quoted context omitted.

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 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. If you use observables for 0-N events and promises for 1 time events you're always converting between the two.

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

#103

Post by uptownJimmy »

tylerlh wrote: post #40

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…

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.

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

#104

Post by Akkuma »

ZoeZoeBee wrote: post #95
oceanstone wrote: post #68

Earlier quoted context omitted.

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

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

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

#105

Post by MBCook »

beders wrote: post #55

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, d…

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.

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

#106

Post by uptownJimmy »

joshmanders wrote: post #14
eva1984 wrote: post #12

Earlier quoted context omitted.

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.

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.

It is one of my most cherished professional goals to avoid ever working with people who think like this. The message this sends to junior devs is so backwards and wrong-headed that it defies discourse.

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

#107

Post by stormbeta »

placebo wrote: post #98

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…

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.

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

#108

Post by narrator »

rhinoceraptor wrote: post #90
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-pat…

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.

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

#109

Post by 0xmohit »

pjungwir wrote: post #13
spion wrote: post #3

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

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!

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

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

#110

Post by qwer »

stormbeta wrote: post #107
placebo wrote: post #98

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…

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.

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