Web 2.0 Without the Browser
Tim O'Reilly recently had a
very interesting blog as a
his comment on
Kathy Sierra's blog about why Web 2.0
is not a buzzword. The point that Tim made here that got me
thinking was his comment that Web 2.0 is just the latest in
a series of names, and the vision stays the same. Tim
says "what I'm really talking about isn't the web at all, or not
just the web, but the movement of technology towards the global
internet as platform, and all that means."
I totally agree. The principles behind Tim's definition of Web 2.0
has very little to do with AJAX or DHTML or even the browser.
It has to do with a way of building and delivering applications
that is enabled by these technologies, but which is not defined by
That got me thinking, well, how can we envision another way of
delivering "Web 2.0" functionality? To me the current way of
building web apps is pretty broken. It's complex, it's heavyweight,
it requires understanding a vast amount of technology, from HTML to
It's just a huge spaghetti of stuff to learn. As a result,
frameworks have proliferated to try and handle this complexity.
It also doesn't
make any sense to me that web servers are mostly in the business of
delivering dynamically generated text markup.
And what's the reason behind all of this? As far as I can see, the
primary reason is because the browser was not initially intended
to serve up dynamic applications.
In the meantime, the user experience has degraded significantly.
AJAX and other technologies have made the browser much more dynamic
and engaging, but it's still just trying to catch up with what we
already had before with standard "thick" client applications.
With an architecture where the presentation code is written purely
in code, and not a combination of code and markup, and is delivered
as a single simple download to run in a real language runtime, then things
can be simplified significantly.
The communication between the client and the server
won't be these masses of presentation markups and scripting, but basic
business operations. The server can do
what it does best: pump through thousands of business operations a second.
The client CPUs can be put to work rendering the user interface and providing
dynamic interaction with the user. Applications written this way can
make much better use of server resources and as a result yield significantly
more scalable solutions.
What's stopping this from happening today? I think there are two major
issues. First of all, getting client-side code deployed to the server
has been slow, complex, and broken. Java Web Start and Flash are
solving this, and I think this can only improve over time (especially
now that Java is open-source).
The other reason is that 3GL languages like Java have been unpopular
in the web space because the kind of person who builds web apps generally
does not have the background or patience to learn a 3GL. They want to
get something up and running fast. I would love to see our IDEs focus
on delivering thick client apps using drag-and-drop application building
as well as a combination of 3GL and scripting languages. We need to
make it easy for web developers to quickly build rich, dynamic apps that do not rely on the browser and all its limitations.
Just a plug: having a local data store like Apache Derby or dojo.storage
is also key to this approach, as it allows the client to manage local state
locally, rather than having to depend upon the server to do it. This
allows the client/server communication to stay focused on what really
needs to be sent to the server: transactions, rather than the little
steps along the way that lead to a transaction.
Web 2.0 is a great thing. A read-write Internet platform and the power
of collaboration and community to create value
is still a huge benefit and a major change in the way we
use computers and the Internet. But that doesn't mean we have to continue to
build applications in this strange arcane way that has evolved since the
late nineties because we're trying to shove dynamic content into a vehicle
that was built for static text.