Flash And HTML

Is there really a war between Flash and HTML? Not according to John Dowdell. He claims that Adobe is all about enabling creativity by providing the platforms in which to do so.

War or no war (there really isn't one), Flash is here to stay for the time being. I for one try to avoid it when building web applications. But that stems back to when you might actually have to install Flash on a browser in order for your user interface to even work. These days, you are less likely to find a browser that doesn't have Flash installed on it.

Don't get over excited about the future of whether or not the web browser experience is going to belong to Adobe. The fact is that they already own a big chunk of it. Just keep that thought on the back-burner.

HTML5 Storage Complexity

With new emerging HTML5 standard, Google is focusing on using the standard for local, client-based data storage. Its nice to have some flexibility in the browser in terms of how data is stored and how to go about retrieving that data. Having a database API would no doubt help in that effort.

But is that getting too complex? Having a feature-rich data store in the web browser might take too much of the design focus away from the overall service architecture. Instead, I think it makes more sense to store URIs on the client. These URIs represent the potentially complex resource states that live on the server.

The New Javascript

It appears that the ECMA organization has approved the new ECMAScript 5, otherwise known as javascript, standard. It has been ten years since an adopted change to the standard has been made. However, this hasn't stopped web applications from evolving to something that resembles the desktop more and more with each passing year.

The ECMA plans to submit the newly adopted javascript standard as an ISO standard. I think this would be a very good move, especially if web browser vendors decide to stick to the standard.

Aside from the javascript standardization front, there have also been some new features introduced. For instance, javascript objects, or JSON objects, will be able to operate in an immutable mode if chosen to do so. This is could prove useful for working with javascript objects that are returned from an API and aren't intended to be manipulated. Also, the javascript interpreter itself will be able to operate in a strict more that is less forgiving toward malformed-syntax. This will be a blessing for developers that don't feel at ease with deployed javascript that may or may not be well-formed; it may or may not work in some browsers.

Skulpt

I just came across the Skulpt project, a Python interpreter written entirely in Javascript. How cool! Although the project is still in its' infancy, the project does look promising. Myself, as I'm sure others as well, have wanted a more Python like syntax for building highly-dynamic user interfaces. That isn't to say that it isn't possible today, it would simply increase productivity. Just like developing some application in Python would probably ten times as fast when compared to writing it in C.

Even if it proves infeasible to have a language within the browser language that is Javascript, this project could prove some interesting things about using Python within the browser. Nonetheless, this is all very interesting. There is a Python interpreter now written in both Java and Javascript.

Javascript Sockets

Is this idea even possible? Can javascript sockets actually exist inside javascript applications? According to this entry, this reality isn't too far-fetched after all. One of key problems this will solve is the current polling requirement of most javascript applications. These applications need to poll the server for state changes so that these changes, if they have taken place, can be reflected in the UI. This is an expensive operation that often yields nothing in return. So, we have this expensive process that is need just in case of a server state change. Below is an illustration of a polling javascript application.



Both Flash and Java Applets are components external to the browser that allow connection sockets to communicate with the server. It seems counter-intuitive to be using a web browser that doesn't work with most of the web without a separate software installation process. The ideal situation would be to provide the javascript application with a socket. This would eliminate the need for both a library external to the browser as well as the need for polling. Below is an example of what a future javascript application without the polling requirement might look like.

jQuery each

Performing iteration activities in javascript is actually slightly more complicated a task than it should be. This is brought about by the cross-browser inconsistencies. Developers can't implement standard javascript looping constructs and expect them to work the same way across multiple browsers. This is simply the reality of web application development. The other reality is that if any developer expects to be productive, they will use a javascript toolkit such as jQuery. Thankfully, the jQuery.each() function provides a cross-browser iteration facility. All the developer needs to supply is the sequence to be iterated over and the callback for each element in the sequence. In addition to the cross-browser iteration support, the jQuery.each() function provides flexibility in javascript applications. The function can accept both arrays and objects as the sequence to iterate over.

Here is an example illustrating the jQuery.each() function iterating over an array.

//Example; jQuery.each()

var arr=["One", "Two", "Three"];

jQuery(arr).each(function(){
console.log(this);
});

Also, during iterations, there will more often than not be a need to terminate the loop. This is achieved by returning false from the iteration callback as is illustrated below.

//Example; jQuery.each()

var arr=["One", "Two", "Three"];

jQuery(arr).each(function(){
   console.log(this);
   if(this=="Two"){
       return false;
   }
});

Addressability Lost Within The Realm Of Ajax

With RESTful APIs and applications, and with HTTP in general, addressability plays a huge role. With web applications that project an Ajax user interface, this addressability is typically gone. There is no notion of URI as far as the end user is concerned. This is because Ajax web applications often have a single URI; the application itself. From this point forward, the end user navigates through the various application states while all the addressable URIs are contacted beneath the fancy Ajax interfaces. If you are an end user using these types of applications, do you necessarily care? That would depend what you are using the application for and the type of user you are. For most end users, if the use interface is well designed, the addressability of the resources involved with the application are a non-issue. Even developers, the type one would think would be interested in the underlying application data, might be too enthralled with how useful the user interface is. If the user interface of an Ajax web application is poorly designed, things change. The data at the other end of the URI suddenly becomes much more interesting.

In more traditional web applications, the ones without the fancy asynchronous javascript toolkits, the URI of almost every resource is accessible from the address bar in the web browser. This is obviously the benefit to having addressable resources in a web application. The URIs are immediately apparent to the end user via the web browser address bar. With Ajax web applications, end users cannot point there web browser to a specific URI and expect the application to behave accordingly. This, I find, to be one of the more annoying drawbacks to using Ajax web applications. Although the user experience of Ajax web applications is improving at an ever increasing rate, the sacrifice of addressability, a powerful concept, has to be made.

But does addressability really need to be lost completely in Ajax web applications? Just because the URI isn't in its' normal location, the web browser address bar, doesn't mean the end user can't know about it. In fact, many web applications that provide an Ajax user interface will also provide a public RESTful API used by that interface, complete with documentation. However, this doesn't solve the problem of the end user that doesn't care about API documentation and just wants page X of the application to appear when they point their web browser to URI Y. I think something like this could potentially work. There would have to be two separate RESTful APIs; one for the application resource data, and one for the user interface. The user interface would interest the end users because they could use these URIs to point the web browser to a specific application state. These user interface application URIs wouldn't even need to be reflected in the web browser address bar. As long as the current user interface application state is advertised somewhere in the user interface, it could work. And it would be incredibly useful.

Web-based applications a good idea?

An entry on infoworld doesn't think so. Apparently the web browser sucks for applications and anyone using them are reverting back to the client server model. Well, it is a client (the browser) and it is a server (whatever). The strong case for the web application in the browser is deployment. There is no easier way to distribute a GUI than the web browser. Unless that is, everyone in the world used Windows.

Of course, the case against the browser is strong too. The same interoperability problems that operating systems experience are shared in the browser domain. In short, your HTML/CSS/AJAX GUI may not work across all platforms (platforms being web browsers in this case).

In terms of GUI interoperability and deployment, the same problems persist. There is no easy way to make everyone happy. And that will always be the case as long as people use different operating systems. There exists no simple unifying solution. Again, with web browsers, you have the interoperability problem. With interpreted languages, it is quite simple to achieve interoperability amongst various operating systems. I think the problem there is deployment. It is a lot tougher to deploy desktop applications that use any kind of data center.

The main problem I see with the suggested solution in the infoworld entry is that there is no mention of distributed data. Lets say I take the advice from the entry and all our customers now use our new Java desktop application. Where did the data go? Any modern requirements will scream distributed data. And that is another complexity there is no alternative for.

All these challenges, distributed computing, distributed deployment, and interoperability, they have been around for a while now. I agree with the author in that for the most part, web browsers suck for any kind of reliable user interactivity. However, I still don't see any solutions over the immediate horizon that will make the browser go away.

Rich clients are still better than the browser

It seems to me that the user experience one gets when using a browser-based front-end, leaves something to be desired. That's not to say that the browser front-end hasn't come a long way, I just don't think its quite there yet.

The main issue I've come across when building or using web browser interfaces, it the lack of cross-browser support. The browser is a lot like an operating system in that there will never be a common ground between your users. There will always be Windows users and there will always be Linux users and there might always be Mac users (there aren't any die-hard Mac users anymore are there ;)).

The difference being, of course, that with rich clients, the main difference is in how the GUI library of choice is built. The implementation generally stays the same. Even if two browsers support the same feature/syntax, it is never guaranteed that the feature/syntax will remain functional. Just because your rich client is not delivered over HTTP and rendered by a browser, doesn't mean it can't function as a web application. As you probably know, there are countless rich web applications in existence today.

On top of it all, rich clients are much more reactive to user input. This is because there is no javascript to execute which is terribly slow (although it has come a long way). The user experience could potentially be bench marked by test users. Your application could have a web front-end, as well as a rich client front-end. Your test users could then be used to inform you of which experience delivers the better experience.

I thing the browser will eventually be able to deliver a user experience at the same level of quality as a rich client can today. Just not yet. And I'm not going to attempt a guess at when that time will be because these estimates are generally wrong in this business.