7 ms·

Be interesting to see if this becomes a target for other languages, e.g. allowing browser applications to be written in Python.

eliben 13y ago
http://gonativeclient.appspot.com/demo http://gonativeclient.appspot.com/demo has a Lua interpreter demo. There's also Python, but you'll have to build it yourself (naclports).
pedrocr 13y ago
I really really hope that this+pepper.js will allow you to deploy Ruby/Python/Go as client-side languages for the Web. Does anyone know how (P)NaCl interfaces with the DOM?
- duhroach 13y ago
  You don't have direct access to the DOM inside of NaCl, but you can pass messages back to JS via PostMessage.
cliffbean 13y ago
We've had other languages running in browsers for quite a while now. eg.: http://mozakai.blogspot.com/2013/05/lua-in-javascript-running-vm-in-vm.html http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...
leoc 13y ago
What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their de facto control over Web standards.
- mindcrime 13y ago
  instead of kludging your document-format specification up into an application runtime So glad to see somebody else saying this. I think you are absolutely correct. The current state of web applications / web browsers is an absolute kludge. Whatever happened to "separation of concerns" or the idea of building tools that do one thing and do it well? But what "one thing" does a web browser do these days? One might think "browsing hypermedia content" but what does that have to do with becoming the universal application runtime?!?!?? Actually, the more I think about it, the more I think "clusterfuck" would be an even more apt term than "kludge" for what we have now. But I largely blame Sun: IF they had bothered to ship something like the Consumer JRE about 7 or 8 years sooner, and IF they hadn't screwed the pooch so badly on security, we could have something like Java / JNLP for hosting "applications" while the actual browser could stick to, well, browsing. I'm actually waiting for something to come along and become "the next Java / Flash" but done right. :-( I'm curious to see to what extent PNaCL can fulfill some of that.
- _prometheus 13y ago
  > What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. Yes! We'd need a bunch of tooling re-built for each platform, but we could do it with static compilation :) > instead of kludging your document-format specification up into an application runtime. Seriously. It's a mess.
- pjmlp 13y ago
  You mean WPF?
  - leoc 13y ago
    I assume that the content-to-presentation stack would include something XAML-ish (or indeed XUL-ish) near the presentation end, sure.
- wmf 13y ago
  This is a similar idea to the MSR Embassies project: http://research.microsoft.com/en-us/projects/embassies/ http://research.microsoft.com/en-us/projects/embassies/

eliben 13y ago

http://gonativeclient.appspot.com/demo http://gonativeclient.appspot.com/demo has a Lua interpreter demo. There's also Python, but you'll have to build it yourself (naclports).

pedrocr 13y ago

I really really hope that this+pepper.js will allow you to deploy Ruby/Python/Go as client-side languages for the Web. Does anyone know how (P)NaCl interfaces with the DOM?

duhroach 13y ago
You don't have direct access to the DOM inside of NaCl, but you can pass messages back to JS via PostMessage.

cliffbean 13y ago

We've had other languages running in browsers for quite a while now. eg.: http://mozakai.blogspot.com/2013/05/lua-in-javascript-running-vm-in-vm.html http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...

leoc 13y ago

What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their de facto control over Web standards.

mindcrime 13y ago
instead of kludging your document-format specification up into an application runtime So glad to see somebody else saying this. I think you are absolutely correct. The current state of web applications / web browsers is an absolute kludge. Whatever happened to "separation of concerns" or the idea of building tools that do one thing and do it well? But what "one thing" does a web browser do these days? One might think "browsing hypermedia content" but what does that have to do with becoming the universal application runtime?!?!?? Actually, the more I think about it, the more I think "clusterfuck" would be an even more apt term than "kludge" for what we have now. But I largely blame Sun: IF they had bothered to ship something like the Consumer JRE about 7 or 8 years sooner, and IF they hadn't screwed the pooch so badly on security, we could have something like Java / JNLP for hosting "applications" while the actual browser could stick to, well, browsing. I'm actually waiting for something to come along and become "the next Java / Flash" but done right. :-( I'm curious to see to what extent PNaCL can fulfill some of that.
_prometheus 13y ago
> What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. Yes! We'd need a bunch of tooling re-built for each platform, but we could do it with static compilation :) > instead of kludging your document-format specification up into an application runtime. Seriously. It's a mess.
pjmlp 13y ago
You mean WPF?
- leoc 13y ago
  I assume that the content-to-presentation stack would include something XAML-ish (or indeed XUL-ish) near the presentation end, sure.
wmf 13y ago
This is a similar idea to the MSR Embassies project: http://research.microsoft.com/en-us/projects/embassies/ http://research.microsoft.com/en-us/projects/embassies/