In 2002, I wrote an article in CoDe Magazine regarding the diminishing importance of HTML. In that article, I prognosticated that HTML would be slowly on its way out to be replaced by richer technology such as Web services and other distributed mechanisms to deliver rich connectivity to more traditional desktop applications that could even be delivered through browser interfaces. The technology to make this happen actually arrived shortly after the article through Web deployment of .NET applications, and more recently with ClickOnce support in .NET 2.0, which improves the deployment model considerably. However, this model has not taken off in any significant measure either in public-facing applications or even in intranet scenarios. So here we are now in 2006 and I can say that I was overly optimistic.
While distributed technology has made some inroads with better tools, HTML continues to be the king of the hill when it comes to the dominant application development platform. And Web standards have barely changed since the turn of the century, leaving developers stuck in a Web development stasis. HTML continues to dominate the application development scene. This is even truer now with the recent re-discovery of technology that now has become AJAX. The AJAX hype has sparked a lot of new attention on the Web platform because it allows some limited desktop-like distributed functionality inside of the browser itself. Ironic, isn’t it? The Web platform is trying to become more like the desktop and succeeding much more rapidly than any desktop technology did. But interesting as AJAX is-it’s really old technology and downright antiquated and a hack when you compare it to full-blown distributed technologies available on true distributed platforms like .NET or Java.
Stasis on the Web
Isn’t it interesting that the technology that has been the bread and butter for so many developers for so many years has been in stasis for so long? As ASP.NET developers, we sometimes forget that the underlying platform hasn’t changed much because there are so many new features-server-side features for the most part-that keep ASP.NET developers busy learning and understanding the server-side technology. But let’s not forget that the underlying HTML and its limitations are still there and haven’t changed. In one way it feels like we’re building bigger and bigger houses of cards on top of a very basic platform.
A great example of this is Atlas, Microsoft’s recent AJAX platform. Atlas is a very ambitious project that tries to bootstrap on top of the browser to provide a richer experience for developers. It succeeds to a large extent, but if you take a look at the implementation you find a massive amount of code to work around the core issues in the Web client-side platform. It’s scary to think that the technology we work with every day requires so many workarounds and hacks that are specific to browser implementations, JavaScript quirks, and who knows what other unpredictabilities. Hats off to Microsoft (and other client side framework vendors!) that attempt to even the score, but it’s a crying shame that this sort of thing is necessary in the first place. Functionality like what the Atlas client-side library provides should be native to the HTML platform and not have to be implemented through script code as application level code-this sort of thing belongs in the platform itself.
If you look at the Web-related standards-HTML DOM, CSS, and JavaScript-you’ll find that not a lot has changed since the year 2000. The HTML of 2000 doesn’t look a heck of a lot different than the XHTML or-more likely-HTML 4.01 we use today. In 2000 JavaScript was at version 1.1, and it hasn’t seen a lot of enhancements in the 2 ‘dot’ releases since-we still have a somewhat quirky yet fairly usable language to write client-side code. And to this day we continue to have the same sort of browser incompatibilities when it comes to HTML, DOM, and CSS interpretations by the browser vendors.
But more importantly, we’re still looking at a terminal-like interface inside of the Web browser. There are only seven input controls (Textbox, TextArea, Button, CheckBox, Radio, Select, FileUpload) supported in HTML. Think about that for a minute: seven input controls! These controls are very basic and, in order to provide better input, we continue to have to reinvent the wheel over and over and continue to generate mountains of repetitive HTML, to *simulate* functionality that we take for granted in a desktop application.
How many times have you built a Web application and wished that you had a drop-down list box or a list box that has multiple columns? Or how many times have you mucked around with DHTML logic to build a custom tree-like display? How many times have you tried to create reasonable editing functionality (even if you use a third-party control)? These are *common* usage scenarios, yet they’re not addressed directly by the platform you are using, instead getting addressed with often complex HTML markup and script code.
It is true that server-side tools can often help you generate this kind of “control” markup for you by creating hideous amounts of HTML and script code, but this begs the question-if this is such a common scenario: Why isn’t that sort of thing built into the browser in the first place?
Here are a few controls that I’d like to see supported natively in the browsers: ListView, TreeView, Html Editing, Date Time Selection, Tab Control, Menus. How about a standard model to host XML data inside of the page similar to IE’s non-standard Xml Islands? How about a client-side databinding mechanism for controls? I’m sure you can think of a few of your own.
Many of these types of controls would be relatively easy to implement at the browser level because most host operating systems natively support these controls in the first place. And to top things off, new controls wouldn’t interfere with existing controls, so backwards compatibility could be maintained. Yet we’ve seen no real improvements for many years.
Imagine what you could do if you had rich controls like those I suggested. You would have more control over creating your user interface than you have with today’s cranky and non-standard implementations. In addition, these controls would require less code generated on the client and would perform better with a large amount of data.
Along the same lines, one of the big requests in browser applications is support for better drawing and graphics abstracts to provide a richer experience right in the browser itself. This is the domain of Flash today, and if your solution requires anything rich-fancy graphics or slick animations-it’s not likely you’ll do that sort of thing in HTML. Granted, Flash and Microsoft’s new Windows Presentation Framework (WPF) are huge platforms and you could never mimic them with incremental improvements in the HTML DOM model, but why aren’t there at least more graphics primitives and basic animation features provided in the DOM?
Today developers use HTML in ways that the original design never really called for and we continue to shoehorn our applications into this limited interface. This is good business for tool vendors who can continue to sell complex HTML-based controls to simulate a richer interface. But it’s bad business for the rest of us who keep reinventing the wheel with non-standard code and hacks and workarounds over and over again.
The point is this: We shouldn’t have to simulate-some of this functionality should simply be built into the browser.
Do You Really Want a Richer Browser?
The counter argument against richer functionality is that the current HTML standards are simple and easy to learn and work with. Today’s browsers have enough problems implementing the standards consistently. Adding additional, potentially more advanced features would only make browser compatibility even worse.
The current Web formats that developers use are based on standards, and many argue that standards are the most important thing developers have for the Web platform. This “standards über alles” mentality is actually quite common these days and gives voice to the sentiment of developers who yearn for a consistent platform. Yet, standards and all, we still have many compatibility problems. The HTML DOM implementations of the major browsers still vary considerably and that means developers must write hack code to make client-side markup and code render and run reliably on various browsers. In my Web development work I find that browser incompatibilities of one sort or another easily account for 10-20% of the time I spend on Web development. And it’s been getting considerably worse recently as I work with AJAX technologies that require more client-centric UI and code.
There’s something to be said for simplicity. I think much of the acceptance of Web technology has come from the fact that in many ways it’s easier to build simple Web applications than desktop applications. Desktop apps with their complicated UI layers and fully event-driven interfaces can get very complex very quickly. By adding rich controls to HTML it’s possible to think of the HTML platform becoming more like a desktop platform with the same sort of event model and therefore getting more complex.
From my perspective though, a more complex but more complete browser implementation would be a good thing, especially if it can (and I’m sure it can) be built incrementally on top of the existing standards without breaking backwards compatibility. The complexity wouldn’t affect the initial “getting started simplicity” because any new features would be built on top of the existing platform. If developers want to build rich client-side Web applications using technologies like AJAX and whatever it will turn into, the first step is to provide a richer platform on the client. This means better programmability, better controls, better interoperability, and let’s not forget better development support (decent editors and debuggers especially). We can only hope but the truth is that my expectations for this to happen are not high.
Standards
Standards are obviously important and we all benefit from consistency. However, standards matter little if vendors don’t actually implement them correctly or consistently. Currently there’s no official validation of browser standards. The various browser vendors make little or no effort to try and fix their implementations even if problems are known. Microsoft has been the worst culprit here with Internet Explorer having many standards-compliance issues. Microsoft never bothered with the criticism that IE isn’t standards-compliant because it simply could get away with it being in the dominant position it has been for so many years. Luckily this seems to be changing, at least a little, with IE 7 providing some relief for browser standards in the IE platform. This seems to be mainly driven by the steady erosion of IE marketshare driven by end users and even more so by developers migrating to other browsers like FireFox. Microsoft is also once again moving into a more Web-centric view with its own products and I can only guess that Microsoft’s own developers would prefer a more compliant environment to work with themselves, which hopefully may result in some internal pressure to fix IE.
It seems a shame that these issues can’t be addressed in a reasonable manner. If we are to have standards there should be a standards body responsible for the validation of these standards and how they apply to the major vendors. Maybe there should be a verification process with a seal of approval or certification with a World Wide Web Consortium (W3C) compliant logo on browsers. If there was official testing and validation, there could also be an official location to check for compatibility issues in a public place that in effect could be used to shame the browser vendors into fixing their problems. Nobody makes money by selling their Web browser, so vendors use the browser as leverage to push their corporate (or open source) agenda. Since there’s no bottom line, getting companies to agree to verification or any other sort of scrutiny seems highly doubtful. There is simply little to no incentive for vendors to improve browsers other than to “buy user loyalty” to a particular vendor’s platform by providing a browser that at least offers the same basic functionality that other platform vendors offer.
In an ideal world, the major browser vendors could get together and agree on how to implement the standards. Many of the browser incompatibility problems stem not from a vendor maliciously disregarding the specs, but vendors misinterpreting or simply implementing the various standards differently.
Consider the CSS implementation, which is fairly out of whack between the various vendors. No one vendor implemented CSS exactly the same way. At the end of the day, most vendors are not following the standards on many little things or interpreting the standards in non-standard ways. We’ve surely all done this: You work on a piece of code in one browser and then you check the code in another browser and find the behavior is completely different (example: overflow behavior on containers). Usually it turns out that browsers don’t follow the same spec but interpret somewhere in the middle. All vendors should implement a common set of default values as specified per spec. Many of the formatting options start with different defaults so it’s often difficult to get consistent designs without setting every possible obscure CSS style to get a consistent default. Using CSS shouldn’t be this difficult.
Building a standards-compliant browser is no small task, but the browser vendors dedicated to building these browsing engines should have no problems finding the resources to fix these issues and at least make an effort to shoot for close compatibility across the board.
Ah - one can dream.
Lack of uniform browser support hurts all of us. End users, developers, and even the various browser vendors have to live with the flawed browser model implementations in their own HTML design as well.
Innovation Is Dead
Many people love to point fingers at Microsoft for being non-compliant and stifling competition, yet at the same time you have to give Microsoft credit that back in the day, Microsoft was actually driving Web technology very hard. Internet Explorer was the first browser to support DHTML-including proprietary extensions unfortunately-that eventually found their way into the W3C standards. IE 5 also introduced one of the most useful browser features, HTML behaviors, which provided a mechanism for extending browser operation in many ways that sure looks attractive in this age of stasis. But unfortunately this feature never got much attention.
Microsoft also created the XmlHttp object way back in 1998, which is now the basis for AJAX technology and has now, eight years later, been drafted for inclusion into the W3C standards. Amazing-eight years later! In a knee jerk reaction, the W3C goes out and accepts a draft of a technology as a result of the technology taking off on its own without standards approval. This gives you an idea of the amount of stasis that we are facing in Web standards!
Think about it. What other Web/HTML/JavaScript features in the last five years can you think about that made you sit up and exclaim, “Wow this is cool!” and “I can use this right away.” Most of the improvements we’ve seen over the last five years have been minor tweaks and adjustments in the CSS standards, but beyond that there’s a huge void of innovation.
All of the innovation that is happening today is trying to work around the limited HTML model. This takes the form of sophisticated server-side frameworks like ASP.NET that generate complex HTML for you and client-side libraries that sit on top of the existing browser model and provide the semblance of a stable and consistent object model.
Since the turn of the century-a lifetime ago it seems-Microsoft has been resting on its laurels, riding out their browser dominance in typical Microsoft fashion: Get to the top of the heap and then squat. Microsoft, who had been the major driving force for improvements, decided good enough is good enough and nothing has changed since. Mozilla was sidelined due to a disastrous complete re-write that went years over projected dates and browser innovation got stuck in a complete no-mans land.
It’s easy to point at Microsoft as a target, yet the other browser vendors surely haven’t offered any progressive thinking. Mozilla took years to get ready to ship a product and it’s only now in a position to actually start thinking about pushing new technology. Nowadays, when we’re talking about browser innovations, it’s about how you can manage your favorites and tabbed browsing hotkeys as opposed to language improvements. It’s a shame because in terms of usability, the latter probably has much greater effect than the superficial application improvements.
I think the standards have hobbled us all. Nobody wants to do anything new because doing so would not be standards compliant. But standards can’t move forward if there’s no forward thinking or experimentation. It’s the typical chicken and egg scenario where you can’t move forward until there’s a standard, but new standards can’t be created until there’s some experimentation or formulation of new standards. We’re frozen at a standstill.
The W3C isn’t a forward-thinking body. The W3C requires proposals to come first that then get adopted into drafts for review. But unless there’s experimentation, nothing gets done. So the question is, who does it fall upon to think up improvements for the future?
In the end, this is where proprietary solutions come about. Mozilla has XUL which is pretty slick but has been largely ignored. There are a variety of user interface JavaScript frameworks out there that are nice but monolithic and fairly difficult to use because they are implemented through JavaScript code. Microsoft is building the Atlas client framework, which is Microsoft’s way of extending within the confines of standards to avoid incurring further damage to Microsoft’s image as a proprietary vendor. I think we cannot count on Microsoft to innovate in the browser space anymore either and probably for good reasons. All of these solutions are punting-stopgaps and workarounds-when the real solution of improving the original Web standards is not being addressed.
WinForms, WPF, and Flash
Several vendors have made attempts to build new, richer standards that can run inside of the browser such as Mozilla’s XUL and Microsoft’s new XAML, but I don’t see these heading towards universal acceptance like HTML. I would love to see XAML take off because it will offer developers exactly the functionality they need to create richer browser applications. It has the kind of forward thinking necessary to move Web application standards forward. But XAML comes from Microsoft so I think it’s doomed from the start as a broad reach platform on the Web. The anti-Microsoft crowd will never take to it and this crowd seems to be growing. In addition, it’s not based on HTML so it’s too different for continuity. I’m sure XAML will have some limited success but I don’t think it will be an HTML-killer on the Web.
I think it’s always interesting to have discussions between desktop developers and Web developers. Desktop developers tend to look down on Web developers for the limited UI that is available. While you can build Web applications that have the rich feel of a desktop application with highly interactive real-time interfaces, it takes a lot of work to make that happen. And in most situations, rich Web applications try to simulate a desktop-style interface anyway.
Today Microsoft’s ClickOnce technology allows you to run Windows Forms applications and provide the same deployment model that Web applications enjoy and still that technology gets ignored-even for internal applications. Users have a real need for richer applications and I run into many situations as a Web developer where customers ask for features that are simply difficult or downright impossible to build using a Web interface. A desktop application or other rich application can and is often a much better fit. Many people push for Web interfaces when a desktop or rich interface would be a much better choice.
For better or worse, it seems as though HTML and standard Web interfaces are the only “approved” way to deliver applications. Mechanisms such as WinForms using ClickOnce or Web deployment, although viable in many situations, are often tossed out as options simply because Web applications are considered the de-facto standard. Habit wins over utility almost every time.
The bottom line seems to be this: If it’s not part of the raw HTML Web standards or an extension thereof-it’s not going to be a serious player for the broad reach Web space. Many have tried but none have succeeded.
No Easy Answers
I don’t pretend to have the solutions to these issues and aspirations. Heck, it is really not up to every day developers. The browser vendors and the W3C folks hold the keys to improvements and neither are easy to influence.
My focus with this editorial hasn’t been to answer these issues but to inspire some thought about what developers want the browser to be in light of the application platform that it has already become, and the distributed application platform that it appears to be becoming with the acceptance of AJAX/Web 2.0 technology. Ask yourself whether you would like to see a richer browser environment or whether you want to go on using 1970’s technology to build your user interfaces. And if you think that change is needed, make some noise about it. Ideas and communication are important because stagnation is best overcome by discussion and inspiration, which comes from new ideas or simply reawakening an old but good idea. Hey, just look at XmlHttp… it can happen.
