joelgwebber

I agree. We should go back to the W3C's existing visual design, which I've always found to be beautiful.

Languages like CoffeeScript do fall into the "alternative syntax" category. And things like emscripten (and some others I've seen) probably fall into the latter. If you try to abstract out a traditional VM on top of Javascript, you're likely to get poor results.

As another commenter suggests, though, we have a language like Haxe, which is much more than just an alternative syntax. And GWT does a very good job with Java -- with the exception of some corner cases, it's usually as fast as hand-written Javascript, and often faster because of a great deal of static optimization. The Google Closure compiler arguably defines a different language (if you turn on "advanced optimizations", it only accepts an effectively-statically-typed Javascript variant).

Don't hold your breath. Everyone seems to be predicting huge gains in Javascript performance based on two data points (it used to be really, really slow, and now it's only 5-10x slower than native). But an incredible amount of effort has been poured into Javascript optimization, and it's crawled way up the asymptote, so to speak.

The reason Javascript performance is likely to max out well below that of native code (and even below less "dynamic" dynamic languages like Lua) is that it's freakishly dynamic. JITing dynamic VMs resolving dispatches (this.that) efficiently by making assumptions based on the state when a function (or trace) was compiled. When those assumptions change, they have to fall back and either interpret or recompile. In Javascript, there are a lot of things that can change to break these assumptions (e.g., anything, anywhere, in the prototype chain). Much more so than in more straightforward dynamic languages.

It's also not really true to suggest that optimizing dynamic languages is somehow "uncharted territory" and that we should expect huge gains as people explore the space of solutions. Most of the techniques used in VMs like V8 trace their history all the way back to Smalltalk (and Self, sometimes via HotSpot).

I'd like to point out a couple of things about these choices for examples of rich UI libraries: All three of them throw most of the DOM, and reimplement almost everything from scratch: structure, layout, and most behavior (outside of that provided by input elements that can't realistically be implemented by hand). I don't think you can ask for a stronger indictment of the DOM and related APIs with respect to implementing applications.

And that's the problem. It's not [p]NaCl vs. Javascript. It's whether the core APIs are designed for the task, which in the case of web applications they clearly aren't. The most egregious failings of web applications stem directly from bad APIs, and if you look at their counterparts (for example) in iOS and Android, there's absolutely no comparison. A better script engine (and yes, almost anything would be better than Javascript) would be nice, but would do very little to solve the API problem (don't forget that NaCl can't call anything not provided by the browser, so it can't serve as an "escape hatch").

There are those who suggest that the browser APIs are close to "good enough" and just need to be tweaked a bit to make it possible to create good, efficient web apps on par with modern native apps. I'd like that to be the case (my day job is working on browser application tooling and infrastructure), but so far it's not happening where it matters most -- on mobile devices. On the desktop you can usually get away with murder because the machines are so fast (and have so much memory), but on more limited mobile platforms (and by limited I mean ~1GHz ARM with ~0.5G of memory) web apps aren't even close to their native counterparts. There are some laudable attempts out there (e.g. Gmail mobile, the Sencha Touch demos), but if you poke on them a bit you start to notice obvious performance and memory issues (e.g., when Safari Mobile crashes on the iPad it's usually out of memory).

Does this mean native apps in app stores will "win", and the web will "lose"? The web "won" on the desktop (for most kinds of apps, anyway), in spite of its severe limitations, because it provided a reasonably stable platform and super-simple deployment. App stores solve the deployment part of this problem reasonably well, but fail badly at the cross-platform part. Can the web be made "good enough" in time to win again? I don't think anyone can accurately predict the outcome at this point.

I'd say it's a lot cooler than having to change the HTTP protocol and push new web browsers to everyone.

And how, pray tell, would you expect a crawler to fetch the content at twitter.com/#!/ev, considering that the server doesn't even see the hash part of the URL? That's the whole point.

The simple fact is that plenty of sites (like Twitter, Facebook, and lots of Google properties) are using client-side code to build fast interactive sites, and it necessitates this kind of infrastructure.

One important thing to consider before going down that route -- the font metrics in the Canvas API are extremely impoverished, so it will be very difficult to do much more than a simple text editor. In particular, there's no support for constraints, wrapping, etc. You can only ask for the width of a given string. This is particularly nasty if you want to do, e.g., asian languages that are hard to segment. The browser desperately needs real font metrics, segmentation, etc.

The Java Datastore API is much more straightforward as well. I strongly prefer to just use it directly over JDO/JPA, which suffers from a bit of an impedance mismatch.

It's April 2, and still true :)

Minor clarification: The code doesn't literally contain the shareware levels (we don't have the right to do that either) -- there is a script that will download and convert them for you.

And I've confirmed that it works on the full game pak as well (though conversions won't work, as q2 game dlls are native code). Time to dig up that old copy of Q2!

It's also worth pointing out that a compiled GWT application can be deployed entirely statically. The Java RPC system does require a servlet container, but there are lots of other ways of talking to servers (JSON[P], XHR, etc).

I don't believe so, though the web implementation of Latitude (http://maps.google.com/maps/m?mode=latitude) for iPhone and Palm Pre does.