I still think there is a long-term desire to "build once, run everywhere" with a certain class of software. With decently fast Internet access becoming ubiquitous, the web browser became the simplest delivery mechanism for that kind of software, which I think resulted in the explosion of "web applications" over the past decade.
Granted Java tried to create a VM that's "build once, run everywhere", and for the most part it succeeded and is still strong today. It can also be relatively straight forward to build and compile in C everywhere something small and simple as long as you use portable libraries. But in both cases the delivery and update mechanism is not as easy as: type facebook into your browser's address bar and press enter.
ActiveX, Java applets, Flash, and Silverlight all failed to take off (Flash had more success, but mobile has since killed it off) for building applications. Why?
I've used some software built on Adobe Air and I've found that to be a fairly pleasant experience.
What can we build that gives the benefits of a browser-based delivery, but is better than HTML/CSS/JS?
No, asm.js is just a clever, compatibility preserving workaround to tame javascript's dynamic nature that has been resisting all optimization attempts successfully since its inception.
I see no reason why we should stop using javascript as a scripting language for DOM.
I see no reason why we should stop building applications that only calls for simple HTML forms.
Traditional web will be alive and well as long as we continue to speak HTTP freely.
As pointed out in the comments on the post - there's a big pain point in DOM manipulation.
So applications which write directly to Canvas/WebGL will probably be fine, but for writing a normal web page you'll probably stick to normal JS (or something closely related to it).
And when I'll see a Python code running on my browser rendering on a Canvas as the Emscriten QT port does... I'll make myself blind with a fork in front of the developer of such a beast, yelling: "How the f--- am I supposed to use this now?!"
DOM and "native" browser interfaces means full accessibility support. Don't take shortcuts because you don't understand JavaScript.
The only language thing I miss in JavaScript is a better functional approach. But that's what transpilers are for.
Are we really comparing Python to JavaScript "as they are"? What make you choose a language instead of another one is the environment. Would you use a library-less python? Is Node.js cool because it's JavaScript, or it's cool for the miriad of libraries and traction it has?
And BTW, I'm not saying a transpiled JS is clearer than Python, I'm saying that a functional approach to classes (Haskell way) is impossible in JS as it is, and that transpilers (think of Row, LiveScript...) solve that problem de-sugaring it. Nothing more than that.
I love Python, I love JS. But would you love Python if you were locked down to Python 2? JavaScript must be backward compatible to keep its "web" role. Please stop confusing languages with environment.
You missed the point. The complaint was about UI accessibility of HTML versus QT-rendered-in-an-opaque-canvas. Hence yuchi suggesting he'd blind himself with a fork in front of the developers to drive the point home.
Didn't Google already write Google Apps and Google Maps in Java (or Go), and then compile it to Javascript? Because somebody at Google really doesn't like Javascript, and preferred to use something more "enterprisey".
When it comes to JavaScript, a team starts running into problems far sooner than they ever would when using C, C++, Java, C#, or more mature scripting languages like Python and even Perl.
It's not at all difficult to create maintainable, reliable code bases in the aforementioned languages with hundreds of thousands, if not millions, of lines of code. Having a proper compiler or interpreter (and not just lint-style checkers) does help a great deal. Having a sensible language to begin with also helps.
When using JavaScript, the problems start arising much, much sooner. It just doesn't offer the language features necessary for anything much beyond short scripts. An undisciplined team using JavaScript will run into problems when approaching a mere thousand lines of code. Their software will be unmaintainable if it ever manages to get into the tens of thousands of lines.
Even teams of the best, most experienced and most disciplined JavaScript developers often start running into problems once into the tens of thsouands of lines of code. After having witnessed this on many projects, it becomes clear that using some other language is the best option, even if it's converted to or compiled down to JavaScript in the end.
I don't think it comes down to not liking JS. JS has its uses, but you get quickly diminishing productivity returns as your application gets larger and hairier. I've actually had a project where the "M" and the "C" (of MVC) was written in GWT-able Java, and the view with JS. Right tool for each job.
"Think about a native-like Frontend Experience that communicates with a cloud backend for compute-intensive tasks, stores all your data in the cloud and is availabe for you on any PC with a browser in the state you left off."
Are there any extant models where this actually happens, browser-based frontend or no? I'm dubious. What user-interactive tasks exist which are compute-intensive but data-light and latency-tolerant enough to make such an offloading make sense? Are there any existing non-browser-based applications which actually offload significant amounts of work to cloud servers? Even the much-hyped SimCity "it does work in the cloud!" is doing 99% of the simulation client-side.
The closest I can get to this is MMOs and FPSs (where remote computation is mostly because of the multiuser shared state you need) and things which are essentially data lookup services like Google or Google Maps (and I'm not sure whether those fit the profile the author had in mind).
Well for apps like Mathematica or simulation staff it could make sense.
Also running things like 3D Studio in the browser while the rendering is done in the cloud could work fairly well. This wouldnt require the frontend to be in the browser obv, but when i work on something in the office, get home and see the same state of the app on my pc at home, that would be pretty nice.
One thing that I think will change about web development will be the open-source nature of it. Today, the worst thing you typically run into when trying to understand someone's code is minification. Taking LLVM bitcode and transforming it into JS will probably make it extremely difficult to understand the original code because it'll be more like reversing from assembly. The actual structure of the code is altered dramatically by the compilation process.
Personally, I'd love to be able to code in a different language and compile to asm.js for deployment. I think I'll try to maintain the open spirit of the thing though, and publish my original source for those who are curious.
I can see advantages and disadvantages to having closed-source web code, so I'm not sure what the end fallout will be. I hope it's not abused though, as I do like to see others' cleverness on display.
On the contrary, this very much follows the typical mentality we've seen with the evolution of the web.
It's one more example of throwing in yet another layer when every other layer has proven to be insufficient.
And it's another example of trying to once again twist JavaScript into something it isn't very good at doing.
Once again, like so many web technologies before it, this will cause waste for years to come. There will be a huge waste of time for users who sit there waiting for slow code to execute. There'll be more wasted time and effort for developers stuck dealing with the messes that this will create.
It's clear that a proper VM of some sort would be useful in today's browsers. Trying to build this upon some awful subset of JavaScript is not the right way to do it.
ugh. I am so sick of this "build a proper VM" wailing. It is such a naive and ignorant position. It completely ignores the reality of the market. JavaScript is dominant, it is fast, it runs on basically every device, browser vendors are deeply invested in it and you want to throw all that away and start afresh? ASM.js is a realistic way to get better performance today, not in the 10 years or so it would take for a new platform to reach acceptable adoption rates. And who's to say that some new "proper" VM wouldn't end up with warts like JS has anyway?
ASM.js has nothing to do with performance. It's about abstracting away the utter pile of shit that is JavaScript so that we can start using the languages of real men on the web.
There have been plenty of works done in this area already. See WebSharper, Script#... just two of the many available in the .NET ecosystem.
ASM.js is about formalising a known-good subset of JS that can be guaranteed to be compatible across browsers and therefore prime territory for building compilers on top of.
JS is nothing more than an intermediate language; it is similar to MSIL, JVM Bytecode, ASM. The only difference is that it happens to have a slightly C-style syntax. This is merely a coincidence and does not change the fact that is still an intermediate language designed for the web. It is utterly crazy the world has persisted writing code in it for so long. It is the modern web day equivalent of writing code in Assembly language.
What you're saying is contradictory. If JavaScript is already "fast", then why the need for something like this "to get better performance today"? If JavaScript is "dominant", then why is technology like this needed, mainly to enable developers to use non-JavaScript languages?
The market is speaking, and it's saying that JavaScript needs to go.
Besides, there are numerous proven VMs and runtimes that could either be used directly, or at least used as a model if a new system is needed. NaCl and PNaCl have already shown one much better approach that is possible. Your "10 years" estimate is not based on reality.
And frankly, no, I don't think any proper VM or runtime would ever end up as bad as JavaScript is today. No other language, aside from perhaps PHP, exhibits so many inherent, fundamental flaws. It would take significant effort (and ignorance) to duplicate the same degree of mistake and flaw.
1. speed is relative. it's possible for fast things to go faster. JavaScript as it stands is fast enough for a lot of tasks, ASM.js makes it faster in certain places. This can only be a good thing.
2. The market isn't saying JavaScript needs to go, JavaScript skills are high in demand, more so than ever.
3. This is the crux of your misunderstanding. I agree it would be nice if browsers supported e.g. LLVM out of the box. But they don't. And for political reasons they won't. If a company as large and powerful as Google cannot push NaCl adoption at all in other browsers (and NaCl was announced in 2008, so we're already half way to 10 years), how will you get them to adopt $YourVMofChoice? This is where ASM.js really wins - it is a subset of JavaScript, so it already works in other browsers, albeit without the performance boost and it is much easier for browser vendors to implement support for ASM.js than it is a whole new VM. Being backwards compatible means more web developers are likely to use it which will put pressure on other browser vendors to implement it. No one is arguing that ASM.js is a better technical solution to the problem, but it is a much better practical solution to the problem.
4. So this is another thing. Most of the people who are against ASM.js seem to dislike JavaScript the language. But ASM.js would free you from JavaScript almost entirely. The only time you'd see it is when you're debugging the "bytecode", and surely human readable bytecode is nicer than whatever something like LLVM spits out? Anyway, it seems like slightly curious reasoning.
>"If JavaScript is already "fast", then why the need for something like this "to get better performance today"?
This feels obtuse -- obviously JS today is faster than it's ever been, but we want native c performance out of it. Do you have a in-browser VM solution today that can do complex, GPU-powered full 3D on every platform?
Then your VM solution is already inferior to javascript and will need significant time, money and development to even catch up to javascripts current level of "fast".
(Using, of course, "game" performance as a benchmark for the vague term "fast")
>"The market is speaking, and it's saying that JavaScript needs to go.
What? How do you rationalize this? Every major browser supports it to their core and most are working on dramatic imporvements for their implementations. Every mobile device supports it natively. Every computer I've seen in the past decade supports it.
The market is speaking? Where? Where is the market speaking? What devices are without javascript?
What browsers don't support javascript?
I think you are confusing the "market" for "a small subset of a-typical vocal developers".
Is it faster than 5 years ago sure. But the amount of work on needs to do have good performances is just silly. Is it everywhere ? sure. But i've seen a lot of crazy JS demos , i'm running a decent machine ( Macbook pro) and sorry but most of the exemples i see have poor perfomances , and nothing close to native performances. So imagine a soft you need to use 6 hours a day , you'll feel the bad perfs , trust me.
So please let's stop saying javascript is fast, it is a lie. Speed is not something absolute , it is relative. It is slower than native and will always be. Native will always be easier to optimize too.
Doesnt mean we cant do anything in html5/js , just mean we cant do everything. And the more "special" feature one uses the less "compatible" the js app will be.
Now is ASM a good thing sure. But let's not fool people just to promote JS.
I agree. There's absolutely no reason to have photoshop in the browser. If you want to sync your files with 'the cloud' you don't need a browser for that.
Best part of this article is the typo in "Software makers could more easily deploy the common subscription based payment model of todays webapps to fight privacy".
This article is making a common mistake; confusing JavaScript the language itself with the DOM.
Compiling to asm.js just gives you the ability to translate your other language code to executable JavaScript. It doesn't solve the issues of DOM interaction.
In order to write your client side code in Ruby you'd need a DOM library LLVM them somehow understands how to translate into its JavaScript equivalent.
In the near term its certainly much easier just to write JavaScript. Which is honestly, really, really easy.
No, it doesn't. The author is suggesting porting a GUI toolkit (e.g. KDE) in asm.js, rendering it directly to the user, and doing away with the DOM altogether.
Isn't it exactly a thing in which Java failed about a decade ago? Apps running in a VM using GUI toolkit instead of DOM, delivered right into your browser window? What could be better? Well it's proved to be a total failure on the web.
You're splitting hairs. In practice, if all you're dealing with from the DOM is one canvas element and a URL that's static, you've pretty much "done away" with the DOM.
That's not true at all. You need some way of interacting with a back end (as well as the browser.) Whether that's via forms or AJAX requests, you need more from the DOM. The DOM is not just a GUI toolkit.
I am not splitting hairs, you are glossing over serious limitations to this approach.
Developing some kind of API binding for the DOM or JQuery is no impossible task though, similar things have already been done in other languages (in C# and the Xamarin Framework for example)
Betteridge's law of headlines is not some magic pixie fairy dust you can sprinkle in the comments to immediately nullify the linked article. You have to provide some sort of substantive reasoning.
For example, you could say that there are plenty of static sites (primarily html, images/video and css, perhaps with a light sprinkling of cgi and js) out there, for which emscripten/asm.js would be overkill and more complicated to boot. Therefore the old ways will endure alongside the new.
Or you could claim that the hard bit of current techniques is interaction with the dom, and that emscripten/asm.js wouldn't change that one bit.
No doubt you can come up with more antitheses if you put your mind to it.
Granted Java tried to create a VM that's "build once, run everywhere", and for the most part it succeeded and is still strong today. It can also be relatively straight forward to build and compile in C everywhere something small and simple as long as you use portable libraries. But in both cases the delivery and update mechanism is not as easy as: type facebook into your browser's address bar and press enter.
ActiveX, Java applets, Flash, and Silverlight all failed to take off (Flash had more success, but mobile has since killed it off) for building applications. Why?
I've used some software built on Adobe Air and I've found that to be a fairly pleasant experience.
What can we build that gives the benefits of a browser-based delivery, but is better than HTML/CSS/JS?