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

Comments

What browser apps need..

[dotwhynot]

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

Re:What browser apps need..

[Georules]

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

Re:What browser apps need..

[KozmoStevnNaut]

It's the default action for the backspace key for basically every browser ever on Windows, as well as in Explorer windows. I used it that way for a long time, but since switching to Linux where using backspace to go back in history isn't the default, I was annoyed for a little while and then just stopped using it. I have no idea why it's the default on Windows, though.

I did lose a lot of forums posts back in the Windows days due to backspacing while not having the text box focused.

Re:What browser apps need..

[MMC Monster]

I used it that way for a long time, but since switching to Linux where using backspace to go back in history isn't the default, I was annoyed for a little while and then just stopped using it.

FYI, it's still the default behaviour of backspace on Firefox on Linux Mint.

Re:What browser apps need..

[Saffaya]

Who the hell actually uses backspace to go back in history on a website?

Maybe people who navigate windows with the keyboard ?
That's what backspace does in windows explorer.
Go back to the folder you came from.

Re:What browser apps need..

[tlhIngan]

..is to not have a backspace ruin everything you just did just because you didn't have the focus you thought you had (Chrome!)

The big problem is the javascript "rich" editors that mess with browser state saving.

Backspace is a non-issue a lot of the time if you're using standard HTML widgets - every browser I've used from IE, Firefox and I think even Chrome save the state so if you accidentally backspace, you can hit Forward and boom, everything is restored. It's useful if you want to multi-quote Slashdot, for example.

But, rich editors break this functionality. I don't know why. Though, most rich editors work enough that backspace won't leave the page (or they use a javascript alert to keep you from blindly doing it), which is good for accidental purposes, but you lose it all when you return.

Quite annoying, really. Especially since the browsers even return text field contents if you close and re-open the tab (using Ctrl-Shift-T to reopen last closed tab, or reopening a tab from the history). Except well, rich editors. They always blank themselves...

Re: What browser apps need..

[Georules]

Why not just rebind back in history to a button that doesn't have such a high potential to accidentally lose your work in the wrong context?

Re:What browser apps need..

[hackertourist]

You can thank Microsoft for that moronic decision. It's also in e.g. Outlook. Why you would want to map a key that's universally used to delete stuff, to act as "go to the previous view" (and worse, swap between the two behaviors depending on focus) is beyond me.

Golden Hammer

[Anonymous Coward]

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.

Re:Golden Hammer

[Sla$hPot]

JavaScript is more like a sonic screwdriver, where node.js is the tardis and you are doctor who.

Re:Golden Hammer

[gweihir]

And in addition, those using it do not understand how they should actually doing things. Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it. A browser is just a glorified terminal, _not_ processing infrastructure.

Re:Golden Hammer

[Anonymous Coward]

And you can go further with the hammer analogy. The hammer is not a universal tool; you can do lots of damage whailing away with one when really the task at hand calls for something else. Javascript has the merit of being easy to pick up and use (again like a hammer), but its awfully malleable nature (like that golden hammer) works against making robust code. That's bad enough inside of a browser, but now people want to use it for big projects. Yow! It wasn't designed for that! I can think of at least a dozen big flaws, but try this one on for its impact on large projects: a variable that suddenly has global scope because you missed declaring it in a var in a function. Do that twice anywhere in your big system and you've got strange problems.

I shudder every time I think of how policykit (one of those evil friends of systemd) is set up to use Javascript as a scripting language.

Golden hammer: a tool purchased at way too dear of a price and poorly suited for the job.

Re:Golden Hammer

[gweihir]

With real software, I do not have that. Reading comprehension: fail.

Re:Golden Hammer

[Jeremi]

Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it.

I don't see why a browser-base app could not, at least in principle, be as reliable and secure as "real software". As an example, say I write the real application you recommend, and then I also find a way for it to run inside a web page. Will it become insecure simply because there is now a web-browser window wrapped around it?

Re:Golden Hammer

[gweihir]

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.

Re:Golden Hammer

[narcc]

Did everyone forget about Java?

It failed in the browser for good reason.

Re:Golden Hammer

[NotInHere]

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.

Re:Golden Hammer

[jargonburn]

Just the Doctor.

Re: Golden Hammer

[Anonymous Coward]

I write and teach JavaScript for a living. Long ago I thought Java could be the executable cousin the JavaScript. Alas, I was doomed to find a SLOW byte-code interpreter for the sake of multi-platform support. I can tell a program written in Java when running on any platform within 15 seconds just by the drudgingly slow execution speed. More than 10 years later, with many Java engine updates, I've seen only minor improvements. Java is a great teaching language but will never penetrate business applications to any significant degree until it runs faster for the end user.

Re:Golden Hammer

[K. S. Kyosuke]

Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it.

There's no way in which a non-browser client-side application is more reliable or secure than a client-side application in the browser. That is, unless you deliver it as some kind of tamper-proofed USB dongle with its own processing resources (and perhaps even then).

Re: Golden Hammer

[ranton]

Java is a great teaching language but will never penetrate business applications to any significant degree until it runs faster for the end user.

You do realize that Java is the #1 language for enterprise business applications right?

Re: Golden Hammer

[gweihir]

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.

Re: Golden Hammer

[gweihir]

They do, but that is not the primary problem. The primary problem is that these "tools" attract coders that suck.

Re:Golden Hammer

[gweihir]

Somebody has standardized some interface, but that is vastly different from having a generally accepted "standard interface". Seriously, some insight required in this discussion.

Re: Golden Hammer

[gweihir]

Not everything that comes from the NSA is bad. Also, not everything they do can easily conceal backdoors. Some insight into the subject is required to understand what things comming from the NSA are dangerous.

1. Basically, all crypto that uses "magic constants" without a clear and complete spec of how they were reached is highly suspect. That includes most ECC crypto the NSA has done so far and is likely the reason the NSA and some vendors like RSA are pushing for the use of ECC crypto.

2. On a bit more abstract scale, all crypto implementations that do not have their full design and design rationales published are highly suspect. They often represent a compromised design, that, for example, may in some instances get compromised but not in others. ("compromised design", because it is not possible to verify from the outside whether the implementation is compromised or not and there are both compromised and non-compromised implementations that look the same from the outside.) A good example is Intel RDRAND, which is definitely a compromised design. It has a number of design choices that go way beyond "clueless" and must be intentional. The pathetic excuses of the lead developer and the pressure by Intel to use it as the only randomness source basically confirm things: https://plus.google.com/+Theod...

3. But then there are other things. SELinux is an access control layer, and while configuring it is a bit convoluted until you get the hang of it, there is no complex mathematical magic in there that you can use to hide backdoors. In fact, its implementation is rather simple. Hence it can be easily expected, and intentional security flaws will be very hard or impossible to hide. That is why SELinux deserves a high level of trust.

What people overlook is that the NSA is not monolithic. It has its intelligence devision (the evil scum that basically try to take the Internet away by making it as insecure as they can), but they also have a part that is tasked with actually securing IT infrastructure. While the NSA should be disbanded and its former and current leaders should be locked away for life as recognition for all the evil they have done to the human race, they have done and published some pretty good work as well. And as with any government bureaucracy, the right hand of the NSA does not know what the left hand does.

Re:Golden Hammer

[gweihir]

While not impossible to do in principle (see qemu), such a VM is exceedingly slow.

Re:Golden Hammer

[gweihir]

That is just not true at all. Maybe look at what secure software engineering can do these days?

Re: Golden Hammer

[Fnord666]

1. Basically, all crypto that uses "magic constants" without a clear and complete spec of how they were reached is highly suspect. That includes most ECC crypto the NSA has done so far and is likely the reason the NSA and some vendors like RSA are pushing for the use of ECC crypto.

Very true in general. With elliptic curves, you need to use specific curves because randomly selected curves are easily compromised. Only curves with very specific properties are acceptable, but as you point out the NSA has not publicly enumerated those properties. The very same thing happened with the selection of the S boxes in DES, but in that case it turned out that the NSA recommendations did, in fact, harden the algorithm from attacks such as differential cryptanalysis, an analytical technique not publicly known a decade later. Unfortunately the recommended elliptic curves have turned out a bit differently so far and thst shift seems to echo the changing mindset of the NSA and/or the administration that it reports to.

Re:Golden Hammer

[NotInHere]

That "somebody" is W3C. And if Microsoft doesn't implement it in their internet explorer, the fact that it is a "standard interface" is not the fault of "browser vendors", but of microsoft. and browser vendors (even microsoft) have aligned their js implementations.

So yes, there is no "generally accepted" standard interface, when you define "generally accepted" as being runnable on IE8. But when you can afford to say to your users "get a modern browser" (still don't understand why google discontinued their chrome frame), you can use that standard interface. In the meantime, you can write in HTML5 and provide a flash fallback, there are lots of good libraries that provide you with such a solution without much effort from you.

Re:Golden Hammer

[art123]

While literally true, in practical applications, a compiled native binary client application is worlds more secure than a JavaScript client application.

Every person running the JavaScript client has a full debugger sitting in front of them in which they can examine all of the code and change it at run-time.

To do the same to a native binary requires skill in decompiling and assembly language, which even 99% of most software developers do not have.

Even .NET and Java apps that are trivially easy to decompile compared to a native binary are more secure than JavaScript.

Re:Golden Hammer

[martin_dk]

In other words, security by obscurity?

Re:Golden Hammer

[Daniel Hoffmann]

Javascript is a great language but with several minor annoyances. Much like C++ there are some stuff you should not do and some features that if used incorrectly can bite you in the ass. CoffeeScript fixes a lot (but not all) of the problems with Javascript. Node.js on the server is nothing like doing browser javascript.

The real problem is the DOM/CSS/HTML and using Javascript to manipulate it, this mishmash of technologies is the result of years of gradual evolution without a clear pattern (first there was HTML then CSS and Javascript were invented to manipulate it).

Re:Golden Hammer

[Daniel Hoffmann]

> a variable that suddenly has global scope because you missed declaring it in a var in a function
"use strict"? Also I believe that node.js defines scopes by files, not for the whole application.

Re: Golden Hammer

[TheBilgeRat]

I am curious why you choose C and explicitly state !C++... Why not D, then? Heck, why not assembly for the target architecture? Those security issues you have aren't necessarily from the language but for the lack of an effective gatekeeper. If you are building large software, somewhere up the chain should be a benevolent dictator with the power to reject bad code from wherever it may originate. Any language can be abused. In my realm, it tends to be the old C coders who do the most damage because they love whipping out "optimization" tricks or abuse pointers mercilessly. The fact is most schools are graduating java coders for an "enterprise" language, and most haskellers tend to be autodidacts (Not sure of any CS department using functional languages as their go-to enterprise language).

Re: Golden Hammer

[Wootery]

Well of course applets are awful. Pretend they don't exist; that's best for everyone. (With browsers following a trend of making it quite hard to get applets to run at all, even with Java installed, applets essentially don't exist these days anyway.)

Swing/JavaFX aren't that bad. Google's GWT is pretty good. The real use of Java is web-servers and, as ranton states, enterprise business applications.

will never penetrate business applications to any significant degree

I suspect neither of us knows what you're talking about.

Why the hell...

[beelsebob]

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.

Re:Why the hell...

[NotInHere]

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.

Re:Why the hell...

[gweihir]

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.

Re:Why the hell...

[Tablizer]

Why the hell are we still stuck using Javascript...

Because it would take a large group of organizations to cooperate and work together, which rarely happens. Closed source wants to lock out competitors and open source wants to each be their own kings of their own little hills for bragging rights. (Almost nobody really works for "free", they all want either money or credit/status.)

I'd loooove to see a GUI-friendly markup language that is either far less dependent on any scripting or application code for the common desktop-like GUI idioms, or at least is not heavily dependent on ONE language, like JavaScript is per DOM.

But it's probably too big a project for a small group of geeks to get right (or to make good enough to gain traction). Rich GUI kits are not easy to implement. Plus, it probably has to be backward compatible with most of the existing HTML stack. The separation of applet and HTML page is part of what killed Java applets.

Re:Why the hell...

[IamTheRealMike]

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.

Re:Why the hell...

[Intrepid imaginaut]

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.

Re:Why the hell...

[gweihir]

Oh, I do understand the arguments for it, but it still causes a lot more problems than it solves, and hence should not be done, ever. Reliability and security are critical. If you do not have them, stop right there. Wanting "fancy" is not a valid excuse to mess up. And lets face it, most modern web applications have pretty low actual processing needs. An inefficient implementation on the server-side is not a valid excuse to do processing on the client. It is an often used one though.

Re:Why the hell...

[Jeremi]

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

Re:Why the hell...

[StripedCow]

Totally agree with that.

The only problem seems to be the acceptance of NaCl by the other big browser vendors (Microsoft, Mozilla).

Here's what wikipedia says:
(warning: could be outdated)

Reception
Some groups of browser developers support the Native Client technology, but others do not.

Supporters: Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[30]

Id Software's John Carmack praised Native Client at QuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."[31]

Detractors: Other IT professionals are more critical of this sandboxing technology as it has substantial or substantive interoperability issues.

Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no intention of running native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."[32]

Mozilla's Christopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft's ActiveX technology, plagued with DLL hell.[4]

Håkon Wium Lie, Opera's CTO, believes that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."[4]

See http://en.wikipedia.org/wiki/G...

Re:Why the hell...

[washort]

Other languages target Javascript too. It's not as simple as you make it out to be.

Re:Why the hell...

[beelsebob]

The JVM has opcodes for allocating objects and calling methods on them

And there are many languages out there that don't work in terms of objects and calling methods on them ;).

Re:Why the hell...

[DuckDodgers]

Since Java is Turing complete, you can use objects and methods on objects to mimic those other language features.

Re:Why the hell...

[DuckDodgers]

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.

Re:Why the hell...

[DuckDodgers]

Thank you for that link. Interesting. I was aware of about ten projects that compile to or enhance Javascript, but that list is enormous.

Re:Why the hell...

[gweihir]

Well, since of all these sites I use only Amazon and Google, it seems that JavaScript is primary a tool for wasting people's time. No surprise. But who says I refuse to use JavaScript? That is entirely in your mind. I will just call trash trash, even if I use it because there is no good alternative.

Re:Why the hell...

[K. S. Kyosuke]

First JVM is not language-specific:

Meaning that it easily supports (without unreasonable overhead) execution of pointer-based languages such as C, or multiple-inheritance languages such as C++, or dynamic languages (with hash-like objects) like Javascript or Python, or multiple-dispatch languages such as Common Lisp/CLOS, or languages with restartable exceptions such as (again) Common Lisp, or languages with lazy evaluation strategies such as Haskell or Scheme, or languages with continuations such as Scheme, right? Oh, wait, it doesn't - it has fundamental assumptions about how the language running on it should work! Well, guess what, going for a lower-level VM and simulating a virtual CPU removes a lot (even if not all) of these assumptions. That's the whole point of why LLVM was created.

Re:Why the hell...

[K. S. Kyosuke]

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?

But they can't. They either have to look sufficiently like Java in order to be able to run on it, or they have to resort to complicated translation strategies to pretend that they look sufficiently like Java. For example, one of the hallmarks of Smalltalk is the #become: operator that causes an object to be replaced by another object of any class (including fixing all the references to the object from anywhere if it can't be replaced physically in place). That's no problem in a dynamically typed language (the new object just has to provide adequate behavior, and of course you have to know what you're doing) but JVM simply doesn't have any such operation. (A similar thing goes for the CHANGE-CLASS operator in Lisp, or any other operation tweaking existing objects such as redefining a class to add instance fields to all existing objects of some class.) Thus "implementing Smalltalk on the JVM" basically means "implementing a sufficiently castrated dialect that omits anything that can't be done on the JVM " (at least everything that can't be emulated efficiently).

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.

What invokedynamic gives you is allowing you to tweak the dispatch mechanism in a limited way. While sufficient for Python for example, it's still useless for Lisp. It still also requires the use of some complicated translation strategies because it still doesn't make Java objects look like Python dictionaries (with objects of the same class potentially having different instance fields).

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

They're sufficiently close to Java to be runnable on the JVM provided that the developers of the runtime engage in reasonable flesh mortification. That's not the case with many languages. And what's the point of using a different language if it's not providing you any differentiating features?

Re:Why the hell...

[K. S. Kyosuke]

Of course, if you write an emulator for it, anything can be run on the JVM. That doesn't mean it will run at a usable speed.

Re:Why the hell...

[K. S. Kyosuke]

Actually, the "non-bright" person who came up with Javascript based it on Self and Scheme. If only we had more such "non-bright" programmers! The problem was that the design had to be fleshed out basically over a weekend or two, thus causing virtually all the mistakes that were basically impossible to fix since then.

Re:Why the hell...

[K. S. Kyosuke]

AMD64 is at least sufficiently low-level that implementing multi-word arithmetics on top of it is fairly transparent and doesn't incur any unnecessary run time costs.

Re:Why the hell...

[DuckDodgers]

Dynamic languages were under discussion, and the only dynamic language I'm aware of that's slower on the JVM than in its original interpreter is Javascript. The Javascript interpreter Nashorn on the JVM is fast, but not as fast as Chrome's V8 or Firefox's IonMonkey Javascript engines.

For other languages, sure - I imagine Ocaml, Haskell, C, C++, etc... would be slower if they ran interpreted on the JVM.

Re:Why the hell...

[K. S. Kyosuke]

Well, see my other comments: JVM makes such assumptions about the code being run that anything actually interesting is difficult to implement on top of the JVM. And that includes interesting dynamic languages, namely Common Lisp, Scheme, Self, Smalltalk.

Re:Why the hell...

[gweihir]

Thanks, that is exactly what I am saying. If technology is not done sanely, there usually is a huge cost to pay at some time that invalidates all advantaged gotten.

Re:Why the hell...

[gweihir]

I know that. That person has the valid excuse that JavaScript was never intended to be used for anything large or security-critical. It was a quickly hacked-together tool to do small things like changing the color of a button on mouse-over. The problem is all the utterly clueless morons that think JavaScript and the browser are suitable for real computing.

Re:Why the hell...

[NotInHere]

OK, point taken.

Re:Why the hell...

[IamTheRealMike]

So Clojure is not an interesting Lisp-like language? BTW there is a smalltalk for the JVM: http://www.redline.st/discover...

Re:Why the hell...

[StripedCow]

If even half that effort was directed at making PNaCl viable on all browsers, we would be so much further forward.

If you start a kickstarter campaign, I would back it.

Re:Why the hell...

[StripedCow]

Reliability and security are critical.

It is much easier to make a handful of bytecode-instructions secure than it is to make the wealth of what is JS today secure.

Re:Why the hell...

[DuckDodgers]

Common Lisp already runs on the JVM, http://abcl.org/

Re:Netflix DNA

[93 Escort Wagon]

It's not regular DNA - it's Adonis DNA.

Meh

[bhcompy]

I hate it. Makes browser loading/transitions slower than just loading a JVM or Flash(and that's saying a lot), fucks with mobile, fucks with NoScript, screws up common hotkeys like backspace which loses what you've written Google Docs unless you're smart enough to run Lazarus(which you shouldn't have to), etc etc etc. Trying to be slick just makes it worse.

Re:Meh

[Intrepid imaginaut]

The delayed transitions are just shitty resource management from lazy hacks, that's a bunch of plugins loading from hither and yon, and it grinds my gears too.

JavaScript sucks badly

[gweihir]

Do your damn application logic on the server, as it is indented to. Everything else is insecure and unreliable. Really, that something is possible to do does not mean it is by any means a good idea.

Re:JavaScript sucks badly

[Anonymous Coward]

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

I guess you expected the slashdot servers to correct that?

Re:JavaScript sucks badly

[gweihir]

For most things, that is actually not true. For the few things that need to beat the interaction limit (~200ms), a web-application might not be the right choice in the first place.

While I fully agree on the server-side validation, one thing the client cannot be trusted to do either is keep your web-app isolated from others, which basically invalidates the whole idea for anything serious. Really, a web-browser is not a VM, even if often misused as such these days. If you need that fast response, probably best move away from the idea of doing it as a web-app, especially as the browser does not ensure fast response either. Unless you want to start coding for a specific browser in a specific version running on a specific platform?

Re:JavaScript sucks badly

[gweihir]

"I want" is not a valid excuse for using fundamentally defective technology. It is just an expression of egomania.

Re:JavaScript sucks badly

[gweihir]

It is also cheaper to have your client's browsers get hacked than your servers. But you are right, the bean-counters are at the root of most evil these days.

Re:This is really quite stupid

[gweihir]

Indeed. And with server-side generated clean HTML, you also get rid of all the browser issues. This is really another example of technology being misused to (badly) cover up architect, designer and coder incompetence.

Re:Its good

[gweihir]

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.

Re:Netflix DNA

[gweihir]

So you man all looks and no function?

Bytecode not Textcode

[kervin]

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.

Re:Bytecode not Textcode

[diamondmagic]

I'm pretty sure that's what Java was supposed to be.

In any event, the problem they're discussing isn't unique to JavaScript/ECMAScript, it would plague a bytecode solution too... They're deciding to send all the dependencies they could possibly need over the wire before they know they'll need them, instead of deciding which ones to send on the server-side when the page is requested.

Javascript

[BitcoinBenny]

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.

Re:Javascript

[Bill Dog]

Well, whatever emerges, will be about enabling the less-skilled (in software engineering), and hence lower paid, to take up programming.

But I shuddered when Google I think it was was making some kind of Java to JavaScript translator. I thought people who only knew and only cared to know Java would end up having much of the software industry catered to them, to where development ceased in the languages of other environments.

Now I'm wondering if it'll be js instead. I wouldn't be suprised if next there'll be a js way to query and manage relational databases, so that "JavaScript Engineers" don't have to learn SQL DDL and DML.

Re:Javascript

[BitcoinBenny]

Oh this is already happening. The node.js stuff is bridging javascript to every ORM, DB, and NoSql technology that exists. It is just an unfortunate reality but I fully expect it to eclipse every other language in terms of popularity over the next ten years, for exactly the reasons you state. Driving down the cost of labor, and unifying skill sets so that people are even more interchangeable.

Browser Apps are NOT desktop apps

[BitZtream]

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.

Re:Browser Apps are NOT desktop apps

[StripedCow]

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.

Re:Browser Apps are NOT desktop apps

[Fwipp]

Most browsers actually support web-workers: http://caniuse.com/#feat=webwo...

And there are a bunch of wrappers to make them feel more like regular threads. Easy-peasy.

Re:Browser Apps are NOT desktop apps

[StripedCow]

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.

Re:Browser Apps are NOT desktop apps

[narcc]

This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.

Only if the developer is a total moron.

To be clear: I'm not talking about web-workers.

Re:Browser Apps are NOT desktop apps

[StripedCow]

You're probably still running Windows 3.1, with pre-emptive multitasking.

Re:Browser Apps are NOT desktop apps

[Fwipp]

Oh no, you've invented a contrived scenario in which you assert there will "surely" be a performance penalty, therefore the model is entirely unacceptable.

Maybe you should just, you know, leave the text in the non-GUI worker to start with? Or you can incrementally update the background thread as the data changes. I'm not even positive that postMessage() doesn't execute concurrently with the calling thread, as I'm sure the JIT could do.

Re:Browser Apps are NOT desktop apps

[Mr. Mikey]

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?

Re:Browser Apps are NOT desktop apps

[Shados]

Atom editor isn't as good as more mature equivalents, but its close.

Adobe has a tool to create responsive website mockups thats also all in javascript/html while still being a desktop app, I forget its name.

A lot of stuff is done in Node-Webkit, and in many cases you probably don't even know.

Re:Browser Apps are NOT desktop apps

[Shados]

A lot of AAA videogames have been done single threaded. Web apps can be done the same way.

Have the action change the state, and use requestAnimationFrame to update the UI nicely, v synced. 60 frames per second is enough to feel snappy. Of course, all I/O is already happening asynchronously, and for the very few cases that are left, you can use workers.

Re:Browser Apps are NOT desktop apps

[Shados]

Adobe Reflow was what I was thinking of*

Re:Browser Apps are NOT desktop apps

[narcc]

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?

Re:Browser Apps are NOT desktop apps

[thetoadwarrior]

Agreed. They're very basic and don't work offline. The only reason I could see that someone would prefer web apps is because they want the NSA to have their data.

Re:Browser Apps are NOT desktop apps

[StripedCow]

Maybe you should just, you know, leave the text in the non-GUI worker to start with?

Let me get this straight. This means that when the user scrolls the document, the web-worker would feed the GUI with lines of text incrementally (?)
However, if, at the time of scrolling, the web-worker would be busy counting words in the document, I don't see how the GUI would not *effectively* freeze just as well (the main thread would be waiting for new lines from the web-worker which is busy counting words).

Or you can incrementally update the background thread as the data changes.

This is like splitting up the task of counting words into smaller tasks that execute incrementally.
"Splitting-up tasks" is the keyword here, and the thing is, that's what threads are supposed to do. If we split up all our tasks manually, we wouldn't need threads.
The web-worker thread-model is not really helping, because we'd have to split up tasks anyway ourselves.

Re:Browser Apps are NOT desktop apps

[Fnord666]

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.

Re:Browser Apps are NOT desktop apps

[KozmoStevnNaut]

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.

Re:Browser Apps are NOT desktop apps

[StripedCow]

The problem is that "threads" are supposed to be a solution to dividing work.
If you don't have threads, how will you divide work without ruining the nice hierarchical structure of your code?
You'll need a special compiler that does this for you. And the result will be *slow* (albeit perhaps more responsive).

Re:Browser Apps are NOT desktop apps

[Mr. Mikey]

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.

Re:Browser Apps are NOT desktop apps

[narcc]

The problem is that "threads" are supposed to be a solution to dividing work.

Yes, but it's one of many solutions, and certainly not the best in every case. Threads come with their own set of problems, after all. They're no panacea. It's your job to understand the benefits and drawbacks of threads, and alternative solutions, and pick the best approach for your project. As threads are not an option in JS, it's a great opportunity for you to explore various alternative approaches. Tossing up your hands and saying "I must lock the UI!" is silly, particularly when it's clear that other applications don't seem to share that problem.

Lets face it: If your code locks the UI, you have a serious problem with your code! Go do some reading about asynchronous programming and event-driven programming. You'll find it quite helpful. Your users will thank you as well.

Re:Browser Apps are NOT desktop apps

[Fwipp]

Sure bud, you have one central non-gui worker, which the GUI thread communicates with and dispatches shit to other workers that need to process stuff. You store a bit of "extra" text (probably 50 pages would easily fit) in the GUI and make requests when it gets closer to the end.

Just because you can't think of a way to solve a particular problem you've just thought of, doesn't mean that high-quality performant programs can't be written in the language. You haven't worked with any other message-passing model, have you?

Re:Browser Apps are NOT desktop apps

[StripedCow]

A customer just called. He pressed "Ctrl+End" to go to the end of the document, while it was counting words. He complains that the user interface is frozen.

Just because you can't think of a way to solve a particular problem you've just thought of, doesn't mean that high-quality performant programs can't be written in the language.

Yes. But because of this problem of the (fictituous) customer, I now have to rewrite my 30.000 lines of code from web-worker style to single-threaded asynchronous style. Unless you have a better idea :S

Re:Browser Apps are NOT desktop apps

[StripedCow]

As threads are not an option in JS, it's a great opportunity for you to explore various alternative approaches.

Please don't forget that the whole point of my comment was that threads are broken in JS.

Go do some reading about asynchronous programming and event-driven programming.

The problem with event-driven/asynchronous programming is that it requires a lot of work, and makes your code look awkward. For example, a simple "for" loop turns into a monster of functions calling eachother, in order to break the inside of the for-loop into small chunks that can't lock the UI. Now imagine a doubly-nested for-loop. You'd need special compilers to keep your code clean.

Remember that Windows 3.1 was replaced by true multitasking for a reason.

Also, asynchronous code can only make use of 1 core of your CPU, which is also a waste.

Re:Browser Apps are NOT desktop apps

[narcc]

Please don't forget that the whole point of my comment was that threads are broken in JS.

That's new. Here I thought it was this:

The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. [...]
This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.

Which is, of course, total nonsense.

For example, a simple "for" loop turns into a monster of functions calling eachother, in order to break the inside of the for-loop into small chunks that can't lock the UI. Now imagine a doubly-nested for-loop. You'd need special compilers to keep your code clean.

Which is also total nonsense. I'm sorry, but your assumptions simply don't match reality. Where did you come up with this stuff?

Again, I recommend you go do some reading about asynchronous programming and event-driven programming.

Re:Browser Apps are NOT desktop apps

[StripedCow]

The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language.

The language is single threaded, doesn't mean it can't support "threads" in a message-passing way. The fact that my old Apple ][ can support threads by hooking 2 of them up through a serial interface doesn't make them "multithreaded". But if you want to look at it that way, then I apparently can't stop you :)

your assumptions simply don't match reality

Ok, so if a "for" loop is transformed so easily into an equivalent asynchronous structure, please enlighten me and show me how.
For example, take these simple nested loops, and I'm curious what code it transforms into.

function f(x)
{
    for(var i = 0; i < N; ++i)
        for(var j = 0; j < N; ++j)
            for(var k = 0; k < N; ++k)
                x = g(x, i, j, k);
}

where g is some constant-time function.

Re:Browser Apps are NOT desktop apps

[StripedCow]

(I forgot to add "return x;" inside the function, but I guess that's clear)

Google has a love/hate relationship with JS

[Tenebrousedge]

Isn't that more or less the idea behind NaCl/Native Client? It doesn't seem to have caught on. For that matter, there was also ActiveX, and the best that you could say about it is that it had a flawed implementation.

Chrome also just added a runtime for Android apps, which seems to handle at least some simple apps at native speed on my chromebook. I suppose that's a java runtime of some sort?

I know that there are many wonderful things done daily in JS, but I really would prefer another scripting language.

Re:Google has a love/hate relationship with JS

[K. S. Kyosuke]

I suppose that's a java runtime of some sort?

Actually, it's based on exactly the Native Client environment that you said hadn't caught on. :-p

Re:Google has a love/hate relationship with JS

[Tenebrousedge]

I was wondering about that, but I didn't manage to find any information. Do you have a link handy? And maybe information about the differences between Google's stuff and ARChon?

When I said that it hadn't caught on, I meant that other browser vendors were not interested in implementing NaCl.

Re:Google has a love/hate relationship with JS

[K. S. Kyosuke]

Arstechnica quotes some unnamed Google guy. Haven't looked at ARChon yet. But implementing an Android runtime for Chrome in PNaCl is a no-brainer, now that Android's native ART runtime uses LLVM bitcode somewhere inside (which "coincidentally" is what PNaCl can consume, with some limitations). You just have to provide some API libraries for to link the Android app against.

Spaces not tabs

[Frankie70]

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

And use spaces not tabs.

Javascript?

[0123456]

Man, web apps are so early 2000s. We're all running local apps on tablets and phones now, dudes.

asm.js

[jopsen]

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 :)

Getting better

[WinstonWolfIT]

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.

In defense of Javascript

[jopsen]

I fully expect it [Javascript] to eclipse every other language in terms of popularity over the next ten years, for exactly the reasons you state. Driving down the cost of labor, and unifying skill sets so that people are even more interchangeable.

It pains me to say this, but Javascript is not that bad... I used to really hate it; but over the last year I've done a lot of node.js development. And if done right, it can be really nice. I usually write classes that takes a JSON object and does something... Then I can be very declarative when I put things together. Also asserts helps :)

But yes, static type safety seems to be underrated these days.

As for driving down cost of quickly writing something, I think that is good... Lots of administrative tasks, etc aren't done electronically because it's too expensive to write a shitty web-application. Don't be afraid for your job, the need for qualified developers won't disappear... Mostly there'll probably just be more tasks that it is feasible to develop (at least that is also a factor).

Re:In defense of Javascript

[Bill Dog]

I for one (and maybe the only one on Slashdot!) never hated js, always liked it, I just don't feel it belongs outside where it was invented, because it has compromises due to what is was created for, where outside that environment there are much more suitable choices. Neither would I like seeing SQL turned into a language across other layers of an application.

And I understand your point that less cost in development opens up more things for it to be economically sensible to automate. I just don't want my occupation to turn into writing shitty code for every little thing.

Re:In defense of Javascript

[BitcoinBenny]

I know you can write good software in Javascript. I wrote my file transfer plugin for gmail SenderDefender for the curious, entirely in Javascript, but it seems to me that going forward well defined interfaces and something like NaCl / PNaCl could really change the landscape. I'm hoping that happens not because I'm afraid javascript will take my job, but that there won't be any other options for the web. I think the points you make are good, but don't you think the javascript software quality is generally lower than the other languages? Its entirely subjective, but with few exceptions I find many Node projects to be very rough.

Re:In defense of Javascript

[narcc]

And if done right, it can be really nice. I usually write classes

Just wait, it gets even better once you learn the basics...

Re:In defense of Javascript

[Jaime2]

It pains me to say this, but Javascript is not that bad... I used to really hate it; but over the last year I've done a lot of node.js development. And if done right, it can be really nice.

That roughly translates to ...

"I used to think that JavaScript had a rough learning curve, with all the pitfalls that lure novices in, but now that I know the language it doesn't seem all that hard to pick up."

JavaScript isn't bad because you can't do something right, it's bad because it's so easy to do something wrong. Being successful using it only shows that you have developed the habits and tools to navigate it's minefields, not that it doesn't have tons of minefields. JavaScript is one of those languages that you can pick up in an hour, but still be clueless about how it works a year later.

about:config, browser.backspace_action=2

[tepples]

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.

"Real piece of SW" for which platform?

[tepples]

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?

Expand and collapse

[tepples]

For the few things that need to beat the interaction limit (~200ms)

What about things that don't absolutely need low latency but still need to complete without an explicit form submission and complete page reload, such as autocompletion of search terms or expand/collapse of replies to a post in a threaded discussion board?

a web-application might not be the right choice in the first place. [...] Unless you want to start coding for a specific browser in a specific version running on a specific platform?

A not-web application needs to be coded for an even more specific platform than a web application. Make it for Mac, for example, and you exclude users of Windows desktop, X11/Linux, Windows Phone, Windows RT, iOS, and Android.

JavaScript is teh SUX!!11

[bigsexyjoe]

Oh, wait. I'm trapped seven years in the past.

JavaScript is wicked fast, has first class treatment of functions, JSON and the object model are beautiful, and its duck-typing supports great mixins patterns. JavaScript is now outside the browser with Node.js. The Node people made some awesome wise design decisions and Node is awesome. In spite of stupid haters, JavaScript just keeps getting bigger and bigger and racking up more successes. It beat Applets, Flash, VBScript, and challengers not worth mentioning to dominate the web. And it is not only on the server now but is showing itself to be in many ways better than other server side languages such as Ruby, Python, and Java. JavaScript is probably the number one language that old code is being refactored into and this isn't just because browsers support it. Other languages can compile to JavaScript, but no one cares because JavaScript is just that awesome. If there is one language that is exciting to follow these days, it is JavaScript.

BUT TEH === ! IT SUX!!

Re:JavaScript is teh SUX!!11

[Jaime2]

JavaScript has lots of good features. But, it also has automatic semicolon insertion, strange type coercion, eval, and no block scope variables. All of these features entice those who don't know any better to write really bad code. It's like pointers in C - not an inherently bad thing, but out of place in business code where reliability is more important than speed. Because of JavaScript's position as "the default language of the web", these features would be incredibly difficult to fix without losing that status.

Re:Netflix DNA

[pete6677]

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

Re:Only Node.js is webscale

[Billly Gates]

That is why hipsters love it as a bad ass Rockstar technology.
http://m.youtube.com/watch?v=b...

Re: Because it's WEB SCALE on the server

[Billly Gates]

It is a badass Rockstar technology

Re:To those who mock Web applications

[KozmoStevnNaut]

Did you choose the "sketchy" type in the pencil settings, by any chance? Try using the "plain" type instead :-)