Slashdot Mirror


JavaScript and the Netflix User Interface

CowboyRobot writes Alex Liu is a senior UI engineer at Netflix and part of the core team leading the migration of Netflix.com to Node.js. He has an article at ACM's Queue in which he describes how JavaScript is used at Netflix. "With increasingly more application logic being shifted to the browser, developers have begun to push the boundaries of what JavaScript was originally intended for. Entire desktop applications are now being rebuilt entirely in JavaScript—the Google Docs office suite is one example. Such large applications require creative solutions to manage the complexity of loading the required JavaScript files and their dependencies. The problem can be compounded when introducing multivariate A/B testing, a concept that is at the core of the Netflix DNA. Multivariate testing introduces a number of problems that JavaScript cannot handle using native constructs, one of which is the focus of this article: managing conditional dependencies."

28 of 195 comments (clear)

  1. What browser apps need.. by dotwhynot · · Score: 5, Insightful

    ..is to not have a backspace ruin everything you just did just because you didn't have the focus you thought you had (Chrome!). And to work offline as good as online. Take email as an example. I really like using travel time to catch up on, reply to and delete email. But often travel time does not have internet access (train, plane). For now, email clients are superior to web email because of this.

    1. Re:What browser apps need.. by Georules · · Score: 4, Insightful

      Or maybe just unhook backspace from "Back in History". Who the hell actually uses backspace to go back in history on a website?

  2. Golden Hammer by Anonymous Coward · · Score: 5, Insightful

    It's unfortunate that Javascript has become the embodiment of the Golden Hammer in the programming world. And, just like a hammer made of gold, it doesn't even work that well as a hammer. It is only so widespread because when it comes to the web, it's the only tool you have.

    1. Re:Golden Hammer by gweihir · · Score: 2

      You are right in principle. All it takes is to make the browser a real VM environment with security guarantees, a standardized interface, etc. But that is not going to happen anytime soon, because virtualization technology is not there yet and pretty complicated, and a browser does not have VM isolation and reliable execution as primary tasks. In fact, if you remember, a browser's primary task is rendering HTML.

      I do expect that some day, many browsers will come with a standardized sand-box that does fulfill all these requirements, but they do not these days and JavaScript is not, by any measure, even a reasonable approximation. I think getting there will at least require a stall in browser development (because they are finished) for several years. That seems to be quite some time in the future.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Golden Hammer by NotInHere · · Score: 2

      You are right in principle. All it takes is to make the browser a real VM environment with security guarantees, a standardized interface, etc. But that is not going to happen anytime soon,

      ... because the standardized interface has already happened, or is happening: https://wiki.mozilla.org/WebAP...

      The fact that browsers have such a large userbase, and its incredibly easy to make browsers execute potentially evil javascript, js is one of the most secure and best sandboxed languages that exist, that is still powerful. OK there are things as canvas tracking, and webgl shaders. But show me something that supports truly secure accelerated graphics.

      When I run my browser, I choose which file to upload. A program running on my computer can read every file I can read. When an application wants to access my webcam, it asks me. On the desktop the application simply accesses my webcam. On X.org you can even write a keylogger without having extra privileges.

    3. Re: Golden Hammer by gweihir · · Score: 2

      Yes, because the dumbest programmers and most IT-challenged managers are found there. Hence it is no surprise they standardized on using the worst tool available that just about can still get the job done. And yes, from code security reviews of quite a bit of "business" Java code for decidedly "enterprise" settings, I do know what I am talking about. I have never seen anything so stupid anywhere else as what I routinely find in Java "enterprise business applications".

      An excellent reason to use C (not C++) for business applications is that then you avoid all the really dumb "coders", because they cannot get anything to work with it. An equally valid choice with better productivity would be Smalltalk, Eiffel or Haskell. In all these cases you need coders with a clue. They tend to be more expensive, but only per hour. In overall project cost, they are far, far cheaper.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  3. Why the hell... by beelsebob · · Score: 4, Insightful

    Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine (not a language specific one like the JVM), that we can compile any language we like to? Half the world is trying to hack around javascript's shortcomings. If even half that effort was directed at making PNaCl viable on all browsers, we would be so much further forward.

    1. Re:Why the hell... by NotInHere · · Score: 4, Insightful

      First JVM is not language-specific: http://en.wikipedia.org/wiki/L...
      Second, javascript can be the compile target of LLVM bytecode. You can compile your favourite C program to js. See emscripten: https://github.com/kripken/ems...
      Third, javascript has a very fast but still backwards compatible bytecode like subset called asm.js: http://en.wikipedia.org/wiki/A...
      asm.js can be set as target for emscripten. The browsers supporting asm.js simply JIT it to bytecode, and those which don't still can run asm.js, but way slower.

    2. Re:Why the hell... by gweihir · · Score: 2, Funny

      Simple: Client-side executable content in web-pages is an exceedingly stupid idea, so all the bright language designers stay away from it. Hence it is JavaScript for all those that do not understand how to do a web application right.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Why the hell... by IamTheRealMike · · Score: 4, Informative

      The JVM is very language specific. For example it has op codes for allocating java objects. A truly cross language virtual machine doesn't have anything anywhere near that high level or specific to a particular language.

      Whuuu? The JVM does not have opcodes for allocating "java" objects unless you use a very strange definition of the term - if it worked that way then how could other languages target it? The JVM has opcodes for allocating objects and calling methods on them, including opcodes like invokedynamic that exist purely to support non-Java languages like Javascript, Python, Ruby, etc.

      The JVM has a really large variety of languages that target it. It's impressive. There are static languages like Java, Scala, Kotlin, Ceylon etc, there are dynamic scripting languages like JS (using the new Nashorn engine it's only about 2-3x slower than V8), there are Lisp like languages, there are implementations of Erlang and so on. And thanks to the fairly well specified "least common denominator" type system Java provides, code written in these languages can all interop pretty nicely.

      If you think the JVM is language specific then I'd suggest looking at Ruby and Kotlin, two very different languages that are not much like Java, yet nonetheless both can run on top of the JVM.

    4. Re:Why the hell... by Intrepid+imaginaut · · Score: 4, Insightful

      It has a lot of merit, especially if you're trying to do anything fancy. Getting the needed processing power from the client, especially in this day and age of overpowered commodity hardware, rather than the server frees up the server to do more important jobs, and really as long as you're sanitising properly inputs why not. What's really needed is a proper push routine but that comes with its own tangled web of problems.

    5. Re:Why the hell... by Jeremi · · Score: 4, Informative

      Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine (not a language specific one like the JVM), that we can compile any language we like to?

      JavaScript is the 'bytecode' to compile to these days.

      Not saying that's optimal, but if JavaScript is what the world's web browsers run, then JavaScript is what people will target to get onto those web browsers. At least you can still use your language of choice to do so...

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    6. Re:Why the hell... by DuckDodgers · · Score: 2

      You will be sitting in the corner holding to your best practices and ideals while the world uses Facebook, Twitter, Google Mail, Office 365, Google search with autocomplete, Netflix, Youtube, Hulu Plus, Ebay, Amazon, and a hundred other websites that make extensive use of Javascript.

  4. Re:Its good by gweihir · · Score: 2

    Idiots trying to be cool are still idiots. On the other hand, the content industry is in such a bad shape, that cool idiots may be an improvement.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  5. Bytecode not Textcode by kervin · · Score: 3, Insightful

    Browsers should not standardize on a particular programming language, but rather on bytecode. But no one wants to use the other's Bytecode solution ( although we have sever great bytecode standards to choose from ) so we're stuck with Javascript.

  6. Javascript by BitcoinBenny · · Score: 2

    Ah Javascript. The language we all love to hate, but isn't going anywhere. It seems like a good portion of all development will be Javascript in the not-too-distant future as legions of low paid programmers take up code writing and maintenance.

  7. Browser Apps are NOT desktop apps by BitZtream · · Score: 3, Interesting

    Lets stop pretending they are anything close.

    Google docs/sheets/whatever is a really crappy imitation of a full fledge office suite ... from 15-20 years ago. It doesn't even compare to Office 95 other than it has online sharing and collaboration, which is great, except thats a tiny subset of what its actually used for.

    Just because you can make a half assed, no where near feature complete but looks pretty and does the first 3 things that come to mind look-a-like of an desktop app doesn't mean its a desktop replacement.

    There are no desktop applications 'written entirely in javascript' unless you redefine what a desktop application is to fit a narrow subset of what everyone else does.

    Learn to use the right tool for the job and stop thinking just because you can make something look-a-like and emulate a few basic functions that it is the same thing. A screwdriver can be used as a hammer, but it makes a shitty hammer. Google docs CAN be used in place of a full fledge office suite, but it makes a shitty office suite when you replace one entirely. Most geeks who use 'office suites' don't actually use office suites, they occasionally type a few pages into a word processor, sure but they don't do the same things as your full time paper pusher.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    1. Re:Browser Apps are NOT desktop apps by StripedCow · · Score: 3, Insightful

      Lets stop pretending they are anything close.
      Google docs/sheets/whatever is a really crappy imitation of a full fledge office suite ...

      The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. It's like going back to the 80s.
      This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.
      In this day and age, this is totally unacceptable.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    2. Re:Browser Apps are NOT desktop apps by StripedCow · · Score: 4, Informative

      Web-workers are not cutting it. For the following reason.
      Real multi-threaded programs have a shared address space. Web-workers do not.

      Example: suppose your GUI runs on a 1 megabyte long text-file.
      The data-structure that models the text-file is 2 megabytes long.
      Now you want a web-worker to do something with this text-file in the background (e.g., count the number of words).
      So you start a web-worker thread. But then you need to send the text-file as a message to the thread (since there is no other way the thread can reach the data).
      Sending this 2 megabyte chunk of data will surely freeze your GUI for a while, and so the whole point of multiple-threads is mostly lost.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    3. Re:Browser Apps are NOT desktop apps by Mr.+Mikey · · Score: 3, Interesting

      And yet, I use Google Docs on a regular basis... and find it sufficiently powerful, reliable, free, and with the features I need. If you'd like to create a competing product, please do... otherwise, just what are you bringing to the table?

      --
      wants to be the first monkey to touch the monolith
    4. Re:Browser Apps are NOT desktop apps by Fnord666 · · Score: 3, Insightful

      Oddly enough, that makes my point. That "problem" was solved ages ago. Why is that we've seemed to have collectively forgot old, but excellent, solutions to common problems?

      Because three week crash course dev school graduates won't have a clue what pre-emptive multitasking is.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    5. Re:Browser Apps are NOT desktop apps by Mr.+Mikey · · Score: 2

      Because of convenience. Updates and new features are added automatically, and the developers only have to deploy a single copy to know that everyone has the latest features and bugfixes, instead of having to rely on people updating their local copies. And as long as you have access to a computer with an Internet connection, you have access to the apps you're used to.

      Of course there are downsides, but local software has downsides too. It all comes down to your user profile, and for most people, Google docs has all the features they need. For power users, you have locally-installed applications with larger feature sets and harder learning curves.

      Also, with Google Docs I have full access to my content anywhere, on any device... and, again, all for free. Desktop software, in these respects, is hardly superior.

      --
      wants to be the first monkey to touch the monolith
  8. Spaces not tabs by Frankie70 · · Score: 4, Funny

    Do your damn application logic on the server, as it is indented to.

    And use spaces not tabs.

  9. asm.js by jopsen · · Score: 2

    Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine...

    asm.js is a subset of javascript that is easily translated to low-level instructions... And runs at near native speed in browsers that optimize asm.js.
    Don't get me wrong, I totally agree that asm.js is a messed up construction... One can think of it as a bytecode encoding in Javascript...
    But it works, it's fast, and it's backwards compatible... Though anyone trying to use large asm.js programs in browsers with a poor javascript engine will get an extraordinary poor performance :) In in practice it might not be "backwards compatible" as speed is a feature.

    Anyways, why not? It works :)

  10. Getting better by WinstonWolfIT · · Score: 2

    As an old-school back end specialist, I hated the spaghetti runtime error aspect of Javascript -- until I started decoupling various aspects using, for instance, AngularJs. Lack of compile-time checking is an increasing part of even compiled languages like C# (dynamic, reflection), but since AngularJs supplies dependency injection, sanity has returned to the logic that needs to be in the front end. As I've increasingly shifted page loads to Ajax calls, my pages have become sweetly responsive even on slow (mobile) connections, and the turnaround time of a Javascript code change is often simply that of saving a file and refreshing the browser page, compared to starting a new session from scratch on a compiled back end change. It's also no contest on the turnaround of compiled vs Javascript unit tests.

    The decoupled nature of AngularJs leads to remarkably few actual moving parts or Hail Mary references ala jQuery. The last logical step is whether or not Ajax calls are to node.js, but since back end Javascript is as testable as anything out there, it comes down to preference and the maturity of the back end framework.

  11. about:config, browser.backspace_action=2 by tepples · · Score: 3, Informative

    In my copy of Firefox on Xubuntu, backspace does nothing if a text area isn't focused. If I want to go back I can press Alt+Left. When I started typing this post, I didn't know if it's default or if I had previously done what is described on the first result from Google firefox disable backspace. Short answer: put about:config in the location bar, put backspace in the search bar, and change the value of browser.backspace_action to 2 (nothing). Turns out it defaults to 0 (navigate back) on Windows and 2 elsewhere since late 2006.

  12. "Real piece of SW" for which platform? by tepples · · Score: 4, Insightful

    If you really need client-side processing, do a real piece of software for it.

    For which platform shall this "real piece of software" be developed? Windows (desktop), X11/Linux, OS X, Windows Phone, iOS, Android, Windows Store, or something else?

  13. Re:Netflix DNA by pete6677 · · Score: 2

    Why do hipster designers insist on dumbing down the entire internet by removing useful features and replacing them with worthless JavaScript pages?