
GUI's still the pinnacle of productivity, let's help them out - tabtab
Ignore specific technologies, standards, and programming languages for a thought experiment. What&#x27;s the most productive UI design for regular office productivity? The answer is still GUI&#x27;s, a technique that&#x27;s several decades old. All the focus on finger-based mobile and social networks hasn&#x27;t changed this fact.<p>While it may be possible to build a highly-productive mobile-style UI, it&#x27;s difficult to get right and&#x2F;or requires more user training. The mobile UI world is a sub-set of GUI idioms, for the most part. This means you are more constrained; working with a smaller pallet.<p>Desktop-style GUI&#x27;s can fit more on a given screen because the pointer is smaller compared to finger aiming, can have roll-over text for cryptic icons, right-click options, nested pop-ups for drilling down into progressively further detail, and others.<p>Emulating full GUI&#x27;s in web browsers has proven tricky. The emulation libraries are huge and often break when new browser versions or brands come along.<p>If the industry faced the fact GUI&#x27;s are not going away any time soon, perhaps it would form a good GUI-over-HTTP standard. It could roughly resemble Microsoft&#x27;s GUI XAML, but be cross-platform, &quot;stateful&quot;, and interactive. The Tk or Qt engines maybe can serve as the base for a &quot;GUI browser&quot; or browser plug-in.
======
ktpsns
XUL (Mozillas XML-based widgets) or JWS (Java WebStart) seem dead, but I don't
know why. They could provide exactly what you ask for -- zero install rich
interfaces with better performance then HTML-based ones.

~~~
tabtab
I found XUL kind of cryptic and round-about. Maybe its philosophy somehow paid
off in the longer run, but it's not newbie-friendly, discouraging fiddlers and
experimentation.

And Java damaged its client-side reputation via the Applet fiasco. Namely
over-extending itself by trying to be an entire virtual OS, and not paying
enough attention to security.

Lessons from these: K.I.S.S., don't drift from mission, and security matters.

~~~
przemo_li
Actually, what killed both is market size.

Internet boom === small simple apps where emphasis is either on looking good
or being very responsive.

That meant that vast majority of developers where not in a market for rich GUI
stuff, but for better CSS and smaller size.

OTOH desktop never rewarded simple apps. Distribution and marketability asked
for more features exposed via GUI, thus most developers where OK with bigger
in scope GUI stuff.

As for "next browser breaks your stuff" excuse, I think it wasn't true for a
very long time now. Include polyfills, css defaults reset, do transpiling into
less features and you are good to go.

OTOH, web underwent multiple groundbreaking shifts in computational models.
This is why complex but somewhat encapsulized/localized Angular/Ember won over
spaghetti inducing predecessors and why truly encapsulated/localized Reacts
eats old Anguler for breakfast.

One last point would be about crazy stuff in programming languages /
programming paradigms that was already available in 60's and 70's at least as
a statements of need. Those made for very stable platform on which GUI
ecosystems could be build. Relative instability of JS with generational
changes can explain why it gets a new ecosystem every few years.

~~~
tabtab
Big GUI apps don't need a big download packet, assuming a good "GUI browser"
that can shift most domain logic to the server. Just make each
window/form/panel an independent packet. An application can have say 5,000
forms, but if you only activate 30, then it only downloads 30 (plus a few
reference files for constants and defaults. A pre-loading a larger set perhaps
can be on option.)

Re: _" As for "next browser breaks your stuff" excuse, I think it wasn't true
for a very long time now."_

I'm not convinced yet. It may be improved, but not solved (mostly because IE
can finally be considered dead.) The current candidates have long learning
curves, are version fragile, or both. Corporate products tend to target
specific browser(s) to reduce the version risk, but that's not really solving
the problem, it's reliance on a mono-culture just like MS-Windows.

Regardless, IT still needs a stateful GUI markup standard, at least to help
desktops be cross-platform. It would improve desktop standardization even if
the Internet ends up ignoring it. The X Window System is a useful idea, but is
designed for LAN's instead of WAN's and internet, partly because it doesn't
buffer UI i/o, creating too much interaction latency.

