Will Emscripten/Asm.js kill Web-Development as we know it?
plus.google.com
plus.google.com
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?
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.
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).
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.
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.
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.
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).
Am I missing anything notable?
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.
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.
Its not a big pain but it would make my life easier!
Photoshop on a Chrome Pixel, for instance, makes a lot of sense.
The only thing I'm locked into is Chromium, and even that I can replace.
I'd like to add Chromium to your list.
And your answer is... that... "vendor lock-in"?
I'm sorry, but you're making zero sense.
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.
Flash? Silverlight? ActiveX?
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".
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.
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.
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.
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.
And this hypothetical API would need to be implemented individually for each language that you want to use for client side scripting.
Like I said, in the near term it's a lot easier to just write JavaScript.
Porting a GUI toolkit only relieves your need to deal with CSS, it does not alleviate you of all need for the DOM.
I am not splitting hairs, you are glossing over serious limitations to this approach.
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.
But you have to say something substantive.