With HTML5 we are experiencing many of the same issues we had when Java was young. The problem is not with the Java specification, or in this case the HTML5 specification. The problem is with the implementation. Not all features are implemented. Not all specifications are complete, so browsers have their own implementation of the rough draft. The result is that you can’t always write code and have it operate the same in every environment.
A second issue is that by operating in a browser there is generally a separation of the host operating system and the browser for security reasons. This makes it difficult to write applications that are not always enabled through a browser, meaning HTML5 applications are not always going to be a replacement for native applications. At least based on how things are implemented today.
Two readers provide their perspective on this and many other issues. Here’s what they have to say.
Jude Writes:
I think the most frustrating part of web development right now is the inconsistency with how different browsers behave and interpret CSS, JavaScript, and HTML. Not even the difference between IE and Chrome, Firefox, etc. but even just differences within versions of IE itself. I won’t even touch on mobile. It seemed like one of the major reasons to move from the desktop to the browser was for platform and OS independence, but it seems like we’ve just traded one OS or for another (the browser).
To directly comment on your subject, SPAs give a rich end user experience, but like anything else, the requirements and (tolerance for) cost of the application will really drive if it’s worth the retooling.
This is more of an observation than a complaint, but I heard somewhere that it takes so long to paint the Golden Gate bridge, when the workers are done, they just start back at the beginning again because it’s time for another coat. That’s what web development is starting to feel like.
Colin writes:
It’s true that there is a big change coming in with HTML5 enabled browsers and the power of new JavaScript libraries and that "more" code is being javascript based .
What I particularly like about your article is your heading "Moving Off the Web Server" the reason will become apparent below.
Traditionally we had a browser which talked to a web server. The browser was lightweight and most of the hard work was done by the web server — everybody knows that….
What is different today is :
On the Web Server side :
Many of the so called Restful services are either corporate web server based or cloud based like Google/Microsoft office with document handling, excel, Drive etc etc.
There is in fact an increase in interest in providing both applications and even app. developments tools over the Cloud.For the Cloud based services you "don’t" need a web server.
In fact you can even build a small generic secure communications layer using a Cloud service
like Google spreadsheets — So there goes your web server !!!
I have detailed how this may be done on my website
www.magic-with-data.com
but its still far from being used by larger networks. What’s different is that this concept is cloud based ! So with new technologies new doors open.
On the browser side
You mentioned that JavaScript and HTML5 may become more powerful than Java in working in any computing device.
I would like to respectfully disagree on this point.
I would say that JavaScript and HTML5 will make use of "existing local" Java interfaces / code to provide some really
slick features.
To do this we need to break the accepted Browser sandboxing ie the browser cannot access local resources . We also need to do this in a secure way.
Personally I have used this concept many times where (in Windows) I use a multiple browser controls embedded in a C# .Net form or on Android use multiple WebView components in an Android form. With this we open the doors for JavaScript & HTML5 to communicate with local resources !. However in the design of such a powerful framework security must be kept in mind with local resource being made available to only known websites loaded in the browser
components.
With this concept one can pull data from one browser page and move it or analyse it on another web page WITHOUT ! changing the original website’s code .
The reason for stressing the "No changing the original website’s code" is that the provider of services will not do this because of the cost involved in changing code and re-validating the system unless of course there is a need. But for the most flexible and "unknown" use cases we need this and this can be done as shown above. Again with javascript code injection we can enhance websites without changing the original code.
This concept again opens up new possibilities.
Thanks fellas for the comments. You can add to the discussion online. I’ll be moving on to another topic tomorrow. Feel free to send suggestions for topics you’d like to see us cover to my email at btaylor@sswug.org.
Cheers,
Ben