Hacker News Reader

Comment by ndriscoll | Hacker News Reader

Beyond the fact that almost all web "apps" are actually honest documents, let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious. Every single application used to have a more powerful version of that by default. There were GUIs for users that were simple enough to find and use that my 90 year old grandma had customized the theme on her windows 98 machine.

View on HN

Kinda like TUI in most terminals where you have 16 colors by default, but those are dependent of the user themes. And it’s quite easy to create a theme engine.

Most GUI suffers from the NIH sydrome. Instead of using system components (and systems values and colors), every designer are pushing for adhoc widgets with fixed values.

Its not the GUI developers fault usually, it's the platform's fault.

Nobody can decide on standards because everyone is greedy. Microsoft has, like, a dozen GUI platforms and they're all Windows-only. Apple doesn't even use an off the shelf rendering API. And android is... Well, android.

Sure, I would like to use the OS provided controls. And then maybe after that we can all hold hands and sing Kumbaya.

You are 100% right, we have messy incompatible systems because there is no standardization. It is arguable that standardization of something that is so subjective is always going to be problematic. Design patterns are invented all the time and they start to infect other applications/platforms and mutate over time.

The only reason the original post think that "used to be a solved problem" was because we used to have a standard for guis: win32. But obviously people wanted more powerful/flexible UIs and more importantly, cross platform guis so it eventually died off.

A lot of design innovation came because the web is extremely flexible while at the same time being extremely non-standardized.

I honestly don't think it's really all down to being greedy. Even the Linux desktop suffers from this to some extent.

I think it's because UI design is very much something that can't really be "solved" in the traditional sense, so a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.

> a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.

Most standard toolkits provide escape hatches to have your custom components. I think most designers wants their view imposed to the users instead of following the platform constraints. Like instead of the standard play/pause button every player have, they want their own custom ones. Instead of using the standard tree widget, they want to create another that is the same, but behaves a bit differently. And then they say GTK is not good, let's go with HTML in Electron.

Linux has two application toolkits and they work pretty well together. Windows, again, has a dozen. And they're closed source. Microsoft could just... not... do that. They control the entire thing. But they chose to do it.

Greed is maybe not the right word, but maybe it's more like ideological greed. Like everyone wants things their way 100%. They won't settle for 99%!

Like okay, with Apple and vulkan and metal, is vulkan the best API? No. Is it the most performant? No.

But it's pretty fucking good. Its 95% of the way there. But for greedy apple, that's not good enough. So they say "fuck you, heres metal, good luck developers!"

And now people only make Mac apps if there's a gun to their head and they really need that tiny slice of market share.

Its the same thing with Qt versus bespoke UIs in ImGUI or whatever. Qt is really, really good. Its not perfect.

But we're really gonna burn it all down and start over for like... a 1% improvement in code architecture or something? Really? We're chopping off both our legs so that our pinky finger hurts slightly less?

Sigh. Okay. Such is the way of developers, I guess.

Furthermore, part of the unspoken role of the platform is showing off your brand’s personality with your flashy custom UI. For many, using standard components would be missing the point. Part of the product is the vibes and the website conveys the vibes.

Have fun selling your stakeholders

  <select multiple

edit: I forgot that it's not a "type" attribute, rather a boolean "multiple" one in the markup.

Also, don't forget that if you want to submit the values with something else than a GET wirh URL params or a POST with formdata mimetype for the body, you'll need JS anyway.

You can use it as backing for some JS component though (visually hidden), this is often done to have components work accessibly and with maximum interoperability. And to get functionality and tests right without implementing complex ARIA standards perfectly and running into constant issues with vanilla form submits (see above) or focus states and a11y.

I find that also in that regard there is a certain irony that now we have devs, with graphics cards that probably can do real time raytracing, but then they reach out to the same experience as my teenager self writing Turbo Vision and Clipper applications on MS-DOS, 30+ years ago!

User interfaces were mostly solved around 2000s. Almost everything after that was gimmicky. And if you don’t need images that much, text interfaces are quite powerful and fast.

And those native web widgets generally match the OS theme

I think it was OK for web to have custom designs as it was things that you interact with on a needed basis (like reserving a ticket). Your desktop was a permanent place where programs were used daily, so you expect consistency there.

> Every single application used to have a more powerful version of that by default

Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.

(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)

This would be less of a problem now that dark/light mode has become a mainstream thing. Both normal users and developers often switch between light and dark, so bugs would be found quickly and solved with high priority.

The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.

It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.

"Beyond the fact that almost all web "apps" are actually honest documents, ..."

The www is a document publishing scheme

The documents can contain links ("URLs") pointing to files of any type, text or binary

The documents can contain hyperlinks to each other

Option #1: Publish HTML with visible hyperlink to source code, the www user chooses whether or not to download the code, compile it and run it on their computer

Option #2: Publish HTML with hidden link to executable code, presume that the www user is using a program that contains an interpreter for the code, downloads it to temporary storage and runs it automatically without any www user interaction

Option #2 exposes www users to endless surveillance and monotonous annoyances

It is amusing to watch so-called "technical" people try control this default behaviour in popular browsers, the automatic running of other peoples' Javascripts

Their "solution" is to write their own Javascripts, e.g., "browser extensions"

Whoever maintains the browser software can limit or disable this "solution" at any time for any reason;

Currently companies engaged in online surveillance-based, programmatic, targeted advertising are the browser maintainers

But that nonsense only applies to Option #2

Option #1 is still in heavy usage

Although the number of www users aware of it may be relatively small

For myself as a document consumer, the www still functions well as a document publishing scheme

s/advertising/& services/

The problem goes further back than CSS - we're trying to write applications using the DOM. There needs to be a universal Motif-style windowing stack for browsers, but I don't have much confidence that browsers writers will ever agree on any sort of a standard there.

With wasm and canvas you are free to do what you want if you like to re-implement typical GUI behaviors that DOM provides. You could probably compile motif to webasm.

A lots of those applications should be standard forms and documents, but they’re adopting application techniques for one reason or another.

the problem is that every piece of navigation on a site turns a document into an application. separating actual document content from a "frame" that includes navigation and site styling has always been a problem. take hackernews for example. it is not a document. but every message is its own document and the rest is an application to view those documents. you practically can not avoid using application techniques if you have a site with multiple documents.

Hacker News is very much a collection of documents and forms with hyperlinks creating the whole concept of applications. No need to add desktop interactivity (which is already provided by the browser: loading documents, submit the form,...).

Most SPAs are reinventing the browser features (history, routing, navigation state, submitting forms, showing request's responses). When you really needs a full fledged application, those don't really matter (Figma, music players, document viewers,..).

No, a hypertext document is still just a document and not an application.

a single document, yes, but once i have more than one document and i want to add additional documents, i need navigation so that i can browse and find those documents. if each document only links back to the parent, and that parent lists all the documents, fine. but if i want to have the same navigation available on all documents, then i need to start making a distinction. that menu to choose the document should not be part of the document itself. the menu is an application used to navigate between documents.

the distinction i make is that a document is static, an application is dynamic. that menu needs to be regenerated every time a new document is added. if i include the menu in each document then every time i add a new document, i have to edit every other document to update the menu.

that has implications, including the timestamp when that document was last changed. therefore the distinction matters. i do not want to have to touch every document in order to update a menu. the menu should be distinct and be changeable without touching existing documents.

current html standards do not allow that because they do not support include. and http does not support directories. that's one advantage gopher had over http.

i can include the menu with javascript, or i could use xslt. but either way, the menu is an application, and it's not part of the document.

no being able to make this distinction is what forced me to build dynamic websites already in the early 90s. back then we didn't even have javascript, we only had serverside includes and eventually servers that could generate whole pages dynamically. it is in part what led me to a search for better webservers than the ones ncsa and cern were offering. but that's another story.

The menu is a templated document fragment, and XSLT runs completely before anything on the page exists (so it's not usable for interactive applications unless you run it in a javascript processor). What you're claiming is like saying a linked CSS file somehow makes the page an application. The application is the browser, and it knows how to put together linked fragments, templates, and styles to form a document. XSLT is exactly how current HTML standards allow static client-side includes just like CSS is how they allow styles.

The application is the browser

except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.

compare that to an email client or really any other application. hackernews is a messaging application.

a linked CSS file somehow makes the page an application

no, to keep with the analogy, the CSS part IS the application.

XSLT is exactly how current HTML standards allow static client-side includes

well, kind of. you need a lot of code to describe a simple template: https://news.ycombinator.com/item?id=44398626 [1]

and that still doesn't work for cases where you want multiple document in one view though.

it is at least a step in the right direction. it allows me to keep the document separate and free of navigation artifacts (the linked example is not ideal in that case, but it can be done).

but the same is achived if i build an SPA with javascript. the browser first loads the SPA application, and then the application loads the documents to be displayed. that allows me to keep the documents as original on the server. and unlike xslt this also works for multiple documents in the same view.

[1]: for those reading that thread to the end, the chromium issue turns out to be limited to the fedora build of chromium, nightly builds from the chromium website and chrome work.

> except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.

And that is all that needed. If you want to provide a common structure for navigation, usually a menu, it should be sent as part of the page. Which means the document and the navigation needs to be composed server side (either on the fly, or generated once). Then you can enhance the page client side (which is rarely needed).

> let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious

It would be possible to have this, by building all apps on the web platform exclusively from native input elements.

For forms. With no fancy things like combo boxes or multi selects!

Window interface, menu bar: using native controls there is ofc a power that web apps don't have.

Regarding the rest, I think you are painting the past with rose-colored glasses.

Yes, UI kits for native applications are more powerful than the web platform in many regards.

But the Windows applications I remember often were a mix of native controls and custom (of course, unthemable) elements.

Many applications even went out of their way to avoid native controls. E.g. SAP, Winamp, and loads of other programs I don't remember now.

Reinventing UI controls is not exclusive to the web platform and "the new kids" have no OS UI framework to build on. They have the web platform.

I too remember the styling options in Windows pre Windows 7.

I loved to play with the ones in Win98.

Most of them would have unpredictable effects on most desktop applications, because of the unpredictable mix of native controls and custom GUI.

If you want to improve web apps, why not argue for better native HTML interactive elements? E.g. menu, multi-select, date-picker...

What I agree with is that handling zoom, font size, color schemes should never be eschewed or ignored.

Oddly enough, in my work history, the Venn diagram of the people who argued for "just make it look like the design, nobody zooms" and the people being smug at web UI was very large. Smug at CSS too, the next moment cheering for obscure and inaccessible, bug-ridden "CSS-only" solutions that the one person who can write CSS proposed as a joke, because a styled toggle switch "shouldn't require JS" (I somewhat agree with this, although the programming language is unimportant).

Rant over... nostalgia is a nice thing.

But web apps are not Windows applications or GTK applications or macOS applications, and these all habe never been as perfect as you make them out.

Sure, large, data-driven applications with good developers for native UI did many things better than many web applications do.

But that's not because web app programmers are too stupid to just do the same thing. That's a tired trope.

Sure, web development has a low barrier to entry. Ranting about it has an even lower one though.

Your comment kind of reminds me of old school Winamp and its skins.

Someone’s never used the old MacOS before OS X. Anyone remember Kaleidoscope?

Someone’s never used Windows before Vista. Remember how themeable XP was across all apps?

We had standard OS controls, that’s why all that worked. The web has… extreme customization per website.

Customization was ok for the web because it was documents and forms. But then they bring those ideas inside the desktop space where you used to have consistent interfaces for your computation.

I kind of wish that the OS provided to the browser the following pieces of theme information...

    1. is dark mode
    2. primary background color
    3. primary forground (text) color
    4. primary accent color
    5. secondary accent color
    6. warning accent color
    7. danger accent color

Then the application could use those to apply overall skin/theme to the web application(s). However, you will still have those sites/apps that want their own. The biggest example imo is Slack.

Even material or fluent are similar enough that applications using either tools with the above values for an overall theme would be easy enough to apply throughout an application.

Reply on news.ycombinator.com