r/javascript • u/endpointben • Aug 11 '15

Netflix.com Adopts Universal JavaScript, Drops Java From Rendering Pipeline

http://www.infoq.com/news/2015/08/netflix-universal-javascript
482 Upvotes

96% Upvoted

115 comments sorted by

View all comments

Show parent comments

7

u/jimbobhickville Aug 11 '15

Javascript is very limiting for writing backend services like APIs, even with everything available from NPM. You hit one blocking call, you're done. I generally dislike Java, but it makes a lot more sense for those things than Javascript does. It's not just an "it isn't broken", it's a better tool for the job.

2

u/novagenesis Aug 11 '15

I've noticed no such issues. Most of our calls are handled by the db, not the app. We're using two servers and have incredible load tests. We had plans to 5+5 cluster against our load balancer for scale, and discovered no need.

We calculated our product would scale 5x again before we bottleneck on the app itself with these two threads , at which point we would already have clustered mysql servers. You have to be smart with your code using node, but then the scale comes incredibly easy

The answer to a for loop issue for us was just to add bluebird into the mix. We scale with less work than the company's scala apps

4

u/juhmayfay Aug 12 '15

It's also extremely important to realize the use cases. For simple db operations, sure, node scales well. But if you need to start doing heavy processing before or after your db calls then java will destroy node.

3

u/novagenesis Aug 12 '15

I used to drink that same Kool Aid. "Node's great for I/O, but choose something else for everything else".

Two thoughts on that. First, people are as likely to choose Python as Java for heavy math... While node's math libraries aren't mature, it tends to crush python by orders of magnitudes with apple-to-apple calculations.

But yeah, Java's still faster than node for heavy stuff... But I think there's more caveats than people realize here.

You're not going to make your heavy duty operation as a POJO and start hitting it a million times per minute. Just because node.js gives you great I/O scale for free, doesn't mean there's a bad ROI on careful scale for math.

As I said before, for loops and recursion, you can async them to disable blocking (works for heavy operations as much as it does for database operations).

If it's one massive calculation, instead of millions of big calculations, you have to add a service infrastructure... but you have to setup a JBoss server or the equivalent to handle that scale in Java in a real world scenario.

Maybe Java has higher ROI for big-math scale, but I've discovered the profitable way that it's not nearly as bad for node as the stereotype claims. You're talking a 2-3x, not 2-3 orders of magnitude.

I'm not saying Java is not worth it. There's times when 2-3x is worth the greater programmer-share and greater maintenance. There's also the paradigm shift to node. Some problems don't breakdown well in terms of defers and events. They need to be mapped. Alternatively, some problems don't breakdown well in terms of objects. We're just more trained to normalize to OO more than other paradigms.

I've yet to find a problem that can't be solved in node and can't scale in node. I have often found problems that require rethinking in node.

1

u/juhmayfay Aug 12 '15

Well put. I agree with your comments and agree that node is definitely very capable for many things. If you have a small team and want to do everything in JS, that makes a lot of sense. Plus in most applications, that extra performance usually isn't needed. And if it is, its way easier to just throw another server at it vs rewrite the whole app in a different language. That said, in my experience, working on a large javascript code base with ~15 devs has been a nightmare, while its been pretty easy to do the same with a large java project. Keeps things fun

1

u/novagenesis Aug 12 '15

Sounds like a modularization issue to me. Java gives you that more inexpensively. If you're service-oriented, you probably don't have the same kind of worries about 15 people on the same code base (probably because you're teams of 5 people on smaller codebases).

My team is only 4 right now, so you have it right for that... But an interesting thought is that we also maintain an app as complicated as our .NET team's app, and they're 12 strong... and we have more technical debt that we're paying back than they do (our original codebase was written by 2 junior devs and went live in a weekend, and we only killed the last of that code 2 months ago, if you can imagine what that means)

I doubt our project will ever scale to 15 devs, but if it does, I agree that we would need an architectural change to something more modularized to lessen the headaches.