5 ms·

That ship sailed a long time ago. I see it as when they gave up on Friend Connect / OpenSocial as when they sort of gave up on the idea of open-first, and inste

That ship sailed a long time ago. I see it as when they gave up on Friend Connect / OpenSocial as when they sort of gave up on the idea of open-first, and instead started focusing it competing feature-for-feature. Mozilla is the champion of the open web these days. Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is. And now Mozilla is embarrassing them with emscripten and asm.js.

derefr 14y ago
You know, I keep seeing this "proprietary NaCl" statement around, and having played with it myself, I have a bit of a soapbox. There's nothing proprietary about NaCl: all the specs are open, and Google actively wants Mozilla and others to support them. To be charitable, though, I guess what most people mean by "NaCl is not open like Javascript" is that it's low-level--compiled binaries instead of readily-accessible script. And that's true; it exposes less to the user--and although it would be perfectly possible for every NaCl module to be debuggable through the browser with embedded symbols, just like Javascript is, it hasn't happened yet. But you know, NaCl isn't for that, as far as I can tell. It's not a thing to write the business-domain logic of your web app in. It's far too clunky to develop with, if that were the intent. Instead, what NaCl seems perfectly suited as, to me, is an architecture for writing pluggable scripting-language virtual machines. In other words, to give freedom of choice to use a backend other than V8 to write your web app against. Java-in-the-browser, Ruby-in-the-browser, Erlang-in-the-browser; any of those would be possible, and just as transparent+useful as Javascript-in-the-browser (in fact, V8 itself could be lifted out to being just another NaCl module.) And since the site would deliver the "runtime" for the scripts itself[1], any compatible browser could pull it down and execute it, instead of waiting for IE, Firefox, Chrome, etc. to all adopt the new language before anyone can start using it (a Sisyphean wait.) There's already one perfect example of how this all would work: Adobe Flash. Flash is, in Chrome at least, an NaCl (PPAPI) module. Now, Flash isn't a shining example of openness--but using a custom interpreter is not where it goes wrong.[2] You can easily imagine Flash without that problem: a world where you can have <script type="text/actionscript"> and the Flash runtime will reach in and execute that code, just like the Javascript runtime reaches in and executes your JS. --- [1] This doesn't necessarily have to be true, though. The browser can come with default language runtime modules, and then the webapp can suggest a site-specific runtime module, but the browser doesn't have to take that suggestion. Which is exactly the way a thing that is considered "open" on the web works: fonts! Think of an NaCl module as being no more or less than a custom @font-face rule for the execution of a script. [2] Flash goes wrong by embedding its programs into proprietary binary asset packages [SWFs]; goes wrong again by drawing everything onto a single canvas, not allowing for anything like DOM manipulation; and then goes wrong a third time by having only one de-facto implementation with no open standard.
- samastur 14y ago
  What do you mean by specs are open? Published fully or developed communally? Fully published is obviously better than not, but is rarely enough. Openness is not a binary choice.
  - derefr 14y ago
    Developed communally, as part of the Chromium project. Not as a vendor-neutral working group or anything of the sort yet, mind you. But there's no reason it wouldn't move to become that if any other vendor was actually interested in coordinating on it--they're not hiding their cards inside Google's walled garden or anything.
    - MatthewPhillips 14y ago
      You're incorrect, that's not how NaCl or Dart were developed. They were developed in secret years before released. They're alpha versions had all of the fundamentals established when finally presented to the public.
      - derefr 14y ago
        I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. Everything was designed in secret at some point: within the head of whoever was thinking about it, before they decided to start talking about it.
        MatthewPhillips 14y ago
        > I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. You don't? Go look at the nacl commit logs and count how many non-Google employees are contributing. That it was developed in secret is precisely the reason for this (not because they are against outside contributors today). If you develop a supposedly open technology in secret it either needs to be 1) really good or 2) really popular. XHR is successful because it fits into both. Whatever you may feel about NaCl, Microsoft, Apple and Mozilla don't think it's good.
lucian1900 14y ago
NaCl (in particular PNaCl) is merely a different approach. I would call asm.js crazy, but that's just me. Something similar could be said about Dart, but there the language itself is not so interesting (merely not insane). The VM is potentially the language-independent bytecode and stdlib in a browser we've all been waiting for. While Google have been behavin evil-ly lately, in particular related to Google+, NaCl and Dart are not examples of this.
- pcwalton 14y ago
  Why is asm.js crazy?
- hosay123 14y ago
  Nacl is not merely a different approach, it's a wholly backwards incompatible approach based on techniques that tried and failed in the 80s (try searching for ANDF).
  - mkr-hn 14y ago
    A lot of things were tried in the past, but they fail for a variety of reasons. Some are picked up later and work because the fatal problems were addressed. I couldn't find much on ANDF. Can you be more specific about why it failed?
- ville 14y ago
  To clarify, Dart VM is not a bytecode VM: http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/
michaelwww 14y ago
> Google started their proprietary ... Dart project because they claimed you couldn't make JavaScript any faster than it currently is No, they didn't. Google started Dart because they had a bunch of Java programmers who were having good success building JavaScript web apps such as Gmail with Google Web Toolkit. They thought to formalize it with Dart instead of using a hacked up Java dev environment. I have a client who needed a web app fast, so I took a chance on Dart and did it in half the time. The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. There's a bright side to all the dislike and misinformation about Dart though, because it gives me a competitive edge.
- mistercow 14y ago
  >The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. I would feel very uncomfortable about that unless it's the sort of client that doesn't really have the tech background to assume you're writing it in JS in the first place. I think if someone is paying to have software written for them, they have a right to have some control over what language it's written in and what libraries it uses. After all, if they need to hire someone else to maintain it or add to it later on, they're going to have a far easier time finding a JS developer to do that than a Dart developer (at least for now). And, of course, you have the right to charge twice as much to do it in JS if it's going to take you twice as long.
  - michaelwww 14y ago
    I agree with you, but this client really doesn't care, only that it is done quickly and it works. They're pretty happy and are lining up more work for me. I'd say the greatest experience I had with it besides real types, code completion and intellisense, is that it ran first time on iPad (Safari, Chrome, FF), Mac and Windows FF and Chrome. I had a slight problem with IE9 and 10, but nothing too hard to fix. The client had paid someone to do it in ActionScript/Flash but the project had to be cancelled when Flash on mobile was mostly deprecated. I didn't look at the ActionScript code, but later found out there is a lib for that (haven't tried it and won't unless I have to someday) http://www.dartflash.com/ http://www.dartflash.com/
mistercow 14y ago
>Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is I don't remember them saying that. I remember them saying that JS has insurmountable performance problems, but that's very different from saying that JS is as fast as it can get. As for asm.js, it's another approach to the same problem. An insurmountable problem for a VM usually means that there's a limit to how well the VM can reason about arbitrary code. The clever thing about asm.js is that it gets around that by just restricting the language rather than inventing a new one. The clever thing about Dart is that you would rather write in it than kill yourself. And yes, of course asm.js is meant to be written by compiling via emscripten, but that means trading far more dynamicness for speed than you would with Dart.
acdha 14y ago
I was with you on the first paragraph but the second goes off the rails on the second sentence. It's hard to say that Google isn't also championing the open web unless you claim that Chrome isn't a Google product - NaCL and Dart are interesting experiments but it's not like Google hasn't poured a TON of expensive, high-quality time into creating an industry-leading JavaScript engine (along with CSS, HTML5, etc. support) and put a similar amount of time into evangelism, developer outreach, etc. Even if Google cancelled Chrome tomorrow, the entire open web community would owe them a debt of gratitude for administering the coup de grace to IE's reputation as the only significant desktop browser and pushing Mozilla to heavily invest in performance and the user experience – they cared about them before but as we can see now, setting your goal as “better than IE” was still too low. There were a bunch of nice things which happened around that time – Firefox, Safari, iPhone, etc. – but the thing which really opened the desktop market moving was Chrome shipping a radically fast, user-friendly browser which you could install even on typical corporate IT-mismanaged desktops and which you never needed to think about updating. Web standards advocates had spent years preaching using standards first and fallbacks for compatibility and related ideas but the rise of Chrome seems to be what got the mainstream web developer to really internalize that idea and start coding with the assumption that the browser would improve before they revisited a site.

derefr 14y ago

You know, I keep seeing this "proprietary NaCl" statement around, and having played with it myself, I have a bit of a soapbox. There's nothing proprietary about NaCl: all the specs are open, and Google actively wants Mozilla and others to support them. To be charitable, though, I guess what most people mean by "NaCl is not open like Javascript" is that it's low-level--compiled binaries instead of readily-accessible script. And that's true; it exposes less to the user--and although it would be perfectly possible for every NaCl module to be debuggable through the browser with embedded symbols, just like Javascript is, it hasn't happened yet. But you know, NaCl isn't for that, as far as I can tell. It's not a thing to write the business-domain logic of your web app in. It's far too clunky to develop with, if that were the intent. Instead, what NaCl seems perfectly suited as, to me, is an architecture for writing pluggable scripting-language virtual machines. In other words, to give freedom of choice to use a backend other than V8 to write your web app against. Java-in-the-browser, Ruby-in-the-browser, Erlang-in-the-browser; any of those would be possible, and just as transparent+useful as Javascript-in-the-browser (in fact, V8 itself could be lifted out to being just another NaCl module.) And since the site would deliver the "runtime" for the scripts itself[1], any compatible browser could pull it down and execute it, instead of waiting for IE, Firefox, Chrome, etc. to all adopt the new language before anyone can start using it (a Sisyphean wait.) There's already one perfect example of how this all would work: Adobe Flash. Flash is, in Chrome at least, an NaCl (PPAPI) module. Now, Flash isn't a shining example of openness--but using a custom interpreter is not where it goes wrong.[2] You can easily imagine Flash without that problem: a world where you can have <script type="text/actionscript"> and the Flash runtime will reach in and execute that code, just like the Javascript runtime reaches in and executes your JS. --- [1] This doesn't necessarily have to be true, though. The browser can come with default language runtime modules, and then the webapp can suggest a site-specific runtime module, but the browser doesn't have to take that suggestion. Which is exactly the way a thing that is considered "open" on the web works: fonts! Think of an NaCl module as being no more or less than a custom @font-face rule for the execution of a script. [2] Flash goes wrong by embedding its programs into proprietary binary asset packages [SWFs]; goes wrong again by drawing everything onto a single canvas, not allowing for anything like DOM manipulation; and then goes wrong a third time by having only one de-facto implementation with no open standard.

samastur 14y ago
What do you mean by specs are open? Published fully or developed communally? Fully published is obviously better than not, but is rarely enough. Openness is not a binary choice.
- derefr 14y ago
  Developed communally, as part of the Chromium project. Not as a vendor-neutral working group or anything of the sort yet, mind you. But there's no reason it wouldn't move to become that if any other vendor was actually interested in coordinating on it--they're not hiding their cards inside Google's walled garden or anything.
  - MatthewPhillips 14y ago
    You're incorrect, that's not how NaCl or Dart were developed. They were developed in secret years before released. They're alpha versions had all of the fundamentals established when finally presented to the public.
    - derefr 14y ago
      I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. Everything was designed in secret at some point: within the head of whoever was thinking about it, before they decided to start talking about it.
      - MatthewPhillips 14y ago
        > I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. You don't? Go look at the nacl commit logs and count how many non-Google employees are contributing. That it was developed in secret is precisely the reason for this (not because they are against outside contributors today). If you develop a supposedly open technology in secret it either needs to be 1) really good or 2) really popular. XHR is successful because it fits into both. Whatever you may feel about NaCl, Microsoft, Apple and Mozilla don't think it's good.

lucian1900 14y ago

NaCl (in particular PNaCl) is merely a different approach. I would call asm.js crazy, but that's just me. Something similar could be said about Dart, but there the language itself is not so interesting (merely not insane). The VM is potentially the language-independent bytecode and stdlib in a browser we've all been waiting for. While Google have been behavin evil-ly lately, in particular related to Google+, NaCl and Dart are not examples of this.

pcwalton 14y ago
Why is asm.js crazy?
hosay123 14y ago
Nacl is not merely a different approach, it's a wholly backwards incompatible approach based on techniques that tried and failed in the 80s (try searching for ANDF).
- mkr-hn 14y ago
  A lot of things were tried in the past, but they fail for a variety of reasons. Some are picked up later and work because the fatal problems were addressed. I couldn't find much on ANDF. Can you be more specific about why it failed?
ville 14y ago
To clarify, Dart VM is not a bytecode VM: http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/

michaelwww 14y ago

> Google started their proprietary ... Dart project because they claimed you couldn't make JavaScript any faster than it currently is No, they didn't. Google started Dart because they had a bunch of Java programmers who were having good success building JavaScript web apps such as Gmail with Google Web Toolkit. They thought to formalize it with Dart instead of using a hacked up Java dev environment. I have a client who needed a web app fast, so I took a chance on Dart and did it in half the time. The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. There's a bright side to all the dislike and misinformation about Dart though, because it gives me a competitive edge.

mistercow 14y ago
>The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. I would feel very uncomfortable about that unless it's the sort of client that doesn't really have the tech background to assume you're writing it in JS in the first place. I think if someone is paying to have software written for them, they have a right to have some control over what language it's written in and what libraries it uses. After all, if they need to hire someone else to maintain it or add to it later on, they're going to have a far easier time finding a JS developer to do that than a Dart developer (at least for now). And, of course, you have the right to charge twice as much to do it in JS if it's going to take you twice as long.
- michaelwww 14y ago
  I agree with you, but this client really doesn't care, only that it is done quickly and it works. They're pretty happy and are lining up more work for me. I'd say the greatest experience I had with it besides real types, code completion and intellisense, is that it ran first time on iPad (Safari, Chrome, FF), Mac and Windows FF and Chrome. I had a slight problem with IE9 and 10, but nothing too hard to fix. The client had paid someone to do it in ActionScript/Flash but the project had to be cancelled when Flash on mobile was mostly deprecated. I didn't look at the ActionScript code, but later found out there is a lib for that (haven't tried it and won't unless I have to someday) http://www.dartflash.com/ http://www.dartflash.com/

mistercow 14y ago

>Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is I don't remember them saying that. I remember them saying that JS has insurmountable performance problems, but that's very different from saying that JS is as fast as it can get. As for asm.js, it's another approach to the same problem. An insurmountable problem for a VM usually means that there's a limit to how well the VM can reason about arbitrary code. The clever thing about asm.js is that it gets around that by just restricting the language rather than inventing a new one. The clever thing about Dart is that you would rather write in it than kill yourself. And yes, of course asm.js is meant to be written by compiling via emscripten, but that means trading far more dynamicness for speed than you would with Dart.

acdha 14y ago

I was with you on the first paragraph but the second goes off the rails on the second sentence. It's hard to say that Google isn't also championing the open web unless you claim that Chrome isn't a Google product - NaCL and Dart are interesting experiments but it's not like Google hasn't poured a TON of expensive, high-quality time into creating an industry-leading JavaScript engine (along with CSS, HTML5, etc. support) and put a similar amount of time into evangelism, developer outreach, etc. Even if Google cancelled Chrome tomorrow, the entire open web community would owe them a debt of gratitude for administering the coup de grace to IE's reputation as the only significant desktop browser and pushing Mozilla to heavily invest in performance and the user experience – they cared about them before but as we can see now, setting your goal as “better than IE” was still too low. There were a bunch of nice things which happened around that time – Firefox, Safari, iPhone, etc. – but the thing which really opened the desktop market moving was Chrome shipping a radically fast, user-friendly browser which you could install even on typical corporate IT-mismanaged desktops and which you never needed to think about updating. Web standards advocates had spent years preaching using standards first and fallbacks for compatibility and related ideas but the rise of Chrome seems to be what got the mainstream web developer to really internalize that idea and start coding with the assumption that the browser would improve before they revisited a site.