Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

Is HTML5 good for application developers?

HTML5 will make the Web browser into an application runtime environment similar to how Java and .NET work, but will use a mishmash of old technologies to achieve this. Is this good for application developers? Is this a good way to develop applications for the next 20 years or is this a big step backwards in application development?

What is an application runtime environment?

An application runtime environment is an application that hosts the execution of other applications. The application runtime environment is written for a specific operating system, but the hosted applications are written in languages specifically for the application runtime environment, which makes these hosted applications platform independent. Java Runtime Environment and .NET Common Language Runtime are examples of application runtime environments.

What's wrong with making the Web browser into an application runtime environment?

Having the Web browser become an application runtime environment is in principle a good thing. However, using HTML as a Graphical User Interface (GUI) language, JavaScript as a programming language and Cascading Style Sheets (CSS) as a layout language is architecturally unsound. It will lead to spaghetti code applications, and will take HTML5 applications longer to develop and cost more money to build than comparable desktop applications.

Building applications in HTML5 is architecturally unsound

HTML5 is a kitchen sink of technologies - a mishmash of functionality built on top of past design mistakes or shortcomings in old technology.

HTML was designed to be a document structure language. It lacks the most basic features of a GUI language such as the ability to create real dialog windows. Most usage of HTML to create GUIs involves kludges, such as using floating DIV elements instead of real windows. Not only does this create user interfaces that do not comply with standards for the given operating system, but also they are not accessible.

JavaScript was designed to be a lightweight and simple language to give a more interactive user experience. It was a language for non-programmers. JavaScript in HTML5 lacks the rich class libraries found in Java and .NET. Class libraries contain reusable functions for features such as advanced drawing, encoding, encryption, network communication, etc. Also, the way JavaScript is implemented with HTML makes the browser vulnerable to security breaches.

CSS lacks the necessary features for doing layout for Web pages and certainly does not have the necessary features to do layout for applications.

HTML5 applications are likely to become spaghetti code

Because HTML5 applications will be built from loosely coupled technologies, often by non-traditional programmers, the result will inevitably be spaghetti code - code that is complex, tangled and full of workarounds for browser versions/bugs or shortcomings in the technology.

HTML5 applications will take longer to build and cost more money

Most of the time (and therefore most of the money) spent in developing applications is consumed by debugging. Because of the loosely coupled technologies that make up HTML5, it is not possible to create an Integrated Development Environment (IDE) on par with Visual Studio or Xcode. This makes debugging HTML5 applications far more difficult than comparable desktop applications. Also, JavaScript is an interpreted and loosely-typed language which also increases the complexity of debugging. This means that the development of sophisticated applications will require larger development teams, more time, and more money.

Did anyone ask what we developers want?

Hey browser vendors - you're making the browser into an application runtime environment for us developers - right? Before you started, did you ever think to ask us developers if we want to continue using kitchen sink technology for the next 20 years?

Public comments

1. Posted by Breton
on Tuesday 2009-11-10 at 03:50:57 PST

You are fully welcome to continue developing java applets. Good luck with that.

2. Posted by warren
on Tuesday 2009-11-10 at 05:50:50 PST

Java applets, Flash, and now RunRev (formerly Revolution) has a plugin allowing development of in browser apps... is there something wrong with that idea, Breton, or is your comment not meant to be as dismissive as I have interpreted it to be? It's true that Flash and Java have been overused and trivialized but so has, in case you haven't noticed, javascript. I'm about fed up with all the time-wasting animation effects that are all the rage among web developers these days, as one example. But, I am also disturbed by the uncritical enthusiasm for these browser based applications. Most of those of my acquaintance are clumsy and slow to a degree that would leave a traditional desktop app without users. In this case I have no use for them. It's just not so much trouble to find and install a "real" app, and I am not unwilling to pay for skilled and useful programming. I am not at all interested in the "coolness" of getting things to happen in a web browser that only recently were "impossible". Who cares... and why? Nor do I receive any special thrill from "interacting with the server" in that type of implementation. Just a waste of time to me. (Flash on the desktop leaves me similarly unimpressed and dissatisfied and I am distressed at how many are jumping on that three-wheeled bandwagon, but that's an only vaguely related matter *wink*)

A comment about the last sentence of your post, Vlad: If you as a developer don't believe this is a satisfactory technology, please use something else! Ignore it! Go ahead and build useful applications using the language and environment you prefer and leave this to those who are more impressed by their virtuostic ability to make heretofore impossible things happen at all than by exactly how well they happen. You, your users, and most likely your bank manager, too, will be happier ;)

3. Posted by Breton
on Tuesday 2009-11-10 at 07:34:47 PST

You don't have to look far to see people complaining about how unbearably awful plugin based apps are in terms of user experience. Flash apps in particular take up a large amount of CPU and memory, and cause browsers to crash a lot. just figuring out how to even download the java plugin is an obfuscated maze, and once you've installed it, it becomes pesterware. "Hey dude, it's java, great news! I've got another incremental update for you!"

html+javscript is already installed on 99% of the worlds computers, it is cross platform (Mac, Linux, Windows, Mobile), runs more efficiently and cleanly, better sandboxed, better security model, requires no plugins, and it works with the actual browser content rather than appearing as a foreign object hovering over the page content like a sluggish UFO. It doesn't typically break bookmarking or the backbutton like plugin based apps do. It is not a proprietary technology, and has numerous open source implementations, free of patents.

Yes, it is a system that evolved over the course of many years, and it is not as "clean" in its design as some other platforms. Yes there will be messy code, just remember: you can code fortran in any language. And sure, html and javascript were originally not designed for complicated applications. Guess what? Computers were not originally designed to run in interactive mode! It's called evolution, baby! But If you don't want to take advantage of the installed base of 99% of all computer owners, you are welcome to code for the smaller subset of people willing to spend an afternoon installing software runtimes.

4. Posted by John
on Tuesday 2009-11-10 at 08:07:53 PST

Your anti-spam question is rubbish - do I enter the word 'four' or the numeral 4, or in fact is the answer: zero, nil, nought, nothing, 0 etc.? (Depends whether you know your mathematical precedance correctly, and whether I know it too!)

Secondly, calm down, and ask yourself if you prefer the alternatives: you want to build in Flash? how compatible is that, when it doesn't even run in the browser, but requires an additional plug-in layer?

5. Posted by Vlad Alexander
on Tuesday 2009-11-10 at 08:24:39 PST

Breton wrote: "You are fully welcome to continue developing java applets."

John wrote: "you want to build in Flash?"

Breton and John, why do you see that as the only alternatives? Why do the browser vendors believe that the rule of the game is to reuse only what is already out there?

Regarding the anti-spam question, how do you get 4? The answer is either "0", "zero", "zip", "zilch", "nil" or "nada". And thanks to you I've added "nought" and "nothing".

6. Posted by Breton
on Tuesday 2009-11-10 at 14:40:12 PST

"Breton and John, why do you see that as the only alternatives? Why do the browser vendors believe that the rule of the game is to reuse only what is already out there?"

Because they're the ones that actually have to build the damn thing. 10 years of utopian planning resulted in nothing but vapour. Now they're just getting realistic. What works now? Let's build on that. Now that the web is an established platform, we don't have the luxury of just replacing it. That is just simply not how reality works.

http://en.wikipedia.org/wiki/Gall's_law

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

If you're going to replace the web with a system that occupies the same niche, you basically have to move the earth: It has to posess equal, or more power out of the box to a system that has been built over the course of nearly 20 years. It has to be able to use all the vast amounts of content out there which already exist, without breaking a single page, or it will simply be rejected by users. It has to leverage the skills of all the millions of designers, writers, developers, and editors who have already spent years learning to write for the existing platform.

Would you like to tell them that they have to start over and learn a programmer's system, where the content is bound up in the program code? A system where you need someone with a specialised degree before you can correct a typo? Is that what you mean when you rail against decoupled technologies? Or perhaps you think all those people don't really deserve their job, and should be replaced with java or .NET guys?

Perhaps I'm not being fair on you. I just can't quite understand what you're getting at though. What would you build instead?

7. Posted by Shanon
on Tuesday 2009-11-10 at 15:34:38 PST

Web apps have definite advantages in these areas:

1) You don't need admin rights to install or use them.
2) You don't need to setup firewall/security exceptions on installed machines.
3) You can upgrade them without user input.
4) You can hire graphic a designer to make them look good.
5) You can still use java, .NET or ruby on the back end for heavy lifting.
6) There is a LOT of knowledge and experience out there that you can leverage.

8. Posted by JohnJ
on Tuesday 2009-11-10 at 15:45:49 PST

Use GWT if you want rich Java libraries for the client... All of those HTML5 technologies have GWT hooks.

9. Posted by Arle Nadja
on Tuesday 2009-11-10 at 18:47:50 PST

Sure HTML5 is good for app developers. Having it available does not harm any alternative to web development and makes web development more powerful. Why discourage anyone from taking advantage of an open platform?

10. Posted by Vlad Alexander
on Tuesday 2009-11-10 at 19:43:37 PST

Arle Nadja wrote "Why discourage anyone from taking advantage of an open platform?"

"Open" platform and a "good" platform are different things. But they are not mutually exclusive. Why not build a good, open platform. Why do we have to use a poor, open platform?

Shanon wrote: "Web apps have definite advantages in these areas"

Great! I agree! Let's build a Web platform that is better than what we have now.

Breton wrote: "Because they're the ones that actually have to build the damn thing."

Yes, but we have to use the damn thing. The 5 companies (Google, Opera, Mozilla, Apple and Microsoft) that are actively engaged in HTML5 development have some brilliant engineers working for them. For their own products they apply innovation and imagination to push the boundaries of software. Yet when it comes to Web technology, there is no spark, no vision and no inspiration. Why?

11. Posted by Breton
on Tuesday 2009-11-10 at 20:27:39 PST

Because everyone has to agree with it, and everyone has their own ideas about what "good" means. A standard like html5 requires consensus, and isn't a good place to innovate. As Douglas Crockford says, if you're innovating in a standard you're doing something horribly horribly wrong. html5 is mostly about codifying what browser makers have already done. "Spark" and "Vision" cannot happen within a committee environment.

For the non standards part of the question, I encourage you to read this recent article on Mark Pilgrim's site:

http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element

It's a fascinating look at the history of how a rather important feature was added to the browser platform. The pattern seems to hold true for most features of the web stack. Coming up with an idea is the easy part, getting everyone to agree, and actually building the thing are more difficult, and shipping code generally wins over, as I said earlier, utopian ramblings about some ideal platform that we should be using instead.

You still haven't actually specified what you would replace html5 with though, by the way. But I can tell you from historic example, unless it's strictly a superset of what we already have, blink tags and all, it probably won't work.

12. Posted by Vlad Alexander
on Tuesday 2009-11-10 at 22:14:26 PST

Breton, Mark Pilgrim's article basically states that in the past, the developers of HTML language could not work effectively together. It was a different environment. At that time we did not know what the potential of the Web could be. Because we failed to work together in the past and it is very challenging to work together now, this does not mean that should repeat past mistakes. We are now all stakeholders in the Web and we must all work together to improve it.

Breton wrote: "You still haven't actually specified what you would replace html5 with though"

I am still formulating my ideas and I will present them in future posts. What I do know is that HTML5 is inadequate to meet the needs of the future Web. Imagine the Web you want to see 20 years from now. Then imagine the steps we need to take to get there. Is HTML5 a step towards your vision of the future Web or a diversion?

13. Posted by Hector
on Tuesday 2009-11-10 at 23:22:46 PST

Yeah. Why not develop a new technology and throw away the whole internet. Let's build a new internet. Who cares about that few trillion pages, they're written in HTML... super old stuff. Man, do you think this is reasonable? Well, fine go ahead and create the Internet 2.0 and get rid of that old HTML and the clumsy JavaScript. I didn't get your suggestion for this super magic technology or how it will work. Ok, so HTML is not perfect, neither JavaScript, CSS, Java, C++, PHP, Ruby, Python, etc. Sorry, we can't live in that kind of world. You got to learn to program "into" the language instead of programming "in" the language. Many people have done so. They have build tools to help them, like the GWT. Smart developers take advantage of what they have and make wonderful things with it. Lame developers complain that the technologies are plain wrong and that we need new ones, which somehow their are unable to describe. HTML+CSS+JavaScript doesn't work for GUIs? Tell that to the Capuccino developers and their awesome apps: http://280slides.com/Editor/ They've build tools to enable them to create awesome web apps without even writing HTML or CSS or JavaScript. They don't, but their platform do it for them. So, that's still plain old HTML... the clumsy, old technology. If you don't believe me, go to that link and hit the "View Source" menu item.

14. Posted by Mark B
on Tuesday 2009-11-10 at 23:32:35 PST

Vlad,

I think you're looking at this from the perspective of someone who works with html circa 1998 or earlier. The reality is that browsers and frameworks have matured incredibly within the past two years.

Given A) reset css frameworks, B) jquery/mootools/prototype/yui javascript frameworks, C) 960/yui/flex html layout frameworks, html-based applications are easier to develop now than they have ever been. While html5 is what I would only call a marginal improvement over what we have now (given a large chunk of the spec dedicated to semantics rather than actual human-visible-elements) it's still, for me, the environment of choice.

As a web app developer, I don't need to worry about 32bit/64bit editions of my codebase. I don't need to worry about taking care of HIG differences between, say, Windows and Mac. I don't need to worry that my users are using the latest version of my app-- if they're hitting my site, they're using the latest version. I don't need to worry about machine capabilities of my users. I don't need to worry about inter-machine communication, if I'm working on an app that talks between users. All of that is built into the browser. HTTP is a dead simple protocol, and there's no reason to reinvent the wheel when the browser brings so much functionality to you for free.

"Imagine the Web you want to see 20 years from now."

I hypothesize that at the rate technology is increasing, this isn't possible. However, I can imagine a world where every piece of hardware we use is IPv6/HTTP aware regardless of whatever CPU it's actually running.

15. Posted by Satya Prakash
on Wednesday 2009-11-11 at 06:04:27 PST

I also have something to say about html5 and I have said in my blog. The exact url in there in link.

16. Posted by Vlad Alexander
on Wednesday 2009-11-11 at 10:38:33 PST

I wrote: "Imagine the Web you want to see 20 years from now."

Mark B wrote: "I hypothesize that at the rate technology is increasing, this isn't possible."

It can be done because it's your vision of the Web, not a prediction of the future. For example, say 20 years from now you are driving your car in a new city and you get hungry. While you are driving, you speak to your car's computer and ask for the location of a nearby, reasonably priced restaurant that offers vegetarian black bean soup. The car's computer speaks back to you the price of the soup and provides you with driving directions to the restaurant. Nice feature to have 20 years from now, right? Now ask yourself as an app developer, can this be done in HTML5? Also keep in mind that the authors of the HTML5 spec estimate that it will take about 15 years before there are 2 browsers that fully implement HTML5.

Hector wrote: "Who cares about that few trillion pages, they're written in HTML"

Nobody is saying we should discard those pages. Future specs do not need to be backwards compatible. Future browsers need to be backwards compatible by supporting old and new specs.

17. Posted by cryo123
on Wednesday 2009-11-11 at 13:41:51 PST

Vlad : I mostly agree with your opinion : we all have to recognize that developping a application is a different matter than developping a web site even if there can be common issues.
HTML/CSS/Javascript are not designed for developping applications even if some HTML5 features are very interesting indeed.
There are more and more demand for RIA (and especially Flex of course) technologies in projects we are working on in my company.

That does not mean we blindly see Flex and its Silverlight, JavaFX brothers as the holy grail : they DO have lot of bugs ...
and yes using plug ins can be troublesome : they can make you browser crash, they are not always easy to upgrade,...
But it seems obvious to me those technologies provide a programming model which is more efficient for developping applications IMHO.

Designing UI layouts is a simple but good example of what I mean : any developper which has worked on a Flex project quickly understood how to setup UI layout whereas it is easy for me to remind lot of weird DIV positioning issues in my older projects. I'm still waiting for the CSS3 advanced module layout to be implemented in all browsers... I still notice many UI differences
between all the browsers I use when I use them.

Shannon :

1) You don't need admin rights to install or use them.

As a admin, I can also block some websites so I do not understand what do you mean

2) You don't need to setup firewall/security exceptions on installed machines.

Out of subject : it is easy to use HTTP web services with RIA technologies

3) You can upgrade them without user input.

I do not see that as a advantage. Automatic software upgrades are not the holy grail : moreover upgrading a Flex app is as easy as upgrading your favorite web site.

4) You can hire graphic a designer to make them look good.

Never heard of tools like Adobe Catalyst ?
what prevents designer and developer to work together on a RIA project ?

5) You can still use java, .NET or ruby on the back end for heavy lifting.

The same is true for Flex. AMF services can be hosted on .NET, Java, PHP,...

6) There is a LOT of knowledge and experience out there that you can leverage.

I'm so impressed by this sentence :)

18. Posted by Jason Grant
on Thursday 2009-11-12 at 07:13:02 PST

What are you proposing as alternative? I broadly agree with your points, although separating JavaScript and CSS into external files usually means leaving clean HTML in the output.

There are issues of mixing business code with HTML, however this is also handled relatively well by some frameworks.

19. Posted by Vlad Alexander
on Thursday 2009-11-12 at 09:10:52 PST

Jason Grant wrote: "What are you proposing as alternative?"

First, I propose we discuss the problems of the Web. This has not been done before. Second, we need to have a vision of the kind of features we want in a future Web. This has not been done before. Third, we need to work together to build these features. This has not been done before.

In my next post I will discuss the problems HTML5 is causing authoring tool vendors as a consequence of not working together.

20. Posted by Gernot Kogler
on Friday 2009-11-13 at 00:31:36 PST

I came to HTML / CSS / JS with a strong background in developing rich client business apps (Java, .Net). From my view, HTML / CSS are great for describing user interfaces, much better than WinForms, Swing, you name it. I cannot see why HTML5 is going into the wrong direction.

As for your example "20 years from now": The device in your car would hardly be a html5 browser. It would be a speech recognition device that would talk to an application backend over HTTP. And that backend would hardly be implemented in HTML/CSS/JS.

21. Posted by Rob Crowther
on Friday 2009-11-13 at 08:34:30 PST

> Did anyone ask what we developers want?

What's stopping you joining the whatwg mailing list and telling them what you want? Anyone can contribute, it's not just a list composed of browser developers.

22. Posted by Nicolas
on Friday 2009-11-13 at 09:18:12 PST

Hi all !

Sorry but i have to agree with the original poster. First, we can keep all the HTML/CSS/Javascript stuff and go ahead. HTML5 sites will not work on legacy browsers either.

An application and a web site is not the same thing. And you do not have the sames need.

You can perfectly write an application with classic GUI techniques, more more efficiently and benefits from key adventages :

- full use of client CPU & memory horsepower. What you can do with a simple 133Mhz pentium is not possible at reasonable speed even on most modern hardware on a browser with HTML/Javascript.

- Full object model and advenced design tools. You can make a windowed application in minutes when the same thing will require month using most advanced web technique. Just think of 280 Slides exemple. What they offer, is just a very basic power point like app, something that performed very well and fluidly on P133 and that any studient could make 6 month... For the web only few company are able to do that. It is shown at the best of the best... Still worse than what we have on classic GUI for more than 20 years. What the point ? Using 10 ou 100 more developpement time, it barely work. But it's using HTML/CSS so it's fun and cool ?


For the deployement concern, just use web start or thing like that. Just make your app update itself upong startup and your are done.

Developping web application is very long, it's hard. Technology and framework change every years and the is no clear standard or winner. What we have now ? We just starting to see slow and featureless version of destop application on the web. And that's only the big one like Adore, MS, Google that can do that. Because using the web, it's simply to complex for most of us.

HTML/javascript, is good for e commerce, online banks, encyclopaedia... It's not for very interractive application. It's not good to design a car motor, show complex business data, or make very interractive GUI. It's a limitation of the design.

A standard like Flash.Java FX or other thing like that but promoted by W3C would be great. But we are far from that.

Maybe it's time to leave all that web buzz, and admit that you don't have to use it for everything. After all, all you need is a website to dowload/updgrade your app and it to use http for communications with the server.

And hey i see many software vendor that now make à web version of their business app. Many time it's very slow, it was very expensive to make and their customer prefer the old destop version.

You will not go with classic GUI dev if you want to sell computer or thea bags, but you can définitively do that if you make enterprise applications. And it will be far easier, far less expensive. You'll be able to concentrate on business needs instead of web technologies bugs and concerns.

23. Posted by Vlad Alexander
on Friday 2009-11-13 at 11:26:40 PST

Gernot Kogler wrote: "As for your example '20 years from now' ... that backend would hardly be implemented in HTML/CSS/JS.

What language/technology will be used to create the restaurant's Web site?

Rob Crowther wrote: "What's stopping you joining the whatwg mailing list and telling them what you want?"

I had direct contact with the key people behind HTML5 on mailing lists and various blogs over the years. Unfortunately, from my experience and comments from others, they are not interested in your opinions unless you take a pledge of allegiance to the HTML5 design principles. And even then the environment in which HTML5 is developed is not really open because your ideas are not given equal consideration with browser vendors. Ian Hickson, the editor of the HTML5 spec wrote:

"The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don't implement it, the spec is nothing but a work of fiction."

The browser vendors see themselves as the real citizens of the Web, with the rest of us are just visiting. I would like to see future Web technology designed in a real collaborative effort.

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.