

Will Emscripten/Asm.js kill Web-Development as we know it? - kayoone
https://plus.google.com/u/0/105644069994668210113/posts/BpBBtuH5848

======
daigoba66
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?

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

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

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

~~~
pekk
And transpiled Javascript is clearer than Python how?

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

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

~~~
AndrewDucker
Because, IIRC, trying to work on large systems with many developers doesn't
work nearly as well without static typing.

~~~
daigoba66
Large systems, in my opinion, generally benefit from static typing.

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

Am I missing anything notable?

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

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

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

~~~
phpnode
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?

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

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

------
Associat0r
Smart programmers would never let target platforms dictate their source
language.

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

~~~
kayoone
yeah i meant piracy obviously, damnit :) Cant change it in the shared item
anymore for whatever reason...

------
aioprisan
LLVM is not C/C++

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

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

~~~
ebbv
You can't "do away with the DOM altogether". You need to have some method of
interacting with the browser; location, AJAX requests, cookies, etc.

Porting a GUI toolkit only relieves your need to deal with CSS, it does not
alleviate you of all need for the DOM.

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

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

------
asplake
<http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines>

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

But you have to say something _substantive_.

