Every one else seems to be chucking their opinion into the Web 3.0 debate, so I think I will too.

For the second time at least - on Jan 10th 2006, I blogged on “Ruby in the Browser and Web 3.0”:/blog/ruby-versus-javascript-for-web3.0.html Soon after Obie Fernandez and Dion Alamer disagreed on the idea, and in April of 2006 Dion created Ruby in the browser instead of JavaScript . Andres Almiray soon followed with Groovy in the browser instead of JavaScript .

Obie will probably disagree with this entry too :-)

Anyway, back to my predictive Web 3.0.

In short, I think it is a new technology (as well as all that semantic, social, pervasive stuff from other bloggers). One thing that is missing from other ideas though: I think it is a new technology.

HTML Sucks

HTML + Javascript just does not do it any more. Click on my earlier post above to see the ‘glass ceiling’ issues that dogs this declarative + procedural combination, and particularly a prior project ‘Thicky’ from 2004. There are multiple problems with Web 1.0 and Web 2.0 that can only be solved with hundreds or thousands of lines of JavaScript. It is not easy to make a UI as sophisticated as desktop applications, with today’s web technologies.

What excites me is the pseudo-declarative forms pioneered by Groovy / JRuby’s “builders”. It is a way of having that easy-start declarative world like HTML, but being able to keep to the same language for the heavy lifting and go way above that glass ceiling. To run, it is going to need a new browser plugin though, which many will claim is one plugin too far.

Swiby Rocks

So a colleague Mike Ward’s blog bought my attention to Swiby and I contacted the author (Jean Lazarou) to discuss the potential of the Thicky redone in JRuby, and I’m pleased that Jean agreed and we brought his project to Codehaus and kept the name Swiby.

With Swiby (when we get it finished) the pages, should be shipped from the server side web frameworks like those today (Ruby on Rails, or Waffle), and executed in the browser via that plugin. All of these will be possible:

  • AJAX-like behavior
  • lazy loading of hidden tabs, or sections of a page
  • threaded / timed events
  • client side object storage more sophisticated that the current browser cookie
  • amazingly rich interfaces (YouTube, GMail, Writely should be easy to do)
  • equivalent of CSS for properties of widgets
  • server side decoration a la Sitemesh or PhpMesh
  • tiny pages, quick loading, and quick transitions from one page to another

Differences to incumbents

The characterizing difference between Swiby and the rest (JavaFX, Silverlight, Flash), is that pages can come one by one. Just like they do for the HTML web today (ignoring AJAX / dynamic HTML). It will mean that, unlike incumbents, pages -* are bookmarkable

  • are indexable by search engines (provided Google et al can parse ‘text/swiby’ like they do ‘application/pdf’)
  • can be lazily retrieved from the servers in sections (one tab/panel at a time etc)
  • will be small

It is also worth remembering that UI and function are separated in JavaFX, Silverlight and Flash. With Swiby you get the Pseudo-declarative form that more easily allows you to punch through the glass ceiling.

Just in case people are worried, it is not the case that Swiby is UI mixed with data, like Web 1.0. It can be if you really want, but it will also allow data separated from pages.

Perhaps Swiby is closest to JavaFX. We think Swiby has a made a better choice of markup language than the one underpinning JavaFX, and that can function as in a way similar to HTML today, instead of loading from the server as a large binary blob.

JRuby side effects

Swiby is going to be able to take advantage of the fact that Ruby pages can be JIT compiled. Second and subsequent hits to the same page or fragment of page should yield speedups. Being interpreted in the first instance means that the lowest possible impediment to display is possible - remember the web is successful today because people have a tolerance to a small delay on page rendering. After they click on something, I mean.

Swing side effects

Swing as a UI toolkit is fantastic. Its flexible enough to make full blown IDEs like Intellij IDEA from.

It neatly provides a number of pane constructs that should make it easy to do advanced UI elements in. A YouTube movie player, would be made from a base pane, and some player controls visible in the glass pane in only tens of lines of Swiby code (provided JMF were available in the classpath)

We need help…

It is still early days, and JavaFX is miles ahead, bit this seems to me to be the right way, and JavaFX the wrong way. So we are looking for developers to help out. Here are people who might be attracted to this project -

  • a Swing expert who loves or wants to get into Domain Specific Languages (DSLs) written in Ruby.
  • a Plugin writer who can help up target Internet Explorer, Firefox or Safari.

blog comments powered by Disqus


October 13th, 2007