4 ms·

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 t

by mcosta 13y ago

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?

pekk 13y ago
Is HTML5 Canvas also another kind of Flash? Is your objection that NaCl is not a DOM manipulation API?
Groxx 13y ago
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.
- bad_user 13y ago
  > Chrome is positioning itself very, very strongly as a platform, not just a browser That makes no sense, because the browser is by definition a platform.
  - karl42 13y ago
    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.
    - bad_user 13y ago
      When? In 1995?
- RyanZAG 13y ago
  "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.
Derander 13y ago
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.
cromwellian 13y ago
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.
- ahomescu1 13y ago
  Neither Flash nor Java applets had access to the DOM, I think that was the point of the comment.
  - moutarde 13y ago
    Flash and Java applets do have access to the DOM.
    - ahomescu1 13y ago
      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).
    - cromwellian 13y ago
      Yes they do, but ExternalInterface and Common DOM suck. Pepper has a more direct-binding feel.
Sanddancer 13y ago
It is js accessible through the rpc api: http://www.chromium.org/nativeclient/how-tos/simple-rpc 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.
exDM69 13y ago
> 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.
eliben 13y ago
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.

by mcosta 13y ago

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?

pekk 13y ago

Is HTML5 Canvas also another kind of Flash? Is your objection that NaCl is not a DOM manipulation API?

Groxx 13y ago

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.

bad_user 13y ago
> Chrome is positioning itself very, very strongly as a platform, not just a browser That makes no sense, because the browser is by definition a platform.
- karl42 13y ago
  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.
  - bad_user 13y ago
    When? In 1995?
RyanZAG 13y ago
"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.

Derander 13y ago

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.

cromwellian 13y ago

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.

ahomescu1 13y ago
Neither Flash nor Java applets had access to the DOM, I think that was the point of the comment.
- moutarde 13y ago
  Flash and Java applets do have access to the DOM.
  - ahomescu1 13y ago
    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).
  - cromwellian 13y ago
    Yes they do, but ExternalInterface and Common DOM suck. Pepper has a more direct-binding feel.

Sanddancer 13y ago

It is js accessible through the rpc api: http://www.chromium.org/nativeclient/how-tos/simple-rpc 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.

exDM69 13y ago

> 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.

eliben 13y ago

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.