4 ms·

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborat

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a single language and seemingly little real effort to build a Multilanguage abstraction. If you told me 20 years ago about what the web would become, I'd be amazed. If you went on to say that all programming would be in a single language -- I'd think you were crazy, yet here we are. The web should have added 1st class support for plug-ins, rather than the direction we went to effectively abolish plugins from browsers.

jmspring 13y ago
Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.
- kenjackson 13y ago
  JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.
  - _delirium 13y ago
    I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?
    - AnthonyMouse 13y ago
      There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler. But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
      - BugBrother 13y ago
        I came into this discussion many hours late, but I have to ask: Why are people discussing as if asm.js didn't exist?! It is fast. (It even support integers!) To me, asm.js looks like a bad kludge -- and a great road ahead, just extend it a little bit over the next decade with the stuff compiler writers will clamor for. Am I missing something?
        AnthonyMouse 13y ago
        What you're missing is that there is no need to do that. Using JavaScript as an intermediary representation for other languages on a permanent basis is kind of ridiculous. Improving browser support for JavaScript-as-IR provides no benefit over adding support for a "real" IR and introduces superfluous complexity which is the enemy of both performance and security. Compiling other languages to JavaScript is a tolerable transition mechanism while browsers that don't support something better are still popular, but trying to improve the ability of browsers to interpret compiled-to-JavaScript code from other languages is farcical -- if you're going to update the browser then update it to support something better than JavaScript, not to improve the performance of the horrible legacy transition kludge.
        BugBrother 13y ago
  - bzbarsky 13y ago
    > JavaScript and HTML are a lot more bloat than machine language code written to the wire. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web). And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?
    - kenjackson 13y ago
      That's not how you measure bloat. There's a huge runtime associated with that JS code, and you ignored performance.
      - bzbarsky 13y ago
        Ah, you mean client memory bloat, not transfer bloat (i.e. pageload time). That part was not very clear at all. You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving. I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.
- bratsche 13y ago
  Why do you care what the target of the compile is if you're happy with the language you're writing in? That seems like being upset that some code you wrote in a language you like might be running on some processor you don't like.
  - Twirrim 13y ago
    Because it requires some really difficult conversion work under the surface. For example, JS has no concept of integers. To shoe-horn other languages in involves a lot of extra work, which by nature is going to be less efficient. Worse, the javascript engine's JIT can't take advantage of some of the semantics of the language being converted, e.g. if the JIT knew for sure that the number was an int, it could take advantage of that in various ways, or make a smarter decision based on the known performance characteristics of the hardware it's running on.
  - SiVal 13y ago
    because it's inevitably a leaky abstraction
    - stplsd 13y ago
      Jesus, the next time I will read phrase 'leaky abstraction' I am going to throw up.
- AnthonyMouse 13y ago
  The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.
  - baddox 13y ago
    If there exists a tool that compiles your language of choice to JavaScript, and the stuff you write in your language of choice works on modern browsers and is stable and performant, why do you care that it's JavaScript being compiled to and not byte code?
    - peterashford 13y ago
      Because JS will always be compromised by being JS shoe horned into a role it wasn't designed for and not byte code optimised for the purpose at hand. Shoe horning technologies into roles they weren't intended for could describe the entire scope of why the Web sucks (e.g.: HTML mixing presentation with semantics).
  - acqq 13y ago
    If you think about it, bytecode you wish just doesn't exist, whereas JavaScript does and it works: http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-...
    - _random_ 13y ago
      The point is that we have something that sucks, not that we don't have anything at all.
  - 13y ago
- tim333 13y ago
  I guess Google's Dart is trying to go that way. Not sure it's going to get there though.
cbhl 13y ago
The web was multi-lingual, it's why script tags have a "type" parameter. I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.
- chipotle_coyote 13y ago
  Uh, scripts aren't plugins, right? In theory there could be other scripting languages for use in web browsers, which is what the "type" attribute would have been used to indicate. It's just that nothing else ever really took off. Other than Microsoft's VBScript, the only browsers I can think of that supported other scripting languages were early proof-of-concept attempts like Grail. I think you're a bit confused about browser plugins in general here. They're OS-specific and CPU-specific. I can run Linux, Windows and OS X on a MacBook, but I need OS-specific versions of both the browser of my choice for each one and the browser plugins of my choice for each one. If the iPhone has helped contribute to the decline of plugins, it's because iOS doesn't support them at all, full stop -- if it did, though, they'd have needed to be compiled in iOS-specific versions even if the iPhone used x86 chips.
  - cbhl 13y ago
    I was responding to two statements in one comment; I apologize for the confusing non-sequitur. I do agree that plugins are OS and CPU specific, but I think the popularity and explicit lack of support in iOS and Mobile Safari (which, to my understanding, are stripped down ports of OS X and Safari) really caused web developers and their clients to move off of Flash (and other plugins). For a number of years, Adobe shipped a version of Flash for Android, and I'm under the impression that they were always willing to port it to other platforms/devices if paid enough money (since the Linux binaries had an explicit restriction from inclusion in devices; you could only use them with general-purpose PCs). Java ME ran on phones for years, too, although I don't recall anyone shipping a mobile browser with Java SE plugin support. If someone (a client or web developer) wanted their website to work on iPhone, they had to remove the plugins, and I think many people just started designing around that constraint.

jmspring 13y ago

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

kenjackson 13y ago
JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.
- _delirium 13y ago
  I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?
  - AnthonyMouse 13y ago
    There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler. But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
    - BugBrother 13y ago
      I came into this discussion many hours late, but I have to ask: Why are people discussing as if asm.js didn't exist?! It is fast. (It even support integers!) To me, asm.js looks like a bad kludge -- and a great road ahead, just extend it a little bit over the next decade with the stuff compiler writers will clamor for. Am I missing something?
      - AnthonyMouse 13y ago
        What you're missing is that there is no need to do that. Using JavaScript as an intermediary representation for other languages on a permanent basis is kind of ridiculous. Improving browser support for JavaScript-as-IR provides no benefit over adding support for a "real" IR and introduces superfluous complexity which is the enemy of both performance and security. Compiling other languages to JavaScript is a tolerable transition mechanism while browsers that don't support something better are still popular, but trying to improve the ability of browsers to interpret compiled-to-JavaScript code from other languages is farcical -- if you're going to update the browser then update it to support something better than JavaScript, not to improve the performance of the horrible legacy transition kludge.
        BugBrother 13y ago
- bzbarsky 13y ago
  > JavaScript and HTML are a lot more bloat than machine language code written to the wire. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web). And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?
  - kenjackson 13y ago
    That's not how you measure bloat. There's a huge runtime associated with that JS code, and you ignored performance.
    - bzbarsky 13y ago
      Ah, you mean client memory bloat, not transfer bloat (i.e. pageload time). That part was not very clear at all. You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving. I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.
bratsche 13y ago
Why do you care what the target of the compile is if you're happy with the language you're writing in? That seems like being upset that some code you wrote in a language you like might be running on some processor you don't like.
- Twirrim 13y ago
  Because it requires some really difficult conversion work under the surface. For example, JS has no concept of integers. To shoe-horn other languages in involves a lot of extra work, which by nature is going to be less efficient. Worse, the javascript engine's JIT can't take advantage of some of the semantics of the language being converted, e.g. if the JIT knew for sure that the number was an int, it could take advantage of that in various ways, or make a smarter decision based on the known performance characteristics of the hardware it's running on.
- SiVal 13y ago
  because it's inevitably a leaky abstraction
  - stplsd 13y ago
    Jesus, the next time I will read phrase 'leaky abstraction' I am going to throw up.
AnthonyMouse 13y ago
The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.
- baddox 13y ago
  If there exists a tool that compiles your language of choice to JavaScript, and the stuff you write in your language of choice works on modern browsers and is stable and performant, why do you care that it's JavaScript being compiled to and not byte code?
  - peterashford 13y ago
    Because JS will always be compromised by being JS shoe horned into a role it wasn't designed for and not byte code optimised for the purpose at hand. Shoe horning technologies into roles they weren't intended for could describe the entire scope of why the Web sucks (e.g.: HTML mixing presentation with semantics).
- acqq 13y ago
  If you think about it, bytecode you wish just doesn't exist, whereas JavaScript does and it works: http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-...
  - _random_ 13y ago
    The point is that we have something that sucks, not that we don't have anything at all.
- 13y ago
tim333 13y ago
I guess Google's Dart is trying to go that way. Not sure it's going to get there though.

cbhl 13y ago

The web was multi-lingual, it's why script tags have a "type" parameter. I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.

chipotle_coyote 13y ago
Uh, scripts aren't plugins, right? In theory there could be other scripting languages for use in web browsers, which is what the "type" attribute would have been used to indicate. It's just that nothing else ever really took off. Other than Microsoft's VBScript, the only browsers I can think of that supported other scripting languages were early proof-of-concept attempts like Grail. I think you're a bit confused about browser plugins in general here. They're OS-specific and CPU-specific. I can run Linux, Windows and OS X on a MacBook, but I need OS-specific versions of both the browser of my choice for each one and the browser plugins of my choice for each one. If the iPhone has helped contribute to the decline of plugins, it's because iOS doesn't support them at all, full stop -- if it did, though, they'd have needed to be compiled in iOS-specific versions even if the iPhone used x86 chips.
- cbhl 13y ago
  I was responding to two statements in one comment; I apologize for the confusing non-sequitur. I do agree that plugins are OS and CPU specific, but I think the popularity and explicit lack of support in iOS and Mobile Safari (which, to my understanding, are stripped down ports of OS X and Safari) really caused web developers and their clients to move off of Flash (and other plugins). For a number of years, Adobe shipped a version of Flash for Android, and I'm under the impression that they were always willing to port it to other platforms/devices if paid enough money (since the Linux binaries had an explicit restriction from inclusion in devices; you could only use them with general-purpose PCs). Java ME ran on phones for years, too, although I don't recall anyone shipping a mobile browser with Java SE plugin support. If someone (a client or web developer) wanted their website to work on iPhone, they had to remove the plugins, and I think many people just started designing around that constraint.