Limits Of Html Stack

Over in GuiMachineLanguage, a debate rages about whether the existing trend of using the HtmlStack can scale sufficiently to provide rich GUI's over HTTP; that is CrudScreen-friendly GUI's that can emulate desktop GUI conventions. "HTML stack" is generally considered to be HtmlDomJsCss-based solutions, such as AjAx. This topic is an attempt to better organize the debate in an outline format.

Working Abbreviations and Terms

HTML++ - Nickname for the "HTML stack", namely HtmlDomJsCss and/or AjAx.
Rich-GUI - A GUI kit/system that can emulate common desktop behavior and widgets.

Some believe it cannot do the job because of one or more of the following reasons:

MicroSoft will sabotage the effort using its "usual tricks" because it would cut into sales of its desktop-centric products. More on this below.

JavaScript makes for a poor SystemsSoftware programming language in which to build GUI primitives.

There's too many brands and versions of browsers to have reliable DOM/JavaScript behavior.

The size of a sufficient widget code (usually JavaScript) is too large to be practical. Common UI behavior should be built into the browser.

CSS is a different language than markup (HTML/XML), creating confusion and increasing the learning curve. See BradyBunchGridDiscussion for a possible alternative.

JavaScript and AjAx have cross-site XMLHttpRequest limitations in order to close security holes, and these limitations forbid some of the richer Applications. Similarly, HTTP has limitations that make real-time updates a challenge.

HTML and JavaScript remains unsuitable for certain graphics-intensive operations that keep many applications rooted to the desktop (GoogleEarth being one example among many).

Culture-Clash - Web standards/conventions flow against many desktop features (See WebBrowserMissingWidgetWorkArounds for some examples)

No wide-spread "base" tool has ever been built primarily out of a scripting language. JavaScript was not designed for SystemsSoftware. Thus, we are entering unexplored territory.
- What, exactly, do you mean by "base tool"?
- SystemsSoftware - Tools used by application developers, not built by application developers for specific domains (although I agree there's an overlap).
- In that case, you are incorrect to say that no wide-spread SystemsSoftware has ever been built primarily out of a scripting language. Consider RubyOnRails, for example.
- ROR is borderline. I've made my own CRUD web frameworks out of scripting languages also, but I'd hardly call them SystemsSoftware. ROR is just like such a thing that caught on to others. And I hear ROR is hype-crap for anti-SQL OO fanboys, difficult to install/configure on servers, and rather slow. There's also things like SwitchBoard framework. Plus, we wouldn't need self-rolled such things if the tools better fit the domain (CRUD).
- There are many instances of SystemsSoftware written in scripting languages (some have already been named in this and related topics, such as Pyjamas and Flapjax, the extjs libs) and other projects mentioned recently on WikiWiki (e.g. OpenCroquet - 3D collaboration in SmalltalkLanguage), but the 'widespread' criterion is actually rare among any software (including SystemsSoftware) developed in any language. In any case, there is much precedent for SystemsSoftware to be developed in scripting languages so long as it is either not performance-critical, or the JustInTimeCompilation and GarbageCollection have reached a level where performance is acceptable. JIT performance for JavaScript is very impressive in the V8 and SpiderMonkey implementations. Even before the relatively recent improvement of JITs, there is even longer precedent of building SystemsSoftware in scripting languages (like Perl or Python) then using a 'hard' language to optimize inner loops (e.g. a matrix multiply function). I think you are in error to say this is 'unexplored territory'.
- Common DBMS, OS's, network management, and GUI engines are not written in scripting languages. I've never heard of OpenCroquet. It's a tiny niche product. Further, the growth of netbooks and smart-phones is putting pressure to have small and fast rendering/GUI engines. It's difficult to get this from scripting languages. Possible if the industry tries hard enough perhaps, but it's yet another hurdle. While it may be possible to get scripting languages to work on such devices, it's obviously far from the ideal tool for it. C/C++ compilers are carefully optimized for such and would be a much better choice.
- Merely having limited distribution does not mean you should dismiss ideas as 'tiny, niche products' (but since you believe it does, you should be consistent by throwing away your own original ideas on the same basis). Also, I agree that better support for smart-phones and such does benefit from smaller, faster rendering/GUI engines... but that is not a hard 'limit' of the HTML stack, and there are dedicated HTML rendering engines for phones. More a problem is adapting the display and UI for phones, which is related to the sort of display 'transforms' associated with accessibility and CSS.
- It's not about "hard limits", it's the shear multitude and quantity of hurdles. People have to throw ugliness at ugliness to force it to work. And HTML rendering is not sufficient for many web-sites. They'll want the "++" also. (Fold-able screens are in the lab now such that someday not too far off people will have a wallet-like device that has an unfold-able screen to get like 10 inches of width.)
- Well, I agree that we should be avoiding hurdles. Indeed, any proposed replacement for HTML should make a big list of existing hurdles and solve as many as possible.
- Including reducing the acceptance hurdle caused by loading it with too many unfamiliar technologies and stuff not related to the stated goal. They want better HTTP-able GUI tools, not Xanadu Emacs 2.0. Needless to say, you and I put very different weights on the feature wish-list and I doubt that will ever change.
- [You're speaking only for yourself. Yours is not a view representative of practitioners as a whole, whom in my experience -- and especially among Web developers -- seek the most powerful tools they can get. It is both presumptuous and illogical to assume your limitations are found in the majority of others in your profession.]
- Hold on, Tex, why is your assessment of what developers want assumed to override mine? I'm willing to LetTheReaderDecide at this stage. If they agree with your priority rankings, then they can accept your conclusions, and vise verse. I don't trust you with summary assessments. You two have proven too biased and stubborn.
- [We both know you're speaking entirely for yourself. Why continue to pretend otherwise?]
- You mean "the reader" or "biased and stubborn"? Never mind. I don't want your answer. I'm 99.99999% sure it involves me being bad, lazy, stupid, or evil. Developers spend far more time futzin' with and repairing GUI/UI technology these days for web than they did for desktops in the heyday of desktop GUI's (accept for DLL conflicts). Something very useful and productive got lost over the years. Sure, micro-managing GUI's is good job security, but I don't want to waste time fixing scroll-bars and emulating combo-boxes with 1000 lines of JavaScript, I want to spend it on making tools that help business users be productive. I want to paint pictures, not build canvases and brushes. They used to be commodities.

Hedges can be good - In case HTML++ fails, it's good to have alternatives in the near background.
- That said, there are plenty of alternatives in the background without need to invent more...
- Example? I see very few that seem to "care" about business-oriented CrudScreens. Most seem to want to be the next HTML, and target yet more eBrochures. -t
- MicrosoftSilverlight, Flash, portable Java application, X11, XUL, OpenGl+SimpleDirectmediaLayer, VisualBasic, etc. And what they "target" is irrelevant; only of what they are "capable" matters.
- These are proprietary, and/or poor, not focused on CRUD, too similar to HTML++ to serve as a good hedge, etc.
- (1) Proprietary is irrelevant because it is not a contradiction to 'Rich GUI', and is not a "scaling" issue. (2) "Not focused on CRUD" is irrelevant because, as noted, what they "target" is irrelevant; only of what they are "capable" matters. (3) "Too similar to HTML++ to serve as a good hedge" seems to lack argument and evidence: you need to explain two things (a) how the above are too similar to HTML++, (b) how things similar to HTML++ cannot serve as a good hedge.
- I've excluded proprietary tools for reasons already stated near the topic intro. True, proprietary tools are a hedge against the failure of OSS ones, but that does not exclude the need for an OSS hedge. A rough analogy would be saying that a motorcycle is a hedge against a failing car. While this is true, a different vehicle that is still a car would be a more comparable hedge to the original car. Cars have features that motorcycles don't.
- Huh? Which 'features' does the OSS 'car' have that the Proprietary 'motorcycle' does not, merely by virtue of being OpenSource?
- Yes. Being OSS is important enough that it deserves a hedge option also. After all, few would bother to use HTML++ CRUD-oriented widgets/kits if merely being CRUD-friendly was the primary goal. Anyhow, I'm focusing on OSS solutions here. If you want to compare others, be my guest, but I may not participate.

They've been trying to get rich GUI's from HTML++ since the late 90's and progress has been very slow (except in areas like GoogleMaps, which are not CRUD). This is yet another yellow alert suggesting it's the wrong path.

DiscontinuitySpike or forced dichotomy exists between browser windows and CSS panels. A browser window gives one automatic features, but less control than a CSS panel.

Some counter-beliefs include:

Existing web-page conventions are good enough, and there's way to re-work interface to not need desktop conventions.

HTML and DOM continue to improve in ways critical to supporting rich Internet applications. Modern support for , for floating elements including , and upcoming support for ScalarVectorGraphics, Image Maps, and Canvases are all very powerful tools for rich GUIs. That is, we aren't looking at a stagnating standard. We're looking at a set of standards that continues improving to meet demands. Even HTTP is looking at renovation, such as headers and hashing to support more intelligent caching for shared script libraries. <ul> <li> Alleged Con: While those are useful in their own right, they don't address typical <a href="CrudScreen.html">CrudScreen</a> applications. <ul> <li> Sure they do, albeit indirectly. They form primitives for building arbitrary <a href="CrudScreen.html">CrudScreen</a> applications in big chunks as opposed to pixel-at-a-time. </li> <li> They are barely above that. </li> <li> Explain. </li> <li> One uses them to build widgets from scratch at a relatively low level. This is why the source code for a compound widget, such as a tree or grid, is often 10k of source code or more. In some cases, programming them pixel-by-pixel may be simpler because one is not trying to code around the idiosyncrasies of specific DOM implementations. If the lines-of-code count using raw pixels versus using DOM is about the same, then it could be argued that DOM is not helping, but is merely circumstantial baggage. </li> </ul> </li> </ul> </li> </ul> <ul> <li> One can use <a href="JavaScript.html">JavaScript</a>+<a href="DocumentObjectModel.html">DocumentObjectModel</a> as GUI-assembly, and <a href="AjAx.html">AjAx</a> for communications, without writing a single line of <a href="JavaScript.html">JavaScript</a> or <a href="AjAx.html">AjAx</a>. This technique is already in heavy use. <a href="GoogleWebToolkit.html">GoogleWebToolkit</a>, Flapjax (<a href="http://www.flapjax-lang.org/),">http://www.flapjax-lang.org/),</a> Pyjamas (<a href="http://pyjs.org/)">http://pyjs.org/)</a> and others are based on this. <ul> <li> Con: Cited examples currently fail to address many of the issues listed in <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a>. <ul> <li> The cited examples serve their purpose. That purpose did not involve addressing every alleged issue from <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a>. Therefore, the above 'Con' is irrelevant. </li> <li> If they address only a small percentage, then they don't serve the purpose, therefore the "con" is still relevant. </li> <li> Not true. The examples serve their purpose, which did not involve addressing any alleged issue from <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a>. Further, it's vacuous. <a href="GoogleWebToolkit.html">GoogleWebToolkit</a> does address <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a> via support from extjs. </li> <li> We already discussed extjs. It's missing common conventions and nobody has showed all the widgets working smoothly together on the same page. </li> </ul> </li> </ul> </li> </ul> <ul> <li> Microsoft has already made its attempt at sabotaging DOM. They'll have a hard time making it worse due to the screams of the wounded and <a href="BackwardsCompatibility.html">BackwardsCompatibility</a> issues. They'll have a much easier time making it better; but even if they don't, the dynamic adaptation of <a href="JavaScript.html">JavaScript</a> code to Microsoft is already embedded even in the above tools. <ul> <li> Con: MS's behavior with regard to VB6 shows that they will completely abandon <a href="BackwardsCompatibility.html">BackwardsCompatibility</a> if it serves their goals. In VB6's case, it was likely the threat of Java that motivated them. (More on <a href="MicroSoft.html">MicroSoft</a> is below in it's own section) <ul> <li> Counter: With VB, they were sole owners and arbiters. The same cannot be said here. </li> <li> That doesn't matter much. It's about how much MS will risk pissing off customers in order to make a strategic change. They've shown multiple times that they'll play dirty when they feel sufficiently threatened. they've bribed standards committees with gifts and banquets, arbitrarily tweaked the memory management of their OS to force incompatibilities with IBM's OS/2, stretched the meaning of words in legal agreements to the very edge, and sold VB6 source code dependents down the river. The bigger the (perceived) threat, the greater the evil. They will protect their rich desktop capabilities because that's their bread and butter difference between the competition. </li> </ul> </li> <li> Re: "Microsoft has already made its attempt at sabotaging DOM." - Even if true, that doesn't stop them from tying again with different strategies. Greece tried more than once to invade Troy. They may have slowed because current HTML++ still sucks compared to real GUI's. Again, they could probably bust a lot of HTML++ tools simply by fixing mounds of bugs they've been sitting on. (Examples given below under "Sabotage Via Gradual Standards-Compliance".) When you program against a poor-quality DOM like MS's, you often have to put in a lot of work-arounds and fudges to or with apparently arbitrary behavior discovered by trial-and-error. Well, one day MS may decide to "fix" this arbitrary behavior. They may first release fixed for their own tools that rely on the problems, or simply fix bugs that don't affect their existing products. Commodore ran into such a problem when it tried to release newer versions of Commodore computers. It turned out that many software manufacturers relied on discovered bugs to either gain performance advantages, work around other problems, or because they didn't know any better. This is one of the reasons why the Commodore-64 was produced pretty much as-is for almost a decade. They couldn't improve it without breaking mounds of existing software. They decided it was cheaper to discount it every year rather than chase the high-end with a new model that would have poor compatibility. -t </li> <li> Re 2: "Microsoft has already made its attempt at sabotaging DOM." - We don't know if that was their best shot, a partial shot, or merely experimenting to study reaction. By many accounts, not improving their DOM and JS engines is most of their prior attempt, and they don't have to lift a finger to do it. It is perfectly within their ability to add enhancements, security "features", and bug-fixes that break things. They do it to other products even when they don't intend to all the time. </li> </ul> </li> </ul> <ul> <li> "Too many brands of browsers" - or, more generally, clients - is a symptom of success for any standard. The degree to which you punish or allow some degree of non-compliance is a business decision, though one can provide some automated compliance tests to help encourage greater compliance. Over the last decade, three 'Acid tests' (<a href="http://en.wikipedia.org/wiki/Acid1,">http://en.wikipedia.org/wiki/Acid1,</a> <a href="http://en.wikipedia.org/wiki/Acid2,">http://en.wikipedia.org/wiki/Acid2,</a> <a href="http://en.wikipedia.org/wiki/Acid3)">http://en.wikipedia.org/wiki/Acid3)</a> have helped achieve compliance for HTML++ - even from Microsoft, though they still resist enabling it by default. In any case, it is fallacy to assume and a challenge to prove that a standard to replace HTML++ will do 'better', so complaints of this nature are difficult to justify as more than <a href="WishfulThinking.html">WishfulThinking</a>. <ul> <li> [removed rude wording] <ul> <li> Added again. And '<a href="WishfulThinking.html">WishfulThinking</a>' is not rude. You want rude, I'll give you rude, you fucking sophist who takes criticism like a whining pansy. </li> <li> You mean <a href="WishfulThinking.html">WishfulThinking</a> like the bloated HTML++ stack will EVENTUALLY come around? Goddam arrogant asperger hypocrite! Even the ones you pay for are garbage. Loading an entire GUI engine for every session? That's fucking moronic, making even Microsoft look good. </li> <li> No, I mean '<a href="WishfulThinking.html">WishfulThinking</a>' like "If 'my standard is successful then by some <a href="HandWaving.html">HandWaving</a> magic everyone will be in complete compliance, unlike HTML++!" or "Somehow my standard can be successful AND I'll control the only implementation - I'll just ignore how having only one implementation is pretty much a logical contradiction of a standard being 'successful'...". I'm not indulging in hypocrisy here. I don't believe HTML++ will 'come around', but I'm quite confident that it will 'hold out'; jury-rigged it may be, but built of sturdy components. </li> <li> Comments about "only implementation" are below. Nothing sinister going on. </li> </ul> </li> </ul> </li> </ul> <ul> <li> With regards to your other comment - which is an entirely off-topic <a href="RedHerring.html">RedHerring</a> under the above subject of standards compliance (just as I've learned to expect from a fucking sophist like yourself) - loading the entire GUI engine is a performance issue. HTML++ has quite a few performance issues along with a plethora of safety and security and composability and productivity issues. A large 'GUI engine' is hardly the worst even just looking among the performance-related concerns - it, at least, can be easily improved by keeping a more permanent cache for the imported <a href="JavaScript.html">JavaScript</a> code of sites visited often. But, as noted below: there's a large and ever-growing gap between 'worse performance than preferable' and 'performance too bad to be practical'. </li> <li> I agree it's off topic. I was very angry. With regard to performance bottlenecks, portable "web" devices are becoming popular. Large JS libraries and JS speed may be an issue on those as they grow more commonplace. </li> <li> And, committing a formal fallacy, aka "being wrong", if such was done, for the sake of argument, is generally considered a lessor rudeness "sin" than insulting people. I know you have an outlier moral system, but I feel it unfair that you judge me based on an outlier system. Come back to planet Earth. -t </li> <li> Being intentionally disingenuous (aka sophistry or distraction tactics) is worthy of accusation according to most people I know. So is professional negligence in the form of gross ignorance, especially when the ignorance is maintained by agenda (<a href="WishfulThinking.html">WishfulThinking</a> qualifies as an agenda). But what earned the insult was how you reacted to the accusation. I withheld insults until you saw fit to edit my words and on the basis that a rational accusation was 'rude'. You find me three people who frequent <a href="WikiWiki.html">WikiWiki</a> who think I'm out of line, and I'll reconsider my behavior. </li> <li> Continued at <a href="InsultJustificationDiscussion.html">InsultJustificationDiscussion</a>. </li> </ul> <ul> <li> There's an enormous gap between "larger than preferable" and "too large to be practical", and that gap grows wider as bandwidth and CPU resources increase and as <a href="JustInTimeCompilation.html">JustInTimeCompilation</a> improves. Widget code is, perhaps, larger than preferable. It is not too large to be practical, as evidenced by widget libraries - both commercial and <a href="OpenSource.html">OpenSource</a> - such as <a href="http://www.activewidgets.com/">http://www.activewidgets.com/</a> and <a href="http://www.extjs.com/">http://www.extjs.com/</a> . </li> </ul> <hr/> Microsoft Sabotage Possible ways to sabotage <ul> <li> Cripple Internet Explorer's <a href="JavaScript.html">JavaScript</a> or DOM (some claim it already is). </li> <li> Start a new standard that (initially) out-competes the open-source one by: <ul> <li> Working tightly with popular MS-Products like Windows, Office, Exchange-Server </li> <li> Providing a fancy drag-and-drop IDE for it, something open-source is usually slow with. This could kill adaption of the open-source one in corporate-land. </li> <li> Bribe the standards bodies with perks and gifts, something that allegedly happened with OOXML. The result is standards that: <ul> <li> Favor MS's existing formats </li> <li> Favor Windows OS architecture, such as spaces and case-insensitivity in file and URL names </li> <li> Are poorly-defined such that MS's existing implementation becomes the de-facto behavior, giving it an edge. </li> </ul> </li> <li> Make MS's version be pre-loaded on Window. </li> <li> Work with another well-known company to produce a semi-proprietary standard that has partial-legitimacy as a multi-company de-facto standard. </li> </ul> </li> <li> Build a slick and catchy rich-GUI markup language that runs very well on Windows but only on Windows. (So far their tries have not been "slick", but MS tends to keep trying when they set their mind to something.) <ul> <li> This one is 'fair competition' and is not 'sabotage' in my opinion. As far as attempts go, it is worth pointing to <a href="MicrosoftSilverlight.html">MicrosoftSilverlight</a>, <a href="DotNet.html">DotNet</a>, and <a href="WindowsPresentationFoundation.html">WindowsPresentationFoundation</a>. So long as they don't pretend it's supposed to be an open standard, I'd not consider it underhanded at all. </li> <li> Whether it's classified as "devious" or not, the outcome is the same: it kills the OSS competition. What MS tends to do is develop lots of different kinds of "little technologies" that are half-ass marketed. If a specific threat pops-up, they usually have something fairly similar to the competition already in their arsenal such that within about a year they have a ready alternative. For example, in the mid 1990's they quickly retooled their existing VB-Script engines to compete with Perl for dynamic web pages (<a href="ActiveServerPages.html">ActiveServerPages</a>). They didn't have to create it from scratch. Java is about the only thing that caught them completely off-guard, mainly because they let their languages grow long-in-the-tooth. </li> <li> So? I'm a fan of <a href="OpenSource.html">OpenSource</a> myself, but any given unit of <a href="OpenSource.html">OpenSource</a> software still ought compete by its technical merits, utility, and marketability (including portability and licensing rules). That includes browsers, bit-torrent clients, layout engines, <a href="JavaScript.html">JavaScript</a> implementations, secure-sockets libraries, etc. Microsoft is successful because they are able to push to completion systems that OSS guys have in the past have had difficulty completing (i.e. providing visual <a href="IntegratedDevelopmentEnvironment.html">IntegratedDevelopmentEnvironment</a>s). </li> <li> This is largely because the OSS community has paid insufficient attention to rich GUI tools and standards. If you want to stab MS in the heart, then create and perfect a nice rich-GUI standard that developers can rally around for both desktop and web (HTTP) apps. The result should look more like <a href="PostScript.html">PostScript</a> than C libraries. In other words, <a href="GuiMachineLanguage.html">GuiMachineLanguage</a>. -t </li> <li> [Do you have evidence that anyone outside of you is searching for these "rich GUI tools" and not finding them in GTK, Flash, Silverlight, HTML+DOM+AJAX, Java Applets, WXWidgets, Java Swing, .NET, etc.? The reality appears to be that there are plenty of rich GUI tools and standards available to <a href="OpenSource.html">OpenSource</a> developers; so many, in fact, that it's a matter of negligible concern. That said, I do think there's something conceptually interesting in the idea of an interactive display language for developing the presentation side of database-driven business applications (or interactive applications in general) that deploys equivalently to the Web, desktop, mobile devices, etc., but I'd be hard-pressed to come up with a business case for it.] <ul> <li> I've talked to web developers that used to be desktop programmers and missed many of the features of those tools. Generally they end up using Java, Dot-Net, or Flash, saying that open-source is poor at keeping up with GUI's. -t </li> <li> [I am a Web developer and a desktop programmer. (Yes, I can walk and chew gum at the same time.) What features does your web developer colleague miss? GTK+ and wxWidgets are every bit as sophisticated as Java Swing or Windows Presentation Foundation, at least in any respect that matters. Alas, there is no direct competitor to Flash in the <a href="OpenSource.html">OpenSource</a> world, but I shouldn't think this would be a problem for developers producing business applications. It certainly isn't a problem for me.] </li> <li> See <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a> </li> <li> [What a strange little page that is. It's wistful, nostalgic longing for the heady days of client/server desktop apps, circa 1994. Guess what? Those days are gone. That style of UI is out of fashion. Editable data grids and MDI displays are, for many users, problems rather than solutions. They're reflective of a (lazy) application design philosophy that treats the application as little more than a facility to expose database tables to the user, thus forcing him or her to reinterpret his job in terms of tables or translate it to table interactions. A good application provides a means to hide technical detail, facilitate the user's job in the user's language, and uses system metaphors that the user understands. Unless the user is a DBA, these are almost never tables! Modern business application development is focused on workflow automation, efficiency, intuitiveness and ease of use rather than festooning the screen with awkward widgets and grids in a misguided attempt to turn tables into user interfaces.] </li> <li> Perhaps because of spreadsheets, many business-oriented users relate well to tables. Plus, they are a visually compact way to represent a lot of similar information. Web designs often scatter related info around to different screens/pages. Thus, one has to go back and forth or have a good memory. While it may make the app easier to learn, it may reduce productivity for fully-trained users. Remember, my specialty is custom internal biz apps. Some people will be using the tools for hours on end such that favoring initial training at the expense of future productivity is often not the best strategy for the company. There's a place for both approaches, but both should still exist, and this includes "smart-grid" and MDI style interfaces. There's no one right way to design UI's. The optimum approach often depends on the users and usage patterns, such as a few users that use it heavily versus many occasional users that may only get month-end reports, for example. Web designs tend to fit the latter style because on the Internet it's uncommon for services that are used heavily by a typical customer. The web was a great place for "occasional" services where ease-of-learning was important. However, biz apps often have more "dwell" style usage patterns where fewer individuals spend lots of time with a given service or tool. Further, MDI can take better advantage of dual-monitor systems, which are becoming more common. Ideally the tool would offer both tabbed and MDI such that the user can choose. Perhaps if they are allowed to open two instances of the app, that would serve the same purpose. But, it risks the user accidentally having two versions of the same record/document open. Or a "drag bar" for a split screen. But the idioms for HTML-browser centric versions of the same thing have yet to catch on. Maybe in ten years people will accept the new idioms, but so far the desktop-centric idioms are more familiar to users, and us developers know how to make use of them to fit the expected usage patterns for our apps. MDI is very flexible with it's placement options, especially with modal dialog boxes, which are quite useful. I've yet to find a decent HTML++ replacement for modal dialog boxes. If you can describe one, be my guest. It's hard to know whether the new (and immature) web idioms are the preferred approach, or people are simply living with their limitations to obtain the benefits of HTML++, namely no install step. I suspect it's the latter. -t </li> </ul> </li> <li> Per "rules" listed in <a href="GuiMachineLanguage.html">GuiMachineLanguage</a>, I'm only considering OSS and HTTP-friendly (non-installed) GUI's. I agree there are plenty of proprietary and non-HTTP tools out there. After all, those are the ones that spoiled us to real GUI's. Java also disqualifies because it's too app-language-tied. -t </li> <li> [What do you mean by a 'HTTP-friendly (non-installed) GUI'? How is Java 'too app-language-tied'? As a GUI language, why should it be any more tied to the application than, say, SQL?] </li> <li> Because SQL is not an application language. (Perhaps someday someone will find a way to wrap Java's GUI into something that doesn't look like Java without making an ugly mess.) I picture something declarative in nature, perhaps like HTML but have a richer set of widgets, statefulness of screen (refresh optional), and support MDI. -t </li> <li> As far as "non-installed", I meant per app there. In other words, each app normally doesn't need an "install" step. A generic GUI engine may need to be installed, similar to Flash, but anything that uses that engine ideally wouldn't need to install it again just as one doesn't need to keep installing Flash for each Flash app. (Although Adobe seems to force version upgrades much too often.) -t </li> </ul> </li> </ul> <hr/> <a href="JavaScript.html">JavaScript</a> as <a href="SystemsSoftware.html">SystemsSoftware</a> <hr/> Version-Mania <hr/> Widget Download <hr/> Web Conventions Sufficient <hr/> Reference Implementation Re: "...just ignore how having only one implementation [of <a href="GuiMachineLanguage.html">GuiMachineLanguage</a>] is pretty much a logical contradiction of a standard being 'successful'...". I never hard-limited it to one. You put words in my mouth. The first one would serve as the "reference implementation" to provide at least a basic set of rich-GUI behavior. Other vendors etc. would possibly branch off or start from scratch, but at least have theirs do what the original did. It would be roughly comparable to Mosaic (but not proprietary) early in web history. Further, if there's already open-source C or C++ source code for it, then there'd be almost no reason to start from scratch like web browsers often did. Alternatives would be forks. Even though <a href="MySql.html">MySql</a> is popular, for example, nobody's likely to start from scratch if they don't like it. They'll grab the C/C++ source code and tweak it. The only exception may be if the programming is absolutely horrid. -t I 'put words in your mouth,' you say? I think this qualifies as a case of 'the shoe fit, and <a href="TopMind.html">TopMind</a> decided to wear it'. You're the one who identified your own assertions about <a href="GuiMachineLanguage.html">GuiMachineLanguage</a> with a generic statement of <a href="WishfulThinking.html">WishfulThinking</a>. You managed to put my words in your mouth without any extra prompting from me. Anyhow, people <a href="RewriteCodeFromScratch.html">RewriteCodeFromScratch</a> for a variety of reasons, not all of them good. <a href="NotInventedHere.html">NotInventedHere</a>. To simplify the code. For portability. For modularity. For embedded performance. For distributed/grid performance. For real-time certifications as needed in Aircraft cockpits. For tighter integration with another language. Don't like the particular licensing terms you offer. Etc. And even 'forks' can deviate quite far from center - I have heard it claimed that a change of 25% of a codebase has about the same cost as a rewrite from scratch, since changing that 25% requires learning what to change and estimating change impacts and reading lots of code. I think you should widen your perspective about the suggested "only exception". There are ways to keep to one 'reference implementation'. One is to be so insanely convoluted that nobody else can take over - for example, as they say, only the Perl interpreter can parse Perl. Another is to have a large body of code tying people to your implementation - such as Eclipse extensions, Emacs text modes, applications and drivers for an OS kernel. In that case, maintaining compatibility might be so much a hassle that you don't bother replacing anything. Give an inch, and people will take miles of shortcuts and tweaks on standards. They will be slow to fix errors, will lobby to modify or make more flexible standards to match their implementations, and will generally achieve '<a href="GoodEnough.html">GoodEnough</a>' compatibility. (I speak from experience on two standards bodies for unmanned systems.) If they have automated tests and benchmarks that 'score' them, that gives a goal - something they can shoot for 100% compatibility and 'better performance' on - but building such tests before the reference has been forked is not easy to perform without <a href="BigDesignUpFront.html">BigDesignUpFront</a>, and will likely become (as it so often does in practice) a painful and very political exercise at reining in the deviants. The reference implementation doesn't have to be "kept". It may only start the ball rolling, like Mosaic did. But for the most part anything that worked on Mosaic still works on modern browsers. Thus, if the original reference implementation provides decent and relatively simple <a href="CrudScreen.html">CrudScreen</a> idioms and behaviors, the future ones are likely to also. -t Indeed, you are quite right on both those points. One is unlikely to devolve from the reference implementation (which is, in part, why Microsoft will have a hell of a time sabotaging HTML++). That said, giving you these points is irrelevant to the overall argument, which is (if you've forgotten) about avoiding the need for explicit (server-side) cross-client compliance tweaks. The HTML++ stack is relatively easy to sabatoge because it's shear complexity provides plenty of "legitimate" opportunities. For example, they may out-of-the-blue decide to fix a bug in IE+1 that a popular widget or kit relied on to exist. Or place a pop-up confirmation message on XMLHttpRequest, claiming it a "security precaution". Thus would undermine the usefulness of <a href="AjAx.html">AjAx</a> in one fell swoop. MS pays people millions to think up things like this and thus it will be better than my guesses. Sure, they can attempt such sabotage, but (a) it would be dreadfully obvious to everyone, (b) it would break their own pages and other popular pages - even <a href="MicrosoftSilverlight.html">MicrosoftSilverlight</a> relies on <a href="AjAx.html">AjAx</a>, (c) if they fix a bug in IE+1, the other people will fix their kits. <ul> <li> Regarding "(b)", what MS could do is create a service similar to Java applet signing such that it has to go through a "signing" process. MS could register all their stuff and charge for others to do the same, with bureaucratic and/or Windows-centric rules. </li> <li> I don't see how this qualifies as sabotage. </li> </ul> <ul> <li> Regarding "(c)" - Such would create "update panics". You come in Monday morning and a mission-critical app no longer works because MS updated their DOM engine. The widget vendor, if they still exist, may have a message on their website that they were recently made aware of the problem and are currently working on it. It's a week before they release a fix. You may have a dozen apps that have to wait. </li> <li> It won't work with IE+1, you mean. But you can tell your clients to hold back on upgrading til you've fixed your site, or direct those who have updated to use an alternative browser until your site is compatible with Microsoft's changes. Sure, this is far from ideal, but it also isn't unusual - users expect such delays because they've grown used to living far from ideal (<a href="WorseIsBetter.html">WorseIsBetter</a> and <a href="FutureDiscounting.html">FutureDiscounting</a> motif). </li> <li> True, but it's yet another hurdle that HTML++ puts on the industry. "Just get used to it's downsides" can be used to justify anything. Further, I've seen changes in IE from MS security updates, not necessarily version changes. </li> </ul> <ul> <li> If your survival is threatened enough, then obviousness and breaking your products that are marginal products anyhow is not going to be reason enough to stop. And like I already pointed out, there are smaller things that may not be so obvious or news-worthy. Death by a thousand ant bites may be their approach instead of a single gorilla. MS's "security" updates break software and drivers all the time. They don't give a sh8t. Look at VB6 or the recent Active-X-Pluggin-in-<a href="FireFox.html">FireFox</a> mess. </li> <li> If your survival is threatened enough, then obviousness and breaking your products is tantamount to suicide. VB6 could do so due to lack of serious competition - its survival was not threatened. Microsoft disables most of ActiveX by default in IE 7 due to security issues, and has a neat little security box for its own software. You are not making a convincing argument here, <a href="TopMind.html">TopMind</a>. </li> <li> Java was the "serious competition" that triggered the change. MS was afraid of Java, and thus they made the tradeoff and ended up pissing off many shops. C# copied many Java features and Java's "feel". MS was previously leaning toward a scriptish feel to their language family, but abandoned that trend to match Java. This shows MS will cast off a limb (VB customers in this case) to protect the body itself. </li> <li> Further, they had Delphi, <a href="PowerBuilder.html">PowerBuilder</a>, and <a href="RealBasic.html">RealBasic</a> lurking in the back-ground. Your assessment that they had no "serious competition" is poor. I never even heard of <a href="RealBasic.html">RealBasic</a> until that episode. <a href="PowerBuilder.html">PowerBuilder</a> used to have full-page ads in all the main IT magazines showing VB source code compared to their own (which was allegedly smaller for common data-oriented activities). </li> <li> And, please don't tell me when you disagree with me. Instead, tell me when you agree. This will reduce text. -t </li> </ul> Please explain the server-side sentence. -t While you pulled a quote about 'reference implementation' in particular, the initial reason you were arguing the benefits of a single <a href="OpenSource.html">OpenSource</a> implementation is to avoid issues like <a href="JavaScript.html">JavaScript</a> today where the code must include 'variations' for different clients (such as Internet Explorer vs. Firefox vs. Opera). Either these variations must be stored on the server and shipped to the client OR must actually run in 'tweak-mode' on the server. This is what I mean by 'server-side cross-client compliance tweaks'. You seem to be under the impression that an initial reference implementation will ultimately avoid need for these tweaks, but in truth you'd need to guarantee much more to achieve compatibility while avoiding these tweaks: pixel-perfect representation, along with communications compatibility. <a href="JavaScript.html">JavaScript</a> was originally meant to be a client-side application language for domain-specific behavior not handled by strait-HTML. However, because people want richer GUI's, it gradually has shifted toward being used as a SystemsProgramming language because using it in web-apps it does not require downloading extra junk to get desired UI behavior. (The main reason for using web-apps' is the advantage over desktop EXE's in not having an "install" step). If the primitives of the "base" fit closer to the UI needs, then sending-an-entire-gui-engine-inside-<a href="JavaScript.html">JavaScript</a> would NOT be needed. If there ever comes a time that <a href="GuiMachineLanguage.html">GuiMachineLanguage</a> cannot handle the base needs because of changes in UI conventions or needs happen, then it may again be time to do the same and create a new standard rather than over-stretch the existing standard. There's a point where starting over is better than bending an existing standard so very hard that it hurts. The HTML++ is either very near that point or past it. <hr/> Re: 'Proprietary is irrelevant because it is not a contradiction to 'Rich GUI', and is not a "scaling" issue.' Please clarify. By 'scaling issue' I was thinking in terms of 'reaching a technical limit'. Being proprietary isn't relevant to your 'working definition' of 'Rich GUI' and it isn't a technical concern (i.e. there is no technical reason to believe that whatever straw breaks HTML++ will also break a proprietary hedge on the basis that it is 'proprietary') therefore whining about a hedge being 'proprietary' isn't a relevant complaint, at least not in the above context. There are contexts in which OSS vs. proprietary may be relevant, but achieving 'Rich GUI' or '<a href="CrudScreen.html">CrudScreen</a>-friendly' is not among them. I meant an OSS hedge. <hr/> I've also noticed that HTML++ apps based on <a href="AjAx.html">AjAx</a> or Ajax-like technologies never "finish" drawing a page. The "spinner" indicator never stops. (Not sure what they call it now, but it used to be a spinning globe or logo in the upper right corner.) Really? Go to <a href="http://dbappbuilder.sourceforge.net/Rel.php">http://dbappbuilder.sourceforge.net/Rel.php</a> and see it it does that. It doesn't do it for me. It uses <a href="AjAx.html">AjAx</a>. My error, I forgot to say "some". I apologize. By the way, that site look like it could have done fine with plain-jane HTML. That would reduce risk of new-version-breakage. It may be an <a href="AbstractionInversion.html">AbstractionInversion</a> and/or <a href="ResumeMasturbation.html">ResumeMasturbation</a>. That's a little harsh, isn't it? Do you always assume the worst motivations? <ul> <li> I did say "may", suggesting it's merely a possibility rather than wording it as a known fact. And I didn't know who authored it at the time. If you were offended, I apologize. </li> </ul> As it stands, yes, it wouldn't be significantly different using plain-jane HTML, except for a bit slower page-to-page navigation and the usual unpleasant page refreshing. However, it's a test-case for the core of a new CMS framework I'm working on to replace my old CMS framework, and it uses <a href="AjAx.html">AjAx</a>. {The 'spinner' indicates that the HTML pipe hasn't been closed. It's actually a property of HTTP streaming (<a href="http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push),">http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push),</a> and not of <a href="AjAx.html">AjAx</a>. The primary utility of this feature is to achieve low-latency updates (in the milliseconds range, instead of seconds), so you're most likely to see it in highly interactive or multi-user <a href="AjaxWebApplications.html">AjaxWebApplications</a>. Not all <a href="AjaxWebApplications.html">AjaxWebApplications</a> use HTTP streaming.} <hr/> Sabotage Via Gradual Standards-Compliance Here's an example of how Microsoft can sabotage HTML++ frameworks in a gradual way by "improving" their standards compliance. Typical HTML++ JS code looks something like this: <code> // activity A If (non_IE_browser) { dom.page1.featureA.normal_way(foo); } else { dom.page1.featureA.different_way(foo); } // activity B If (non_IE_browser) { dom.page1.featureB.normal_way(foo); } else { dom.page1.featureB.different_way(foo); } ...etc... </code> <ul> <li> [That isn't how cross-browser <a href="JavaScript.html">JavaScript</a> is written. It's well-known that more recent IE versions are progressively adding support for standard features, so no robust JS works by checking whether the browser is or isn't IE. "polyfills" implement newer standard JS features, but only if they don't already exist, falling back on the native implementations in modern browsers (including IEs that implement the new features!). Tools like <a href="http://modernizr.com/">http://modernizr.com/</a> operate on the principle of feature detection rather than browser detection, and conditional comments are used to patch around particular bugs in old versions of IE. It's simply not an option to "sabotage" the W3 standards by progressively supporting them more and more, because all decent cross-browser code will do nothing but benefit from it. -DavidMcLean] </li> </ul> <ul> <li> Please elaborate on the last sentence, especially regarding "benefit". Yanking or changing implementation for a feature is generally their main tool for subterfuge, not adding. -t </li> </ul> <ul> <li> [Polyfills implementing a missing feature are typically inferior to native support for the feature; there may be an execution performance hit taken by reimplementing the feature in JS, for example, and there will definitely be a (probably small) hit taken loading over the network the extra code to implement the feature. Thus, improving your browser's support for standards, which permits cross-browser code to use native implementations of features rather than polyfills, will benefit the code. As for your other point, yanking features or changing their implementations does not correspond to your original argument, that being that MS would progressively improve their support of the W3 standards - the standards do not specify features that are not provided, so removing a feature is not moving closer to the standard, and a changed implementation would have absolutely no impact on client code since it's an implementation rather than an interface. A change in interface, which can occur if features are implemented based on draft standards (the flexbox specification is an example), does require client code to be tweaked accordingly, but this is well-known and is already accounted for in the feature detection process: Typically the older versions of the spec are identified as a separate feature and may be handled separately. When IE does implement the newer versions of specs, feature detection picks this up, and therefore the right client code for the newer version will automatically be brought in. -DavidMcLean] </li> </ul> <ul> <li> Regarding native widgets versus GUI-browser-drawn widgets, I'll take cross-platform consistency over speed if the first is <a href="GoodEnough.html">GoodEnough</a>. At least give the UI designer a choice whether to allow native widgets to render something versus the browser library. Intranet projects may be more likely to use native than Internet or biz-to-biz because an org's internal environment is often more controlled or known. As for the rest, there appears to be a misunderstanding. I'll ponder a better way to explain it. </li> </ul> <ul> <li> [Well, yes, of course you'd take cross-platform consistency over speed. That's why we have polyfills, to create cross-platform consistency with a minor speed cost on the nonstandard platforms. Native implementations of the same features remain superior to the use of polyfills, trivially, since a native implementation of a standard feature implies the same consistency without the speed hit. I'm not sure why you're specifically drawing a distinction between native widgets and GUI-browser-drawn widgets, however; I speak of features, such as HTML5's <canvas>, CSS3's flexbox, and JS's localStorage, EventSource, etc. While it's true that HTML5 introduces aspects such as <input type="date">, <audio>, and <video>, which could be viewed as widgets in a sense, the development and progression of the standards are by no means focused on such things. Far more important is the introduction of generic, flexible features that afford previously-inaccessible base functionality - for example, as there was no standard way to include audio or video in an HTML document, these added tags are first-and-foremost introducing new basic functionality. Additional input types are as important for semantics of markup as they are for widget purposes. -DavidMcLean] </li> </ul> If MS wants to sabotage an emerging desktop-like web standard, they could gradually "fix" their HTML++ such that it requires the "normal_way" methods. Code like above would break. (Often it's more than just method name, but rather a different way to go about it entirely. The example is simplified for illustration purposes.) And they could do this gradually. There's probably hundreds if not thousands of areas where IE differs enough that conditionals/polymorphism like above are required. MS could break ("fix") say 5 a year, perhaps targeting the biggest implementations of the emerging CRUD-friendly HTML++ standard(s). They couldn't be accused of "violating standards" by the monopoly police since technically they are becoming more compliant by fixing these differences. (I can picture Balmer laughing in a meeting, "Ha ha, they want compliance, then we'll give it to them!") It has been suggested that changing their engine would also damage MS web-oriented products. First, most MS's web-oriented products are not selling very well. They may decide the sacrifice is worth it. Second, MS can plan a year or two ahead of the game, giving repairs time to propagate. Only they know what they are going to fix down the road, not competitors. Their HTML++ components could be prepared by having JS such as: <code> If (non_IE_browser || IE_version > 7) { // note version clause dom.page1.featureA.normal_way(foo); } else { // older IE dom.page1.featureA.different_way(foo); } </code> (Sure, competitors can monitor MS's <a href="JavaScript.html">JavaScript</a> to look for such oddities. However, copying them is difficult without the ability to test them. The context is likely to be too different. MS has access to their own alpha versions, but not others.) Since JS tends to be downloaded upon each use in HTML++ land, the fix would quickly be available. And for desktop-bound stuff, Microsoft's standard update system could take care of most of those. The OSS world is too de-centralized for any such fixes to propagate fast. I was just reading about Windows 7 the other day. It uses semi-subtle techniques to "encourage" Windows users to become more dependent on Microsoft Network. Coincidence? <hr/> <ol> <li> /15/2012 - <a href="HtmlStack.html">HtmlStack</a> still sucks. HTML5 is mostly entertainment improvements and untested. Time for a real GUI replacement standard. </li> </ol> <hr/> External Links <ul> <li> Standards Potpourri - <a href="http://www.infoworld.com/d/developer-world/html-still-not-all-its-cracked-be-591">http://www.infoworld.com/d/developer-world/html-still-not-all-its-cracked-be-591</a> </li> </ul> <hr/> See also: <a href="WebBrowserMissingWidgetWorkArounds.html">WebBrowserMissingWidgetWorkArounds</a>, <a href="GuiMarkupProposal.html">GuiMarkupProposal</a> <hr/> <a href="CategoryGui.html">CategoryGui</a>, <a href="CategoryInternet.html">CategoryInternet</a>, <a href="CategoryMicrosoft.html">CategoryMicrosoft</a>, <a href="CategoryWebDesign.html">CategoryWebDesign</a> <hr/> <a href="OctoberZeroNine.html">OctoberZeroNine</a> </div> </body> </html>