Wednesday, 14 December 2011

Ditch the Web Browser

This article is on why I think it is time to ditch the traditional Web Browser, with it's support for HTML (5) and JavaScript, Flash, Silverlight, Java etc..

So, the first question is, what is wrong with what we have got?

  • 1) In HTML, textfields etc.. are nested within their layout containers. This makes it difficult to move things around within the browser. I think the 'data' should be sent back as one concern, the 'default' layout as another concern, and the 'widgets' used to render the data in another section. Validation rules should be sent back separately too. The layout binds widgets with data items and the data items are bound to validation rules. Look and feel should be separate as well (which it generally is at the moment with CSS, as long as developer's don't add styling inline). Finally, security rules should be sent back as well. Caching rules should be built into the page too!!! So, in terms of separating the concerns of a web page, we already have rules: a) data b) widgets c) layout d) validation e) styling f) security g) caching The advantage of this, is that we can then leave the layout on the client, and just the data is sent back and forth. The clients can customize the layout information.
  • 2) Data interchange format This is typically HTML, JSON or XML. But it is hard to process these languages on the client side. The data interchange format should be transparent to the web page, why should it care what the format is? Then we can start supporting technologies like Protocol Buffers and even parts of Thrift. We have marshallers plugged into the browser to allow it to understand the different standards based data formats. I mean, if I want to pass some data from a flex widget to a JavaScript widget, how hard is that at the moment, and then call a SOAP based web service using Ajax? This is far too difficult, this stuff should be simple.
  • 3) Strictness The browsers, allow developers to send back badly formed pages, they also allow developers to put styling inline, just put scripting in the middle of a page etc.. Why? This is bad practice, we should be trying to help developers create maintainable web pages. Let's make things tighter.
  • 4) Speed of new features To get new features into the browser, we have to wait for a standards committee, then have to wait for it to be implemented into a browser. Why not make the architecture of this new platform, pluggable. We want control still over what get's get officially released however, else you get swamped with plugins, and you don't know which ones work well and which ones don't.
  • 5) Development of Web Pages should become easy Let's open up development to anyone. Let's create a rich IDE and allow a user to drag a button onto their web page, and then right click on the button and select -> "When the user left clicks this button..."

    -> "I want to my text box to ....". -> "turn the colour red" -> "I want to popup .....". -> "Customer Details Window" -> "I want to hide ...." -> "I want to mimize .... " -> "I want to resize. .... " -> "I want to move this ... " -> "I want to reduce this in size by %"

    Typically, we are normally doing very basic things in a web page, but it is really hard work to get a new page of data back
  • 6) Richer widgets built in Why have we still not got a paginatable table available to us, that allows us to sort and filter???? This is such basic functionality that is not available to us.
  • 7) Event mechanism Too restrictive, what if we want to broadcast events within a web page to other components / widgets that we did not even design? (that have come from another site??)
  • 8) Graphics built in Obviously we have HTML 5 now, but needless to say Graphics should be built in, along with Video tags, Charts, Maps (with pluggable providers), Timelines etc..
  • 9) Advanced Widgets SMS message, Nested Webcam Panel, Skype, Social Networking Widgets, Instant Messenger. I want to be able to build up my web page how I want it.
  • 10) Back button does not work With new Ajax / RIA style apps, the back button does not work
  • 11) Too many browsers Constantly trying to get web pages to behave the same in different browsers.
  • 12) Testing is hard
  • 13) Developing is too hard

New Browser Design Goals

  • 1) The user should be able to drag and drop their web pages around, to organize the page how they want.
  • 2) Browser, sent the following items as separate concerns, data, widgets, layout, validation, styling, security, caching.
  • 3) User should be able to style up the page how they want.
  • 4) User should be able to produce a 'mashup', ie. create a 'pane' and drag it into the web page on the browser.
  • 5) Back button should literally 'undo' last action, OR take user back to previous site (if they have just changed URL).
  • 6) New Browser, should allow pluginable architecture for new language features. What happens if we want a 3dvideo tag?
  • 7) Rich Widget library
  • 8) Event bus built in to allow communication between heterogenous components running within the page.
  • 9) IDE that allows users to build web pages easily.
  • 10) Security should be built in from the ground up
  • 11) Parental controls should be configured on widgets

Tuesday, 13 December 2011

GWT Plugin How it Works

GWT Plugin Description of how it works

Spring MVC and Spring WebFlow

Another quick entry to detail my experience with Spring MVC and Spring WebFlow.
  • Spring MVC rocks. It is simple and works.
  • Spring WebFlow - we used this with Spring MVC, and got ourselves tied in knots at one point deciding what *is* a Web Flow, and it can get tricky when you go from a flow into a sub flow, and then want to exit etc.... All problems that we could of avoided if we had not used Web Flow. Of course, the big USP (with WebFlow is that it supports conversational state. Trouble is, it is not often you actually need that, it is useful if you have a Wizard set of pages to code up.

Where we ended up with WebFlow was that we used WebFlow if there was an update screen, that spanned more than one page. If it was a view / read only web page, we would use MVC, and if it was an update screen which was just one page / one form, then we would just use MVC.

In hindsight, I would not use WebFlow again as I don't think the benefit's (conversational state and it manages state for you cleanly so if you spawn multiple browsers you can have no collisions), outweight the negatives of a) having to learn the WebFlow syntax (which increases the learning curve for developers), and b) introduces this grey area of what is, and is not, a flow.

Thoughts on jQuery, DOJO and GWT

Having used both these JavaScript extensively over the past couple of years, I thought I would give some brief notes into my experiences of using them.

jQuery - this library is excellent at marking up a page with some enhancements. Would I write an entire JavaScript based application using jQuery? I would not use pure jQuery on it's own, if I was going to use it for a heavy js application, I would use a framework / set of patterns for ensuring the code does not end up being very difficult to maintain. The main problem with jQuery 'out of the box', is that it encourages developers to manipulate their pages using selectors and performing actions on those selectors. Whilst this is very powerful, it can also lead to very unmaintainable code, because unless you have a good understanding of what is in the HTML DOM, then you don't really understand what these powerful expressions are doing. Some programmers may document what they are doing, but a lot of programmers will not. But, on the whole, if you want some simple enhancements, jQuery is very impressive, a great set of plugins, and we have not had any problems with the library, it seems very stable, which is great.

DOJO - this library differs significantly to jQuery, in that it encourages the developer to create classes and custom components (called Dijit's) from the start. So in terms of the 'programming model', DOJO win's hands down. Where DOJO is not so great (and I was using version 1.5.1 on a legacy browser IE 6), is that some things are hard to do, such as styling a button. Why is styling a button so hard? Well DOJO nests the button in a load of div's or span's (I forget), and each of these layers has a css class associated with it.

See: Style Button for more info about styling buttons (although I do not recommend this method, it does highlight there can be difficulties doing such a simple task).

The other reason I am not so keen on DOJO are a) not many people 'seem' to be using it b) it is slow unless you configure your application to go through their Shrinksafe compiler. But, in general, it is 100% JavaScript application, so unless you have a strong team of developers (and preferably JavaScript ones at that), there is plenty of scope to get yourself into problems.

GWT - It is early days with GWT, but so far I have found the development environment quick to setup. I like the showcase (don't they always look good), and the debugging facilities are great. It is a bit of a weird concept, writing Java Code and spitting out JavaScript code, because we are at the end of the day, still manipulating the HTML DOM. In terms of what you get out of the box with GWT, I am using 2.4 and started using the DataGrid the other day, and found it buggy when adding it to a basic dockable resizeable panel, when taken out of the dockable container, it worked.

The upsides of using the Toolkit are that it is going to work well with Google API's, Map's, Calendar's etc... It still does not seem to have taken off quite yet, a jobserve search will show not it's future is still uncertain:

GWT Trend

Maybe the fact it compiles into JavaScript makes people nervous.

So, what would I use for RIA?

It would depend on how 'rich' it needed to be:
  • If I was trying to write a web based application with some widgets enhanced, I would choose Spring MVC with jQuery.
  • If I was trying to write a really whizzy rich application, I would choose GWT.

The Play Framework looks interesting, but the increase in volume of their forum has not carried on the trend of the previous year:

Play Framework Forum

however, google trends shows there is more interest in it: Play Framework Trends

and just looking at the demo app, it looks like you can just chuck a load of javascript code inline to do stuff, which again, can create a maintenance headache if you have a team of 10 UI dev's going at it.

Of course, if there were graphical elements to the application, then this would bring HTML 5, Adobe Flex and Silverlight into the mix.

The bottom line is that JavaScript is brittle, it always has been, and it always will be. Until the tools for JavaScript improve and developers can get decent refactoring tools / pre-interpreter syntax checking of code, that situation will not change any time soon.

Personally, I think Google needs to try to get rid of HTML / CSS / JavaScript, and create a new type of browser, with a new meta language built from the ground up, where widgets are built into the language, and data is sent in an efficient form (Protocol buffers or Thrift maybe?). Layout and styling should be customizable by the user, just a default hint sent to the browser as a starter for 10.

UI Screen Designs

I saw an internal demo today from one our developers, who showed us how he could mock up some UI screens, for presentation to a customer using this tool: Axure - It seems to work nicely, although I am not sure about how good it would be to build a fully usable prototype. It can certainly do some basic view switching, and looks good for defining simple form based views.