Comments on HTML's Time is Over. Let's Move On.

Pat Connolly — Tue, 28 Aug 2007 00:38:49 GMT

While HTML may, or may not be nearing its end in terms of usefulness, the discussion of Macromedia Flash as an application development tool is lacking in its originality.

Flash was undoubtedly originally developed as a linear animation tool. However, with the development of Flash MX, and a little outside the box thinking, the possibilities are endless. While Flash works directly with J2EE, .NET and ASP, there are endless other opportunities, including Cold Fusion. As long as you can develop a dynamic content page with any application server, you can pull those variables into Flash, which creates a robust application environment.

While Flash may be linear in nature, the introduction of extensive action scripting with the manipulation of timelines and content through variables creates an application that is as successful and impressive as the person that developed it….it just takes some talent and a little imagination.

David Heller — Tue, 28 Aug 2007 00:38:49 GMT

This is great. I really wanted to provoke a discussion like this, in this community very much so. That being said I want to comment on a few of the comments that have been said thus far (and maybe provoke some more).

Just to clarify, I am talking about application development. Publishing is still and will still be a great thing to do in HTML. Why the heck not? Especially b/c HTML and XML work so darn well together. As a CMS person I understand that more than most.

1. Flash – Anyone dismissing Flash out of hand, does not know flash anymore. Flash MX changed all the rules. Also, I did say that it can’t be taken seriously until they improve the development environment so that it performs better for programmers. They may have to split the UI into two. This is something that the folks at Norpath have actually done quite well.

Sub points on Flash. Flash MX works with JSP, .Net and even ASP appserving environments. It will even run directly from a J2EE environment.

2. .Net is many things and MS has been doing a wonderful job of confusing people about what it is and promising a lot more. It will have its own UI environment, but that UI environment is just really a marketing scam replacement of VB. It will only run on Windows. The only difference is that it will communicate via .Net protocols.

3. XUL – The concept is very sound, but from what I was told and from what I’ve seen, it is window dressing only. The content of the applications that it supports still require DHTML to funciton. I’m still stuck using the same limited widgets as before. G-d! I would just kill for one HTML combo-box.

4. Standards-based HTML – What standards? Who’s standards? What browser? I could write code that is completely standards compliant and I get 2 things: 1. less functionality b/c it doesn’t support as much as the browser say they support. 2. pages that look differently in various browser/platform sets. Standards compliance is a myth for anyone wanting to get more than a publishing environment out of HTML.

5. Did I say “broadband”? I think I said “bandwidth”. I never meant to imply that broadband should be required. What I was suggesting was that applications that are attempting to be ported to this environment have severe bandwidth issues. Anyone who has worked in a CMS based on the web will realize this once they transfer their first PSD file over a modem so that it can be converted by the server using a digital asset management program, or somone using a DMS that takes care of PPT files and is constantly transferring the documents back and forth for editing.

What I was really trying to refer to though is the display of large sets of data with much metadata associated with each “row”. The more intelligent you want your navigations to be (actions as well) the more metadata you need to port w/ each row. Thus you need to reduce HTML wherever you can. In our case we can’t use ID tags along w/ class tags and this severly limits our ability to differentiate efficiently styles.

Ok, I’ll stop there for now … I hope the discussion ensues here. I also want to propose that if there are enough people interested in Web application development that we start our own community. For now the bulk of what we do will continue to be in HTML, but I would like to see other environments spoken about too. Any takers? == dave

PeterV — Fri, 26 Jan 2007 14:51:09 GMT

I liked the article by the way. Nice overview! Only oversight seemed XUL.

PeterV — Fri, 26 Jan 2007 14:51:09 GMT

I agree with the ‘HTML doesn’t do apps’ sentiment. Not to say it can’t do it, it just isn’t an efficient way to develop stuff. The problem is: Flash isn’t either. I think the main reasons for that are:
- Flash only recently got a decent programming language
- the development environment for Flash is based on the animation paradignm (timeline, ...) Macromedia should build a developer development environment for Flash if it wants Flash to take the thin app space.

Mary Deaton — Fri, 26 Jan 2007 14:51:09 GMT

Of course HTML is still usable for many things, but the point of the article, I thought, was application development, not Web page development. Applications are interactive and do more than call up information; applications let people create things or change things. While I am not immediately going to go out and learn Flash as a result of this article, it seems very valuable to the profession to be looking ahead at what might address the limitations of the current tools. Even if the alternatives are not fully baked, we have to keep testing them until they are ready to come out of the oven.

It is critical that in future versions, the browser and the contents of the browser not ignore each other. Both the Mac and Windows allow the application developer to leverage the functionality of the OS and the browser needs to offer that same sort of leverage.

Futhermore, the browser itself needs to be more aware of what operating system it is running under and feed that information to the content layer.

Which is not to say that browsers should run under only one operating system. Oh, no. If IE has a function that is worth having, then IE itself ought to figure out how it is going to run that function on a different platform, rather than simply say, Sorry, you cannot use this function because I do not like you.

Matt Johnson — Tue, 28 Aug 2007 00:38:48 GMT

HTML will go away once everyone in the world has a T1 line.

Flash will go away before HTML. HTML is needed to make .Net, Java, and other server side technologies to work with the client. Even though Macromedia hired Mr. Nielsen, Flash is still over 90% unusable.

ct — Fri, 26 Jan 2007 14:51:09 GMT

“Ultimately, I donÕt see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing”

What about Flash then? It is a misapplied tool that was never meant to be used for anything other than animation. All technologies have (dis)advantages, so we’re always deciding which one is the most appropriate for each particular job.

Where DHTML or other web/based applications fail, desktop-based software is usually the best solution. It may present cross-platform compatibility problems, but this in many cases is not an issue when a company has already standarized on a particular OS.

Jamison — Fri, 26 Jan 2007 14:51:08 GMT

We also can’t ignore the 500 pound gorilla in the room: Microsoft. Their .NET platform is also a way to develop thin client applications (both within IE, with ASP.NET, and on the desktop with small .exe files that connect to servers)

Microsoft’s version of DHTML and their VB Script languages aren’t a crossplatform solution, but as it stands now, there is already a movement to using Microsoft IE and IIs to deliver internet-based applications.

...as for HTML. I do not see HTML’s time a ending. Yes, there are a lot of places were HTML just doesn’t scale to (chat is one web app I often see Java used for), but there are many web applications it works very well for.

Web based e-mail is a good example. While it’s true that Java, Flash or one of the other alternatives mensioned would let us develop more robust interfaces, it would no longer be accessible anywhere (from a laptop running Windows XP, to a PalmPilot with a wireless internet connection.

HTML is not going away. As andrew points out, most of the web is still just text, and a lot of issues with HTML are solvable (one I see all the time, is large chunks of javascript used to detirmine the browser and then render correctly for it, when the browser could have been detected on the server and then only the appropriate code sent to the client), and all the discussed tools have their own place for one purpose or another.

vanderwal — Fri, 26 Jan 2007 14:51:08 GMT

There are too many stones missing in this article to get me across the stream (a metaphor an English professor always chided me with). There are some errant statements in this article also, such as the Netscape 6/7 and IE 6 browser’s vast differences, which we know if one codes to W3C standards will be minimal. The use of JavaScript in the DHTML argument can provide problems as this is where differences lay, not in the HTML/XHTML. While on the XHTML topic the XML Event is on the W3C HTML Working Group plate and may address some of the missing elements discribed in this article.

The article was missing any reference to why we would need to move beyond HTML as an example. I have worked building Web browser based applications over the past 6 years and have found some limitations, but there are many different desires for applications. I have been part of teams that had dynamic interfaces that allowed the user’s to select data from disparate sources and run analytics on this newly combined data source, then the user could also see the results of the analytics in charts or graphs or Dynamic maps that all ran in a Web browser running DHTML.

There is some nice functionality that can be gained from DHTML or Flash, but it is no where near driving anybody to making the bold claim in the title of the article.

One argument was broadband. Broadband for data access? What poor application is being run here. Broadband has its purpose, but using it as a means to create a better interface points to poor interface development for data. Another mis-step was accessability as properly marked-up HTML is one of the best methods of making information accessible and usable.

Accessing the desktop is the most worry worrisome element. The Web browser is nice because it allows access to information that does not depend on my operating system or requires me to download an application that may have a security hole that provides access to the whole of my information. Being able to download datasets based on a standard allow me to process the data in Quicken, Money, or some other tool that reads the standard data format.

Groove as an example is a perfect example. Groove made use of XML and browser components to add functionality not available in other applications. Groove is nice and offers functionality few competitors provide. The problem is it does not run on my strongly preferred operating system. Had Groove stayed with a more standards compliant front end to their application rather than closing it to Microsoft only or selected an interface that ran on all operating systems I would still be a devoted user.

This article could use a serious rewrite to make it half way convincing.

Andrew Otwell — Tue, 28 Aug 2007 00:38:48 GMT

The URL seems to have gone from that last post. The article on ftrain.com is

http://www.ftrain.com/archive_ftraintwo_15.html

Andrew Otwell — Tue, 28 Aug 2007 00:38:48 GMT

Paul Ford, over at ftrain.com, happens to have just written a really nice article about considering a geneology of computers which among other things touches on why deterministic technology ideas like “we need a new standard format starting now” don’t work.

John S. Rhodes — Fri, 26 Jan 2007 14:51:09 GMT

“Ultimately, I don’t see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing.”

Few people would argue about the first sentence. Of course HTML isn’t meant to be used as an *application* development solution. That isn’t a very spicy idea.

The second sentence is more interesting. While *you* might feel that it is a “misapplied tool” I would bet that many of the folks doing the misapplying would not agree. People use tools as they want to use tools. A hammer used as a screwdriver *can* turn screws. (I’ve done this.) People use what you give them. It simply doesn’t matter that some people don’t want other people to bastardize HTML—they do, and they will.

Andrew Otwell — Thu, 27 Mar 2008 17:32:25 GMT

David, don’t forget that the majority of “stuff” moving around on the web is basically still text and images. For many IAs, HTML is and appropriate and effective way for organizing and displaying that content.

”...the time has come to create a new system that is low bandwidth, utilizes a single code base for all platforms, and is componentized enough to make updating and customizations easy using internet-based distribution.”

Sounds great, let me know when the software industry and human nature allow this for *any* technology segment. Telecom hasn’t done it in a much longer period, even consumer electronics have barely managed to accomodate standardized remote controls.

Considering that just displaying HTML is a fairly straightforward task, even the browser makers haven’t done too well, as you mention. Who do we entrust with a truly long-range idea like yours? Realisticly, it would have to be Microsoft, given the difficulty of designing, building, marketing, and killing-off of competing standards that would be needed.

Jess — Tue, 28 Aug 2007 00:38:48 GMT

Also needing mention is XUL, Mozilla’s Extensible User Interface Language. Mozilla’s UI is built in XUL, as are quite a few applications now (there’s even a nice O’Reilly book).

cheers,

Jess

H. "Teepee" Get — Fri, 26 Jan 2007 14:51:08 GMT

Another tool/technology worthy of mention: Rebol

http://www.rebol.com

Similar in some ways to Curl, Rebol lacks an IDE, but it has a pretty solid cross-platform, tiny-footprint interpreter. Rebol is useful for batch processing, CGI and development of network-aware thin-clients.

If they decide to put the needs of mainstream users ahead of eccentric developers and fringe OS zealots, they might emerge as a serious contender.