5 ms·

> It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable. With SourceMaps it

by laktek 14y ago

> It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable. With SourceMaps it's possible to make them readable[1]. Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE. [1] - https://wiki.mozilla.org/DevTools/Features/SourceMap https://wiki.mozilla.org/DevTools/Features/SourceMap

daeken 14y ago
> Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE. So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.
jre 14y ago
I don't think NaCl is targeted at web devs that are comfortable developing in the browser. It's targeted at the other devs that aren't comfortable with JS and who write C++ (or other) code (like in games or other graphic-intensive stuff).
ANTSANTS 14y ago
There's audio processing stuff that I'd love to do in web browsers, but I refuse to touch Javascript with a ten-foot pole. I am the kind of person that would like NaCl to be adopted outside of Chrome. If you are the kind of person that is more interested in building the "app" part of some application of that kind of program, you have nothing to fear from NaCl -- just think of it as opening up the "standard native code" (native browser code, like video codecs, gzip decompression, etc) part of the web browser to everyone. You don't really care about what's going on under the hood when your users decompress some data you served to them, as long as everything works properly, right? That's pretty much the definition of something that most web developers couldn't care less about, and that people who do (for lack of a better term) "fast computing" care desperately about. To give a recent example, what if you'd like to start serving Opus audio to all your users? The standard response to that idea now is "that's funny, Internet Explorer will never even support Vorbis, and that's over a decade old." If safe native code execution was a standard part of the browser right now, it would be trivial to distribute an Opus decoder alongside the "web app" you implemented in Javascript. Opus would just be your competitive advantage, not something you need to beg people to implement. It would already be ubiquitous. Before anyone mentions X implementation of Y audio codec in Javascript in an attempt to discredit the value of native code execution, just stop. I highly doubt it will work acceptably on my mom's computer (the average computer that accesses your site is almost surely a hell of a lot less powerful than you may assume it is), and I highly doubt you'll ever be able to rival the performance of native code for processing on the order of video codecs anyways. Not to mention the fact that the majority of the nontrivial Javascript audio demos you've heard were made possible in no small part due to standardized, native code linear filtering and convolution. "Frustration" would be the word that sums up the whole "web app" movement to me. When I see that someone's made a client-side GIF animating "web app," all I can think about is how it would have taken two seconds to hook an existing highly performant C GIF encoder up to some Javascript, and instead we had to wait for someone who knows Javascript to hack a painfully slow (and therefore useless for the vast majority of users) alternative together. You know how ubiquitous similar server-side services are? That's because all it takes to make one is a simple Javascript/HTML form (or HTTP, if you want to get trivial)-based interface to an existing C program. Just think of where client side web apps could be right now if the same were true for them.
- jorangreef 14y ago
  You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX. What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that. For example, instead of coding up IndexedDB and leaving no alternative, just provide proper POSIX, and let the database community do its thing.
  - MatthewPhillips 14y ago
    How would you expose POSIX on Windows?
    - jorangreef 14y ago
      POSIX is an interface not an implementation.
  - gsnedders 14y ago
    Because there's more interest in improving the (publicly accessible) web as a platform than improving installed web apps. Regardless, to expose such a low-level API would eliminate one of the big advantages of the web: given a browser, I can use any web app on any device. Given, for example, given a TV (which are typically closed platforms, but increasingly often include a fully featured browser), you likely wouldn't be able to install anything that a certain web app depended on (and even if you could, what are the odds that it's been tested on a big-endian platform?).
    - jorangreef 14y ago
      No, it would not eliminate the big advantage of the web as you say, merely deepen it. See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
      - 14y ago

by laktek 14y ago

daeken 14y ago

> Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE. So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.

jre 14y ago

I don't think NaCl is targeted at web devs that are comfortable developing in the browser. It's targeted at the other devs that aren't comfortable with JS and who write C++ (or other) code (like in games or other graphic-intensive stuff).

ANTSANTS 14y ago

There's audio processing stuff that I'd love to do in web browsers, but I refuse to touch Javascript with a ten-foot pole. I am the kind of person that would like NaCl to be adopted outside of Chrome. If you are the kind of person that is more interested in building the "app" part of some application of that kind of program, you have nothing to fear from NaCl -- just think of it as opening up the "standard native code" (native browser code, like video codecs, gzip decompression, etc) part of the web browser to everyone. You don't really care about what's going on under the hood when your users decompress some data you served to them, as long as everything works properly, right? That's pretty much the definition of something that most web developers couldn't care less about, and that people who do (for lack of a better term) "fast computing" care desperately about. To give a recent example, what if you'd like to start serving Opus audio to all your users? The standard response to that idea now is "that's funny, Internet Explorer will never even support Vorbis, and that's over a decade old." If safe native code execution was a standard part of the browser right now, it would be trivial to distribute an Opus decoder alongside the "web app" you implemented in Javascript. Opus would just be your competitive advantage, not something you need to beg people to implement. It would already be ubiquitous. Before anyone mentions X implementation of Y audio codec in Javascript in an attempt to discredit the value of native code execution, just stop. I highly doubt it will work acceptably on my mom's computer (the average computer that accesses your site is almost surely a hell of a lot less powerful than you may assume it is), and I highly doubt you'll ever be able to rival the performance of native code for processing on the order of video codecs anyways. Not to mention the fact that the majority of the nontrivial Javascript audio demos you've heard were made possible in no small part due to standardized, native code linear filtering and convolution. "Frustration" would be the word that sums up the whole "web app" movement to me. When I see that someone's made a client-side GIF animating "web app," all I can think about is how it would have taken two seconds to hook an existing highly performant C GIF encoder up to some Javascript, and instead we had to wait for someone who knows Javascript to hack a painfully slow (and therefore useless for the vast majority of users) alternative together. You know how ubiquitous similar server-side services are? That's because all it takes to make one is a simple Javascript/HTML form (or HTTP, if you want to get trivial)-based interface to an existing C program. Just think of where client side web apps could be right now if the same were true for them.

jorangreef 14y ago
You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX. What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that. For example, instead of coding up IndexedDB and leaving no alternative, just provide proper POSIX, and let the database community do its thing.
- MatthewPhillips 14y ago
  How would you expose POSIX on Windows?
  - jorangreef 14y ago
    POSIX is an interface not an implementation.
- gsnedders 14y ago
  Because there's more interest in improving the (publicly accessible) web as a platform than improving installed web apps. Regardless, to expose such a low-level API would eliminate one of the big advantages of the web: given a browser, I can use any web app on any device. Given, for example, given a TV (which are typically closed platforms, but increasingly often include a fully featured browser), you likely wouldn't be able to install anything that a certain web app depended on (and even if you could, what are the odds that it's been tested on a big-endian platform?).
  - jorangreef 14y ago
    No, it would not eliminate the big advantage of the web as you say, merely deepen it. See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
    - 14y ago