The browser wars are once again upon us

Posted 3 May 2007 at 20:39 UTC (updated 3 May 2007 at 20:42 UTC) by advogato Share This

After a lull, the competition between the major players in the browser / web client space is heating up again. Now that Microsoft has ramped up their PR campaign on Silverlight (formerly WPF/E), and Adobe is doing the same with their Apollo, a lot of people are talking about what it all means, both in terms of the technical merits of the platforms and the effect of proprietary lock-in on freedom. One particularly skeptical take on the latter is Mark Pilgrim's Silly season post, which has been making the rounds of the tech blogs.

The way I see it, the Rich Internet Application (RIA) space is really heating up this year. The three major players are Apollo, Silverlight and web standards (represented most effectively by Mozilla).

Apollo looks appealing at first sight - a runtime which combines the advantages of Flash, PDF, and the Web. However, when you look at the thing more closely, you get the impression that it's actually a frankenstein of three different runtimes glued together not all that seamlessly.

One runtime is PDF. But, at least in the first cut, the scripting layer (JavaScript) doesn't really have access to the full graphics model (the content streams). In fact, though Adobe has been playing with XML representation of PDF files, JavaScript does not have DOM access to that XML. It does, of course, have access to forms, and there is a crude graphics model at that layer (polygons, etc.), but not the real deal.

Another runtime is Flash. And of course that's always had strong interactivity and a pretty good programmable graphics model. Fact is, Flash has long had technically what it takes for a long time to be a RIA platform. My best guess about what's been holding it back has been the rather closed development environment (but see below regarding OpenLaszlo).

The third runtime is khtml (the same codebase as is behind safari). But this is the part that seems wierdest to me. I don't think users want a random html engine. I think they want their RIA's to interoperate smoothly with their web browser. In the Developer FAQ, they say something along the lines of, "you could build a web browser on top of Apollo," but that hardly makes any sense to me. Where's the smooth user experience if you do that?

Technically, web standards are way behind. SVG, in particular, has not caught on, and probably won't be implemented (well) anytime soon in IE and Safari. A lot of "Web 2.0" apps actually rely on egregious hacks in order to get things done. But, keep in mind, a lot of apps don't really need sophisticated graphics. For those, web standards are a pretty clear win. You get seamless browser integration, a rich tapestry of available tools, and manage to avoid lock-in to a proprietary runtime.

I think Silverlight is by far the best from a technical point of view. The big advantage over Apollo is that it ought to integrate smoothly with the browser, especially if the browser is IE. But they have plugins for Firefox and Safari too, and, over time, it wouldn't be surprising to see that go even wider. The Mono project provides a lot of the pieces of what's needed for a good open source implementation, and if WPF/E really catches on, I think we could expect to see that happen.

The other big advantage Silverlight has over its competition is the CLR, which lets people write their apps in powerful languages including C# and Python. One of the things I expect to see is much more fluidity in the line between client and server, and using languages that are well implemented on both sides makes sense.

But I'm not actually sure how compelling that advantage is going to be. JavaScript is something of a universal in the RIA space, and I've been very pleasantly surprised by what I see coming down the pike for JS 2.0. I've always thought of JS as something of a toy language, but it looks like it's really growing up. For one, they're stealing some of Python's best ideas, including its module (import) system, generators, and properties. For two, while JS 1.0 really only admits slow interpretive implementations, 2.0 adds on a carefully designed type system that ought to allow implementations at least as good as Java.

So I think you're going to see real applications written pretty soon in JS, and I also predict that the market for good libraries is going to explode as 2.0 comes online. Not only that, but you can use that layer to insulate apps somewhat from details of the runtime. For example, you could have a "rich graphics" library that dispatched to SVG or WHATWG canvas on standards-compliant browsers, VML or Silverlight on IE, or Flash if running on the Apollo runtime. That's about as powerful a force as any, I think, for avoiding lock-in and forcing the runtimes to compete on the quality of their implementations and smoothness of integration, rather than availability of exclusive apps only available for one runtime.

We're already starting to see development tools based on that model: develop using standards and free software, then compile into proprietary platforms that happen to be well supported in the consumer space. A shining example is OpenLaszlo, which basically compiles apps written in JavaScript and XML into Flash, or, more recently, into DHTML based on Web standards.

As with Microsoft's Blackbird attempt over a decade ago, it seems likely that their short-term technical head-start won't be compelling enough to make people forego open development tools. But, this time around, it certainly won't be for lack of publicity and hype on the part of the vendors.

In any case, one thing seems clear, if surprising: the language of the future is JavaScript.


Downloading and executing code, posted 3 May 2007 at 22:07 UTC by Omnifarious » (Journeyer)

I want some system calls in Unix so that an application can voluntarily drop certain privileges. JavaScript has a sandbox, so that's one piece of the security puzzle, but the OS should be able to police the browser app itself in case the worst happens.

I don't trust Flash in the least little bit to be at all secure. It is a very closed system. It's not even well enough understood that a good Open Source clone of the client can be hacked together quickly. I wouldn't be surprised to discover all manner of attacks through subverting the Flash runtime or just using something it's supposed to do on purpose that nobody thought through.

I only slightly trust JavaScript to be vaguely secure, and that's only because the JavaScript interpreter I use has a very open development model.

I would not trust CLR to be secure at all either. Especially since from what I understand about CLR, they may have given up some of the restrictions that Java had that allowed it to ensure that there were a certain set of rules no Java program could break.

And the OS security model the browser currently runs under is utter garbage. It should not have access privileges to everything I do. It should be allowed to read and update its cache, its preferences and its cookies, and that's about it (though quite a lot of nefariousness can be done with just that). Anything else should have to go through some kind of gatekeeper app that asks me if that's what I want to do.

Yes, It Is, posted 4 May 2007 at 18:20 UTC by nymia » (Master)

The take-up seems to be gaining momentum as we were swept high by these shiny gadgets. Silverlight may be late in the game. although I won't be betting against Silverlight since (my guess) it is going to be free as in beer, much like IIS and IE.

Definitely, a spear and arrow intended for Adobe who is marching deep into their territory.

Also, Icaza announced a Linux port of Silverlight several days ago. That should add more chaos into the frenzy.

Yes, the market is warming-up.

Scope of Icaza's latest project, posted 5 May 2007 at 03:11 UTC by chalst » (Master)

nymia wrote: Also, Icaza announced a Linux port of Silverlight several days ago. That should add more chaos into the frenzy.

What's the scope of Silverlight-on-Mono? If it includes Silverlight streaming, then can we expect Novell to get some blowback on this one: a free implementation of Silverlight streaming would pretty much wreck the DRM "content protection" claims that Microsoft is trying make for the platform?

*smirk*, posted 5 May 2007 at 07:09 UTC by robocoder » (Journeyer)

[..] the language of the future is JavaScript.

That said, any thoughts on Curl (the RIA platform)? My feeling is that any technical superiority it might have, the company lacks the marketing muscle to go head-to-head with either MS or Adobe, and they may have set too high a premium for their wares (i.e., commercial deployments start at $12K).

Curl & Miranda, posted 5 May 2007 at 12:07 UTC by chalst » (Master)

robocoder wrote: they may have set too high a premium for their wares

Even the giants of industrial infrastructure don't charge for programming language environments, so the market doesn't support positive premiums. You can "sell" deployments for money if you provide large amounts of high-quality, "free" consulting. For people who followed the story of the much more innovative functional programming language Miranda, that provides a pretty clear analogy.

Re: Scope of Icaza's latest project, posted 5 May 2007 at 21:19 UTC by nymia » (Master)

What's the scope of Silverlight-on-Mono? If it includes Silverlight streaming, then can we expect Novell to get some blowback on this one: a free implementation of Silverlight streaming would pretty much wreck the DRM "content protection" claims that Microsoft is trying make for the platform?

Good question, I'd love to see something like that running on Mono and Xlib.

I'm not sure what legal requirements are needed to make that possible, though. I'm guessing Icaza and company will have to jump hoops and sign legal binding agreements just to get a roadmap on the SDK development path going for Mono.

Aside from the legalities, I would like to see Icaza come out alive and kicking. It's a tough job trying to push code into the public domain. Hope he succeeds.

On the subject of curl..., posted 7 May 2007 at 13:25 UTC by chalst » (Master)

...it looks as if one of experts, Paul Withington, has joined us. I've emailed him to see if ptwithy is legit.

Write once, run everywhere?, posted 8 May 2007 at 16:33 UTC by ptwithy » (Journeyer)

I would not call myself an 'expert', but a journeyman. Disclaimer: I am currently working full time on OpenLaszlo, funded by Laszlo Systems. A couple of observations:

Curl, like Apollo and Silverlight depends on a proprietary player or plug-in. Flash being the oldest has wide distribution. WPF/E will surely catch on fast, given the promoter. Curl has a much tougher row. (Last I knew, its JIT still only generated x86 code and only ran on Windows or Linux).

The beauty of a proprietary plug-in is that cross-platform compatibility is guaranteed. The drawback is that it is single-sourced (and proprietary). [Note: Both Adobe and Microsoft have annouced their intentions to open source large portions of their development environments, and Adobe has donated their Javascript engine to Mozilla, but neither of these announcements make the complete player open source.]

Contrast this with standards: AJAX (Javascript+DOM+CSS+XHR) -- these have many implementations with no guarantee of cross-plaform compatibility. When those implemenations are open, compatibility improves.

We like to think of OpenLaszlo's LZX language as a higher level language that lets you express your application in a more concise way. As mentioned in the main post, it can compile to the Flash player or to AJAX. We have demonstrated compiling to SVG (and are working with the SVG committee), and Sun has demonstrated compiling to Java. It is very probable that compiling to WPF/E will happen soon... given that OpenLaszlo is open source, for all we know Microsoft may already have that working. (:P)

And yes, the language of the future is Javascript. It is rapidly becoming the equivalent of Lisp.

Equivalent of Lisp?, posted 8 May 2007 at 19:17 UTC by ncm » (Master)

It seems curiously appropriate that Javascript programs are the only ones I run these days that consume all available RAM and swap space, and that crash. They are also the only programs I run that depend on a garbage collector. I doubt this is a coincidence.

Nothing I encounter on the web that I have any reason to want to use depends on having Java installed. That's good. Javascript has become unavoidable, though, and Flash will be soon. Each increment degrades my web experience a bit, with rare exceptions (Google Maps; any others?).

The only hope I see is to run each Javascript/Flash/what-have-you script in a separate subprocess, killed when you leave the page. The OS doesn't fail to collect the memory of a killed process, or to release it for use by other programs. We can't keep undisciplined web-site maintainers from sending us bad code, but we should be able to keep them from polluting our browsers too badly.

JavaFX, posted 9 May 2007 at 06:01 UTC by nymia » (Master)

Interesting to note the announcement of JavaFX posted on SlashDot.

It looks like JavaFX was groomed to face Silverlight, Flex, AJAX.

/bin/sh, posted 9 May 2007 at 08:01 UTC by chalst » (Master)

ncm wrote: It seems curiously appropriate that Javascript programs are the only ones I run these days that consume all available RAM and swap space, and that crash. They are also the only programs I run that depend on a garbage collector. I doubt this is a coincidence.

Funny. I abandoned using Gnome & KDE around 1991 because of their poor resource peformance, to embrace the lisp-based, garbage-collected sawfish window manager. Emacs has mostly been pretty well-behaved spacewise: my stability problems with it over the years have mostly been due to non-terminating code, not gluttonous code.

Do you really not run perl at on your machines?

Resource efficiency, posted 9 May 2007 at 10:48 UTC by chalst » (Master)

ptwithy wrote: And yes, the language of the future is Javascript, to which ncm responded Javascript has become unavoidable, though, and Flash will be soon. Each increment degrades my web experience a bit, with rare exceptions

As I've posted before, I don't think the correlation between coding quality and presence of garbage collection is anything like as close as ncm seems to think, but there is certainly a sense in which garbage collected programming languages provide something of a lifeline to bad code.

Is there anything that can be done about this? Proof carrying code provides a technology: code can be guaranteed to run within given resource bounds; but there is no possibility of web-2.0 companies providing PCC in the current environment. Is there anything that might work?

Leaky GC programs, posted 9 May 2007 at 21:27 UTC by ncm » (Master)

chalst: I have to admit also running Emacs, which hasn't been obviously leaky or crashy, lately. Neither has most of Gnome, lately. While abandoning Gnome and KDE around 1991 would have been remarkably foresightful (if ineffectual), adopting sawfish would have been positively prescient: none of those projects existed in 1991, and many readers here must have been more interested in learning to ride their bikes without training wheels than in Free Software.

I don't draw any connections between coding quality and garbage collection. I draw strong connections between presence of GC in a language and that language's suitability for applications other than pure computation. That said, a garbage-collected language is not necessarily worse for any particular task than C, and could be better.

I do try to avoid running Perl, for reasons unrelated to GC. However, I don't think of Perl (or Python) as a GC language.

:), posted 11 May 2007 at 12:01 UTC by lkcl » (Master)

you guys are just _too_ funny :) you take this stuff all so seriously!

ncm: my bicycle was assembled / welded by my grandfather, who was an extremely good engineer. unfortunately though the bicycle split in half after five years, when i became much bigger :)

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page