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-javascript127
Aug 11 '15
Does this mean Netflix is now 100% scripted content? I'll show myself the door
21
u/keystorm Aug 11 '15
Nah, it's just getting shorter runtimes.
3
u/hahaNodeJS Aug 12 '15
For at least this set of benchmarks, JavaScript is, on average, 2X slower than Java. JavaScript is 5X slower for 75% of tests. So, while I appreciate your humor, the opposite is generally true.
3
u/dayjobtitus Aug 12 '15
But he didn't specify benchmarks and while taking into account the entire picture it could be slower, the javascript side of things (the side most impacting arguably outside of the stream itself) would perform better and seamless if done right.
1
Aug 12 '15
While your post isn't a popular one, I agree with you. Java's asynchronous capabilities just don't hold up to JavaScript's.
1
u/I-Code-Things Aug 12 '15
Sounds like they moved a lot of logic to the client side freeing up a lot of server resources.
Also that benchmark is very vague. It says javascript is slower at binary trees. What about them? Constructing them, traversing them? Doing binary searches? Maybe it has something to do with Javascript not having trees and you have to make your own pseudo tree.
Also it doesn't include java vs node server performance. Java has a lot of overhead for making simple requests.
I'm not saying Javascript is a good language for the server by any means. I just think your link is biased and you could find a benchmark that makes javascript look 2x or 5x faster than Java if you wanted.
1
u/igouy Aug 12 '15
Also that benchmark is very vague.
One-click to the source code of each program.
your link is biased
In what way is it biased?
1
u/I-Code-Things Aug 13 '15
In what way is it biased?
Every test includes print statements and setup code which are calculated in the total run time. Not necessarily a big performance hit but in benchmarks that type of stuff should not exist.
Some of the benchmarks use code that was proven in other tests to perform poorly in JS and good in Java. (binary operations, shifts, etc).
Even in JS itself, there are ways to write your code to be much more performant. Scanning through a couple tests showed areas where the JS could be improved significantly.
It's comparing heavyish algorithms where the topic being discussed is using the two languages as serverside languages. Tests related to handling requests under different loads would be more relevant.
Not saying that JS is a fast language at all. Without strict types and having a dynamic compiler, it isn't going to be fast. I'm just saying that showing one person's benchmarks isn't going to convince me that Java is a better server language than Node. Similarly Go often performs much better in benchmarks than Node. However, under normal server conditions (simple rest calls, etc.) their performance is about equal.
1
u/igouy Aug 13 '15 edited Aug 13 '15
Firstly: the claims you make don't seem to be examples of bias in the benchmarks game. otoh when you write - "showing one person's benchmarks isn't going to convince me" - that would be plausible as an example of bias :-)
Secondly:
poorly in JS and good in Java. (binary operations, shifts, etc)
Which tasks, do you say, specify that those operations must be used?
where the JS could be improved significantly
Here's how to contribute your significantly improved JS programs. (Please test that they are significantly improved for the workloads shown, and please diff output against the expected output file.)
0
30
u/kenman Aug 11 '15 edited Aug 11 '15
This is the first mention I've seen of "Universal JavaScript", is that the preferred nomenclature now, or just an enterprisey rendition of "isometric" "isomorphic"? Or are they different somehow?
36
Aug 11 '15
From the article:
As applied to JavaScript, Charlie Robbins presented the idea in 2011. He called it "Isomorphic JavaScript" which has resulted in years of debate over the poor name. In recent months, the term Universal JavaScript has gained acceptance.
2
3
1
u/delta4zero Aug 12 '15
It's a more accurate name according to some
https://medium.com/@mjackson/universal-javascript-4761051b7ae9
0
5
Aug 11 '15
[removed] — view removed comment
23
u/nschubach Aug 11 '15
isomorphic has specific mathematics meaning that doesn't quite match what is going on, but the same JavaScript is being run on the server and client in Universal.
2
u/moreteam Aug 11 '15
It also has a special meaning in sociology. And in math it has multiple meanings. Word have multiple meanings. "Isomorphic" in the context of Javascript frameworks refers to a rendering approach.
2
u/MrBester Aug 12 '15
Because "agnostic" was obviously too contentious a word that wasn't already in use regarding JavaScript /s
2
u/quarterto Aug 12 '15
Trouble is, isomorphisms in the mathematical sense are already a thing in computer science: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
1
u/moreteam Aug 12 '15
Yeah, that term comes up all the time in the context of JavaScript development. That would be truly confusing. /s
25
u/freebit Aug 11 '15
I think the biggest news here is the dropping of Java in a company that was plum full of Java developers.
25
u/awj Aug 11 '15
They dropped it from the server rendering of their frontend website. No mention of anything else. That part is the tip of the Netflix iceberg, I'm sure there's still boatloads of Java making the service happen.
2
u/clarle Aug 12 '15
Many of the rest of Netflix's services are still in Java, but a lot of those services are also open-sourced and very solid.
The Node.js apps communicate with the JVM-based libraries over HTTP through Prana, which is also open-sourced.
The Netflix GitHub organization has the rest of them, as well as a lot of the tools built on AWS that are being used in production today, so definitely check them out!
0
Aug 11 '15
[deleted]
6
2
Aug 12 '15
[removed] — view removed comment
1
u/sgoody Aug 12 '15
I'm noticing Go is getting less attention here on reddit these days... I'm wondering if the shine has worn off. Also, see my comment above
11
u/stormcrowsx Aug 11 '15 edited Aug 11 '15
From the sounds of it they only dropped it from the rendering line. Most of the people who worked in rendering probably knew Javascript as good or better than Java. So it makes a lot of sense for everything rendering to be in Javascript.
Their backend api's and services are probably mostly Java and it wouldn't make much sense to go about rewriting all of that to Javascript.
4
u/fooey Aug 11 '15
If you haven't read their culture slide deck, it's worse than you think.
NetFlix is really mercenary about their employees. They pay top dollar, but there's very little loyalty expected in either direction.
7
u/dsk Aug 11 '15 edited Aug 11 '15
Did they actually drop it or did they drop it from rendering HTML but kept the service APIs Java-based? Because if they did the former, that would be idiotic. The latter makes a ton of sense.
2
u/novagenesis Aug 11 '15
Can I ask why? Our APIs are all in node.js right now and they have scaled fantastically.
Is it just "it wasn't broken, we don't fix it"? I'm assuming whatever they changed was "not good enough".
12
u/stormcrowsx Aug 11 '15
I would think the "it wasn't broken, don't fix it" would apply here.
The list of issues I can think of with moving it all to Javascript: You'd have to retrain all the Java devs to Javascript, you'd move a massive codebase to a language without static type checking (done wrong this is a disaster waiting to happen), and performance wise Javascript isn't going to beat Java by any significant numbers.
None of the cons I list above affect the rendering/frontend side because most Java devs on the front know javascript, rendering HTML in Java is not static type checked typically, and its not crazy fast.
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.
3
u/way2know Aug 12 '15
You hit one blocking call, you're done.
Why would you hit a blocking call if you're writing proper async JavaScript code?
0
u/jimbobhickville Aug 20 '15
Apparently you've never worked on a codebase with other imperfect people.
5
u/fooey Aug 11 '15
If you write blocking code in JS you're doing it wrong.
If you're running Node, it's expected that absolutely everything is done async.
-7
2
u/Calabri Aug 11 '15
I think there's a few layers to the system. Nodejs is perfectly fine as a frontend API - and you can put node in front of Java, but I would assume 90% of the data is cached, and if it's not cached then the node server would probably outsource the task, and that would prevent blocking.
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.
1
u/ioloie Aug 12 '15
Node might not be multi-threaded but there are a number of tools and patterns that allow you to make it multi process which gets you that scalability.
2
Aug 11 '15
Why fix something that isn't broken? Especially since there is a lot of big data stuff for Java. The cost to retrain/rehire/rewrite the back end in JavaScript is pretty high.
1
u/novagenesis Aug 12 '15
I never once said to fix what's not broken. I'm just referencing "that would be idiotic" if they chose to drop Java entirely for some reason. I never implied Java was broken.
Nothing answers the question "is Netflix's Java stack broken". Are you implying that the stack can't be broken because it's Java? If it were a broken Java stack, does my comment on "that would be idiotic" not make sense?
Especially since there is a lot of big data stuff for Java.
Oh absolutely. There's also an ocean between your data warehouse and your web engine. If they're the same piece of code, perhaps your'e doing it wrong.
The cost to retrain/rehire/rewrite the back end in JavaScript is pretty high.
Absolutely. I worked at a shop that fixed a perl app that wasn't broken by picking up a Java team. It was a tremendous waste. Responses to me keep saying not to fix what's not broken, but I never said you should.
1
u/rem87062597 Aug 12 '15
Somewhat related, but they wrote a really interesting article about Node.
1
u/novagenesis Aug 12 '15
Somewhat related, I had to solve the kind of problem (not on Netflix's scale) at one point in the past. It can be ugly in any web engine. New versions of express have promoted router to a first-class citizen, so dynamic route-rebuilds can be done more cleanly now, making it less likely to create a middleware leak. That said, it's a lesson I intend to take to my team because it may be relevant to use sometime. Repeatedly adding the same middleware is bad because node doesn't know to magically collapse the repeated middleware.
5
3
Aug 11 '15
Javascript isn't the same as Java?
/s
5
u/xXxdethl0rdxXx Aug 11 '15
Tell that to a good half of the recruiter spam I get.
1
u/dotpan Aug 11 '15
Same, I figure what they do is have a huge filter where they just type in Java (and Javascript is included in the results) and then email blast.
0
Aug 11 '15
[deleted]
10
3
u/xXxdethl0rdxXx Aug 11 '15
Might wanna take another try at posting there, chief. I'll let you call a mulligan just this once.
1
Aug 11 '15
Forgive my ignorance but I didn't really think you hired or were a {language} developer. Is Java that unique that you hire people that know Java rather than people that know various programming principles and practices and if they don't have to spend the 3 weeks ramping up on Java, that's just a bonus.
I love Python, but sometimes NodeJS is better suited, so I jump into that, gaining pleasure that I'm paid to learn more stuff. Or maybe some Java, ActionScript (shudders) or whatnot.
2
u/juhmayfay Aug 12 '15
I think both are important. It's necessary to be able to pick up different languages and know the basics of static vs dynamically typed, compiled vs interpreted, etc. But just because you can pick up a language in a month and write a program doesn't mean you'll write it well. And that's why you see "<insert language> developer". The nuances, the shortcuts, the gotchas, how to debug quickly, how to tune... Those are learned from experience - even after several years you will still have more to learn.
1
Aug 12 '15
Very fair. So if you know you'll be focusing on one language, you can get veterans of that language.
Now I'm curious how common a job sticks to a language or two vs. how often it changes over time.
1
u/juhmayfay Aug 12 '15
It happens, but I don't think it's common for jobs to completely change languages. Usually they'll pick a language that's good for the field they are in. Completely rewriting code in something else is time consuming and thus very expensive.
4
2
u/myevillaugh Aug 11 '15
I get the value of consistent code, but something seems off. Why was code repeated on both the server and the client? Why were sections the user wasn't going to see rendered in the first place? As written, this sounds like shitty legacy code.
2
u/fooey Aug 11 '15
Fewer round trips, fewer and bigger cache entries
Probably though, it's because building big SPA's without frontloading everything in one big JS file is challenging.
If every page request has to get a new template and script package, you're defeating a lot of the point of using a SPA framework.
2
u/thenumber24 Aug 11 '15
Wappalyzer plugin said that it detected React on Netflix last night, so I'm not surprised they're making the switch
1
u/fooey Aug 11 '15
From what I understand, they're moving all their UI to React for everything they have: web, mobile, roku, consoles, tv's, etc.
They're really going to be giving React-Native a work out, I hope they push all the stuff they're doing back out to the public.
1
u/oculus42 Aug 12 '15
If you look at the source of their UI, you will stop wanting them to push it back out to the public.
1
u/ImAPyromaniac Aug 13 '15
React injects a lot of that stuff, if you get react developer tools, you can see the code they wrote.
2
u/bayhack Aug 11 '15
Wait so they just changed their server side code from some java backend to a JavaScript backend?
16
u/trippel Aug 11 '15
Still a Java backend, but Node is what can be considered the front of the backend.
4
u/fooey Aug 11 '15 edited Aug 12 '15
Node's really great at being middleware for aggregating data from multiple sources and feeding that down to the client.
It's like a denormalizing layer for APIs.
I think GraphQL is really going to promote Node for those sorts of uses.
2
u/trippel Aug 12 '15
Indeed, Netflix has been doing this for a while now, Walmart Labs, PayPal, and even the company I'm working have dropped their Java-based services for Node in this area. It's a really excellent separation of concerns and allows us frontend engineers to have better control over the content we're responsible for.
4
11
5
u/bayhack Aug 11 '15
oh i see the api's and all are still java, but the templating and etc is going to be done in js. sorry just making sure i have a clear understanding of this
1
u/DarkMarmot Aug 12 '15
no -- the web services from client to server are node.js -- the internal web services from server to server inside netflix are java being called by node.js...
1
u/bayhack Aug 12 '15
Yeah that's what I meant all the back end servers are java nd server to client is node.js
7
u/Booty_Bumping Aug 11 '15
Isomorphic javascript means you're rendering the HTML on the server using javascript, then once the page loads, use the same code to make the page dynamic. Doing this makes it easier for search engines, and increases the page load time.
React combined with browserify is a common way to make isomorphic web apps.
2
u/MrBester Aug 12 '15
No. "Isomorphic" JavaScript is simply JavaScript that doesn't care if it runs on the server or the client. What it is used for is irrelevant.
1
1
u/dontfeedthecode Aug 12 '15
It'd be nice if they'd work on making click events for playing videos a bit more responsive, I often have to click multiple times to get videos to start in Chrome when hovering over items in the showreel.
1
u/oculus42 Aug 12 '15
From the article:
Baxter told InfoQ that code quality is of the utmost importance.
From the website:
<div class="slider-item" data-reactid=".1olue1hk2rk.2:$mainViewRTG.$=1$/browse:0.1:$2.1.0.0.0.2.0.$=1$title_70272727_2_1:$item_1"><div id="title-card-70272727" class="smallTitleCard lockup title_card undefined" tabindex="0" aria-label="Death in Paradise" role="link" data-reactid=".1olue1hk2rk.2:$mainViewRTG.$=1$/browse:0.1:$2.1.0.0.0.2.0.$=1$title_70272727_2_1:$item_1.$title_70272727_2_1"><div class="ptrack-content" data-ui-tracking-context="%7B%22location%22:%22homeScreen%22,%22rank%22:1,%22request_id%22:%22386ef08a-424d-4bf1-91d6-4b14962777b9-198704448%22,%22row%22:2,%22track_id%22:13927326,%22video_id%22:70272727%7D" data-reactid=".1olue1hk2rk.2:$mainViewRTG.$=1$/browse:0.1:$2.1.0.0.0.2.0.$=1$title_70272727_2_1:$item_1.$title_70272727_2_1.0"><div class="video-artwork" style="background-image:url(http://cdn1.nflximg.net/images/1777/8701777.jpg);" data-reactid=".1olue1hk2rk.2:$mainViewRTG.$=1$/browse:0.1:$2.1.0.0.0.2.0.$=1$title_70272727_2_1:$item_1.$title_70272727_2_1.0.0"></div></div><span data-reactid=".1olue1hk2rk.2:$mainViewRTG.$=1$/browse:0.1:$2.1.0.0.0.2.0.$=1$title_70272727_2_1:$item_1.$title_70272727_2_1.2"></span></div></div>2
1
u/jodraws Aug 12 '15
My sweet summer child.
That's what you see after it's processed, not the original source.1
u/oculus42 Aug 12 '15
I understand it's the processed output, but it is also a horror show of hyper-repeated information. The
data-react-idattributes account for more than half of the page weight.1
-5
u/IAmALinux Aug 11 '15
Hopefully, this will increase compatibility with Linux!
18
u/xcjs Aug 11 '15
Ah, this actually just changes the language that builds the HTML for the page on the server, although it sounds like they might be doing some client side stuff too.
It doesn't actually change how the video stream is played at all.
7
u/tbranyen Aug 11 '15
It's already very compatible with Linux... Firefox works (as used by Rabbit Cast) and Chrome has been working great for what feels like a year now.
1
1
Aug 11 '15
[removed] — view removed comment
4
4
u/atomic1fire Aug 11 '15 edited Aug 11 '15
On Chrome they use a built in DRM component provided by Wildvine. This runs with HTML5 Encrypted Media Extensions, so no.
On Firefox they use silverlight, but I imagine now they can use Adobe Primetime's Encrypted Media Extension to play movies. edit: Firefox still uses silverlight
Basically it's all html5 now, but they have DRM that makes it so you can't just download videos off netflix and share them.
0
u/lodewijkadlp Aug 11 '15
Lol DRM on Linux?
As if it works :/ Worst case screencap and reencode the whole thing.
Silly, silly people...
2
u/Spivak Aug 11 '15
I don't like it as much as any other Linux user but the goal of DRM has never been to keep people from ripping the content but make it annoying and require technical skill.
The whole industry is built on control and exclusively. It's a slow process to change that mindset.
3
u/atomic1fire Aug 11 '15 edited Aug 11 '15
Actually the only thing stopping compatibility with linux is media codec support.
Chrome on linux already works, in addition you can get a netflix desktop version that basically acts as a windows version of firefox. Plus I assume EME support on firefox for linux should be well on it's way.
There's not really anything hampering netflix on linux other then if you want a dedicated client, but even then the web version works well.
1
-2
u/RankFoundry Aug 12 '15
Just say Javascript for fucks sake. Why do we need buzzwords for everything?
0
Aug 12 '15
[deleted]
0
u/RankFoundry Aug 12 '15
Yeah, coming up with a cringe-worthy term to describe writing JS that can run in two places is so dumb. I can write Java, C#, C++, C and various other languages that can run in multiple environments. We didn't come up with stupid names for those.
0
Aug 12 '15
[deleted]
0
u/RankFoundry Aug 13 '15
Who says you have to say that? Just say Javascript. Nobody says, "Java that executes wherever there's a Java Runtime Engine". This is just stupid.
-6
u/fzammetti Aug 11 '15
Will this make the site not painfully slow in Firefox on my Nexus 7?
1
u/evanbananas Aug 11 '15
I'm curious as to why you wouldn't just get the app at that point?
1
u/fzammetti Aug 11 '15
As I mentioned in another reply, the app doesn't have feature parity with the web site. The app is clearly targeted at streamers only, whereas I do both. So, things like viewing and manipulating my disc queue, searching for things not available for streaming and adding them to my queue, these are things I can't do with the app.
1
Aug 11 '15
No, they were already running with client side templates, the only difference is they had duplication or frustration when they wanted to render the initial page load or some templates on the server so they replaced those server side java templates with duplicates of the javascript templates and render them in node.js such that any page request may be loaded on the server or on the client without any differences.
Netflix was already using React on the browser side, that does not change, basically this means they run React templating on the server as well in cases when they want to render something server side (like for a search engine crawler or for a JSless client or to warm the initial page load)
You should likely be using the Netflix app on an android device.
1
u/fzammetti Aug 11 '15
I would use the app if it was full-featured... I can't modify my disc queue in the app the example. Only on the site can I do that.
2
1
Aug 11 '15
It very well could make the site faster on a tablet. It depends why the site is slow on the tablet. If the initial page loads are completely rendered to HTML on the server, then the initial page might load a lot faster, and you may be able to see the content while the JavaScript is downloading and executing.
0
Aug 11 '15
[deleted]
10
3
u/ianme Aug 12 '15
I get what you're saying, but there is a specific reason for moving to Javascript. You're not going to see Go running all the places javascript is currently running in a year.
3
u/sgoody Aug 12 '15
God, I want to like Go, but it's so firmly entrenched in the imperative world and that's the opposite direction I'm moving towards these days.
I mean I love the idea of Go's interfaces and single binary deployments and I guess the concurrency is ok too, but really the language seems too simplistic to me (I know that was a design goal).
I'll try and get my kicks elsewhere (C#, JavaScript, Rust, Haskell/F#/Ocaml).
I'm thinking that Rust will be the end of Go personally.
2
u/snuxoll Aug 12 '15
Honestly, if they can just get F# ported to .Net core I'll probably be done with every other language in my toolbox except for some occasional Python, Vala and C++ for writing desktop apps (unless someone makes a GTK#3).
2
u/stormcrowsx Aug 12 '15
The language simplicity is what kills go for me too. As well as the binary size. Go isn't a good choice for embedded devices or low level programming, its not fast enough to beat out java, and it has less language features than java. I'm waiting on Rust to mature some more and hoping to give it a try but until then I'll just use c for low level and js/python/java for the rest.
1
u/nidarus Aug 12 '15
Go? Doubtful. The whole reason to switch to JavaScript is you'll have the same code on both the front and back end, not because the language itself is so nice.
Some nicer language that compiles to JavaScript/WebAssembly? That's more or less a given. They even wrote that they're looking into it now.
52
u/pizzzzzza Aug 11 '15
Should probably link to the Netflix blog post about it.