TSS reader Shabbir Hussain sent in a question: Don't we feel that HTML is too old and we should have a proper language for the browser? It's not clear what a "proper language" would be - or how adoption would progress - but it's an interesting question.
Here's his basic premise, slightly edited:

In the last few years, there have been a lot of new ideas around creating rich internet applications. So many technologies, so many frameworks, and so many buzz words. Why is the industry not coming together to create a better language for the browser?
Don't we feel that HTML is too old and we should have a proper language for the client side?
Why do we need to write the presentation logic using separate language? Bandwidth is not a major issue, so downloading a few more lines of code on the browser is not a problem.
We need to think out of the box, beyond HTML, DHTML, CSS, JavaScript and their marriage using various framework and coding standards. We have to start thinking about making a language for browser that will have the power of all the above and is native to the browser.

Hmm. It's not an entirely new idea - see XUL for a similar thought about addressing the browser as a base platform, although XUL relies on Javascript as well.
The existence of XUL and the work on HTML5 (wikipedia ref on HTML5 - is it a good sign when the draft pages for HTML5 nearly crash Firefox?) are, perhaps, good ideas but not far-reaching enough. It's worth stopping and looking around sometimes just to make sure you're headed in the direction you want to go - What do you think about Shabbir's proposal for a complete restart? What would accessible and text-mode browsers work with, in a world where active content was the norm?

HTML/CSS is a language for marking up text. As such, it is fine when used properly IMHO. Misused and, like anything, it becomes horrendous. However it + javascript has become the main language for browser-based applications (which is a different problem, for which it wasn't really designed. XUL or Flex solve this better.
I think I would like to see standardisation in building UI components out of HTML elements, and providing them with a usable & standard javascript API.

Over the years java has degenerated into a huge mess capable only of keeping armies of programmers employed to do very little. It has gone from the best language to by far worse than anything even imagined. A testament to the stupidity of programmers.
Javascript should be replacing Java. It is the premiere language with libraries like J-Query , Prototype, etc. changing the way the Web works. Let's hope Java dies a sudden and decisive death soon, and languages like Javascript move to the server.

Over the years java has degenerated into a huge mess capable only of keeping armies of programmers employed to do very little. It has gone from the best language to by far worse than anything even imagined. A testament to the stupidity of programmers.

Other than being pure flame bait, what exactly is the point to this? Who said anything about Java? The article and discussion is about HTML and JavaScript. No one (that I see) suggested using Java as a replacement.
Are you saying that Javascript can replace Java in all contexts or are you talking about web apps only?

Javascript should be replacing Java. It is the premiere language with libraries like J-Query , Prototype, etc. changing the way the Web works. Let's hope Java dies a sudden and decisive death soon, and languages like Javascript move to the server.

We tried this back in 1999.... I think people got tired of dealing with millions of lines of un-refactorable javascript code on the server and the client sides.
Have fun walking down that road again.

Javascript should be replacing Java. It is the premiere language with libraries like J-Query , Prototype, etc. changing the way the Web works. Let's hope Java dies a sudden and decisive death soon, and languages like Javascript move to the server.

We tried this back in 1999.... I think people got tired of dealing with millions of lines of un-refactorable javascript code on the server and the client sides.

Have fun walking down that road again.

Do you know you can organize JavaScript into classes and put each class in a file and use build script to assemble all classes into a big file?
It always a design issue, no matter what language you use. I designed an application with all the related JavaScript functions in classes and that application is even faster than the old application in client/server architecture.
It is fun to write beautiful code.

I have hoped something like that would happen for years. HTML is fine for websites that are mostly documents. But for browser-based applications it is often annoying because of its limitations. JavaScript often seems like a workaround for HTML's limitations. I'd love to see some new development in this area.

Hehe....We're having a hard enough time just trying to get microsoft to focus on implementing the standards out there now (no they don't implement most of them very well yest) - let alone new ones..
I may be a little cynical but have to imagine that microsoft is the idea-killer of the day....Still the thought has merit, it has occurred to me before but thinking something new is needed and actually knowing what "it" is is entirely different...

I have hoped something like that would happen for years. HTML is fine for websites that are mostly documents. But for browser-based applications it is often annoying because of its limitations. JavaScript often seems like a workaround for HTML's limitations. I'd love to see some new development in this area.

I'm almost absolutely positive that someone has already designed such a language. The problem isn't building a better language, it's getting browsers to understand it. It's not a technical problem, it's a logistical one.

As evidence of what you say, the W3C has create a number of upgrades and substitutes for the kinds of HTML we typically see in the wild - XHTML, XForms, new versions of HTML, etc., but it doesn't matter if they are better, cleaner, more modular or more efficient if our "customers" use browsers that don't support them without resorting to plug-ins.

As evidence of what you say, the W3C has create a number of upgrades and substitutes for the kinds of HTML we typically see in the wild - XHTML, XForms, new versions of HTML, etc., but it doesn't matter if they are better, cleaner, more modular or more efficient if our "customers" use browsers that don't support them without resorting to plug-ins.

Well getting people to simple move to proper XHTML would be a huge deal, especially for spidering and 'mashups' (I hate that term). But even that hasn't happened.
I guess it's possible a new language could be created along-side HTML but it would not be used until IE added support for it going back to a point made above. And the problem there is getting MS to support a standard as it is defined.

First, let me say that I've never used Flex but I think Flex is a poor direction for for the future of web development: it's based on proprietary technology (Flash), it's just more XML with a bunch of nested CDATA Javascript (yuck!), it has different bugs running on the exact same browser running on different OSs (more testing fun!), and it has to download a ton of data to the browser to generate those nifty rich interfaces.
I'll pass, thanks.

I think you meant the "DOM" - javascript is fairly stable across most browsers.

I think both are stable. There are a lot more difference between browsers when writing javascript applications then just DOM, in error handling, xml parsing, etc. In some cases the problems are not just cross browser, but even different versions of the same browser. There are entire books out there dedicated to writing cross platform javascript code.
Plus there are many browser differences with respect to CSS that are not an issue with Flex.
In my experience writing RIA in both Javascript and Flex applications I have found that I have to write less workaround code in Flex the Javascript. This doesn't mean that I think that Flex is better or more stable then javascript I just don't agree that it is less consistent.

I didn't say across browsers. I said on the SAME browser running on different OSs. So no, Flex is less consistent.

I didn't say that you did. But I disagree with your point that Flex is less consistent.
My applications are littered with extra javascript methods and code blocks to handle differences between browsers (ajax, dom, error handling, etc). In Flex I more often run into differences between operating system not browsers. They are both inconsistent, just in different ways.

I think Flex give the direction to us that how rich the client side language can be. But if we dream of client side language then it should not be XML based language and we will not need any other scripting language for client logic.
Though I have not used Flex but yes I believe RIA will better severed using Flex rather then integrating bunch of technologies.
Thanks,
Shabbir

But if we dream of client side language then it should not be XML based language and we will not need any other scripting language for client logic.

The XML in Flex is optional. The primary language in Flex is ActionScript 3, an implementation of the ECMAScript standard. ActionScript is very much like the Java language. The XML language in Flex is a declarative language on top of ActionScript. You can use it where you want or not at all. Ultimately the XML gets translated into ActionScript by the first stage compiler in Flex.
-James

Is "Flex" open? HTML isn't controlled by one company (you can argue Microsoft). I thoguht Flex was controlled by Adobe. I don't think any one commerical entity will be able to control the next "big thing".

The answer is yes, we should have something new/better/at least less suck. So why don't we? There are two big reasons.
First, there is the success of HTML 4/JavaScript 1.x. The Internet is big business and it is a big business based on HTML 4. Imagine if you wrote a Java library that had several billion users. It would be pretty hard to change the interfaces of that library or remove deprecated APIs. Heck it's hard to do those things with just a few dozen users.
Still, one could certainly add to HTML 4/JavaScript 1.x. It is harder to do but still possible. HTML 5/JavaScript 2 is exactly that, but one could easily imagine going further. However even HTML 5/JS 2 are seriously constrained by Microsoft.
Microsoft has always had a conflict of interest on web standards, since their main business is desktop software, not web software. At the same time, they essentially own the web standards because of the continued domination of Internet Explorer.
Actually if history tells us anything, it's that web development is about to start getting a lot harder. Web development advanced when browser technology was stagnant. That may seem counter-intuitive, but you really need browser stability to allow for developers to innovate (think AJAX.) Stagnant browser technology really means no new versions of Internet Explorer. Now we had IE7 and IE8 is on its way. Greater browser variation will only make it harder to create web applications, and we will once again have to take least common denominator approaches.

Its not the UI or language ( HTML/Javascript ) thats the problem with WebApps, its the 'Operating System' they execute in. The Browser just doesn't provide enough services to promote really compelling applications.
I mean come on, no Threads :-)
Google Gears is a step in the right direction with Threads and persistence/DB.

I have a feeling that XForms will take over are the main stream UI interface engine in the future. It is structured strongly and it has a clear separation of display and data. There are very few UI markup languages with this level of sophistication.
Imagine XForms , a GUI wizard and a Rules Engine , you don't need a single line of "hand-code" :)

I always seem to be replying to these posts with the same statements.
We may never get to the holy grail client side technology for the web for all use cases, but the technologies already exist to solve the common client side implementation issues. The key is knowing which technology to choose based on the usage context.
HTML and JavaScript have their place and I don't see them going away anytime soon. The most appropriate uses for HTML on the front end are for presenting documents/documentation and for the implementation of Transient WWW Applications like Amazon (JavaScript to fill the gaps). In the case of Transient Applications, you'll obviously need to provide server side support by implementing the back-end in whatever language or platform you like. The same argument goes for other WWW Client Side Techs like Flex, Flash, etc. The main advantage here is not having to worry about deployment/delivery of the front end to the WWW users.
In a more controlled environment like on an intranet, your options for implementing the front end gets better based on the techs you can use here. Most developers want to be as productive as possible and not have to deal with the familiar soup of client techs like HTML + CSS + JavaScript + Whatever else and use one or as few techs as possible. Many technologies have been developed to fill this need such as (Swing + Webstart), (OpenSwing + Webstart), GWT, Silverlight, etc. They also give you more power and flexibility and provide you with the ability to implement heavy use online applications where desktop like performance is expected. Note that I said applications, like in business class applications. Making deployment easy is also a main focus of these techs.
It all comes down to knowing your tech, knowing what's out there and when and where to employ their appropriate use. As developers, we'll always have to exercise this level of due diligence. I like the directions the latter mentioned technologies are taking. I don't like fiddling around with a hodge podge of languages to get the simplest of applications implemented. Productivity, power and ease of use is what I tend to go for.

Libraries like J-Query make it possible to script Ajax GUIs in a few hundred lines of code.. It totally dominates Swing, XUL, Flex, JSF, and JSP. It is breakthrough and people like John Resig and Douglas Crockford are the James Gosling's of today. Unfortunately Java, and just about everything related to it makes productive programming next to impossible.. Java, and especially J2EE, have eveolved into ways to accomplish very little, very slowly..

@Joseph Ottinger: Hmm. It's not an entirely new idea - see XUL for a similar thought about addressing the browser as a base platform, although XUL relies on Javascript as well.

Too late. Many years ago I was dreaming about a new way to develop desktop applications: FireFox + Java, but Mozilla guys never were interested on Java, neither Sun.
Gecko based development is extreme: or C++ (to develop XPCOM components) or JavaScript. JavaScript is weak, C++ is "too strong", poor as platform and not very much portable (and not portable "out of the box" as Java is).
XUL based applications are almost ever JavaScript based. JavaScript is fine for small applications but with applications with very much code (and a large team) becomes a nightmare. And JavaScript is slow, very slow.
May be XUL cooked on the server in Java, but this thing is already "invented", tons of custom tag based Java web frameworks are doing this kind of programming (but in a poor way because custom tag content is not fully managed by developers as a FireFox developer can do with XUL and JavaScript).
We don't need more tags (XUL approach), we need SVG and canvas on any browser because on demand image generation from the server is a dirty hack. Today the main problem is MSIE's poor or lack support of W3C standards (W3C DOM Events, SVG, canvas...).
We need a decent Java browser/web engine to build a new generation of desktop/web applications coded in Java and optionally JavaScript. The same application could be distributed as stand along (desktop) and remotely accessed using AJAX.
To overcome limitations of web technologies, JavaScript pushed from server is an option, GWT is smart doing this.
Another approach (of JavaScript pushed from server) is arising: DOM in the server, furthermore, embedding a browser on the server. For instance ItsNat is a Java W3C browser on the server (applications are coded in Java), Jaxer embeds Gecko on the server (applications are coded in JavaScript).
In ItsNat case JavaScript is replaced by Java for any kind of DHTML with W3C APIs (done on the server and propagated to the client). Disclaimer: I'm affiliated to ItsNat.

A more productive question would be: How do we incorporate the learnings in order to make a language evolve?
As a matter of fact, when we start using a tool (such as HTML, a car, etc.) we discover new possibilities and limitations. As we speak with other users of the tools, we expand our possibilities of use of those tools, patterns emerge, and so on.
After a while, the tool has expanded our possibilities and new needs arise. On the other hand, the use of silimar tools (XUL after HTML, a Mercedes after a Fiat, etc.) lets us desire to have some features incorporated in our tool and we also want to keept some of its original features.
Probably after a few versions, the tool will be quite different from its beginnings. Just because the needs have changed as a product of our learnings of the history, and of the expansion of our possibilities.
So, the point is much more about how to make evolve a tool.
It would probably help a lot to have languages that have a mechanism that helps any user to make the language itself evolve.

...seriously, I never understood, why people are deperately trying to throw away the simple interaction model of HTML to create something "better".
About 95% of the Ajaxafied Web 2.0 applications that try this simply suck. Not because they don't work generally, but because they try to enforce their own broken interaction models on the user. For a lot of the "rich client side functionality", it is much easier, cheaper and better for the customer let alone for old fashioned things like data integrity, to create a superior user interface by reducing bandwidth and server response times.
When it comes to making applications offlinable, there is a fairly simple question, why not just *install* the things and use a distribution mechanism to update the applications. There are tons of solutions for this kind of problem.

Im always replying to these sort of discussions with "OpenLaszlo".
http://www.openlaszlo.org/
Mind you, OpenLaszlo today "compiles" to Flash, or DHTML. I'm not fond of either for user interfaces, but I think there's an important paradigm in OpenLaszlo, and its the same you find in other XUL-like systems: user interface markup.
As other posters have pointed out, HTML is a *text* markup language. Its good that its not controlled by one commercial entity, it coarse enough to be interpreted slightly differtently where appropriate yet rich enough that we do all that we do (e.g. posting to TheServerSide.com).
Where is our UI markup language? Perhaps its OpenLaszlo? Perhaps its XForms? If we don't wake up, it will be Microsoft Avalon/XAML/Silverlight.
I think we do need an open UI markup language. This "UIML" could be transmitted to client systems and interpreted by a "UIML browser", just as HTML is interpreted by a web browser. HTTP could be the deliver mechanism, but a web browser should never be an application shell as it is an entirely different paradigm.

I do not think any language is old. Yes lot of factors do effect in the progress of a language including applicable architecture, marketing, easiness, usability, acceptability by popular vendors, design etc. etc. etc.
As long as a language specification is always advanced to accommodate the best practices and new features, it is a always young. It may also depend on who want to contribute their best idea's and where and it is all based on the personal and political preferences.
Best example is our day to day life is use of our plain old Javascript in current advancements of the Web Development and its important role in so called Web 2.0. Not a big fan of Javascript'ing but am impressed.
Regards to HTML lets see where 5.0 takes existing technologies built along with HTML 4.x and it will be a very interesting change to watch.

How many of the applications being written today actually require a browser based client? Browsers and HTTP have many limitations that I don't need to elaborate on here. But how many projects have we worked on that would be much better served by using SWT or Swing and Java Web Start?
John Murray
Sobetech

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.