"So why not pick the overextended mess we started with."
What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)
What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)
Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE.
Additionally, PNaCL can be retargeted at as-of-yet unknown architectures.
The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately.
This seems reasonable to me; default to portability, provide an option for best-case performance.
It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.
Won't developers have access to PNaCL runtimes? How is this so different than Apple developers having access to the other target hardware
It comes down to toolchains and the workflow they're optimized for. With PNaCL, the portable version is the primary target of the toolchain, from which one generates other native binaries. You can still generate native binaries separately, but ideally, PNaCL would lead.
If the tools lead naturally in the right direction, then developers do follow. If you're feeling really worried about it, define a distribution format that mandates a PNaCL entry.
At various points he talks about how a fresh byte code would address some of the issues raised, and certainly from a full time compiler engineer's perspective, some pristine representation and a handful of tree-walks are obviously going to appeal to his academic side. I just doubt any such perfectly forward-compatible ideal representation will ever exist that can cater to all camps and survive the test of time, because to my knowledge such a thing has never existed.
So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
Resistance that you contribute to with almost every article that touches on NaCL, yes.
It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL.
> So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
Why is this the "inevitable" result?
Instead we have a company that throws specs over the wall like they're teenaged nerds that have just discovered Pascal's pack function, a company that pushed SPDY on everyone despite it relying on a draft SSL feature that got rejected at the IETF (and in the space of 2/3 years we now have three HTTP variants - and why? Because 3 years ago it shaved 1ms off a maps.google.com request). Did you even take a look at the original WebSocket spec? It worked in terms of comparing the entire start of the HTTP request using memcmp()!
Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Not a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them.
Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description
Wait, what? I'm not even sure what you're trying to say here. If you seriously think Mozilla has payed for articles about themselves, you've gone off the deep end.
I know that I personally became aware of asm.js because of an offhand comment Eich made on HN. I posted that link on both reddit and HN, which I guess was the start of the hype, so if you could let me know where to collect my Mozilla money I'd be obliged. :)
ELF was defined in the late 80s/early 90s as part of SVR4. COFF was defined as part of SVR3. Both still exist today.
The JVM bytecode was defined in 1995 and has been evolved compatibly.
I'm curious, though. Do you require the same longevity of web formats that were defined in the 90s? Things have changed quite a bit, and attempting to browse the modern web with a 90s browser is futile.
Given that, I don't really understand what you're arguing for.
> Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry.
Us 'bearded old men' aren't on the web, and its only improvements like SPDY, WebSockets, and NaCL that have made me the slightest bit interested in the web as an application platform.
> attempting to browse the modern web with a
> 90s browser is futile
It sounds like if NaCl compiles things down to ASM x86 (or really AMD64) (?). If that's true, then it's possible for things to not be forward compatible. I'll admit that it doesn't seem likely, especially after what happened with Itanium and AMD64/x86-64, but we could see things move towards ARM.
Given PNaCL, the answer should be 'yes'.
And it's hard to imagine stronger evidence that the people designing the "modern web" are not the few who are willing and able to do a competent job of it.
For the sake of completeness, I'll note one of the biggest detriments of original NaCl: a lack of platform independence.
Platform independence is not an obvious goal for game developers. If it were, you would see the same game show up in every platform, but that's not what we see. Heck, only recently did we really see games show up for Mac. For high performance contexts, you want to be able to express algorithms in a way that takes full advantage of the hardware, and the lack of homogeneity in hardware demands a platform-dependent solution.
The web is not a platform solely for game developers.
Run native game code inside a browser why?
What exactly do you get over, say, running it natively as a desktop/mobile app and just distributing it over the internet and/or web?
On the other hand, that also destroys a game's ability to be archived, creating a cultural "dark ages" if the approach picks up adoption. "Piracy" is essential to future historians.
I have less issues downloading and updating an app like that, than keening with the subpar experience that is web games, browser compatibility et al.
Not to mention that with the speed of todays networks, even manual installation is a non problem.
We can even put a nice facade on top of it: "just visit this page and click "Install" and you get an app running locally after some small download time. It will even be sandboxed and all-in-one, so it won't mess any part of your system".
For one, it's merely one of around 20 steps you have to take in either case anyway (steps like: type url, press enter to goto page, wait for page to load, click through some license staff, click to start to play, click for fullscreen if you want, wait for assets and loading, click game settings, suffer through the intro, read help for the game controls, etc). So, yes, you might get rid of one measly step -- all the while introducing other steps, lags and inefficiencies.
Second, this step buys you freedom from having the program run on somebody else's mercy. Of course for networked games and apps with central servers you cannot avoid it.
But I would sure as hell like to avoid it for any program that doesn't need a central server. I don't want to use "Photoshop in the browser" and loose all my stuff when Adobe decides to lock me out or kill the service a la Google Reader. Plus have it be susceptible to internet outages, slowdowns, and using technologies and speeds that's 2-3 generations behind a native app. Not all programs gain from running on the browser. A lot of them lose.
Yes the scenarios you describe are ridiculous and unacceptable. But thankfully we live in the real world where those extra steps you describe don't actually exist in apps that were programmed by actually good programmers.
As for whether it matters one iota: It matters if you want more people to play your game. You are a progammer, and so you don't perceive the actual difficulty level of software installation. On the other hand, for normal people with average skill levels, having to install software can present a significant barrier to entry.
I have not seen even ONE (ONE) online app or game, where most of the above steps do not exist. You might be able to find one. I doubt you'll find two, much less five.
So, straw-men? Puh-lease.
>It matters if you want more people to play your game. You are a progammer, and so you don't perceive the actual difficulty level of software installation.
For one, you sidestepped all my arguments. I proposed systems like the Mac App Store and Valve -- and even more automated solution, like the Java Web Start for the 21st century (click a button on a webpage, and it's installed and running locally).
And yet, you tell me that "for normal people with average skill levels, having to install software can present a significant barrier to entry", as if we were discussing manual installers and stuff.
You are responding not to what I said, but to the preconceived ideas you have about traditional installers. The stuff I discussed (MAS, etc) are not at all "a significant barrier to entry".
Heck, 5 year olds to 70 year olds can use them just fine on their Mac or their iPhone. I've seen that.