10 ms·

Sitting about 10 feet away from Luke Wagner right now. He has told me that asm.js is Mozilla's response to NaCl. You compile code with Clang (or another compile

• duaneb 14y ago
  > They use special tricks, like (a+b)|0, to force results to be in the int32 range, and avoid overflow checks. Why is this not seen as the worst idea ever? Why this great resistance to moving away from javascript?
  • mccr8 14y ago
    > Why this great resistance to moving away from javascript? To what? What scenario do you envision where Apple, Google, Microsoft and Mozilla are all willing to implement a single new language for the web?
    • duaneb 14y ago
      > To what? What scenario do you envision where Apple, Google, Microsoft and Mozilla are all willing to implement a single new language for the web? Well hopefully we wouldn't make the same mistake again by going with a language and we would just implement a VM on which JS is implemented. It would be much easier to validate the correctness of a VM anyway, achieve better speed than was possible before, and not tie people down to a (painful) language. On a personal note I would actually start to view the web browser as a platform instead of a bunch of tangled strings, cans, and tape. EDIT: I didn't answer your question. But, as a developer, I will only move to the web for my default programming language when I have bytecode or assembly to look at, not some convoluted scripting language. Hopefully, Asm.js is a minor, minor bump on the way towards the browser as a usable platform for arbitrary development.
      • deleted 14y ago
        [deleted]
      • TheZenPsycho 14y ago
        Oh. Right. A VM. On the web. Because that worked reallllly well when Java did it.
        • duaneb 14y ago
          Yes, because all VMs are as bad as the JVM, which was never intended to be run through a browser.
          • TheZenPsycho 14y ago
            oh my, how old are you, little boy? http://en.wikipedia.org/wiki/Java_applet http://en.wikipedia.org/wiki/Java_applet "Java applets were introduced in the first version of the Java language in 1995" Remember, why Javascript is called Javascript. So it wouldn't be seen as competing with Java as "the language of the web". Java, and its VM was designed for the web. To run in a browser. It was given every conceivable chance, and it utterly failed because ultimately, it's fundamentally a terrible idea. But somehow fellows like you are too headcopped to see history for what it is, and you are doomed to repeat it. I remember when most developers would be surprised if you told them you could make programs in Java that are not applets. And java had a reputation for being "that really shitty slow painful web language"
            • munificent 14y ago
              > It was given every conceivable chance Except that it didn't have decent DOM integration...
              • TheZenPsycho 14y ago
                Yes it did. The DOM was designed to be used from JAVA. which is why it seems so out of place and verbose in JavaScript.
    • ajasmin 14y ago
      Now Apple, Google, Microsoft and Mozilla will all have to ensure that tricks like (a+b)|0 are executed optimally though.
      • nnethercote 14y ago
        Yeah, but that's not hard. And there's a spec that makes it extremely clear which tricks are necessary -- no need to reverse-engineer someone else's implementation, and no risk of tricks that work today breaking tomorrow.
      • cpeterso 14y ago
        The beauty of this approach is that browser vendors don't have to execute these quirky expressions optimally. They are standard JS, so they will already work.
  • deleted 14y ago
    [deleted]
    • duaneb 14y ago
      > This isn't moving away from JavaScript. Exactly, that's the problem.
    • sblom 14y ago
      > This isn't moving away from JavaScript. Exactly, that's the point.
  • chc 14y ago
    Why this great insistence on moving away from JavaScript? If it serves the purpose well enough, I see no problem.
    • PommeDeTerre 14y ago
      It really doesn't, though. For the first 12 or so years of its existence it was basically unusable. It wasn't until jQuery hit the scene that it started to meet even the bare minimum level of usability. Even then, it still took a huge amount of effort and investment from Google, Apple and Mozilla to make it what it is today, which admittedly isn't very good at all. Even now, it generally only looks like a "good" option to those who don't have experience with other, better programming languages (PHP excluded; it's nearly as bad as JavaScript is). Developers who do have more experience with other languages usually use JavaScript very reluctantly, and this is especially true when it comes to the best developers. The fact that CoffeeScript, TypeScript and Dart get so much attention just further shows how bad JavaScript is. Developers don't want to use it, and so they try to hide it to a large extent (CoffeeScript), or modify it to be more like languages like C++, Java and C# (TypeScript and Dart). JavaScript should have been replaced many years ago, if it ever should have even been included in Navigator so many years ago.
      • wwweston 14y ago
        > For the first 12 or so years of its existence it was basically unusable. It wasn't until jQuery hit the scene that it started to meet even the bare minimum level of usability. jQuery didn't address problems with the JavaScript language -- to the contrary, it's a pretty good example of the power JS has and what can be accomplished with it. The problem jQuery addressed was the DOM API (and some other points of interface with the browser), which was probably the most significant pain point, and which probably wouldn't have been much different had another language been chosen. > Developers who do have more experience with other languages usually use JavaScript very reluctantly Yes, by and large, one of the biggest problems with JavaScript might be that people seem to approach it as if they don't or shouldn't have to learn it instead of whatever else they're already familiar with. I fit that description from 1999-2003 or so -- along with the description of someone who had/has experience with other "better" programming languages -- but after a few key pointers about scope and functions from someone who had taken the time to learn to use it, I don't share your apparent view at all. My experience has been that it's serviceable and more or less on par with Perl, Python, and Ruby... to the point where my suspicion is that most developers for whom the language itself is a significant obstacle wouldn't do appreciably better were JS magically replaced with something like any of those three. > Developers don't want to use it, and so they try to hide it to a large extent (CoffeeScript) CoffeeScript is JavaScript semantics with different tokens and a handful of shortcuts/sugar. More power to people who enjoy using it, but to the extent anybody's arguing that it's good enough, they're also arguing that JS really wasn't that bad all along.
  • k3n 14y ago
    It's not moving away from, it's addressing shortcomings. As you should know, JS only has 1 type of numeric representation in userland, Number, which serves both floats and ints. Not surprisingly, operations with ints are much more efficient than with floats, and if an optimizer can introspect your code and determine that some value will only ever be an int, internally it will represent it as a int. Otherwise, it's forced to use a float representation. Thus, coercing all values to values that can be internally represented as ints can yield a significant performance boost.
    • shardling 14y ago
      And importantly, still work on browsers that don't specifically support asm.js. They'd be slower, because they wouldn't be taking advantage of the available optimization, but the code would still run.
  • pcwalton 14y ago
    Because backwards compatibility is really important. x86, the Windows API, TCP, IPv4, and Unix (compared to Plan 9) are all examples of things that are full of cruft, but they persist because they have the right survival characteristics. Besides, all it really comes down to is that the bytecode format has a weird encoding when sent over the wire. That's OK. You can view it as isomorphic to a format with a more natural encoding if you'd like; such a "disassembler" would be trivial to write.
    • skatepark 14y ago
      > Because backwards compatibility is really important. x86, the Windows API, TCP, IPv4, and Unix (compared to Plan 9) are all examples of things that are full of cruft, but they persist because they have the right survival characteristics. All of those things were also incredibly successful at what they did. JavaScript and the DOM have not been incredibly successful at turning the browser into a first-class application development platform. This is for many reasons; network performance, CPU performance, the difficulty of composing rich APIs, the lack of cleanly defined re-usable widgets and libraries (eg, the non-suitability of the DOM), the difficulty of interacting with the host. Given that, why not start fresh for targeting applications? Leave JS in place, let your system target it as an output format for backwards compatibility, and -- finally -- clean up the massive cruft of the web as an app platform. Discarding decades of experience in producing effective consumer applications on the desktop (and now mobile) is foolish.
      • samth 14y ago
        > JavaScript and the DOM have not been incredibly successful at turning the browser into a first-class application development platform. Seriously? From where I stand, it looks like browser-based applications are destroying the desktop-based software market with alacrity, and are coming for mobile. And also that major vendors like Google and Microsoft are shipping desktop platforms where JS (and sometimes the DOM) is a primary way of developing applications. The browser as application development platform is one of the two most important developments in software development in the last 20 years. That looks "incredible successful" to me.
  • deleted 14y ago
    [deleted]
  • azakai 14y ago
    No one is saying (a+b)|0 is pretty. If you care about syntax, you would probably use something like sweet.js to make a macro for it or something like that. asm.js is not concerned with pretty syntax. It just takes the existing type of code emscripten and mandreel have generated for a long time now, and writes a formal spec for it. That's useful to get code to run faster. That's it.
  • coldtea 14y ago
    citation needed
  • sultezdukes 14y ago
    Would you be happier if COBOL was the lingua-franca of the web? No dig on Javascript (always had a soft-spot for prototypes), but at the end of the day we have different languages for a reason.
• lucian1900 14y ago
  I'd really much prefer something lower level, so anything can be easily implemented on top with predictable performance (including JavaScript). I don't understand the resistance to PNaCl, it's plugins done right.
  • tachyonbeam 14y ago
    They really want the performance of asm.js code to be predictable, and as a compiler writer, I believe this is entirely possible. The subset of JS they use is made to have good performance. The people here don't seem to like some of the implementation details of NaCl. I think they also might just not want to let Google impose something. Also, the inventor of JavaScript is the Mozilla CTO (shhh!). I'm partial to PNaCl too. I think it's probably better, in the long term, to have a standard bytecode format to compile to... But, asm.js might win this war, just because the road to asm.js support is much shorter. You basically already can compile C programs to asm.js and have them run cross-browser. Worse is better?
    • JA1001AC 14y ago
      Search for "LLVM IR is a compiler IR".
  • dherman 14y ago
    There are good and bad things about PNaCl. But overall, the resistance to PNaCl goes beyond Mozilla -- it's a really hard standardization/synchronization problem. Our goal with asm.js was to produce something that could work today (because it's 100% compatible with existing JS semantics) and work even better tomorrow as engines optimize it even better. Edit: Re: predictable performance, that's exactly what asm.js is about. The performance model is much closer to that of C or PNaCl/LLVM.
  • azakai 14y ago
    This is lower-level. It is JavaScript, but really it is a subset that implements low-level operations. In fact lower than PNaCl, this is past the LLVM IR level.
• stcredzero 14y ago
  > He has told me that asm.js is Mozilla's response to NaCl. For a bit of viewpoint from a couple of years back: http://news.ycombinator.com/item?id=2057443 http://news.ycombinator.com/item?id=2057443
  • pcwalton 14y ago
    The author's specific concern there is about control over memory layout. In that regard asm.js should stack up well, because its memory model is a large linear array of bytes. It's hard to imagine more fine-grained control than that, except if perhaps mmap() and munmap() were supported.