Slashdot Mirror

← Back to Stories (view on slashdot.org)

JavaScript and the Netflix User Interface

Posted by timothy on from the horses-for-courses dept.

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

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

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

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

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

  5. 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.
  6. "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?