E4 and Web 2.0 - Is there a better way?

In The Web 2.0 - or are we going the wrong way?, Tom accurately compares Web 2.0 with 3270 (and 5250) terminals of yesteryear and wonders aloud if Web 2.0 is really the right way to go technically with E4.

This is a good question. What is the right way to go, both politically and technically?

Industry Forces

The way I look at it, the following forces are shaping the industry's solution to this problem:

  • Low-touch deployment model. Web pages load fast into the browser. Hot-deploy changes to the server and clients automatically pick them up.
  • Install the client once. Desktops are very expensive to install and maintain. The web browser is already on literally every desktop out there, courtesy of Microsoft and the Mozilla Foundation. Adobe Flash is nearly ubiquitous too.
  • A rich experience is preferred. Google search will probably remain a Web 1.0 application. But for anything much more complicated than this, the world is moving toward a richer Internet experience.

Technical Choices

Given these realities, let's list the technical means for deploying rich Internet applications and then draw some conclusions about good places to consider investing in E4.

  • AJAX-based Web 2.0 applications.
  • Flash-based applications.
  • Java Web Start.
  • Create a browser plugin like Flash, but that just includes OSGI, SWT, and probably a security model.
  • Create a brand new universal network client based on Eclipse RCP.

Let's look at each of these in turn.

AJAX-based Web 2.0 applications

Tom already described the weaknesses of AJAX: It's basically a hack to turn asynchronous XML requests from a browser into a rich graphical terminal. AJAX applications tend to be sluggish, as they can require round-trip network requests to anywhere in the world and rely on interpreted JavaScript operating over a DOM.

Having said this, AJAX's biggest advantage is that it is already supported everywhere the web is. AJAX is basically the least common denominator platform for rich web applications.

Flash-based applications

Flash is well-understood and fairly ubiquitous, but it is proprietary. It is not as well supported on 64 bit platforms. However, it has a better programming model for really rich graphics.

For example, there is no standard analog of an SWT Graphics Context in AJAX JavaScript, so something like Flash is required in order to implement generic graphics drawing over the web.

Java Web Start

Java Web Start has a reputation for being roundly hated by Java programmers. I have no personal experience with it so perhaps people can elaborate in the comments.

JWS has the disadvantage that its content is not integrated into the web browsing experience. It's basically a way to bootstrap a regular Java application over the web. (Again, if I'm wrong, someone please correct me in the comments.)

A new browser plugin like Flash, but that just includes OSGI, SWT, and probably a security model

This could be really cool to do. OSGI and SWT running in the browser would be very nice. With less than a 4 meg starting footprint, this could be really practical too.

The main problem here is that nobody has written it yet. Also, whoever writes it would need to have someone on staff who is really good at security, if this thing is to be deployed on the Wild, Wild Web (WWW). ;-)

A brand new universal network client based on Eclipse RCP

At JPMorgan, we've already done this. (See also.) The Riena project at Eclipse is also working on this. This makes tons of sense within the corporate firewall because:

  1. You can control deployment of a new universal network client
  2. There normally is a well-defined security model already in place.

To be a general solution, however, someone would have to figure out the security implications of running arbitrary OSGI bundles over the Wild, Wild Web. And then the challenge would be to make such a universal network client truly universal on the Internet– ie: deployed to every desktop.

Conclusion

Looking at the above forces and solutions, it seems to me that AJAX is an obvious platform for building out a new generation of rich Internet applications. It is everywhere.

However, I agree that we we will probably run into the limitations of AJAX fairly soon and want something better.

The only two possibly-viable solutions I can see above are Flash and a custom SWT Browser Plugin. I'd vastly prefer the latter, but fear that the former will win, simply because it's there.

Is there any interest in the community writing a SWT-based web browser plugin?

Discussion

Irakli Gozalishvili, 2008/05/12 15:32

Please not only Flash!!! It has a lot of bugs mostly on Unicode support so all this buggy stuff will be inherited to e4.

Maybe something like firefox extension ??? I think it would be great, it has all from web 2.0 and even much more possibilities!!

Mariot Chauvin , 2008/05/12 15:43

Hi,

Comments below :

*
Low-touch deployment model. Web pages load fast into the browser.

Web pages does not load faster as native application and web browsers consume a lot a memory (For example think of shared libraries which does not exist in a web app).

Hot-deploy changes to >the server and clients automatically pick them up.

See comment on deploying software upadtes in the GNU/linux world.

Install the client once. Desktops are very expensive to install and maintain. The web
browser is already on literally every desktop out there, courtesy of Microsoft and the
Mozilla Foundation. Adobe Flash is nearly ubiquitous too.

I think GNU/Linux have the right model of software deployment , where there is one repository contains all software you may install. You can install any software with a command line or gui.

*
A rich experience is preferred. Google search will probably remain a Web 1.0
application. But for anything much more complicated than this, the world is moving toward a
richer Internet experience.

I think you can construct more richer application with native widgets than with emulated widgets.

The main AJAX drawback for me is the following : The http protocol was not designed to build applications. Transmitting an entire application encapsulted through http is a technically non-sense !

See how web apps reinvent the wheel only to display a window !

David Orme, 2008/05/13 09:51
The main AJAX drawback for me is the following : The http protocol was not designed to build applications.
Transmitting an entire application encapsulted through http is a technically non-sense !

I thought so too until I tried Zimbra

Robert Helmer, 2008/05/12 22:10
For example, there is no standard analog of an SWT Graphics Context in AJAX JavaScript,
so something like Flash is required in order to implement generic graphics drawing over
the web.

There is Canvas http://en.wikipedia.org/wiki/Canvas_(HTML_element) although it's Firefox/Safari/Opera-only right now. There's a workaround for IE.

AJAX is an interesting use of the (originally MS IE-only) XmlHTTPRequest() method, it's certainly not the only way to do this kind of thing. Getting something that works cross-browser is the trick as the web browser market is so highly fragmented, which is why AJAX took off as it did.

I don't think more browser plugins are the right way to go, getting more incremental improvements like those proposed (and implemented in some cases) for HTML5.

Better to figure out why the open web works and is popular, and build on it if you can. Trying to fight it is going to require some mighty justification, but is certainly reasonable if it doesn't work for what you need to do.

For something as global as the Web, “least common denominator”, “worse is better”, “perfect is the enemy of the good”, etc. are the rules. Also, there's something to be said for human-readable markup and interpreted code vs. binary over the wire, as far as keeping things open.

Thomas, 2008/05/13 03:11

I know I cant think this to the end for my own, but I want to bring in a point to the discussion. You propose an SWT/OSGI Browser plugin. I tend to be a little crazy but why do we have to stick everything to the browser ? If its a rich internet application it doesnt have to mean that it needs to run inside a browser. Even RMI (although its not all I want, as its unidirectional) is tunneled through port 80 and works fine on the “web”. What I think is that we need an application platform (and some of the e4 ideas are good, having multiple instances of the workbench for e.g.) thats “web” enabled. Browsers are terminals for the html aera. Why don't we let go of them ? Let your desktop be the “web”. (Google wont like that, I guess) Theres is already something going on for OSGI security in the sandboxes. If we put on some really smart deployment mechanisms, I think we are almost nearly there.

Thomas, 2008/05/13 03:38

I know I cant think this to the end for my own, but I want to bring in a point to the discussion. You propose an SWT/OSGI Browser plugin. I tend to be a little crazy but why do we have to stick everything to the browser ? If its a rich internet application it doesnt have to mean that it needs to run inside a browser. Even RMI (although its not all I want, as its unidirectional) is tunneled through port 80 and works fine on the “web”. What I think is that we need an application platform (and some of the e4 ideas are good, having multiple instances of the workbench for e.g.) thats “web” enabled. Browsers are terminals for the html aera. Why don't we let go of them ? Let your desktop be the “web”. (Google wont like that, I guess) Theres is already something going on for OSGI security in the sandboxes. If we put on some really smart deployment mechanisms, I think we are almost nearly there.

David Orme, 2008/05/13 10:02

Are you advocating “a brand new universal network client based on Eclipse RCP”?

Fabian Jakobs, 2008/05/13 04:29

What about applets? I know applets are a burned child and nobody likes them anymore but with the recent update by Sun they are today basically Webstart applications running inside the browser. This could be exactly what you need for e4. Applets does not have the wide deployment of Flash but I think before you reinvent the wheel and build a browser plugin, you better take a second look at applets first.

David Orme, 2008/05/13 09:48
applets

Has anyone tried this? I know that SWT works over JWS, but I'm skeptical about running SWT over applets.

Can this be done?

before you reinvent the wheel and build a browser plugin, you better take a second look at applets first.

Good thought. The advantage of a browser plugin is that you can have a full OSGI + SWT environment right on the user's PC from the start. So the only thing you actually download is your application's code.

Since OSGI is already geared toward having small dynamically loaded modules, in theory, you could deploy a very large and complex application incrementally this way.

Darren Tarbard, 2008/05/13 12:27

Like you I don't really have any experience with Java Web Start but I believe they are making improvements in this area in an upcoming version to make it more pleasant at least for the user (smaller modular JRE, not locking up the browser during load etc).

sunnyawake, 2008/05/15 08:20

OSGI + SWT running on what?JRE! that's the problem. i think Flash is not suitable for building desktop-like application,but Flash Player and Flash browser plugin is everywhere, so Flash wins.

David Orme, 2008/05/15 18:07

I'm not sure I understand why it's a problem to embed a JRE into a browser plugin?

sunnyawake, 2008/05/16 19:51

good idea! maybe we can strip down OpenJDK's JRE to a minimal size just enough for running SWT as long as it's license compatible. then how big will it be? and how big will your browser plugin be?

blog/e4_and_web_2.0_-_is_there_a_better_way.txt · Last modified: 2008/12/24 12:04 by djo
Back to top
Creative Commons License Recent changes RSS feed