David Van Couvering 's Blog

Web 2.0 Without the Browser

Tim O'Reilly recently had a very interesting blog as a followup to 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 them.

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 JavaScript to PHP/JSP/Perl/Ruby/Java. 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.

Comments

• I agree, now the entire web application flow is merely pure HTML distributed over a protocol. JWS or something more centralized (with pluggable objects, distributed transactions, modular interfaces) will be more sophisticated than HTML or DHTML. Besides, distributed applications would be probably more easy to protect against piracy, but as for browser based web applications, one of the main inconvenient would be a mandatory net link.

  Posted by: fravalle on December 05, 2006 at 05:18 AM

• David,
  More than agree! Few weeks back I ran against a very strange phrase in the internet: "Web OS". It turned to be a desktop manager running in a browser. Several teams are working on such "OSes" already. This caused a whole avalanche of thoughts. Why do we need a web-based desktop if we can have a "desktop-based web"? Why are all these monsters that take half a minute to load, 5 seconds to react a user action and are capable of degrading performance of the whole machine are still called "thin clients"?
  Web applications are often refered to as a solution for deployment problem. JWS is another (better) solution.
  I also would like to ephasize one important point. If rich clients are going to become a true web technology (be it Web 2.0 or not), they should preserve two properties of a web: cross-references in the content and search-friendliness.
  Alex

  Posted by: alexter on December 05, 2006 at 08:33 AM

• thanks for voicing this. i believe ajax is a transitional technology: the first step out of the browser. however, at the moment few have a better proposition. i think java and jws stand a chance.

  Posted by: eitan on December 05, 2006 at 10:02 AM

• I'm concerned about slow turnaround time on new Java versions and the related difficulty getting improvements into JWS. Nice to have it bundled too, but that's one place I think a faster turn-around cycle would be super nice.

  Posted by: tompalmer on December 05, 2006 at 03:53 PM

• Alex, nice points in your last paragraph. REST-like style would be nice to maintain. And hyperlinks directly in the content seem pretty vital.

  Posted by: tompalmer on December 05, 2006 at 03:56 PM

• Agreed. Rather than repeat what I've already said on this topic, I'll just post a link to my latest rant on the subject:

  http://jroller.com/page/mindcrime?entry=a_web_browser_is_not

  BTW, I'm not *necessarily* suggesting that the X protocol and X servers are the solution... Just trying to stimulate discussion on what some
  solutions might be by throwing out one example.

  I actually like JNLP / JWS for solving this problem. Or even applets, which I have a feeling it's time to revisit.

  Posted by: sprhodes on December 08, 2006 at 10:29 PM

This work is licensed under a Creative Commons License.