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

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

Some counter-beliefs include:

Microsoft Sabotage

Possible ways to sabotage

JavaScript as SystemsSoftware

Version-Mania

Widget Download

Web Conventions Sufficient

Reference Implementation

Re: "...just ignore how having only one implementation [of GuiMachineLanguage] 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 MySql 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 TopMind decided to wear it'. You're the one who identified your own assertions about GuiMachineLanguage with a generic statement of WishfulThinking. You managed to put my words in your mouth without any extra prompting from me.

Anyhow, people RewriteCodeFromScratch for a variety of reasons, not all of them good. NotInventedHere. 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 'GoodEnough' 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 BigDesignUpFront, 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 CrudScreen 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 AjAx 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 MicrosoftSilverlight relies on AjAx, (c) if they fix a bug in IE+1, the other people will fix their kits.

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 OpenSource implementation is to avoid issues like JavaScript 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.

JavaScript 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-JavaScript would NOT be needed. If there ever comes a time that GuiMachineLanguage 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.

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 'CrudScreen-friendly' is not among them.

I meant an OSS hedge.

I've also noticed that HTML++ apps based on AjAx 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 http://dbappbuilder.sourceforge.net/Rel.php and see it it does that. It doesn't do it for me. It uses AjAx.

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 AbstractionInversion and/or ResumeMasturbation.

That's a little harsh, isn't it? Do you always assume the worst motivations?

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 AjAx.

{The 'spinner' indicates that the HTML pipe hasn't been closed. It's actually a property of HTTP streaming (http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push), and not of AjAx. 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 AjaxWebApplications. Not all AjaxWebApplications use HTTP streaming.}

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: 

 // 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...
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: 

  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);
  }
(Sure, competitors can monitor MS's JavaScript 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?

05/15/2012 - HtmlStack still sucks. HTML5 is mostly entertainment improvements and untested. Time for a real GUI replacement standard.

External Links

See also: WebBrowserMissingWidgetWorkArounds, GuiMarkupProposal

CategoryGui, CategoryInternet, CategoryMicrosoft, CategoryWebDesign

OctoberZeroNine

EditText of this page (last edited July 22, 2014) or FindPage with title or text search