
The web as a GUI toolkit - pcr910303
https://www.arp242.net/webui.html
======
mrec
> _With the web almost everyone has a machine that has a programmable
> environment by default again. I feel this is a very important and powerful
> advantage that’s often overlooked._

As someone else who cut their teeth on an 8-bit micro back in the day, I agree
with this 100%.

And I think it's a large part of the reason I'm so suspicious of the stampede
in webdev toward _very_ heavyweight toolchains over the past 5+ years; while
they may have had the best of intentions, I think they do end up putting
gatekeeper-ey accessibility barriers around the web's original rough
democracy. It's not that the underlying technology has gone away, more that
when someone starts looking around the mainstream web to see how things are
put together, that's not what they're going to find.

~~~
IshKebab
I agree. Node, webpack, npm, babel, etc. all add a huge amount of friction to
getting started. It doesn't help that they're all overly complex and every
little thing has a different tool or configuration file.

It's a huge complex house of cards that nobody really wants to have to deal
with. Compare it to writing a Qt app, or even something like a Flutter app.
You pretty much just install an SDK and go file -> new project.

~~~
kls
Personally I would argue that it is no more complex than JSP/JSF/Spring or
ASP.NET/Web Components / Web Forms, then you have to bolt on server side
session management, state transfer and the other patterns that emerge from
sending everything to the server. In my opinion doing all of the UI
interaction on the client is easier to reason about and simplifies state
management.

Now I would tend to agree that classic ASP / PHP was conceptually simple and
probably simpler than the current client side landscape, but they where beasts
at scale.

I am not arguing that the current state of client side is where we want to be,
but in a lot of ways it beats where we have been, and that is how we got here.
It will never compete with desktop development because the web just injects a
while host of complexities into the mix that you circumvent with desktop where
you are delivering from the run-time up. For better or worse, the browser, the
webserver and the middleware stack all dictate how we get to go about building
applications for the web.

~~~
unlinked_dll
That sounds ridiculously more complex than clicking "new project" and just
going with it.

~~~
kls
No, I want to be clear, I certainly was not arguing that point, just making
the point that I view the current state as an advancement over where we have
been, in relation to past web development trends.

------
throwGuardian
Agree with all the pros stated in the article. However, there are cons:

1\. Each desktop app is shipping almost a full browser, updating it
independently and bloating RAM, storage and CPU utilization in the process.

2\. RAM/CPU bloat issues are real - even the V8 team advices against
overreliance on excess RAM. They've noticed a speed increase in the process of
releasing V8-lite aimed at aggressive gc

3\. Even amongst the most mature GUI frameworks based on html/js, there's far
too much overhead for trivial things, like reading/writing to file. For
instance, in electron, since the browser V8 context isn't allowed willy-nilly
storage access, a file read from the browser V8 goes across a couple IPC
requests to complete. Also, these hops aren't widely documented and
understood, making desktop apps janky by default, instead of fast by default

~~~
sdegutis
I wonder what would happen if all major OS & Browser vendors decided to agreed
on a long-term plan to migrate/evolve the HTML, CSS, and JS specs &
implementations towards a functional equivalent variation that could be
efficiently implemented with the same semantics and level of security (or
better) but with far less CPU and memory inefficiency, removing indirection
and dynamic abstraction layer by layer, until suddenly we get something that
has all the legitimate benefits of modern web development, but with the same
memory/CPU footprint of Cocoa or .NET, being also cross-platform and built
into every OS. Wouldn't that be great?

~~~
jerf
Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in
our browser. I expect an explosion of alternate layout mechanisms to arise
from that. They won't be very good at first, but they may end up somewhere
neat.

~~~
c-smile
> I expect an explosion of alternate layout mechanisms.

No need WebASM for that. Just one CSS property:

    
    
        div {
          flow: custom [funcname/url(of-layoout-controller)];
        }
    

\+ single function funcname() that will replace children and report min/max
intrinsic sizes.

~~~
Sophistifunk
Wait, is this real? What's it called, so I can google it?

~~~
SahAssar
I'm guessing he's talking about [https://developer.mozilla.org/en-
US/docs/Web/Houdini](https://developer.mozilla.org/en-US/docs/Web/Houdini)

------
skrebbel
Kinda off topic, but the MSX was amazing. We had one too, it was my first
computer too. I vividly recall it came with two 200-odd page printed manuals,
both in my native Dutch. One for MSX-DOS, which told you how to launch a word
processor and print documents.

And one for MSX-BASIC. The manual, sent to every consumer's home, taught you
what variables and subroutines were. It had pictures of jars with $A printed
on the outside that you could put a 5 in and the later put a 6 in. In Dutch!
In my home! I was 10. I was learning programming but I didn't know I was - I
thought I was just learning the computer.

Years later my parents got me a "programming with superlogo" book and only
then I discovered that I already knew how to program. That was pretty odd. <3
MSX and whichever Philips exec decided that consumers needed programming
language manuals.

~~~
AnIdiotOnTheNet
> I was learning programming but I didn't know I was - I thought I was just
> learning the computer

Back then these were not really separate concepts. Frankly, I don't think they
should be nearly as separate concepts today either but nearly everyone making
software seems to disagree.

~~~
andai
One thing I hope will come out of a more code literate society (looks like a
lot of high schools are teaching it now) is that, all software will be written
assuming every user knows at least some scripting.

Often I clone a piece of software because I want to change just one thing, or
even if it's open source I often need to set up a build environment etc... and
I just wanna change like one integer!

~~~
AnIdiotOnTheNet
> all software will be written assuming every user knows at least some
> scripting.

I don't know if that's what the answer is. I prefer the idea that computer
usage naturally flows into computer programming. Take the most used
programming environment in the world: Microsoft Excel. It can be used very
simply as a table of words and numbers, but if you want to do more with it
there are formulas, and when you reach the limit of that there's VBA. We used
to have tools like HyperCard that allowed people to build simple GUI
applications with no traditional programming language whatsoever, but also had
one baked in for when you grew beyond the WYSIWYG editor's capabilities. That
sort of thing basically no longer exists, and to the extent it does it is
merely a copy of what existed before instead of an evolution.

> Often I clone a piece of software because I want to change just one thing,
> or even if it's open source I often need to set up a build environment
> etc... and I just wanna change like one integer!

Yeah, it'd be really great if more software was written with flexibility in
mind. I want to have an API for interfacing with everything, I want to setup
my own custom hotkeys, etc. I can kind of get there today with things like
AutoHotKey, old Macs had AppleScript, Plan9... existed, but it is kind of
ridiculous that this sort of thing isn't baked in to modern computing.

------
themodelplumber
This seems a good starting point for a complex yet possibly constructive tool-
related discussion.

I recently started building a bunch of personal productivity and hobby apps
using Lazarus / Free Pascal, because there are quite a few things I didn't
want to deal with from the web development world:

\- Constant browser upgrades that can instantly change how well your JS tools
work, especially if you integrate third-party components like CKEditor

\- The sheer number of different types of updates that are spread across
various front- and back-end contexts: HTML, CSS, JS, and PHP/More JS/whatever,
but then you've also got to consider your choice of editor / coding
environment, whether you're using SASS, any deployment tools, fonts and font
services, etc.

\- Having a single binary to use vs. needing to open a web browser which will
then try to tie everything together for you, meanwhile maybe you have good
reason not to be using a web browser at all

\- Working with tons of files that exist locally, and will always exist
locally, and which you don't want to add to a server or the cloud (doable via
the web tools but just a bit weird in its way)

It's been nice to just build a thing I need and see it immediately fit into
normal native desktop app characteristics, meanwhile I can focus on the
productive logic and workflow. But that doesn't really even sum it up, does
it? You can do _something like that_ on the web...it's just different.

I found myself with ample time to design an icon for my latest desktop app,
having completed all the main functions, and caught myself smiling at the
thought--it was a good feeling.

~~~
Sophistifunk
Does Lazarus have a good GUI story on MacOS yet?

~~~
badsectoracula
Good, no, but there is a working one. The Carbon backend is still the best
"native" option, though thanks to Catalina that isn't really an option
anymore. The Cocoa backend has issues, but nowadays gets all the effort so
things will improve faster than previously (but you most likely want to check
the development versions).

The most stable and featureful backend is most likely Qt though, largely
because it is also used by people on Linux. There aren't that many Mac
developers after all (and Apple doesn't make it exactly easy for them).

In any case, macOS will always be a sort of "third wheel" for Lazarus since it
is the most "alien" to the way it works. After all the API was designed (by
the Delphi developers) for Windows and it feels most comfortable in Windows-
like environments.

Of course IMO even that is much better than a web-based environment which
doesn't feel comfortable anywhere :-P

------
reggieband
I am extremely negative on HTML/CSS as a ui framework. Yet like many, I have
been paid well to come over to the dark side of Javascript app development.
The opening section in this article is one of the first times I've agreed with
some positive view on the benefits of the environment. Zoom really is a cool
feature that is not easily possible in more traditional GUI frameworks.

I also have to begrudgingly admit that nowadays I can mostly create really
nice interfaces with very little effort. This is thanks to browsers finally
reaching an acceptable level of compatibility (anyone remember Acid CSS test),
Javascript/Typescript evolving with genuine improvements (e.g. async/await),
flex layouts (and soon grid!). There is still huge room for improvement but it
isn't anywhere near as bad as it once was.

------
divan
I'm so on the opposite side of this opinion.

To my view, the better tech aligned with the problem domain, the better off
are developers and end users. Using typesetting format for rich UI apps is so
far from what UI toolkits need and has created enormous amount of pain, losses
and security vulnerabilities. Making it the _only_ available option on the
dominant software platform (web) made it the worst cataclysm in the UI
software industry.

Like, in a slightly different turn of events, it could be Lotus or Excel
spreadsheets format as a GUI framework. You can easily imagine how XLS becomes
the dominant monopoly in UI toolkits and evolve chaotically to accommodate web
demand for UI features. After decades of evolution and billions of lines of
XLS and VB scripts, one could easily find "some things that work very well"
with spreadsheets as a GUI toolkit approach. It doesn't make it a good fit,
though.

Why would anyone think that using text markup language for UI apps can be a
good idea?

------
c-smile
If to speak about browser technology as a GUI toolkit then there are three big
things that are greatly underestimated.

1\. Bubbling/Sinking(Capturing) event propagation schema.

With that schema a container knows what event is passed to a child and did
child process it or not. On desktop, windowed widget handles all its events
without notifying/asking its container.

This actually is pretty big - it enables composition of atomic input widgets.
On Web you can use <input|text> as part of more complex widget.

2\. CSS and CSS selectors in particular.

As the way of styling component from outside - independently from its event
handlers/code.

So code changes DOM state and CSS defines how that state shall be presented.
And not only that but styling of elements in context (cascading).

That is "separation of concerns" at its best.

3\. And the DOM.

While each UI system has DOM ( tree of windows/widgets ) in one form or
another the Web pushes its further: it adds unification of widget
(attributes/states) interface.

Any widget or element may have ID, class or other attributes defined. And
those can be used for styling.

~~~
ridiculous_fish
GUI toolkits certainly allow for containers to act on events before their
children. For example sendEvent: and hitTest: in Cocoa.

The web's event handling is comparatively clumsy. It is cast in terms of
"listeners" which are unable to directly control the event routing. Instead it
exposes fixed, ad-hoc levers: stopPropagation, stopImmediatePropagation,
preventDefault, etc. And because there's no good place to put these methods,
they have to go on the event itself, which means that events are mutable (!).

~~~
c-smile
"sendEvent: and hitTest: in Cocoa"

That is cooperative event propagation. Means it works only when widget
cooperates by itself - designed to be embeddable and expandable - so it
notifies its container about events inside.

Example: try to catch right mouse button click on NSButton instance. Good luck
with this.

"clumsy"

I wouldn't say so. I am doing UIs professionally quite a long time and can
prove that WWW's Event/Sinking event propagation + ability to subscribe to
event by JS closures is the most flexible schema so far. It is a functional
superset of events handling architectures of Windows and any toolkit there,
MacOS/Cocoa, GTK and QT.

------
granshaw
Ctrl+F ability is so understated. I often use mobile sites rather than their
respective apps precisely so I can Ctrl+F to find what I'm looking for on the
page quickly

~~~
GuB-42
To be honest, many apps are nothing more than a crippled browser showing you a
website.

Also: [https://xkcd.com/1174/](https://xkcd.com/1174/)

------
mrighele
I had a similar experience in my youth (just replace the MSX with a C64). The
author is right when he says that programming a PC (either in DOS or Windows)
was non obvious; but once you realized that the best way was to use a
spreadsheet or a database engine, you could get a lot done quite easily. Those
tools may not be as generic as Python or Perl, but you could program whole
applications in a fraction of the time.

As for the web, I think it is still harder than it could be, and the browsers
make it more difficult every day, since they put more and more restrictions
when opening a local page.

------
nitwit005
There's kind of a big bump in using HTML/CSS/JS. It's easy to slap together
some simple stuff, or fiddle with a web page, but you'll hit a certain point
where you want your app to do something useful. Suddenly you'll be stuck
reading about webservers, databases, Electron, and whatever else.

In some ways it's still easier to make a basic Java Swing application. You can
just install Java and start working through tutorials.

------
dzonga
the great thing about the web is universality. no one controls the platform
yet. although, that could change, as browser engines consolidate. The web,
also allows you to be OS agnostic. most of my work is done via the browser.
with the only native programs I run being a media player eg vlc or smplayer
since linux doesn't handle gpu video decoding and some terminal windows. with
tools like Figma etc. Web programs are here to stay and win. Though we suffer
a regression in usability with people who abuse tools like React etc

------
austincheney
Building a browser GUI is simple. I would even argue extremely trivial. Here
is a video demo of one I built in the not too distant past (github link at the
end):
[http://mailmarkup.org/sharefile/demo1.mp4](http://mailmarkup.org/sharefile/demo1.mp4)

It took me a little more than 2 weeks to write and test the GUI in that video.
From this experience I have learned the following:

* If you are comfortable working with the DOM and vanilla JS you should be spending more effort writing the content and services that populates the GUI rather than the GUI itself. I would say this ratio of time should be something like 20% GUI and 80% content starting out and scaling towards greater content effort as the requirements upon the GUI increase.

* A JavaScript based GUI can be extremely fast and responsive. The video demo was captured on a 4k resolution and it performs, at least to human interaction speed, just as responsively as the OS's GUI even in VMs. That high resolution also explains why the video text is hard to read on a small mobile device. I intentionally wrote this to be fast though using vanilla JS and the standard imperative DOM methods, because that is the fastest way to execute things in the browser. It stands to reason if you go about things in a much slower way it will likely perform slower, possibly slow enough that the user notices a huge difference.

* A JavaScript GUI can be extremely lightweight with tiny code. This is only true if you are comfortable working with the DOM without a bunch of code decoration and abstraction nonsense.

* If the code is organized well it will scale well even in the face of numerous competing enhancements. I solved the problem of scale with TypeScript interfaces and constant refactoring.

* There is one aspect that does not scale well, which any feature that requires complex algebra. One example is dragging a highlight rectangle over some elements for a mass selection and ensuring that highlight rectangle is confined to the containing element and that it knows which elements of the parent element are visually occupying the same space and which ones aren't. Another example is that the CSS property text-overflow only works if dimensions are statically available to the current element or its parent node. That means calculating a dimension for an element in order to set the value upon the element, which requires some calculation written by you instead of relying upon something like _display:block;width:auto_.

* All presentation, and I do mean absolutely everything except dynamically modified _display_ , _opacity_ , _position_ , and specified dimensions should be in CSS. The presentation that is not in CSS is directly on the DOM node by dynamically reassigning new presentation values on user interaction where necessary. This allows for smaller and more scalable code.

* All icons are Unicode characters. The only one other graphic, because the desktop background, is an SVG spinner. SVG, being XML, can be adjusted with CSS just like the rest of the DOM.

~~~
Sophistifunk
Got some links where I can read more about this?

~~~
austincheney
Just the code: [https://github.com/prettydiff/share-file-
systems](https://github.com/prettydiff/share-file-systems)

------
tsukurimashou
Funny thing is these three points:

\- Copy/paste anything.

\- Search any text with e.g. Ctrl+F.

\- Back button.

Tend to disappear with javascript frameworks, single page applications, ajax,
and websites partially or fully rendered with canvas

------
baybal2
Web is very inferior to any modestly well done UI toolkit.

~~~
guggle
As someone who spent most of his time in the last 20 years building web
application and only recently (2 years) started using gui toolkits (mostly QT
but also wxwindows), I certainly can relate to this. What a breath of fresh
air... consistent UI, no fiddling with half-assed components or soon-to-
disappear frameworks, no time wasted reinventing the wheel, excellent
performance, no markup/code dichotomy... Great results with ease, I wish I
made the jump earlier.

------
mirimir
I mostly write stuff for others, and they do what they want with it. Or for
GitHub.

But my own stuff only goes on Tor onion sites. So it's strict HTML, because
Tor's latency punishes client-server dialog. And also because people will hate
on you for scripts.

Also, I thought that this might be about WebGUIs. Such as the pfSense WebGUI,
which still amazes me in its depth and usability. Or indeed, that you can
route the WebGUI of a remote pfSense VM as a Tor onion service, and manage it
just as easily as the box in the closet.

------
malkia
yup it is :) fossil ui - runs the browser as UI (from [https://www.fossil-
scm.org/home/doc/trunk/www/index.wiki](https://www.fossil-
scm.org/home/doc/trunk/www/index.wiki))

one of the first examples I've seen, but not the only one.

