5 ms·

You can't make a JavaScript engine run anywhere near fast enough in PNaCl, so you need at least all of V8 in your "kernel". You could run WebKit on top of PNaC

by comex 13y ago

You can't make a JavaScript engine run anywhere near fast enough in PNaCl, so you need at least all of V8 in your "kernel". You could run WebKit on top of PNaCl with some magic V8 bindings, but I don't think this has been done before, and considering how big WebKit and NaCl are, it would probably be a lot of work. Useful work to do, but a lot of work... (And of course, Chromium already supports a process sandbox, so while this could theoretically be a really cool win for architecture, having less platform specific code to maintain, it wouldn't necessarily be much of a security win - the analogy of the kernel only applies so far.)

roarroar 13y ago
I'm aware of all this. I'm not saying it would be easy - and the belief that high speed Javascript is necessary is one reason we've been held back for so long. Nobody should be writing a browser in Javascript (when I mentioned this possibility I was simply humoring the poster's ideas). An "Exobrowser" (or perhaps "Microbrowser") is what we should have by now, but the linked project is not it. NaCl and asm.js are only necessary because operating systems have failed to successfully implement process separation (more crap, monolithic design at work), so now it's being reinvented in user land with the resulting performance overheads. Javascript doesn't need to be fast! The whole idea of high performance programming done in Javascript is stupid, especially if it means saying "no" to a better architecture designed around security and speed for better systems languages. Even Mozilla's penny has dropped on low-level code execution - hence asm.js. If operating systems had been done right in the first place then you could have the following arrangement: - Each browser tab is a separate OS process w/o any access to system calls except for calling browser services - Browser provides services (e.g. graphics primitives, input) - Processes from the same domain can talk to each other - Browser comes preloaded with some preferred, but optional portability layers for the processes - Everything else is libraries, with one domain being able to provide services to another. So mozilla.org could provide its rendering engine either as a library or as a background process (to reduce memory overheads). And so on. This way there's no more waiting 10 years for Mozilla to implement whatever it thinks you need, with their 640k ought to be enough attitude. Their rendering engine has to compete with others. The most popular engines are most likely to already be in cache when someone visits your site, so there is room for lots of vigorous competition. This is all so painfully BASIC, but it will likely be decades before people get it right, if they ever get it right. Chrome is going in the right direction, the poster's linked project is not.
- comex 13y ago
  On NaCl I partially agree and partially disagree. While it's true that the sandboxing is only necessary due to insufficiently flexible kernels, imo the most interesting part of NaCl and asm.js is their use of a portable bytecode that compiles into native code. Portability really is necessary - CPU architectures don't change that often, but if people started distributing websites as native code a decade ago, none of them would have envisioned that a large portion of web browsing is now done on ARM based devices. Yet you cannot make a fast portable JIT. You say that JavaScript doesn't need to be fast, but it's really nice to have a high-level, dynamic language that still runs fast - in fact, it was compelling enough to be one factor in the success of JavaScript on the server, despite the language's weaknesses. However, there's no reason JavaScript (or some suitably compatible dynamic-language bytecode) JIT couldn't be provided as a fundamental API in addition to the static compiler. Yeah, it doesn't feel like a clean architecture when you want to use Python or Lisp and it almost translates neatly to that bytecode but with little runtime differences that end up adding a lot of overhead... but it's better than nothing. I think that your hypothetical arrangement would be very cool. I'm not sure that it would actually be better than what we have - for example, writing a screen reader would likely be a nightmare if some random webpage might be using a browser library that didn't support it; good luck implementing anything like user scripts/custom CSS, scrapers, Readability, magic text reflow for iPhones, smooth zooming, etc. Good luck doing something like the transition to hardware accelerated rendering browsers did a few years ago (sure, you could only support it for new sites, but as is I get smooth scrolling for all sites). And since different engines would now be very fundamentally different rather than the usually relatively thin layers over HTML that are currently popular, developers would have to spend more time learning different APIs. If some engine stopped being maintained, then it would be very difficult to retrofit websites that use it to support the newest features. Et cetera. Meanwhile, these days browsers move pretty damn fast, lessening the advantage of non-standardized development - and many new APIs are hooks to the OS anyway, not things that UI layers could implement on their own. But it would be cool. I don't mean to be too negative: there would be a lot of advantages, and it would be interesting to try out. I suppose it might happen. PNaCl and asm.js are soon going to be supported in two of the most popular browsers; alternatively, if JS engines get good enough that specific support for asm.js isn't required to achieve performance for low-level code (https://bugzilla.mozilla.org/show_bug.cgi?id=860923 https://bugzilla.mozilla.org/show_bug.cgi?id=860923), with the competitiveness all major browsers already have on JS speed, the latter will be "supported" everywhere on short notice. It might not be that long until the first serious attempt to make an alternative UI stack for browsers...
dubcanada 13y ago
Chances are if you want your browser to run fast you won't have one built in javascript :) Javascript is nowhere near the performance of C++, asm.js is getting there, but this obviously isn't built in that.

by comex 13y ago

roarroar 13y ago

I'm aware of all this. I'm not saying it would be easy - and the belief that high speed Javascript is necessary is one reason we've been held back for so long. Nobody should be writing a browser in Javascript (when I mentioned this possibility I was simply humoring the poster's ideas). An "Exobrowser" (or perhaps "Microbrowser") is what we should have by now, but the linked project is not it. NaCl and asm.js are only necessary because operating systems have failed to successfully implement process separation (more crap, monolithic design at work), so now it's being reinvented in user land with the resulting performance overheads. Javascript doesn't need to be fast! The whole idea of high performance programming done in Javascript is stupid, especially if it means saying "no" to a better architecture designed around security and speed for better systems languages. Even Mozilla's penny has dropped on low-level code execution - hence asm.js. If operating systems had been done right in the first place then you could have the following arrangement: - Each browser tab is a separate OS process w/o any access to system calls except for calling browser services - Browser provides services (e.g. graphics primitives, input) - Processes from the same domain can talk to each other - Browser comes preloaded with some preferred, but optional portability layers for the processes - Everything else is libraries, with one domain being able to provide services to another. So mozilla.org could provide its rendering engine either as a library or as a background process (to reduce memory overheads). And so on. This way there's no more waiting 10 years for Mozilla to implement whatever it thinks you need, with their 640k ought to be enough attitude. Their rendering engine has to compete with others. The most popular engines are most likely to already be in cache when someone visits your site, so there is room for lots of vigorous competition. This is all so painfully BASIC, but it will likely be decades before people get it right, if they ever get it right. Chrome is going in the right direction, the poster's linked project is not.

comex 13y ago
On NaCl I partially agree and partially disagree. While it's true that the sandboxing is only necessary due to insufficiently flexible kernels, imo the most interesting part of NaCl and asm.js is their use of a portable bytecode that compiles into native code. Portability really is necessary - CPU architectures don't change that often, but if people started distributing websites as native code a decade ago, none of them would have envisioned that a large portion of web browsing is now done on ARM based devices. Yet you cannot make a fast portable JIT. You say that JavaScript doesn't need to be fast, but it's really nice to have a high-level, dynamic language that still runs fast - in fact, it was compelling enough to be one factor in the success of JavaScript on the server, despite the language's weaknesses. However, there's no reason JavaScript (or some suitably compatible dynamic-language bytecode) JIT couldn't be provided as a fundamental API in addition to the static compiler. Yeah, it doesn't feel like a clean architecture when you want to use Python or Lisp and it almost translates neatly to that bytecode but with little runtime differences that end up adding a lot of overhead... but it's better than nothing. I think that your hypothetical arrangement would be very cool. I'm not sure that it would actually be better than what we have - for example, writing a screen reader would likely be a nightmare if some random webpage might be using a browser library that didn't support it; good luck implementing anything like user scripts/custom CSS, scrapers, Readability, magic text reflow for iPhones, smooth zooming, etc. Good luck doing something like the transition to hardware accelerated rendering browsers did a few years ago (sure, you could only support it for new sites, but as is I get smooth scrolling for all sites). And since different engines would now be very fundamentally different rather than the usually relatively thin layers over HTML that are currently popular, developers would have to spend more time learning different APIs. If some engine stopped being maintained, then it would be very difficult to retrofit websites that use it to support the newest features. Et cetera. Meanwhile, these days browsers move pretty damn fast, lessening the advantage of non-standardized development - and many new APIs are hooks to the OS anyway, not things that UI layers could implement on their own. But it would be cool. I don't mean to be too negative: there would be a lot of advantages, and it would be interesting to try out. I suppose it might happen. PNaCl and asm.js are soon going to be supported in two of the most popular browsers; alternatively, if JS engines get good enough that specific support for asm.js isn't required to achieve performance for low-level code (https://bugzilla.mozilla.org/show_bug.cgi?id=860923 https://bugzilla.mozilla.org/show_bug.cgi?id=860923), with the competitiveness all major browsers already have on JS speed, the latter will be "supported" everywhere on short notice. It might not be that long until the first serious attempt to make an alternative UI stack for browsers...

dubcanada 13y ago

Chances are if you want your browser to run fast you won't have one built in javascript :) Javascript is nowhere near the performance of C++, asm.js is getting there, but this obviously isn't built in that.