A "wiki-tized" name for HyperTextMarkupLanguage + DocumentObjectModel + JavaScript + CascadingStyleSheets. These four have become the cornerstone of "web programming" on the client-end of web applications, for good or bad, if not using proprietary tools, such as Flash or Active-X. HtmlDomJsCss is often used to more or less emulate "desktop" GUI's, which are UI conventions that existed before web browsers grew in prominence.
----------
From: GuiMachineLanguage 

Re: "Why not just add missing widgets to HTML 6.0 and continue using HtmlDomJsCss? Tell me: how long would it take for GuiMachineLanguage to become popular? How many revisions of HTML and advances to JavaScript libraries and DOM will likely come out during that time?"

There are two reasons I doubt extending HTML would work.

First, there are already HTML standards that browsers are choosing to ignore. More "paper standards" will not by themselves move browser makers.
* ''How does this objection imply that extending HTML would not work?''

Second, Microsoft is unlikely to support a "rich GUI" standard, because it would cut into its desktop near-monopoly. Since IE is still the most common browser, if MS does not accept more non-proprietary GUI browser widgets in it, it will likely not become a de-facto standard.
* ''Well, MS is a member of W3C, so I can see why that might be a problem. If it were true. But I feel some need to note that Microsoft is, in fact, working to support "rich GUI" standards. XAML is an 'Open Specification' (which is about as open as Microsoft ever gets). Look it up. Further, it seems you are trying to imply that a '''not-HTML''' solution will have a better chance of becoming a de-facto standard in the face of Microsoft opposition. Do you have a reason to believe this, or are you speculating?''
* I don't trust Microsoft, and neither do many other techies. It's time we do without them. If I owned lots of MS stock, I would also *want* them to sabotage open rich-GUI standards, the same way they try to sabotage every other standard that threatens them. Mere participation does not mean a whole lot. If you are Microsoft and you want to protect your cash cows, what would be the logical choice?
* ''The logical strategy, as always, depends on the positions of the other players on the battlefield. An analysis that ignores Microsoft competition will be a naive one.''

To get around this, the open-source industry may have to create a new kind of browser, perhaps dedicated to a desktop look-and-feel. Perhaps a plug-in to FireFox etc. may work, but many people won't want to download an entire browser just for the GUI kit. If it new GUI kit is a new browser which is smaller because it focuses on desktop-like GUI's and only desktop-like GUI's, it will be more palatable. Now, I cannot "prove" exactly what consumers will do; if I could I'd be a marketing millionaire. I can only describe consumer behavior as best I can based on similar past events and personal experience. If you disagree with my consumer- and MS-behavioral estimation, so be it. -t

''I suspect your consumer- and MS-behavioral estimation involves more HandWaving speculation than research, observation, and analysis. I'm certainly not convinced by it. Anyhow, I'll ask: what do you know of the existing movements in this area? Mozilla Prism, XAML, XUL and Gecko, for example?''

You are going to call anything that is not a double-blind $100 mil study "hand waving". Your request is unrealistic, Sir. And, it *is* based on observation of MS's behavior over the years.

''I don't require $100 million double-blind studies. But I do consider your $0.02 opinions to be grossly insufficient. A minimal investment for a typical survey would be in the multi-$1000 range of valued time and effort, with $1000 being approximately 25 hours salary+overhead for a beginning IT professional.'' 

''You say your opinions are based on observation of MS's behavior. Which behaviors, specifically? and how up-to-date are they - i.e. MS ''has'' been trying to be less... evil... in the last several years. They've opened up many previously proprietary formats and protocols.''

Most of it is window dressing (pun half-intended) so far.

------

'''Rough Melding'''

Further, things like adding an MDI interface may "break" existing web browser behaviors and/or conventions (such as pop-up blocking and tabbed browsing settings). It may be the case that simply adding "missing widgets" (WebBrowserMissingWidgetWorkArounds) cannot be done in a clean way. It may force changes or ugly compromises on existing browser behavior. Web interfaces and desktop interface just plain have a different "feel". Melding the two may not be smooth. Starting from scratch (such as GuiMachineLanguage) may be cleaner at this point because it could focus on desk-top-GUI-like behavior and only that without worrying about how to get along with existing web browser UI's.

''HTML (well, HtmlDomJsCss) already does MDI. It's just called IFRAME.''

* I have not seen HtmlDomJsCss that does most of the things I miss from desktop GUI's well, cheap, and browser-version-friendly.
* ''How much time have you spent looking?''
* I'd estimate a total of about 25 hours over the past 4 years.
* [Last year, I worked on a content management system project.  That's roughly how much time I spent searching for and modifying various OpenSource HtmlDomJsCss combobox, enhanced text box, etc. implementations plus creating a lean AJAX infrastructure to provide a cross-browser desktop GUI-like experience.  It's not that difficult; it just requires some effort and allowances for the fact that a browser environment is not a desktop GUI. In terms of user experience, the end result is just as effective as a desktop GUI, if not more so.]
* What do you mean by "modifying...implementations"? Do you mean you had to tweak and debug actual widget code? If you had to do that, its not mature. Surveying my fellow colleagues, AJAX is still a big PITA, and many are fairly sure future browser versions will break a good many things. Where's a decent AJAX data grid, let alone one that allows combo-boxes and check-boxes in the grid cells? -t
* ''It will be many, many years before starting from scratch produces a mature solution. And you can answer your own questions: http://www.google.com/search?q=ajax+datagrid . About ten seconds of search found a neat one: http://www.activewidgets.com/grid/ .''
** $495.00 
** ''That is a very reasonable price for a full widget set, I'd even say "extremely" reasonable given that you get the full source-code and are licensed to modify it. Even the $2995.00 price for multiple developers is reasonable. But you're free to shop around; the google search includes a price-comparison among four widget sets with grids. You want free, too? How about you estimate up the cost of developing a new standard and getting a working implementation of your new standard... and I'm no Software Engineer, but I think it would cost ''at least'' a few hundred thousand dollars of time and effort... then you decide whether it's a raw deal.''
** Decent desktop GUI conventions have been around for 20-odd years and we still have to buy "ordinary" widgets from fly-by-night companies that will probably be gone in 2 years and the entire 200k source-code for the widgets has to be downloaded to the client each time for every session? This is progress? Maybe it's "good enough", or will be soon, but it's still a large hack that only a mother could love.
** ''When did 200k become 'big'? (it's as much as one mid-size JPEG image...). Besides, if you don't want a fly-by-night, feel free to spend '''more than ten seconds''' doing a search. A bit more digging found me http://www.extjs.com/ which also has grids, happens to be OpenSource, is used widely by such groups as Adobe and Amazon and Sony, comes with two components - pure JavaScript versions, and GoogleWebToolkit versions, etc. This isn't something I even care about. Why should I be the one doing the digging?''

* [I found a variety of pre-written, JavaScript widgets and I modified them -- minimally -- to suit my purposes.  Whilst I won't argue that AJAX ''can'' be a pain, it's not difficult to establish approaches and disciplines that make it relatively painless to apply.  I eventually plan to organise these into a framework for use as an application development & deployment front-end for the RelProject.  I have not found a decent AJAX data grid, but I haven't looked, either. (Looks like someone found one in ten seconds, above!)  I'm not a fan of data grid driven interfaces for end users, though I can see some value in using them for quick-n-dirty raw RelVar editors for administrative and development purposes.  I don't see anything in JavaScript or the DOM that would preclude creating a data grid as effective, or more so, than the "old skool" desktop widgets used in VisualBasic, MicrosoftAccess, and so forth.  It's a matter of expending the effort to develop it.]
* What's the percent chance that newer browser versions will break and "damage" some of your widgets do you think? And how much does managing this library cost? Do you think it's "normal" in 2009 that application programmers have to still code and fix scroll-bars and the like? It may be great job security for you, but outside of that, it's costly and risky.

''And starting from scratch without giving a serious attempt is doubly a mistake:''
* You'll eventually want to have all the features from HTML, anyway. Giving it a serious try offers some significant lessons-learned for future attempts to combine the features, which abstractions and generalizations can be made, etc.
* Unless you can say in no uncertain terms exactly why you ''can't'' simply add the features to HTML, you'll face extremely stiff resistance from the crowd you're hoping to motivate. Laziness, MindOverhaulEconomics, desire to avoid 'new' things are common among the population of users. (You're not an exception. Neither am I, except in my own niche interest area.) 
* (comments on individual paired points moved below)

Your opinion is noted. Let's let them decide that.

''I'm fine with that. You go ahead and implement your 'personal' approach, then convince other people to try it. It'll only take you a few years if you work hard at it and hire some help.''

-------

'''RE: You'll eventually want to have all the features from HTML, anyway. Giving it a serious try offers some significant lessons-learned for future attempts to combine the features, which abstractions and generalizations can be made, etc.'''

''That may be the case, but why worry about the distant future?''

Given that the context involves ''starting from scratch'' to produce something better than HtmlDomJsCss for applications (which is hardly a near-term proposal), it is '''already established''' that you are worrying about the distant future. But, since you asked, I'll turn your question back on you: why ''are'' you worrying about the distant future? Why not let the future settle itself?

''Many companies use Java's GUI without worrying too much about it not being integrated with HTML. Thus, they've shown that they'll put up with the disconnection to get a better GUI.''

------

'''RE: Unless you can say in no uncertain terms exactly why you ''can't'' simply add the features to HTML, you'll face extremely stiff resistance from the crowd you're hoping to motivate. [...]'''
 
''I cannot provide a double-blind million-dollar mathematical study.'' 

Who said you need one? All you really need is a good set of reasons. People will see through insubstantial words.

''It may be possible, but it seems browsers are becoming too complicated and cluttered, and there are '''too many vendors involved now'''. It's easier for one vendor/product to make and manage the features of a GUI browser then getting 6-odd HTML browser vendors to keep up.''

I'm curious from which perspective you believe that is a rational argument in your defense.

When I wear my "I'm an application service provider" hat, I see that ''someone'' needs to write and maintain the browser that can display my applications. Supposing even ''just one'' of the established WebBrowser vendors shouldered that task - Mozilla company and FireFox, say - I'd be assured of a widespread potential user-base, continuing support for the application language, and both portability and distribution of the browser platform. Would I be able to expect the same of T''''''opsGuiMachineLanguageBrowser?

When I wear my "I'm an application user" hat, I'm somewhat picky. I want something that works on ''my'' OperatingSystem, with good regular 'security' updates. I want something that's available when I go to the Internet Cafe, that's readily available on many machines other than my own, that isn't likely to require installing new products. IwantaPony, but a FireFox will do. It has most of these properties. I might prefer a different browser, but I'm certainly better off with FireFox than with T''''''opsFlyByNightGuiMachineLanguageBrowser.

When I wear my "I'm an application developer" hat, I want to develop applications that will work robustly, will work everywhere, will have acceptable or better performance, and will ''continue'' to work in the future without continual support on my part. For me, established standards maintained by some slow-moving monolith that concerns itself with compatibility, such as like WorldWideWebConsortium, are a ''really, really GoodThing''. For me, a popular browsing platform with a good long-term prognosis on its lifetime is a GoodThing, and even if 5-odd HTML browser vendors have yet to ''implement'' the standard, the fact that they are expected to do so is also a GoodThing. I can't expect any of these from T''''''opsWhatchamacallitBrowser.

When I wear my "I'm a competing browser developer" hat, I'm not going to bother supporting some new 'standard' until it is well and thoroughly developed. I really hate coding to a moving target. I also am not going to implement anything that isn't in demand, though if my browser is a 'WebBrowser' I'd probably treat a new version of HTML as a mandate. I may also support a plugin extensions mechanism for my browser, but the plugin will be somebody else's problem. EmbraceAndExtend pisses me off when I'm wearing this hat, so I don't really like pioneers, but if they're courteous enough to at least utilize a distinct <DOCTYPE> field I can tolerate them.

When I wear my "I'm the pioneering browser developer" hat, I see extending HtmlDomJsCss as favorable to many alternatives. It allows me to leverage the existing display framework, existing optimizations, existing DOM and networking protocols, etc.. The HTML has a <DOCTYPE> field, so I can use that to select the interpreter for the document. To keep app-developers happy, the guy wearing the standards developer hat can negotiate with me to promise to continue maintaining select 'stable' versions of the experimental language. Unless I can find some ''really good'' reasons for tossing HtmlDomJsCss and starting from scratch, I'd rather not do so. There is a lot more work that goes into a browser than that idealist with the standards developer hat is imagining.

When I wear my "I'm the new standards developer" hat, I want to create something that will be implemented and used. There are two basic choices for me here: (1) I start from scratch and try to develop something '''much''' better than the competition - enough to defeat incumbency and inertia. (2) I extend an existing standard and try to develop something that has a chance for long-term adoption by an established standards committee. If I go with option (1), I had better be able to say why my new standard is so much better. In fact, I had better be able to do so on stage, at conferences, in blogs, and on WikiWiki, and I had damn well better be convincing, because I need app-developers to join me despite my apparent lack of initial stability. I'm fighting inertia. A good implementation would help. If I go with (2), the burden is much smaller, the implementation is easier, the app-developers are happier, and the probability of success is much higher. 

So, from each of six perspectives, I should, rather than start from scratch, choose to extend HtmlDomJsCss '''until''' it breaks. Well, that's unless I've got something that can overthrow skepticism and inertia both.

Now, putting BlackHat back on, I must ask you, TopMind, exactly why you think it relevant that all 6-odd WebBrowser developers would need to follow you from the start? Which engineering 'hat' were you wearing when you made your argument?

''Based on passed behavior, I find it highly unlikely that MS would put in enough desktop-like features into IE to risk challenging Windows. The desktop is their bread-and-butter. At best, they'd do it half-ass, just enough to claim compliance, but it would be sluggish and buggy and take advantage of holes in the spec. This, we can count MS out, and they have roughly 70% of the market.''

''Besides, it's fairly easy to just release a "GUI Browser" as a stand-alone browser. You download and install it like any other application. If it's open-source, then the other browser makers may be able to incorporate it anyhow if it starts to catch on. -t''
-------
See Also: AjaxWebApplications, WebBrowserMissingWidgetWorkArounds, SeasideFramework, LimitsOfHtmlStack, CurlLanguage 

{EditHint: perhaps Curl should be moved to a product list page}

I disagree. CurlLanguage is not just a product. (Technically, CurlIde would be the 'product'.) Curl is a ''language'' that was specifically developed to address the polyglot problem of HtmlDomJsCss. 

-----
CategoryWebDesign, CategoryInternet, CategoryUserInterface

JuneZeroNine