One Cloud? by liberato
This really wonderful post by Anil Dash echos a lot of what I’ve been talking about in the context of the larger web. I had a discussion with Ben Galbraith recently about this topic during a Mozilla lunch. He and I took (intentionally) different positions on topics to see what kind of discussion we could stimulate around how developers see the web platform.
Ben has some concern that the web platform isn’t as coherent as those that you find from the other big players – the iPhone platform, Silverlight, Java or any of the other giant siloed stacks. (Actually Ben was more interested in the capabilities of those platforms vs. the web, but I’ll talk about that later.) I’m basically of the opinion that the web that we have, and as messy as it seems, actually produces pretty good results. That the incrementalism and experimentation that we’ve seen from web browser vendors results in what I call “developer-friendly incompatibility.” That those changes are eventually codified to standards and taken mainstream because they degrade well and we can learn as we go. (Kind of like life!)
But it does raise an interesting question – what capabilities do we need to have for the web that are found in these stacks? And can they be applied in an incremental fashion? We’re starting to see that with video being promoted as a first class citizen with Flash as a trailing edge fallback. We’re starting to see the web pick up 3D capabilities with participation from Google, Apple and Mozilla. And we have the pretty wonderful library model that has produced jQuery, jQuery UI, mootools, YUI, dojo and many others – all of which come from pushing complexity to the edges of the web community.
But is it enough? Discuss. What’s missing, and what’s interesting? I would particularly love to hear from Java and Silverlight developers. What do you really love about those platforms? Is source-as-delivery and incrementalism enough?
Pingback: Christopher Blizzard (blizzard) 's status on Monday, 10-Aug-09 23:40:18 UTC - Identi.ca
I’m not too worried about the “coherence” or “messiness” of the platform. My main concern is for Javascript as the only language. New sandboxed APIs for graphics, audio, and video are great, and I’m no Javascript hater but I’m skeptical it can reach the performance we need. I want to do cutting-edge 3D games, video encoding and editing, real-time audio effects, etc. Javascript’s type system makes it hard to do math on large arrays of numbers efficiently. A language-agnostic VM might be better in the long term.
Or, for a different solution, perhaps we can expose OpenCL to Javascript in the same way we’re doing OpenGL, and do all the heavy numeric lifting that way.
Development tools. Where’s the “web IDE” that other platforms like flash/silverlight/.net/cocoa have? Most IDEs make the barrier-to-entry a ton lower and thus help attract new developers. Yeah, some people don’t mind having 10 different tools with 10 different interfaces to accopmlish their task, but huge swaths of developers only know an IDE, because IDEs fill a large part of the requirements.
So maybe if there was (already is?) something for Eclipse that just made JS + HTML + CSS + XMLRPC development a ton easier, we’d be close.
Why would a “language-agnostic VM” be faster than a language-specific VM? I believe the way to go is, that if there are features of javascript that make it to hard to execute efficiently, an efficient subset should be found (assuming that one exist) and documented or perhaps enforced via a strict-option and optional type annotations could be added.
The open web might have started to gain some new features, but where are the polished showcases? There seems to tech-demos out there.
You can use jQuery and Mootools and Prototype to script a PHP page that uses MySQL and MS-SQL databases to retrieve information in XHTML, SVG, RDFa, and Microformats.
And yes, that would be messy.
When it comes down to it, the web is just about choice. If developers stick with a few different technologies, it’s actually not messy at all.
I like the web technologies because it’s all interpreted. Sure, the different engines will render things a bit differently from each-other, but I love that I can change things in the middle of a program. You just can’t do that with Java or C or such.
There’s no subset of Javascript that is really efficient. The problem is that Javascript has only one numeric type which morphs from int to double on overflow (which requires constant overflow checking). There’s no way to allocate and/or efficiently process a large array of bytes, floats, int64s, or any numeric type of a specific size. This is a problem for processing buffers containing vertices, pixels, audio samples, or similar data.
Perhaps all that is needed is a way to allocate arrays of specific numeric types in Javascript.
@Modeless For numbers that don’t change types very much TraceMonkey does very well at processing them. Please see this article:
http://hacks.mozilla.org/2009/07/tracemonkey-overview/
It talks about how we can actually make processing number types very fast. (In fact, we do better than the other JS engines at this particular type of processing.)
Keep in mind that we’ll be learning as we go here. If we find a particular kind of operation that’s too slow we can always add APIs for those kinds of things. That’s how the web has changed over the last couple of years – start simple, help libraries optimize as we go.
I did read that article and TraceMonkey is exceedingly cool; however going by the diagram there the overhead is still 3x worse than C or Java in the best case, and of course there are huge performance cliffs to fall off of everywhere.
Processing isn’t the only problem; storage may actually be the bigger issue. As far as I know there’s no way to efficiently store something like a vertex buffer with interleaved floats and bytes in Javascript.
Yeah, that’s probably the case. But we’ll know more once we have more in-the-field testing. It might be enough to add a data structure to support those kinds of things. We’ll learn and iterate based on what we hear, for sure.
Yeah, I’m really looking forward to WebGL; it should make the performance bottlenecks obvious and will hopefully suggest some simple solutions :-)
> There’s no subset of Javascript that is really efficient.
You sound confident. Your statement is of course easy to disprove. But that was why I also mentioned type annotations.