6 ms·

Will Emscripten/Asm.js kill Web-Development as we know it?

31 points by kayoone 14y ago

bartl 14y ago
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".
- kayoone 14y ago
  GWT yes, which is some pretty impressive tech but limited to Java.
  - andybak 14y ago
    Check out pyjs (née pyjamas): http://pyjs.org/ http://pyjs.org/
- AndrewDucker 14y ago
  Because, IIRC, trying to work on large systems with many developers doesn't work nearly as well without static typing.
  - PommeDeTerre 14y ago
    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.
  - daigoba66 14y ago
    Large systems, in my opinion, generally benefit from static typing.
- dougk16 14y ago
  A little old, but here are some internal use cases for GWT at Google: https://groups.google.com/forum/m/?fromgroups#!topic/google-web-toolkit/Mjjk5y9RQbw https://groups.google.com/forum/m/?fromgroups#!topic/google-... 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.
AndrewDucker 14y ago
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).
- kayoone 14y ago
  it still might be possible with things like LLJS that can communicate back to "normal" js code.
- yuchi 14y ago
  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 14y ago
    And transpiled Javascript is clearer than Python how?
    - masklinn 14y ago
      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.
    - yuchi 14y ago
      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.
asplake 14y ago
http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
- freehunter 14y ago
  Freehunter's Corollary: If a headline asks a question, someone in the comments will mention Betteridge's Law.
- mooism2 14y ago
  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.
PommeDeTerre 14y ago
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.
- simonlc 14y ago
  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.
  - kayoone 14y ago
    well id personally love to use my desktop as i left it off with a click of a button on any pc/tablet that has a browser. Its not a big pain but it would make my life easier!
  - VikingCoder 14y ago
    The browser is now an operating system (as Chromium proves). Photoshop is welcome to run on any operating system. Photoshop on a Chrome Pixel, for instance, makes a lot of sense.
    - camus 14y ago
      the Pixel makes little sense to start with unless you enjoy vendor locking.
      - VikingCoder 14y ago
daigoba66 14y ago
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?
Associat0r 14y ago
Smart programmers would never let target platforms dictate their source language.
artificialidiot 14y ago
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.
T-A 14y ago
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".
- aethertap 14y ago
  I had to read that twice, slowly, to notice. Good catch!
- kayoone 14y ago
  yeah i meant piracy obviously, damnit :) Cant change it in the shared item anymore for whatever reason...
ebbv 14y ago
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.
- kayoone 14y ago
  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)
  - ebbv 14y ago
    No, of course it's not impossible. But I was pointing out a flaw in the article, it glosses over this issue. 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.
- swombat 14y ago
  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 14y ago
    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 14y ago
aethertap 14y ago
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.
aioprisan 14y ago
LLVM is not C/C++
fennecfoxen 14y ago
"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 14y ago
  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.

31 points by kayoone 14y ago

bartl 14y ago

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

kayoone 14y ago
GWT yes, which is some pretty impressive tech but limited to Java.
- andybak 14y ago
  Check out pyjs (née pyjamas): http://pyjs.org/ http://pyjs.org/
AndrewDucker 14y ago
Because, IIRC, trying to work on large systems with many developers doesn't work nearly as well without static typing.
- PommeDeTerre 14y ago
  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.
- daigoba66 14y ago
  Large systems, in my opinion, generally benefit from static typing.
dougk16 14y ago
A little old, but here are some internal use cases for GWT at Google: https://groups.google.com/forum/m/?fromgroups#!topic/google-web-toolkit/Mjjk5y9RQbw https://groups.google.com/forum/m/?fromgroups#!topic/google-... 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.

AndrewDucker 14y ago

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

kayoone 14y ago
it still might be possible with things like LLJS that can communicate back to "normal" js code.
yuchi 14y ago
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 14y ago
  And transpiled Javascript is clearer than Python how?
  - masklinn 14y ago
    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.
  - yuchi 14y ago
    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.

asplake 14y ago

http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines

freehunter 14y ago
Freehunter's Corollary: If a headline asks a question, someone in the comments will mention Betteridge's Law.
mooism2 14y ago
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.

PommeDeTerre 14y ago

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.

simonlc 14y ago
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.
- kayoone 14y ago
  well id personally love to use my desktop as i left it off with a click of a button on any pc/tablet that has a browser. Its not a big pain but it would make my life easier!
- VikingCoder 14y ago
  The browser is now an operating system (as Chromium proves). Photoshop is welcome to run on any operating system. Photoshop on a Chrome Pixel, for instance, makes a lot of sense.
  - camus 14y ago
    the Pixel makes little sense to start with unless you enjoy vendor locking.
    - VikingCoder 14y ago

daigoba66 14y ago

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?

Associat0r 14y ago

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

artificialidiot 14y ago

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.

T-A 14y ago

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

aethertap 14y ago
I had to read that twice, slowly, to notice. Good catch!
kayoone 14y ago
yeah i meant piracy obviously, damnit :) Cant change it in the shared item anymore for whatever reason...

ebbv 14y ago

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.

kayoone 14y ago
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)
- ebbv 14y ago
  No, of course it's not impossible. But I was pointing out a flaw in the article, it glosses over this issue. 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.
swombat 14y ago
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 14y ago
  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 14y ago

aethertap 14y ago

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.

aioprisan 14y ago

LLVM is not C/C++

fennecfoxen 14y ago

"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 14y ago
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.