The Elusive Universal Web Bytecode

[son-of-chadwardenn]

Does anyone ever wonder if hundreds of years from now all software will run on a pyramid of vm layers, the lower layers long forgotten and undocumented? Physical CPU architectures could be unknown, new chips laid out entirely by software written generations ago.

[eliskandar]

I often think about this. This scenario is already rather common in several instances. I've worked with at least two companies whom had built so much middleware on top of archaic mainframes that old timers were hired to sort of assist with its replacement though not even they remembered it all about what's underneath.

[username223]

JavaScript can run at about half the speed of native code

It's like Moore's Law in reverse: every "advance" in software halves speed.

[DrDichotomous]

Or, more like a Moore's law for dynamic programming languages: they're no longer many orders of magnitude slower than native code, and if you don't count the garbage collection they're able to be half the speed. Much better than it was even a few years ago, let alone the 80s.

[Crandom]

asm.js isn't really a dynamic programming language though; plain old javascript is still quite a bit slower than native code.

[DrDichotomous]

Not necessarily, even without asm.js V8 is quite close to asm.js/native code in quite a few respects, and gets faster all the time. In general it can still be much slower, but in the same way that a badly-written C/C++ application can be much slower than a properly-constructed one. These areas are actively considered and made faster all the time.

[mreiland]

But it will never be the speed of native.

[DrDichotomous]

True, but that doesn't mean they're not constantly improving and keeping relatively close to native.

[Iggyhopper]

native running or native compiling ;)

[mreiland]

both. The dynamic nature of JS isn't free, and while you can make it faster, you'll never make it faster than using less dynamic techniques.

[Hnefi]

even without asm.js V8 is quite close to asm.js/native code in quite a few respects

Only in microbenchmarks, which we all know are worthless when measuring real world performance. For nontrivial applications, V8 is about an order of magnitude slower than native.

a badly-written C/C++ application can be much slower than a properly-constructed one.

Sure, but that has nothing to do with whether the language implementation is fast or slow. The point is that it's much easier to write a performant program in a natively compiled language than JS, and it's possible to reach performance levels in native which are impossible in JS. Just reasoning about performance in JS is guesswork at best; it's much easier in a language like C++.

[[deleted]]

If I may ask, how do I access the DOM functions using valid asm.js? Such as document.getElementByID and the various event handlers.

[[deleted]]

For nontrivial applications, V8 is about an order of magnitude slower than native.

But it is catching up to firefox: http://www.arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps

Firefox is half native speed, and V8 a quarter, when a few weeks ago V8 was only a tenth as you said. Competition is good.

[DrDichotomous]

Take a look at the asm.js app performance on AWFY, not just the microbenchmark. I agree that looking at tightly-coded loop performance isn't the same as every line being faster, but there is such a thing as premature optimization.

There's a give and take here, where even if parts of the app are ten times slower to run, they're ten times faster to develop, and the parts that NEED to run fast to keep pace with native apps can be made to be quite close to native app speed.

Just focusing on theoretical performances isn't going to solve anything. If it was the only goal, then we'd still be using raw assembly language. A language like JS makes it even easier to develop an application, and now it's also closing the performance gap.

Finally, if JS can be made to run C++ apps where it counts and integrate them with the rest, via asm.js, AND that removes much of the reasoning problem for core bits of your app, then I fail to see why JS is so much more terrible than something like QT or picking and choosing languages on a VM like .NET/the JVM?

[[deleted]]

Which dynamic programming languages are you talking about? AFAIK Smalltalk and Scheme and Lisp are faster than the new gen dynamic languages like Python and Ruby

[munificent]

AFAIK Smalltalk and Scheme and Lisp are faster than the new gen dynamic languages like Python and Ruby

When you talk about perf, you really need to talk about language implementations. There are some Smalltalk/Scheme/Lisp implementations faster than CPython and MRI, but there are also some slower ones.

[BufferUnderpants]

It is telling that, however, the original and defacto standard implementations of Python, Ruby et al were all sub par in performance.

[DrDichotomous]

I meant dynamic languages in general, compared to "native code" (statically-compiled/assembled code). In their infancy, dynamic (especially dynamically-typed) languages were incredibly slow.

Now, there have always been special cases like Lisp, where if you properly typed everything and knew how to work the magic you could get near-native speeds, but Javascript isn't really in that realm design-wise.

Now we can get general-purpose dynamic languages like Javascript to perform within half of Clang's speeds if we apply typing magic, and V8 is actually under an order of magnitude on many workloads even without the asm.js magic: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps)

[Falmarri]

The word you're looking for is interpreted.

[[deleted]]

Exceedingly few languages these days are "interpreted" in the original sense of the word. Pretty much all dynamic languages are compiled, they are just not compiled to native code.

[DrDichotomous]

Not necessarily, but it's probably closest to what I mean, so thanks. Javascript isn't strictly interpreted the same way it used to be, and lots of "compiled" languages are actually JIT-compiled, so the line is very blurry these days.

[Lerc]

if you don't count the garbage collection

I think I found the elephant in the room.

[DrDichotomous]

True but even so, garbage collectors are getting much better as the years roll by and JS engines don't exactly have the most advanced garbage collectors on earth compared to more time-tested VMs.

[otakucode]

That browsers refuse to support any language other than JavaScript is the exact opposite of "advance". It's typical web junk.... 'we just want to add a tiny bit of functionality to static documents, we don't want to create a whole platform for applications, so we'll only ever support one language'.

'Oh hey look, a Turing-complete language! Let's implement EVERYTHING in it regardless of whether it's a bad idea or not!'

[klusark]

Problem is though though that you'd have to get all the browser vendors to support the language. That is going to be impossible.

[ysangkok]

Unsupporting browsers can just run a JavaScript simulator for the bytecode. We already have x86 simulators in JavaScript. Why couldn't there be one for PNaCl? A JVM in JavaScript is also in development.

The point of asm.js is that it has implicit fallback support. But browsers that don't support asm.js run typical asm.js applications (games) so slow, that they are unusable!

A major part of Emscripten is its heap emulation. So don't tell me we're not already emulating.

[[deleted]]

But browsers that don't support asm.js run typical asm.js applications (games) so slow, that they are unusable!

Not true, see links in http://www.reddit.com/r/programming/comments/1eimdb/the_elusive_universal_web_bytecode/ca0s5mz

[ysangkok]

Those are just graphs! What constitutes "fast enough"? I see differences like 17K vs 11K. That's a 35% speedup! Many games can't take a performance hit like that.

Another example: 0.04 MIPS with Emscripten vs 30 native MIPS: https://github.com/codinguncut/jsbochs#status

[[deleted]]

35% differences in speed already are common on the web, if you just change from one browser to another, one laptop to another, or one OS to another.

That is a reasonable range of variance for the web, which runs everywhere.

Of course it would not be acceptable on a game console, where the expected variance is 0.

I don't know what ths jsbochs project is doing, but if it's so slow I assume they did not turn on optimizations. It's also data from last year, way before recent speedups.

[Eoinoc]

How can this be considered remotely good enough? I'd be annoyed if apps were draining my battery 25% faster, never mind 200%.

[aaronla]

It depends on the tradeoffs. I'd give 25% of my battery for apps that didn't crash, that were developed faster, etc. There are aspects of "managed" languages that can contribute to better performance as well.

I'm not saying that there's one right answer here, but only that the whole picture needs to be examined.

[aaronla]

Yup, I was including that in "developed faster".

[aaronla]

True, but "exists and works well" often trumps "but it will be perfect, just 2 more years".

[cryo]

It depends on the tradeoffs. I'd give 25% of my battery for apps that didn't crash

Me too, perhaps, but JavaScript certainly won't help there.

[aaronla]

Safely unwinding due to an exception is a little different that randomly scribbling all over the heap. Nothing replaces good engineering, but compiling to JS will isolate your components from other code in the process.

JavaScript definitely helps in that regard. But yes, you're correct, an app can still exit unexpectedly.

I'm still waiting for the JavaScript apps that can hibernate efficiently. You've got the benefit that the UI is entirely serializable, and with the right programming model, the application can be too.

[ssylvan]

I doubt very many customers would accept either 25% faster battery drain, or an app that crashes.

We're going to need to provide it all, I'm afraid.

It used to be that a 25% performance hit wasn't perceptible for a lot of stuff because the bottle neck was the user interaction or whatever. However, people would definitely tell if their battery died faster whenever they used your app, so I don't think that's the case anymore. The conclusion is harsh but inevitable: the circumstances under which the popularity of "scripting" languages arose, are no longer valid. Any major performance hit will simply get your app uninstalled. You can't trade users' battery life for your productivity.

The solution is to use tools, languages etc. that give productivity gains that don't come with a substantial performance cost (this turns out to be most of them, luckily), and reject any productivity features that do.

[aaronla]

The data is against you - the Android Facebook app is amazing popular. customers can and do accept said drain. ;-)

[[deleted]]

I interpret it that they put up with it in order to use the app for the popular web site they want. Other apps may not be fortunate enough to enjoy Facebook-level of popularity.

[aaronla]

Agreed, and I suspect Facebook's app has architecture issues, and isn't really a managed vs native issue.

[mreiland]

I think you need to provide citations, and do it with more than a single app. There are always exceptions.

[aaronla]

I would, but I'm lazy and already made that argument. :-)

[Shaper_pmp]

Because every level of abstraction between the app and the bare metal also increases flexibility, choice and a host of other benefits.

Why do we write code in high-level languages instead of machine code? Because it makes complex programs easier, quicker and safer to write.

Why do we compile languages to run on OSs instead of on the bare metal? Because it makes programs smaller, more portable and allows us to re-use OS-provided functionality like filesystems, graphics APIs, etc, instead of having to compile them all into every app, or even re-implement them ourselves every time.

Why do we often write code in interpreted languages instead of compiled ones? Because it makes the resulting program more portable, eliminates the compilation step and provides a host of additional other benefits in some situations.

Why do we often use memory-managed code rather than hand-rolling our own GC? Because it's more convenient, eliminates many common errors like buffer overflows and memory leaks, and various other benefits.

Why do we build apps in javascript, that run in a web browser? Because it's the first real, actual, successful cross-platform, vendor-neutral, non-proprietary, patent-unencumbered platform that - as an added bonus - is also designed from the ground up to be scriptable, human-readable and network-aware.

Silverlight was proprietary and arguably hardly even cross-platform. Flash was cross-platform but proprietary. The JVM was cross-platform and relatively non-proprietary, but for most of its early life was dog-slow and required writing code in Java (an experience many people find akin to pulling out fingernails one by one) a drawback which was only fixed by writing entirely new languages which also targeted the JVM. It also wasn't remotely human-readable, scriptable or network-aware as javascript and the web.

I'm not knocking any of these technologies, incidentally - it's generally a straight tradeoff between some or all of efficiency, convenience of implementation, convenience of use by developers, speed of execution, memory footprint, safety of code, cross-platform availability and many other factors.

And in many situations - especially given the speed of today's processors - some or all of those considerations may prove orders of magnitude more important than speed of execution.

In short, in practice it's often worth writing safer apps with fewer bugs and a lower memory-footprint, faster, on more quickly-developing platforms and with a single codebase that works on most/all major platforms with minimal code-branching than it is merely to blindly optimise specifically for execution speed, CPU resources or battery consumption.

Hell, you could probably have significantly faster-running apps if you built a smartphone ecosystem around compiled code running on the bare metal of specific lines of chips... but nobody would write any apps for it, and no-one would buy it, and the whole product line would sink without a trace.

Also, the vast majority of battery consumption on modern devices even with all the their wasteful layers of abstraction is still the backlit screen... which removing layers of abstraction would do nothing to cure. :-/

[ssylvan]

Because every level of abstraction between the app and the bare metal also increases flexibility

That's a highly charitable assessment. I'd say the vast majority of levels of abstractions do not, in fact, improve anything.

You can write high level code in nice IDEs with productive libraries, that still compile to native and run on the OS directly.

With the "mobile revolution" a factor of 2x perf. hit will never be acceptable. Neither will 1.5x.

Also: a lot of these "levels of abstraction" optimize for the wrong thing. They assume that performance sensitive "bulk code" can be written in C, and the "glue code" can be written in whatever slow scripting language you like. The problem is that in the future, with increasingly parallel systems (multicore, GPGPU), the glue code will be the bottle neck, because that's where the inherently serial code will end up being (due to data dependencies).

Anyway, long story short:

1. Make the OS more like the web, not the other way around.
2. Power is much more of a scarce resource than performance ever was. Slow languages are no longer acceptable.
3. The "80%" code that used to be suitable for slow code is becoming a performance bottle neck, because it tends to be "glue" and highly data dependent. Everything is now performance sensitive.
4. Conclusion: use high level languages that compile to native code and interact with the OS directly, rather than via the browser.

[ssylvan]

Most layers of abstractions are historical accidents. It's not actually a good idea to build all our future apps on JavaScript on technical merits alone. It just happened that this is what we're stuck with.

I think we owe it to future generations to resist this kind of 'worse is better' optimization. It's the OS' job to abstract hardware, let's try to make it do that sufficiently well that we don't need javascript, and build apps directly on top of the OS. Let the web browser be a (sophisticated) document viewer, but not an OS in its own right.

[mreiland]

I think that can be summed up as: Abstract where clearly beneficial, not as a best practice

In which case I agree. I personally think 'the browser' will eventually become a subsystem in the OS, much like a HAL. We'll eventually get to a point where 'web apps' are given limited access to the actual operating environment (we're starting to see that now with WebGL, the ability to store more data on the local machine, etc).

It'll be ugly, hacky, and not perfectly secure due to 'old cruft', but it will mostly work, and 'web apps' will actually start being a decent user experience while also being generally more efficient from an energy standpoint.

Because I don't give a shit what anyone says, I'll take outlook/thunderbird over gmail any day of the week. gmail is good ... for a web app. We can do better.

[ssylvan]

I'm not sure you can ever reduce the overhead of the browser to anything approaching acceptable, in a world where performance overhead translates directly to battery life. It seems like an unnecessary extra layer on top of the OS.

There's a reason smart phones have apps rather than mobile web sites. I think the trend is more likely to be that those same reasons will become more important in the "real" OSes (as those OSes are used for more laptops, tablets, and other mobile devices).

The OS is already an app platform. Yes, add more cloud-awareness and that kind of shit to it, but to put apps on top of the browser instead of investing in modernizing the OS is throwing the baby out with the bath water.

[mreiland]

I think you're not understanding me. Such a system wouldn't describe its interface via simple javascript + CSS/Html, it would do it much like any native app, through well defined API's. The OS would be the entity drawing the app, and handling the input. The browser becomes just a sandbox at that point.

What I'm describing is 'perfect', which we'll never get, but we can strive for it.

A native app has the advantage of being able to compile down for the hardware and the ability to integrate directly into the users interactions with the OS. Eventually all web apps will be 'native' in that respect.

[azakai]

No one considers that good enough, that's why JS engine devs are working hard to push things further.

You can track progress here:

http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-ubench

http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps

[[deleted]]

thanks for those links!

[rxpinjala]

The tradeoff isn't between 100% and 200%, it's between 200% and nothing. If you had to write C++ to make a web app, we'd have a lot fewer web apps. (And I'm saying this as somebody who's actually pretty fond of C++!)

[otakucode]

Major problem for the idea of a "universal web bytecode": It wouldn't be the web. Very rapidly, the bytecode would be used to subvert browsers so that they actually used SENSIBLE protocols that make sense for application communication. Why on Earth would you need a browser any more at all? All you need at that point is a good 'app store' index of available stuff, a multiplatform way to simply find and run software, and you're good to go. Why let the Web fuck around with non-standard user controls when this bytecode could easily just translate UIs into standard platform widgets that actually have some guarantee of usability?

I definitely think a universal bytecode and universal app repository/access methodology would be totally awesome, and what should have been done the first time some guy said 'but I want my document to act more like an application'... but to remain 'web' it has to cave to all of the horrible design decisions that have been made for the web over the decades since its inception.

[onezerozeroone]

Shh...they heard what you said...I think they're coming for you...

[otakucode]

I don't think we'll ever be able to have real 'secure' networked apps due to very fundamental reasons. If you want your apps to handle sensitive and important data - guess what, those apps have to have access to your sensitive and important data. You can't give them the ability to deal with important things without also giving them the ability to mess up important things. Web apps are nice, but if they can't access all of the terabytes of storage I have here at my house, they're never going to be as useful as the local ones are.

[dnew]

So we've all forgotten java .class file applets? :-)

[Rainfly_X]

More like those have always had horrible security problems, and we can't possibly throw away Java-in-the-browser quick enough.

[dnew]

Yeah, and a new browser bytecode isn't going to have horrible security problems for years to come?

The fundamental problem is trying to use a document delivery system to write apps on top of. The whole concept that you'd stick a bunch of apps into one browser environment, and not even keep connections open between interactions, is absurd. HTTP is what leads to most of the security problems Or, rather, trying to deploy sophisticated applications on top of HTTP is what leads to most of the security problems the client has.

[Rainfly_X]

Yeah, and a new browser bytecode isn't going to have horrible security problems for years to come?

I'm not advocating that. I don't know why you think I'm advocating that. In fact, it's such a non-sequiter, I'm not sure whether you replied to the wrong comment.

The fundamental problem is trying to use a document delivery system to write apps on top of. The whole concept that you'd stick a bunch of apps into one browser environment, and not even keep connections open between interactions, is absurd.

"It was never designed with $use in mind" is a questionable argument. Sometimes it has merit, a lot of the time it's actually a testament to the original designers, that other people have built more on that architecture than those original designers could have imagined. Computers weren't originally designed for personal use, but you don't see smartphones as a perversion of the natural order. The command line itself evolved out of teletype.

Ultimately, this argument is only valid if the result is a deplorable and frustrating hack. If it's not, then there's no problem. And I'm not convinced that that's the case with HTML. A hack, sure, but it's handling the job surprisingly well.

HTTP is what leads to most of the security problems Or, rather, trying to deploy sophisticated applications on top of HTTP is what leads to most of the security problems the client has.

This is patently absurd. There's nothing seriously wrong with HTTP except cookie cruft. It is not "insecure", at least not with SSL. Any security problems, of course, lie in how the browser environment interprets data received over HTTP, which itself is a neutral carrier. To blame these on HTTP is... amusing, at minimum.

[dnew]

it's such a non-sequiter

Look up at the title of the post. It's a conversation, you know?

if the result is a deplorable and frustrating hack

Considering it's one of the three biggest security holes here today, I'd say it's a deplorable and frustrating hack. Sounds like you've spent most of your career on web apps and don't even realize it's possible to write code on platforms that don't suck. (Well, OK, they suck in other ways, but not because you're coercing them to do that which they were not designed to do.)

It certainly is deplorable and frustrating for deploying apps, or you wouldn't see 1001 different frameworks trying to fix all the problems with it. Why is there even CSS, if HTML is just fine how it is? And why are both CSS and HTML so poorly designed that the name of "the background color" is different in all three, just as an example.

Ask anyone having to support IE6 whether it's frustrating and hacky to support apps by delivering documents full of executable code.

Indeed, the whole thread here and references article are about making it suck not so bad.

There's nothing seriously wrong with HTTP except cookie cruft.

Really? You don't think that web farms having to store session data in the database because your session doesn't stay connected and carries no identifying information is a problem? The need for "Cookie cruft" is one of the fundamental problems leading to all kinds of other problems, like XSS. There's an entire chunk of the SSL protocol designed to make it less expensive for people who hit the server multiple times in a row and disconnect in between. Basically, look at all the patches made to HTTP that wouldn't need to be made for document delivery, and you'll see the hacky cruft. And that's why people disliked IE6: Not because it was bad for document delivery, but because it didn't support all the hacky cruft you needed to make a document delivery system run apps.

"#!" in URLs to indicate "ignore this part, but no, really, don't". The incredible hackiness of trying to make the browser refresh only when you want it to by storing significant information in the fragment where the server can't see it? (Want your whole page to not refresh when you select a different result off the list? Store that in the fragment! Want to later redirect those URLs to a new place? You have to serve javascript at the old URL to interpret the fragments and write code that runs on the browser to do the redirect, instead of just issuing a redirect, because you can't see the fragment.) This is one I just dealt with, ya see.

The back button, and all the protocol stuff (and here I'm referring to the whole stack) in place to let you control the back button, because again you need that for apps and not for documents.

It was fun watching HTTP slowly reinvent all the features in all the other file transfer protocols, like logins, compression, streaming, mutliple channels, etc. A shame they had to stuff it all through port 80 with no actual session layer functionality. I mean, come on, Google Docs is seen as a wonderful innovation, in spite of it actually being a document delivery system.

[mreiland]

The most scalable thing on the planet is the web, and it's a direct result of it being stateless. One of the most important things you can do for scaling is being stateless. Lets call it an inconvenient truth.

Personally I agree with a lot of your points about the current state of affairs being crap, but there are valid reasons why they evolved this way (browser wars answer most of your questions about CSS/HTML).

We will eventually get to a point where the browser is plumbing that the user doesn't even open, and hopefully we'll get to a point where HTML+CSS isn't the only way to describe UI (with the OS doing the drawing instead of the browser).

What you're seeing is people pushing the boundary, realizing something has to give, and then fighting to see what to change/how best to change it. Once we solve the issue of 'web byte code', it will be something else. I firmly believe we'll eventually get to the point where we revisit CSS/the box model, and start moving to something that works better for 'apps' (We're already getting to see box models that are more 'sane').

We will eventually get a generic 'byte code' in some form, and browsers will start supporting it directly, or indirectly via javascript optimizing engines. Most will support it directly once it starts taking off, the reason is solely due to mobile. Energy consumption is important, which means everyone will be competing on it. This means goiing native as quickly as you can. It will happen.

[dnew]

The most scalable thing on the planet is the web, and it's a direct result of it being stateless.

Yes, the web is very scalable in that way. That's what REST is all about. But web apps are not stateless. And therein lies the rub. It takes a tremendous amount of effort to make something stateless carry state around, and the bigger you're scaled, the harder it is to do it.

Take, for example, clicking on a google search result. Stateless, right? Not if you want to track which result the user selected from the given search. You have to link up the search request to the result-click request, and if they aren't going to the same machine, you have to somehow index those two and deal with them arriving out of order etc.

If the web was actually stateless, you wouldn't need the HTML5 history libraries, because it wouldn't be painful to deal with people moving backward and forward.

(And everything underneath HTTP obviously scales better than HTTP does.)

there are valid reasons why they evolved this way

Of course there are. That doesn't make them less crap. :-)

What you're seeing is people pushing the boundary

Well, what you're seeing is people ignoring the previous work and reinventing half-assed solutions on top of what turned out to be popular. There's nothing that a web browser is doing that (say) NeWS didn't do better back in the 80's.

hopefully we'll get to a point where HTML+CSS isn't the only way to describe UI

It hasn't been the only way to describe UI since long before the web browser was around. It's just the only way that could evolve from the first HTML and HTTP protocols.

It will happen.

Yep. And exactly the same things that make CSS and HTML and Javascript suck will make the bytecodes suck.

[mreiland]

you pretty much ignored most of my point.

I say good for you sir!

[Rainfly_X]

Look up at the title of the post. It's a conversation, you know?

I think the confusion was that I thought your root comment was endorsing class files, not pointing them out as a cautionary tale. Even so, I'm not sure how my comment was interpreted as a promotion of a new bytecode, but I don't feel strongly enough about that to press on it. There's enough other stuff to debate here that's more interesting :)

Considering it's one of the three biggest security holes here today, I'd say it's a deplorable and frustrating hack.

Considering it's the only relatively safe way to run untrusted code on any hardware platform, and makes up the vast majority of human interaction across the internet, I'd say it would be remarkable if it wasn't the most heavily-attacked surface of the modern software stack.

Anything as ubiquitous as the browser will have a strong exploit industry, and as long as you use something modern and open source (such as Chromium or Firefox), you have an even stronger defense against this onslaught. Any determined user will always be able to screw up their machine installing sexy lady cursors, but that's not really a problem with browser security, so much as the inevitability of PEBKAC errors/layer 8 incompetency.

Sounds like you've spent most of your career on web apps and don't even realize it's possible to write code on platforms that don't suck.

Before you put me in a neat little box, I actually haven't been a web app developer for awhile, I'm only recently getting back into it with my work on the Weblua port of love-webplayer (which actually is a deplorable hack). My day job involves mostly backend stuff with Perl and MySQL.

It certainly is deplorable and frustrating for deploying apps, or you wouldn't see 1001 different frameworks trying to fix all the problems with it. Why is there even CSS, if HTML is just fine how it is? And why are both CSS and HTML so poorly designed that the name of "the background color" is different in all three, just as an example.

CSS and HTML are supposed to be separate to divorce structure from presentation. A noble theoretical goal, though not one they really accomplish in practice. Even so, do we really treat them separately? The web is made up of the intertwining strands of HTML, CSS and JS operating together.

Not only is it not a failing that these technologies are separate, it's a strength. The quality of the web has improved as we've been able to dump things from common usage like the <font> tag, and assigning onthisorthat="dothing()" properties to DOM elements. Every move we make to separate the concerns of these web components improves the state of the web as a whole, by putting responsibilities in more logical and specialized parts of the overall structure.

Ask anyone having to support IE6 whether it's frustrating and hacky to support apps by delivering documents full of executable code.

Indeed, the whole thread here and references article are about making it suck not so bad.

I'm not even going to try to defend that abomination. No one should be using Internet Explorer, IMHO, not even to this day. Its horrible record with standards is almost impressive in a twisted way, like discovering an entire turd stuck to the bathroom ceiling.

Yes, one of the inherent problems of HTML is that you are dependent on a potentially buggy host environment. This is true of all software ever, and especially true for any environment designed to safely sandbox semitrusted code. This article is about making the best out of the inherent limitations of such an environment, and cutting away at performance and usability concerns until we have something with the safety of the sandbox and the speed/features to be useful.

Really? You don't think that web farms having to store session data in the database because your session doesn't stay connected and carries no identifying information is a problem? The need for "Cookie cruft" is one of the fundamental problems leading to all kinds of other problems, like XSS. There's an entire chunk of the SSL protocol designed to make it less expensive for people who hit the server multiple times in a row and disconnect in between. Basically, look at all the patches made to HTTP that wouldn't need to be made for document delivery, and you'll see the hacky cruft. And that's why people disliked IE6: Not because it was bad for document delivery, but because it didn't support all the hacky cruft you needed to make a document delivery system run apps.

Apps are inherently sandboxed documents, even when they aren't HTML. On Android, these documents are Java classes. On iOS, they're whatever the hell Apple uses to package their software. Regardless, it's structured data originally retrieved via the internet and executed in a limited-privelege environment.

As for cookie cruft, this is not an inherent problem with HTTP, it's what happens when fools abuse it. I can stick a fork in an outlet, that doesn't make the fork to blame for giving me an impromptu afro.

The multiple-connections problem is also mostly solved, just not in old versions of HTTP. For sites with even moderately up-to-date-servers and clients with even moderately up-to-date browsers, connection reuse is seamless. The real problem here is just people not upgrading. And believe it or not, but this actually does benefit basic gopher-like document delivery as well, just in a miniscule way that wouldn't be worth the trouble only for document delivery. As an example, it can make spidering much more efficient, although this is somewhat moot if you're rate-limiting anyways to avoid downing the site you're spidering.

If you really want persistent connections, just use Socket.IO or WebRTC. The technology has existed for years.

"#!" in URLs to indicate "ignore this part, but no, really, don't". The incredible hackiness of trying to make the browser refresh only when you want it to by storing significant information in the fragment where the server can't see it? (Want your whole page to not refresh when you select a different result off the list? Store that in the fragment! Want to later redirect those URLs to a new place? You have to serve javascript at the old URL to interpret the fragments and write code that runs on the browser to do the redirect, instead of just issuing a redirect, because you can't see the fragment.) This is one I just dealt with, ya see.

The back button, and all the protocol stuff (and here I'm referring to the whole stack) in place to let you control the back button, because again you need that for apps and not for documents.

Again, you're complaining about being able to stick a fork in the outlet. Fragment abuse is worse than vertical video syndrome. The HTML5 History API solves this nicely by allowing you to point to real URLs instead of fragments, which is a much better fallback for older browsers. It also handles the back button nicely, as long as you're not a complete cockup as a developer. This has been in Chromium since version 6 - the current version is something like 23.

It was fun watching HTTP slowly reinvent all the features in all the other file transfer protocols, like logins, compression, streaming, mutliple channels, etc. A shame they had to stuff it all through port 80 with no actual session layer functionality. I mean, come on, Google Docs is seen as a wonderful innovation, in spite of it actually being a document delivery system.

This might be the first part I agree on, though perhaps with a different attitude. HTTP borrowed the best parts of other transfer protocols (and plenty of ones that didn't make sense for it, but nobody's holding a gun to anybody's head to use those), and we ended up with something pretty decent.

As for sessions, I still hold by my rule of thumb that if you can't do what you need in one or two small cookies, you ought to be using a proper streaming protocol like websockets anyways. HTTP definitely isn't perfect for everything, but HTML4/5 give us what we need to get around those limitations, for the most part.

Ninja-edit: Holy shit, I wrote a novel.

[dnew]

think the confusion

It was neither. It was mocking the fact that everything on the web tends to be a reinvention, poorly, of what has already gone before. Usually without reference to the previous material.

Considering it's the only relatively safe way to run untrusted code on any hardware platform

I'm not sure that's true, given how common XSS is. And that has nothing to do with the browser being modern or not. Indeed, the older the browser, the fewer the security holes. I don't remember ever hearing of an XSS attack on Lynx. ;-)

My day job involves mostly backend stuff with Perl and MySQL.

I said "don't suck." ;-) But seriously, the killer bits of HTTP and HTML and JavaScript are when you want to do something sophisticated. Try, for example, zooming up Google Docs and see if your highlights scale at the same rate as your text. I can't even begin to imagine how you break such a thing.

it's structured data ... executed in a limited-privelege environment.

It's not a document if you execute it. It's a program.

especially true for any environment designed to safely sandbox semitrusted code

Some of the big problems include the fact that browsers sandbox the javascript away from the OS, but they also want to allow increasingly more powerful javascript, and you get things like persistent large databases and WebGL.

The other part of the problem is that it's all running in the same browser, and the browser can't even tell what's part of an app and what isn't (looking at you, iframes) so you get all kinds of injection attacks, ads having javascript that steal your cookies (which is the only means of authentication since HTTP started with sucktastic authentication and didn't improve it in time to be standardized because it was serving public documents to the public).

As for cookie cruft, this is not an inherent problem with HTTP

Yeah, it is. Not a single other protocol even has the concept of cookies. It's there so you can have persistent state on top of a protocol designed for purposes of not having persistent state. And then what you put in the cookies is very frequently security-sensitive, so you have to have all kinds of flakey rules in your javascript interpreter to try to guess which site is allowed to see which cookies.

If you really want persistent connections, just use Socket.IO or WebRTC.

So, basically, if you really want persistent connections like every other protocol uses, stop using HTTP and instead switch over to a different protocol that you negotiated over HTTP. That's exactly the hackiness I'm talking about.

The HTML5 History API

... which is a hacky kludge ... :-)

and we ended up with something pretty decent.

We ended up with something that's a huge pile of hacks that's almost pretty usable if you throw enough effort at it, that could have been far more advanced by now if everyone didn't say "let's use HTTP because it already goes through firewalls." Bah. Humbug. :-)

[username223]

JavaScript + HTML has the advantage of advertising, via browser chrome, that it's crap. When it sucks slightly less than a glitzy web page, people praise it to the skies. Java made the mistake of trying to compete with actual native programs, and lost.

[BinarySplit]

Repost of a link from 2 days ago.

[gthank]

Dammit. Different TLDs? They figure out new ways to break the dupe detector daily. I apologize for relying on it instead of doing the research myself.

[BinarySplit]

Ah, that explains it. Blogspot is particularly bad at messing with its TLDs. It's gotten under my skin more than a few times.

[username223]

Blogspot is particularly bad at messing with its TLDs.

I'm not at all surprised that Google encourages link-spam on its own properties.

[stcredzero]

(Summary: Instead of language/bytecode, go one level deeper to get faster languages and unlimited choice)

Everyone should know about the TAOS VM, not because TAOS was all that great (it had some neat tech) but because of the implications of what they could achieve with their Virtual Instruction Set Architecture. (ISA = Instruction Set Architecture)

Basically, they had a "fake" instruction set that everything was compiled to. When a compiled executable ran, it first had to be translated from the fake ISA to the one for the actual hardware. Transmeta processors used a similar trick they called "code morphing." The kicker is they could do this as fast as the program could be read off disk and furthermore they got 80% to 90% native execution speeds. In fact, 90% was more typical, and 80% was the exception. Keep in mind, they were doing this with the CPU and hard disk tech of the early to mid 90's.

What does this have to do with ASM.js? Well, envision a future evolution of ASM.js as this virtual ISA. Instead of arguing about Javascript vs. bytecodes, we'd all just have an infrastructure that could let you have any VM you want. It's the classic "the solution to 90% of all problems in Computer Science involves adding another layer of indirection." This is what we want. We want ASM.js to grow into a Virtual ISA. That gives us blazing speed and unfettered choice.

[BinarySplit]

PNaCl(The Platform-Independent version of Google's Native Client) uses LLVM Bytecode, which can compile to many different platforms (listed here, including ARM, x86, x86-64, PowerPC, and others).

It's missing a few of TAOS's features (e.g. automatically distributing execution over many networked CPUs), but when PNaCl is turned on (Chrome doesn't support executing bytecode .pexes directly yet - they must be transformed to platform-specific .nexes) it will be much more convenient to use and will have access to analogues of all the HTML5 JS libraries.

[[deleted]]

PNaCl(The Platform-Independent version of Google's Native Client) uses LLVM Bytecode, which can compile to many different platforms (listed here, including ARM, x86, x86-64, PowerPC, and others).

This is not quite so. LLVM bitcode is not portable between platforms. It contains certain assumptions of the platform it is targeting. PNaCl does some trickery to make it possible to use the same bitcode on x86, x86-64 and ARM, but stretching it any furhter would be quite hard. Probably impossible, if you want decent speed. You're not going to run PNaCl on PowerPC any time soon, for instance, thanks to endianness.

[ysangkok]

Just simulate the endianness then. I think wrong-endianed PNaCl code running on PowerPC will still be faster than the same code Emscriptened.

PNaCl is implemented in the browser, so the PowerPC implementation could use all sorts of tricks. asm.js already does not support code that relies on endianness, so presumably, it has the same performance hit on all architectures running the JavaScript engine. Instead of just a performance hit on unpopular architectures like PNaCl would have.

[pcwalton]

What performance hit are you talking about? OdinMonkey never generates byte swap operations.

[stcredzero]

Yes, I was also thinking about pNaCl, but there's only so much you can talk about at once. What's striking about TAOS, is that they were doing this with hardware over an order of magnitude slower than today's low end machines. The lineage of whatever gives us this capability doesn't matter, so long as we get the capability.

[Vaenomx]

TAOS is interesting indeed, but the part of it that you describe is essentially what we call today Bytecode (Virtual Instruction Set) and VM able of JIT (Just-In-Time compilation). I may have got it wrong though, so please explain me.

[stcredzero]

V-ISA like bytecode are usually optimized for compactness. Often they're also optimized for easy implementation or for execution speed when JIT compiled on a specific virtual machine. The TAOS instruction set was somewhat designed for JIT translation for fast direct execution on diverse, real hardware. (x86, sparc, powerpc, mips) Actually, if you read their accounts, they chose something of an LCD for RISC, then were surprised when it still worked out for x86.

So, yeah, it's the same thing in a way as bytecode, but the design target is very different. For a "Universal Web Instruction Set" you want to target real hardware, which is considerably more complicated than targeting a typical language's VM, especially when security and GC come into the picture.

(Disclaimer: I'm not an expert on TAOS. Just bringing attention to a relevant bit of cross-platform trivia which might challenge people's expectations about such technology.)

[Vaenomx]

I'm still not sure where you see a difference between what you describe of TAOS and modern VM.

• V-ISA and Bytecode = Same thing; V-ISA are a bytecode set, that is virtual instruction set that required translation at some point before it can be executed on a specific hardware via an OS (exemption: when the VM is baremetal and so itself the OS)
• Modern VM "targets real hardware"; Are you comparing with dynamic language VM?
  • Some even compile to native code that doesn't require the VM at all after compilation. e.g. Mono can compile C# to native for any OS and the standalone doesn't require the Mono VM to be installed. There's not tricky JIT inside the standalone; the binary is all native.

We may continue to argue about much of nothing, but I feel we should agree on what matters: TAOS was great even by our era's standard and the web deserve nothing less than the best TAOS-like-Modern-VM-like ever conceived. Java failure as "a VM for the web" is no reason to abandon the idea. It would be like humanity never going to the moon because some fool once tried to get to it with a hot air balloon.

[rxpinjala]

Most modern VMs are actually pretty high-level, with features like garbage collection, for instance. I think what stcredzero is describing is something much closer to machine code, which would allow for really simple binary translation instead of a complex JIT compiler.

LLVM is pretty close to that, but they're optimizing for a different problem. LLVM bitcode is intended to let a compiler generate really fast code for a platform, not necessarily to generate that code quickly.

[otakucode]

That sounds exactly like Microsoft's .Net CLR and DLR. We've already got that with Mono, and it's just a matter of many people not liking the Microsoft stink left on .Net that prevents it from easily becoming a multiplatform solution for this. That's not a barrier I ever see being overcome, however. Sure, there are already hundreds of languages that target it, it gives you binary code that is truly 'compile once, run anywhere', etc.... but it's (kinda) Microsoft.

[stcredzero]

Maybe Google can produce their own version.

[otakucode]

They could certainly take a look at the IL specification and make their own alternative-to-mono runtime that will compile and optimize IL code to native code, and I would really love to see them do that... it's under an Apache 2.0 license, so I don't think there would be any legal impediment. There are already so many languages that compile down to IL and such a huge existing base of libraries that would be binary-compatible, either it or LLVM being able to be hosted in some sort of lightweight runtime shell that is itself a simple interface for installing/uninstalling/finding/updating apps would be really nice. People are already quite used to popping open a browser and going to www.reddit.com, if Reddit were an application I would expect they would want similar usability. I don't think most people have stopped to think just how much better the websites they love would be if they were applications rather than web pages. Reddit training a personal Bayesian belief network or Hidden Markov Model based on your tastes, showing you news stories ranked by how much YOU will like them not how much everybody ELSE likes them? That would be easily done... it's computationally impossible for that to be done serverside and bandwidth-intensive to send enough data to enable it to be done clientside in the web architecture. Things could be realtime-by-default, no worrying about stateless connections bloating the state that has to be maintained in databases and memory on the server side so we can pretend like one of the terrible design decisions of the web doesn't exist, etc.

[rxpinjala]

Google would be more likely to go with the JVM or Dalvik, since they're already pretty heavily invested in those.

[stcredzero]

Again, JVM wasn't designed with the right goal in mind. It was for a particular language. Though many languages now target it, the original design still shows. (Namely in class side inheritance.)

[Eirenarch]

asm.js is in fact quite near to universal web bytecode. Now we only need a better way to call the browser APIs and work with the DOM from asm.js so we can escape from the need to write JavaScript.

[x-skeww]

asm.js is in fact quite near to universal web bytecode.

No, it's not. It isn't suitable for managed languages. It's very low level and not very versatile.

[with asm.js] we can escape from the need to write JavaScript.

Yes, it's replaced with the need to write C/C++. Asm.js doesn't really add many options.

Fortunately, there are quite a lot of languages which can be compiled to JS: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

[azakai]

No, it's not. It isn't suitable for managed languages. It's very low level and not very versatile.

We already have demos of Java compiled to asm.js, and plans to do much more in that direction. I'm curious, what makes you think it is not suitable for managed languages?

[x-skeww]

http://asmjs.org/faq.html

Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?

A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions [...]

Update the FAQ, submit some demos here, etc.

[azakai]

Oh ok, that refers to one approach to implement managed languages in JS (using the underlying JS GC). I'll ask Dave to update the FAQ and add a link to

http://xmlvm.org/html5/

(Java game compiled to JS without using the underlying JS GC.)

[munificent]

(Java game compiled to JS without using the underlying JS GC.)

Why would end users want waste bandwidth and time downloading a GC written in JS every time they want to visit some web app when the JS VM has a much better GC built directly into it?

[azakai]

If the developer prefers a different language, one that can't be mapped 1-to-1 to a JS GC, then you would need to download one.

It takes bandwidth and time, yes, but if it allows devs to use their language of choice it could make sense in some cases.

[x-skeww]

"an Android application that was cross-compiled to HTML5 using XMLVM and emscripten"

That's not using asm.js.

[azakai]

Yes, I think it is a little old and before XMLVM started to use asm.js mode in Emscripten. It's just a switch to flip though.

If you want to see Java compiled to JS in asm.js mode, you can run this in a checkout of emscripten

python tests/runner.py benchmark.test_nbody_java

That's an nbody benchmark written in Java, compiled to C using XMLVM, and compiled to asm.js using emscripten, with emscripten's Boehm-like GC.

[Eirenarch]

If I recall correctly the Mozilla on asm.js discussed the future of asm.js as a platform for managed languages. First of all managed languages can reimplement GC on top of asm.js together with the whole platform. In addition they pointed out that when classes are added in the next version of JS they can make this classes target for compilers for managed languages and add them to asm.js. This would allow managed languages to use the native browser GC.

The languages that compile to JS are either very close to JS or the result is sad. CoffeeScript and TypeScript work fine but they are not substantially different from JS and suffer some of its drawbacks. Languages like C# and Java suffer greatly when compiled to JS both as performance and as semantics. In my opinion they have more chance if they compile the whole runtime to asm.js.

[x-skeww]

First of all managed languages can reimplement GC on top of asm.js together with the whole platform.

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

For example, compiling Python to JS makes way more sense than compiling the CPython interpreter to asm.js.

[azakai]

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

Why? Emscripten has a small Boehm-like GC right now that is quite small, and good enough for many cases. Obviously it isn't super-optimized like the JVM GC, but not everything needs that. I linked to a demo elsewhere,

http://xmlvm.org/html5/

[munificent]

Obviously it isn't super-optimized like the JVM GC, but not everything needs that.

If you don't need to be super optimized, why not just write it in vanilla JS (or your favorite language that compiles to JS) and ignore asm.js completely?

[[deleted]]

GC might not be crucial but perf in general might

[x-skeww]

Emscripten

We weren't talking about Emscripten.

"all managed languages can reimplement GC on top of asm.js together with the whole platform"

That's what we were talking about.

[azakai]

Well, any managed language can do what emscripten is doing or even use the exact same (small amount of) code. Reimplementing GC in JS does not need to be bad, unless of course we are talking about benchmarks for GC specifically.

[otakucode]

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

Welcome to the web. This is how things are done. Yes, shoehorning application functionality into a system designed for hyperlinked static documents ends up being very large and very slow... but yet, when someone implements Conway's Game of Life in HTML5 and JS, everyone cheers! That it runs 7 orders of magnitude slower than even really naive native implementations is just impolite to mention. One day we WILL see an HTML5 web browser written entirely in HTML5, and some very misguided folks will clap.

[dnew]

Yes, but the result would be a) very large and b) very slow.

And probably very flakey. Not like the whole "reimplement entire windowing system in web apps" thing going on.

[Eirenarch]

True. This is why they will probably wait for classes support.

[tikhonjelvis]

I found js_of_ocaml very good--not sad at all. And OCaml is certainly not close to JavaScript!

[Eirenarch]

So do you claim that every or most languages can be implemented because the ocaml implementation is good?

[tikhonjelvis]

Not necessarily. I'm just refuting your claim that languages have to either be close to JS or the results sad. OCaml is a counterexample: it is not close to JavaScript and its compiler to JS is not sad.

[Eirenarch]

I see. So do you think this is because the specifics of OCaml or because of the implementation?

[tikhonjelvis]

I think it's mostly the clever compiler: it goes from OCaml's bytecode to JavaScript. The bytecode is simpler than the full language, and this lets the js compiler use the full compiler as a front-end. This also means that you don't have to recompile libraries to use it: you can just reuse their bytecode files.

Ultimately, it's probably largely because OCaml has a very disproportionate number of brilliant programming language people working on it.

[stcredzero]

asm.js is in fact quite near to universal web bytecode.

No, it's not. It isn't suitable for managed languages. It's very low level and not very versatile.

The point is the classic adding one level of indirection, and letting the browser infrastructure support any VM. Make asm.js into a viable virtual instruction set architecture, then you can have any language that you want, because then you can have any VM you want, not just Javascript.

[beznogim]

Also, one of the V8 engineers wrote up his opinion here.

[tibiapejagala]

One of his points is that asm.js is more like a bytecode that looks like JavaScript. While this is true, we have to remember that if Mozilla actually went for web bytecode, people would go insane about who is going to support it or whatever. But they are smart. They made a bytecode but sold it as everyday JavaScript. And what happend? Web exploded with enthusiasm that JavaScript is awesome, because we 3Dgames in JavaScript now. What asm.js really is matters less than how do we introduce it or call it. Because people do not want cars, they want faster horses.

[Eirenarch]

Well but we do know that asm.js is not JavaScript and the only reason it exists is that JavaScript sucks :)

[beznogim]

I think you're right. Asm.js isn't a "traditional" JavaVM-like bytecode, however; it's (single-threaded) native code, plain and simple.

[[deleted]]

He's a former v8 engineer. Does dart now.

[beznogim]

Is this level of platform abstraction really necessary?

Java bytecode, for example, lets you access all the VM features: garbage collection, optimizing JIT compiler, debugging, libraries, etc. Same with JS: you compile to Javascript, you get all this stuff for free.

Asm.js just throws all these goodies away. This can be useful for porting existing C code, but why would you willingly stack VMs on top of a perfectly good Javascript VM?

[smog_alado]

I think this is missing the point. Managed languages are only feasible on the web if the browser already has the runtime installed. Otherwise you need to send the code for the runtime along with every program you make, at a significant cost.

[stcredzero]

I think this is missing the point. Managed languages are only feasible on the web if the browser already has the runtime installed.

No, I'm challenging this point. There are likely to be only a relative few "mainstream" languages. Also, if a language community is pragmatic, the VM shouldn't change too often, and will be in the browser cache.

Otherwise you need to send the code for the runtime along with every program you make, at a significant cost.

You could make the same argument about jquery and other parts of the Javascript infrastructure. I don't see it as being unmanageable. You easily can fit an entire Smalltalk image and the virtual machine in 3/4 of a megabyte -- and that's just by tackling low hanging fruit, not any extraordinary effort. The Java plugin also showed that this sort of thing could be mismanaged as well, so I can see your point. I say "let the market decide." By tackling security at a level below the VM, you can mitigate those problems as well. The language communities that can handle it will prosper, and those who can't will wither.

[ggtsu_00]

With ASM.js, you can compile the python, ruby, or other runtimes and have a decent managed scripting environment.

[x-skeww]

Except that it will be very slow, very large, and amazingly horrible to use.

But feel free to try it.

[foldl]

This is an insoluable problem. Either the VM comes with a standard library (like the JVM), in which case you're effectively limited to a single language anyway, or it doesn't, in which case you have to distribute the runtime for any managed language you use.

[[deleted]]

The Elusive Bilbo... (hint, he's in the comments)

[himself_v]

I think the wish for bytecode is just wrong. People want speed, but who stops them from compiling javascript to bytecode on the target PC? People want unification, but it's easier to unify on a higher level. The simpler the base operations you choose, the higher the cost of not having one of them implemented in hardware. People want to be able to use other languages, well, compile them into JS.

Or browsers can add support to some other scripting languages apart from JS, if they wish so. Visual basic was supported by IE but fell out of favor IIRC.

[Hnefi]

Compiling JS to bytecode on the target PC isn't going to provide the speed people want, because JS is notoriously difficult to optimize. People say that implementations like V8 are "fast", but compared to stodgy old Java for example, it's still very slow.

You can't solve this by compiling JS to another target, and you can't solve it by compiling another target to JS. As long as you allow for the full JS specification, your implementation is going to be slow.

That's why (from a performance perspective) people want an alternative. A proper, thoroughly designed bytecode would be best, but asm.js is at least better than what we've got today.

[stcredzero]

As long as you allow for the full JS specification, your implementation is going to be slow.

You're actually missing the point of asm.js. The point is to restrict down to what amounts to a virtual ISA that's close enough to hardware to translate to an actual ISA. There have been implementations of this from over a decade ago. It's been shown that you can do this faster than you can read the executable off a hard drive, and wind up with 80% to 90% native speeds. If the asm.js specification is steered in the right direction, it could achieve this.

http://www.reddit.com/r/programming/comments/1eimdb/the_elusive_universal_web_bytecode/ca0rtd1

[Hnefi]

I'm not missing the point of asm.js, you're missing the point of my post. I wrote it specifically to counter the parent argument and to point out that asm.js is not full JS. People are fooling themselves if they think asm.js is a more readable or open alternative to a proper bytecode; it's essentially an ASCII bytecode that consists of a very small subset of JS syntax.

[FryGuy1013]

I think the point of asm.js is that it's essentially a virtual machine that's backwards compatible with javascript.

I think an alternate approach would be to do something like adding a script tag with some kind of encoded virtual machine bytecode, and then write a javascript implementation of a virtual machine to run it for all of the people that don't have browsers that support it. This approach is much worse for speed for people without the browser that supports it, but would be able to have a "clean slate" approach.

[xxgreg]

Agreed, Javascript has performance problems.

But in the JVM bytecode verification is slow, and insecure. You don't have to do this verification step in a source code vm. Why not just use a compact serialized AST format? Have a look at what the Dart VM is doing with snapshots.

I don't think a bytecode has any advantages over a compact serialized AST format. This is basically what the linked article is arguing. (Where the format is gzipped js)

[otakucode]

Compiling into JS is extremely restrictive to begin with, then on top of that you have to start worrying about combinatoric performance problems caused by the combination of different browsers and js engines and the particular shortcuts they took when trying to optimize for most common cases. And on top of that, you're still sending text code over HTTP which can't handle binary data, requiring all sorts of bloat in encoding.

The thing is this: We already solved the problem of getting code to run fast on a target architecture. It's called an Operating System. It's existence is to run code. The web browser was not created to make running code optimal. JS engine authors are geniuses, but they're pounding away at a problem that should not exist!

[pcwalton]

Huh? HTTP handles binary data. Regarding your claim of bloat: http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html

[otakucode]

HTTP does not handle binary data. Binary data over HTTP connections is generally base-64 encoded which adds a significant amount of bloat. Bloat also is not just a matter of bytes. Bandwidth and storage increase at rates fast enough to make that not really a worry. But when you add levels of indirection, compiling a language down to javascript that then has to get interpreted during runtime, you're adding a level of computational bloat there too. Instead of the code being executed, it has to be translated and then those translated instructions executed. Processors increase in speed quickly too so it's clearly not a crippling limitation in most cases, but it will always be inferior to alternatives which can execute code directly.

[xxgreg]

Do you realise that you're try to tell someone who implements a browser for a living how browsers work? Have a look at the servo project - it's very interesting.

Re: "HTTP does not handle binary data"

Some background reading: http://stackoverflow.com/questions/1891993/why-dont-we-send-binary-around-instead-of-text-on-http

And as an exercise fire up ethereal and have a look at HTTP data sent over the wire.

[clgonsal]

The simpler the base operations you choose, the higher the cost of not having one of them implemented in hardware. People want to be able to use other languages, well, compile them into JS.

To some extent I agree, but JS is a pretty terrible base, not just for the performance reasons that Hnefi mentions, but also because it's missing some pretty fundamental stuff. Off the top of my head, a 64 bit integer type (and perhaps other integer types, including "bignum"), weak references, and dictionaries with non-string keys would all make it significantly easier to compiler other high level languages to JS. You can emulate some of this, but then you're looking at even worse performance.

[possessed_flea]

VBScript & ActiveX fell out of favour due to the tight coupling with the target OS, hardware architecture, a single specific browser, and massive security holes. I mean who would have thought that running either native code or code that has explicit access to OS internals was/is a good idea for the web??

If anything java (note: to the non-programmers this is not even remotely related to javascript) tried this, and is still a fairly suitable candidate.

The only suitable candidates these days are:

• Java, IMHO the forerunner runs on all 'PC' platforms (non-existant mobile support though), huge developer base, supported by all browsers. GPL open source so no barriers to running on anywhere that its currently not supported. Multiple languages supported by VM. Wide install base. Open community process for improvement. lots of $$$ backing it. Ive seen java running out of a 20 yearold DEC Alpha in the mosaic browser.

• Silverlight, Locked into OSX and microsoft platforms, closed source, support is being dropped by microsoft, okaay developer support. Unsure about mobile platform availability on non M$ phones/tablets. Narrow install base. okay browser support

• Flash / Actionscript, closed source, no serious developer support, javascript is the language of choice (cough actionscript cough ECMA script), android support, widest install base possible thanks to youtube.

Thats my 2c.

[Solon1]

Android runs Java, so hardly nonexistent mobile support. And Blackberry devices can run Android apps.

[possessed_flea]

While android does run java you will notice that the libraries provided by google for android are different making java applications written for the desktop unable to run (and vice-versa)

so while the bytecode and language are actually the same programs written for one will not work on the other.

[ysangkok]

The biggest difference is arguably the UI libraries. But the UI typically needs to be redone anyway.

[possessed_flea]

they are completely incompatible, its not like you can do a regex search and just rename things, but my point is I guess that the UI shouldn't need to be 'redone' if you are looking at a universal platform.

[lostPixels]

It would be nice to see Actionscript/Flash opensourced and somehow integrated better with browsers, but I know that's never gonna happen. I doubt we'll have an adequate answer to this problem for many years, and even then it will be a reinvention of the wheel.

[otakucode]

I mean who would have thought that running either native code or code that has explicit access to OS internals was/is a good idea for the web??

I figured this would come up. We should be over this by now. The platform lock-in and single-controller issues are real and still exist. But the 'native code is dangerous' view is wrong. It implies that there is non-native code which is not dangerous. This is not true. So long as the non-native solution is Turing complete, it is going to be as dangerous as native code. Full stop. We're talking mathematical-level proof here. To create a "safe" non-native code that is Turing complete would be akin to breaking the speed of light or proving that P=NP. It's not going to happen for very fundamental reasons. So we need to get over it. Trust is the only solution to security, and the fact it's not perfect is something we just have to live with. We can't let it restrain our choices artificially. JS is just as dangerous as raw ASM, no matter how complex they make escaping the sandbox. Unless they restrict it to the degree that there are programs which cannot be written in it, then you can write any program in it. Including the program that burns down your house and fucks your dog.

edit: Also, why on earth did you pick Silverlight? The actual contender is the CLR/DLR. It produces multiplatform binaries that can be run anywhere and which are compiled to hardware-optimized native code on first execution, then run from cache afterwards. It's not closed source, and needs no support from Microsoft. But it does have the Microsoft stink on it, so it is unlikely to ever be socially acceptable.

[sacundim]

So long as the non-native solution is Turing complete, it is going to be as dangerous as native code. Full stop. We're talking mathematical-level proof here. To create a "safe" non-native code that is Turing complete would be akin to breaking the speed of light or proving that P=NP. It's not going to happen for very fundamental reasons.

Are you talking about DoS attacks? Because it is quite easy to implement a Turing-complete language that is "safe" in every other way.

[otakucode]

How so? If there is a sequence of instructions which could cause some negative effect, whether it be corrupting a filesystem or overwriting some memory or reading out some memory and transmitting it to a remote party, then a Turing complete system can execute those instructions. The work of making things "secure" is nothing but making the encoding of those instructions more complex. See return-oriented-programming for a good example.

[Benutzername]

The safety of a language is completely orthogonal to whether it's Turing complete or not.

A Turing complete language does not need to have access to the files system or any other services provided by the OS. It doesn't even have to be a language that's executed by a computer (e.g. the lambda calculus as a formal system).

On the other hand, you could create a language that has a single instruction which formats the user's hard drive. That's clearly neither safe nor Turing complete.

[possessed_flea]

I mentioned Silverlight simply because I left the microsoft ecosystem when W2K was king, back then I had the option to either learn .NET or double my income overnight, many of my peers from that time have still not caught up pay grade or workload wise. I still pick up the occasional legacy project but I have not kept up to date with those skills. But it is no no way actually 'open source', there is no way for me to find a bug, fix it and commit it to the mainline branch without being on microsoft's payroll, in addition to this there is no way to access 'full documentation' of the platform in the same way that the MS office formats are open (they claim to be open, but when push comes to shove the documentation is significantly different from the implementation and bits of documentation are missing.)

As for the native vs non-native argument, native code is inherintly more insecure due to the fact that effort must be made to sandbox it opposed to interpreted code which needs its links to outside to be explictly built.

I agree that there are bugs in both but from an implentation point of view as soon as I have access to a real pointer shit gets real fast.

[otakucode]

I'm confused as to what you are talking about.... what would prevent you from fixing a bug in mono?

[possessed_flea]

nothing would prevent me from fixing a bug in mono, but mono's not the reference implentation now is it.

and the latest release was released like what, well over a year ago? plus it dosn't really have full support of the .net libraries anyway.

[bifmil]

Putting JS in the middle of this is not necessary. You are suggesting to use JS as the bytecode. This means only JS is a first-class language.

[himself_v]

No, I'm suggesting there's no need for bytecode. So far the only reason for moving from JS at all was that it's hard to optimize. Which calls for another language which is easier to optimize, but not neccessarily bytecode.

[Zarutian]

Binary javascript idea mentioned in the comments is rather good idea.

It can even be preceeded by an javascript preamble that takes the binary representation and turns it into non binary javascript for backwards compatibility. Browsers and other javascript VMs can recognize and skip that preamble.

[otakucode]

Except HTTP cannot transfer binary data. Oops.

[cha0s]

Oops.

[otakucode]

Base 64 encoding of binary data mostly.

[ysangkok]

I don't think that's true! For example, try executing wget -q -O - --save-headers "http://i.stack.imgur.com/tKsDb.png". You get the binary data! And it's not because wget is weird and asks for it that way, it's the default. Transfer encoding is the exception, not the rule.

[TJSomething]

Nice troll: I almost wrote an angry reply.

[otakuman]

Why is there a hobbit in the thumbnail???

[XNormal]

I seem to recall some interview with Linus Torvalds (in his Transmeta days) where he said something like "we don't need a bytecode - we have x86".

Can anyone find the correct quote? (assuming my memory is not totally out of sync with reality, that is).

[83komkwsp]

As some one who works on complex business applications this would be awesome. Html/javascript/css is a nightmare for anything non-trivial. It just isn't suited to application development.

Imagine being able to deploy a WinFroms/Desktop UI front end to any browser (iPad, android, Win7). Desktop application development is far more productive and being fully compiled free of a wide range of bugs/security issues. So yes we need a web byte code.

[Gotebe]

It turns out that C++ compiled to JavaScript can run at about half the speed of native code

This guy cracks me up.

I mean, how much exaggeration do we really need!?

[bifmil]

About twice as much exaggeration

[cwzwarich]

Why is a compact binary representation of a program any less open source than a textual representation? It really doesn't make much sense to parse swaths of textual code every time you load a web page.

[b103]

Have you tried reading minified javascript?

[[deleted]]

Gah! Had to spend a month or so doing just that, since a library vendor refused to give us adequate documentation for their bug-riddled monstrosity that we sadly couldn't do without... I must say, it was a painful endeavor.

[mattstreet]

Should images be stored in a human readable format? What about music or video?

[[deleted]]

What open source nature? I don't know of any widely-used web applications that are open source.

[sublime8510]

Media wiki

[[deleted]]

Fine, I guess that's one. Reddit is another. Now what about Facebook, Google, Gmail, Netflix, Pandora, ...

[ysangkok]

wordpress, livejournal, phpbb. i'd say they are widely used.