Is me alone who sees NaCl as another kind of flash? It is just a blob running into a rectangle. No js accesible, almost no browser control over it. How web is this?
Gmail is basically just a blob of js. A lot of modern web apps are. If your definition of the Web is "View Source" capable JS, that battle was lost a long time ago.
NaCL does permit web apps, the Pepper API allows calling browser APIs just like JS, unlike Flash.
The way I look at the browser is, it's a layout engine that manages a Render Tree built by DOM and CSS. It has external bindings for APIs to manipulate DOM, CSS, plus canvas, audio, storage, et al. These APIs may be called from JS, Dart, NaCl. It's the APIs that define the platform, not the programming language.
Too many people are fixated on JS. Really, all that truly matters is having a portable, secure mechanism for distributing code that can call into these bindings. Right now, JS is the only game in town, but there's no reason that has to be the dominant mechanism for the next decades.
If the Web is to be around for another 20-30 years, it needs to avoid stagnation via language zealotry.
Interesting, didn't know that. I think some of the bad perception of Java/Flash pages is because most of them didn't access the DOM, they just dumped their own graphics on the page (AFAIK, you could even use AWT/Swing in applets).
tbh, I see it as (possibly) a better java applet. with better OpenGL support, so "real" games are actually feasible, and not even that hard.
Chrome is positioning itself very, very strongly as a platform, not just a browser, and this is a necessary part of that. I'm not a fan of this ever-widening set of things browsers have to do (separate from each other / external libs / etc) since it just raises the bar for any competitors, but I must admit it is nicer for the user than all the past attempts.
I don't know your definition of a browser, but in my opinion, a browser used to be mainly a document viewer. This is changing now, but the original statement does make sense in this context.
NaCl is actually designed to interoperate with JS in a fairly rich way and this interoperability is designed to be provided entirely by the browser. The idea is that you pick the runtime that you want -- probably the one provided by your browser -- and it pokes (hopefully secured) holes in the safe box that native client guarantees. This includes a sort of networking API that JS can call in to.
Yes, there is some overhead involved in shipping bytes back and forth to another process, but there has been a good amount of work put into the process to making it so (p)nacl isn't in its own box in the corner, and you can have calls thrown back and forth as needed.
Things like this mean that you don't have to reinvent wheels just because you want to push processing to the client side. There's a considerable amount of c/c++/everything else code out there, and it is rather pointless to have to maintain two codebases just so you can have something web-enabled.
Is me alone who sees NaCl as another kind of flash?
It may be yet another rectangle in a browser but there are unquestionable advantages in native code versus JavaScript or Flash (but comes with its own problems too). As such, NaCl is a worthwhile effort even if it never catches on big time and remains a Google research project.
There are important differences from flash. For example, built-in strong security from the ground up. Another example - open source. Another is performance - NaCl is near native speed, Flash (to the best of my knowledge) is not.
NaCl can actually interoperate with the DOM and JS quite well - there are examples in the SDK. It is not aimed solely at "disconnected rectangle"-like applications.
Comments
Is me alone who sees NaCl as another kind of flash? It is just a blob running into a rectangle. No js accesible, almost no browser control over it. How web is this?
Gmail is basically just a blob of js. A lot of modern web apps are. If your definition of the Web is "View Source" capable JS, that battle was lost a long time ago.
NaCL does permit web apps, the Pepper API allows calling browser APIs just like JS, unlike Flash.
The way I look at the browser is, it's a layout engine that manages a Render Tree built by DOM and CSS. It has external bindings for APIs to manipulate DOM, CSS, plus canvas, audio, storage, et al. These APIs may be called from JS, Dart, NaCl. It's the APIs that define the platform, not the programming language.
Too many people are fixated on JS. Really, all that truly matters is having a portable, secure mechanism for distributing code that can call into these bindings. Right now, JS is the only game in town, but there's no reason that has to be the dominant mechanism for the next decades.
If the Web is to be around for another 20-30 years, it needs to avoid stagnation via language zealotry.
Neither Flash nor Java applets had access to the DOM, I think that was the point of the comment.
Flash and Java applets do have access to the DOM.
Interesting, didn't know that. I think some of the bad perception of Java/Flash pages is because most of them didn't access the DOM, they just dumped their own graphics on the page (AFAIK, you could even use AWT/Swing in applets).
Yes they do, but ExternalInterface and Common DOM suck. Pepper has a more direct-binding feel.
tbh, I see it as (possibly) a better java applet. with better OpenGL support, so "real" games are actually feasible, and not even that hard.
Chrome is positioning itself very, very strongly as a platform, not just a browser, and this is a necessary part of that. I'm not a fan of this ever-widening set of things browsers have to do (separate from each other / external libs / etc) since it just raises the bar for any competitors, but I must admit it is nicer for the user than all the past attempts.
"Chrome is positioning itself very, very strongly as a platform"
This is terrible and I wish they'd stop doing this and stick to working with Mozilla more.
That makes no sense, because the browser is by definition a platform.
I don't know your definition of a browser, but in my opinion, a browser used to be mainly a document viewer. This is changing now, but the original statement does make sense in this context.
When? In 1995?
NaCl is actually designed to interoperate with JS in a fairly rich way and this interoperability is designed to be provided entirely by the browser. The idea is that you pick the runtime that you want -- probably the one provided by your browser -- and it pokes (hopefully secured) holes in the safe box that native client guarantees. This includes a sort of networking API that JS can call in to.
It is js accessible through the rpc api:
http://www.chromium.org/nativeclient/how-tos/simple-rpc
Yes, there is some overhead involved in shipping bytes back and forth to another process, but there has been a good amount of work put into the process to making it so (p)nacl isn't in its own box in the corner, and you can have calls thrown back and forth as needed.
Things like this mean that you don't have to reinvent wheels just because you want to push processing to the client side. There's a considerable amount of c/c++/everything else code out there, and it is rather pointless to have to maintain two codebases just so you can have something web-enabled.
Is HTML5 Canvas also another kind of Flash? Is your objection that NaCl is not a DOM manipulation API?
It may be yet another rectangle in a browser but there are unquestionable advantages in native code versus JavaScript or Flash (but comes with its own problems too). As such, NaCl is a worthwhile effort even if it never catches on big time and remains a Google research project.
There are important differences from flash. For example, built-in strong security from the ground up. Another example - open source. Another is performance - NaCl is near native speed, Flash (to the best of my knowledge) is not.
NaCl can actually interoperate with the DOM and JS quite well - there are examples in the SDK. It is not aimed solely at "disconnected rectangle"-like applications.