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 
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.
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.
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.
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.
...it looks as if one of experts, Paul Withington, has joined us. I've emailed him to see if
ptwithy is legit.
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.
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?
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 :)
[ Home | Articles | Account | People | Projects | FAQ ] 
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank