Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views?
I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going.
The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing.
Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.
> The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing.
How can you say this with a "barely competent" level of expertise? I would rather hear a well reasoned argument from someone who knows the ecosystem and its trade-offs.
> How can you say this with a "barely competent" level of expertise?
I get that, and that's why I declared it. I have two reasons why I think the opinion is still valid:
I'm not completely incompetent. I have produced useful web frontend work. After having spent more time on web technologies than a lot of others I still find it to be slower and harder. This point is about learning - I have done some learning in both and I can compare. It's a small sample size, but seems to agree with the experience of other people.
The other point is that most people talking about this are already experts in HTML/CSS. That learning is a sunk cost for them so they're not making fair comparisons. I also sometimes feel like there's a little 'Stockholm syndrome' - they've invested time and effort in learning the techniques and tools required to produce good quality web UI, and now that they can they overlook the effort required to get to that point and proclaim the wonderful nature of what they're using.
The sunk cost thing is the important aspect. I'm not even saying that it's wrong that it's become the standard UI description language - it as at least an open specified standard. I'm just saying that not enough attention is paid to the downsides.
Super valid point. I've been a frontend dev for a while and I'm comfortable with HTML and CSS but I can definitely imagine switching to something else. The sunk-cost fallacy thing is real, though.
But the complexity arises from wanting to make apps with something meant for simple documents. That being said, even building the simplest website nowadays requires a mind-boggling knowledge of the idiosyncrasies of the "languages".
I want to lose my job; I want the next best thing to be completely different but still allow for creativity and productivity.
I'm agree with you but I gotta say, I have yet to find the perfect tutorial that say "follow these N steps and you'll always get what you expect".
For me, the common places things break are, setting up a flexbox and not having the content scale to fit.
Trying to make an app like layout (so the page itself doesn't scroll though some content in various areas might) and again, trying to get various flexbox areas to either fit their content or get the content to fit its area without expanding the page past the window size (note: if you use overflow: hidden you failed)
In any case I'm not a UI/UX designer so I don't do it daily, therefore when I do need to do it it's always a bunch of frustrating trial and error.
That said, I do think there are a class of designers that also don't know these answers. They just know a few frameworks that handle all of this for them.
It is a sunk cost for them. They literally cannot get it back. But for somebody new why should they have to pay this cost if there are many less expensive ways to describe a UI. The lowest common denominator is now invading everything including native. This often happens but it is regrettable.
Because of backwards compatibility, HTML+CSS makes it cumbersome to use the simplest ways to layout things. And it's also confusing because the oldest ways are still very much valid. You have to make divs (or semantic equivalents that I'm not sure are used anymore), and then mark them as different kinds of displays using CSS, with multiple sublanguages for multiple properties.
Compare that to QML Quick Layouts[1], GTK containers [2] or winui controls [3] where you just instantiate whatever kind of display with the container you want in a single model using qml/GTK Builder XML/XAML and be done with it.
The last paragraph really hits the nail on the head. HTML+CSS+JavaScript is just so complex, with so many details to learn, and so many corner and edge cases to understand.
Not necessarily inherently, more as a result of taking a set of tools that were originally designed for doing one thing - creating hypermedia documents - and repurposing it for creating rich application graphical user interfaces. Which is ultimately a very different problem space with different needs and design constraints.
I'm also struck by the total development effort required. Once upon a time, the GUI was something that the whole dev team pitched in on. Hopefully a designer was guiding the work. But all the programmers could easily pitch in on the actual implementation, with minimal up-front training. Nowadays, the work often goes to specialists, and "full stack" is actually a thing people highlight on their resumés, rather than something that goes without saying.
Perhaps that has nothing to do with the technology. Some of what's going on is undoubtedly just that all professions become more specialized as they mature. The bar for what counts as a good UI has also raised quite a bit over time. And the actual ask is quite a bit more impressive, too. A single GUI codebase that can dynamically adapt to everything from a smartphone screen to a large computer monitor, without looking janky at any point in between, is something that, to my knowledge, has never been asked of a Visual Basic application.
But still, even given all that, it's hard not to at least wonder if we could have ended up in a better place if we had been given a technology stack that had been designed from the ground up for the problem domain, rather than having to make do with something that was never meant for this problem domain, but has been adapted to it through the accretion of many layers of hacks.
I did come to appreciate how much detail (and therefore) effort goes into a modern UI. I was building something that was effectively a messaging app for my startup. I was doing it in Flutter so progress was good and things generally behaved pretty well. But so many little things needed to be done to get e.g. the input box to behave intuitively (e.g. hide 'attach image' button when writing text). I was basically copying the standard approach from FB Messenger and WhatsApp. Apps at that level of polish have raise out expectation. That changes thing for developers - when it was "just add a button" everyone could pitch in, but now it can be full time work for several people.
I've used pretty much all GUI frameworks - raw Win32, MFC, WinForms, wxWindows, Qt, WPF, native Android and iPhone.
HTML/CSS is vastly more powerful and productive, especially when using something like React/Vue.
It's not because "web devs who don't know anything else".
HTML/CSS is just a superior technology. No wonder that even traditional GUIs are moving this direction - Qt with QML, windows with their new Win10 flat design API (forgot its name)
> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.
It's still easier to solve these problems than in a traditional GUI, which if you noticed tend to have a mostly fixed layout, exactly because dynamic layout is so difficult to get right in them.
So glad to hear this sentiment. It's frustrating that so many people don't seem to acknowledge how flexible HTML/Javascript is. It's not perfect, it's probably not the most efficient possible set of APIs, but it has to deal with a whole lot of legacy, just like most programming languages/platforms/frameworks.
Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"
Have the same feelings about HTML/CSS and even similar towards JS.
I believe that if one gets a grasp of it, then CSS is extremely easy now, compared to like 5-6 years ago, where on top of CSS itself, you had to be good with all the quirks for IE and other browsers.
If today someone tells that CSS is hard, I honestly get stunned. I wonder if the idea of "everyone can code" might be root cause of current state. I mean - if after some time you cannot get intermediate CSS skills, then I'd say that web programming (and maybe any other) is not for you.
It was with the boom of Tailwind CSS when I started to see a lot of comments like "OMG this framework is great - CSS was always hard for me, now I can do much more".
I just don't understand what happened to classical RAD from the late 90s early 00s. OK web was out of touch because no one really uses the "standard gui" anymore, even something as simple as a button has different look and behavior on every website.
But mobile app should be prime targets for it, and theming is a well understood concept for it too.
So why do we not have a proper rad tool (drag and drop my button where I want it, see the list of events, double clic onclic to edit code to run on clic event, customize onrender if I want some magic look or draw on a canvas,...).
It has got to be better than this html/js horror show.
RAD, a.k.a. UI-nailed-down-to-pixel-grid approach, has died immediately after we've switched from 640x480 pixel screens to variety of display and devices.
But that's not a limitation of RAD. Delphi 4 and Visual Basic both had "align and/or resize proportionally" on all axis.
Making an UI that adapted in size from 640 to 1280 was a 4 clicks matter.
Having COMPLETLY SEPARATE UI for different form factor like we need on the web sure, but that shouldn't be an issue on mobile just pack X version of your UI like you end up doing with all your resources anyway.
RAD was about "every single component you use is generic, you don't care how it works, you only want to say where it is, what event you listen to, and optionally do some custom rendering".
As said above, positionning could be non-fixed, auto-adapted to the view, ...
Delphi scene is still quite active in Germany, enough to keep getting articles on the Windows and .NET developer related magazines, and a yearly conference.
Delphi suffers from the mismanagement from all its owners, and given its target market, you will usually see it being used across corporations that don't think twice about paying for SAP and Oracle licenses.
its a real shame too because the pascal langauge is quite nice and would hold its own against zig or c++. I would even learn the free version and potentially invest in the paid version if it ran on osx or linux. Anything thats windows only is a hard no for me.
One problem is that in larger teams, text descriptions that play nicely with version control are much easier to manage. You can review changes, you can share code etc.
It's not dead though - C# development still has Visual Studio and it can be pretty good.
For iOS and macOS there is Interface Builder that is somewhat like that. It seems to have fallen out of favour. I‘m not really sure why but I know I prefer developing code based UI as well.
The issue most people seem to have with IB/Storyboards is that they're incredibly difficult for multiple people to work on. They're huge, dense XML files, so trying to solve a merge conflict is a challenge to say the least.
It's been a long while since I've done much iOS dev but I also recall when learning Storyboards that there were lots of things that just seemed half baked or poorly thought out.
For example, the only way to set a corner radius from the UI was to type the key-path of the layer property into a "Runtime Attributes" input, in a totally separate tab from the rest of the visual properties.
I also recall headaches over things like setting the colour of the status bar, or titles on Navigation controllers, where the runtime value would often be different to what IB showed for some reason.
As someone who is currently making a living as a frontend dev I feel you - however for anything more visually advanced and everything less standard (and I understand that it is debatable whether that should be done in the first place) it's often quite difficult to achieve a certain visual effect in all the other gui toolkits I have tried (QT, PyGtk). Often image-blending modes, configurable shadows, animations (especially on those properties) and dynamical effects either are not available at all or not as simple to set up as I am used to. Nevertheless I'd like to be educated which framework would be a good fit for building your typical animation rich dribbble/behance design with glassmorphism shadow magic and whatnot without writing custom shaders. Maybe Flutter?
I've made a respectable living off web technologies, and the products I've built create value for many people.
Maybe it's not the sharpest knife in the kitchen and I'm not Gordon Ramsay, but the final consumer product is still pretty close to being regarded as Michelin Star quality, not as a boast but just a point of fact.
Giving an flip "XYZ technology bad!" remark usually comes across as a meme or as uninformed and snobbish. The fact is these "bad" technologies do a whole lot of good.
Isn't C a sweet spot of portability and minimalism ? no matter the defects .. the previous qualities seemed to matter more. I mean there were attempts at replacing C but nothing came close to remove it right ?
C only got there, because UNIX just like the Browser did to JavaScript, has placed it everywhere.
This happened only because Bell Labs/AT&T were forbidden to sell UNIX, hence its source code spread across the industry, with a symbolic price that made it by comparison with other OS vendors feel almost as quite cheap beer.
During the 80's and early 90's, C only mattered in universities and companies that had access to some kind of UNIX flavour.
Everywhere else we had Assembly, Modula-2, Pascal and Basic flavours, BLISS and some PL/I variants like PL/M on CP/M.
So when you happen to have UNIX, and a C compiler around, trying to bring people to use something else, it is the same as trying to replace JavaScript on the browser.
So we come up with our CoffeScript and Typescript likes for systems programming, but C (even in C++, Objective-C) is always there.
We're all well aware of the unix/c coupling. What I'm saying is that for low level memory mangling and primitive operations over the set of register based machines.. you don't get any benefits from using another language it seems. I.. just a dude but some people doing HPC said that you can even reach FORTRAN speed on numerics if you fiddle with the right keywords to avoid aliasing.
Again I'm not a C fan.. but what would pascal or basic give you that is a critical factor in making a better system with it ? modula I can't say. Asm is too coupled to the underlying cpu it's out of the window already.
Safer with less memory corruption exploits to start with.
Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.
And that's something a lot of JS haters have overlooked. I have purposely ignored it for the past few years and am just now getting back into it for doing CLI and back-end Node work... I find myself amazed at what's been added and improved since I was writing jQuery and AngularJS a few years back. I still have no interest in getting back into DOM work if I can avoid it but Node is kinda nice!
Not a lot is bad in the language since es6 (I don't know if they kept hoisting or not) but in any case I don't find any reason to put it that high above the rest :) but I was curious about your reasons mostly.
> HTML/CSS is an inevitable part of the ecosystem because the web is an important target.
You did confuse cause with effect.
In the first place Web accepted HTML/CSS/JS for the good reason - as a classic implementation of "Separation of Concerns" principle.
See:
1. HTML defines semantic structure of UI - DOM tree.
2. JS, as language-behind-the-UI, handles users events and updates DOM tree and its state.
3. CSS defines how that DOM tree is presented to the user in its current state.
These three tasks are so distinct that require their own languages that are optimal for the task.
That split has a lot of sense. For example, HTML and abstract DOM tree alone enables accessible access (a.k.a. Section 508). And so on.
There were, are and will be all-in-one approaches to UI, like Flutter or WPF for example. They will never be universal UI solutions for reasons outlined above, especially on desktop UI.
I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentation are seperate concerns.
A good example is a CMS/wordpress (which as we know makes up a third of the internet or something): Editors are concerned with content, themes are concerned with presentation, plugins are concerned with behaviour.
Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. If it does, its a different separation like M-V-C.
I think all the successful user interface things introduced in the last few years are going for an all in one code approach for good reason: SwiftUI, Flutter, Jetpack Compose, React Native... I may be a little mobile focused?
The options that ios/mac os/android offered for a while to create UI structure seperate from code where not very popular with developers which often preferred to construct and modify the entire UI tree with code "manually".
What‘s the state of the art in windows and linux UI programming?
The thing is that accessibility works acceptable only on semantic DOM trees. HTML and its DOM was designed with that in mind. Flutter's DOM is not, it is not semantic - it is a Dart code that defines visual structure for particular screen layout.
Mobile applications are significantly less demanding (more simple in UI terms) - they have very reduced set of components and layouts. Essentially all mobile UIs are built with <radio>,<checkbox>,<button> and <list> vocabulary.
The reason is simple: most of the time mobile apps are serving "reading user" role. While desktop is the place for "writing user"s (a.k.a "content generation" role). Desktop is the place where you must support different editing, object manipulation paradigms - UI on desktop is more rich. Just check apps on your mobile - 90% of them are very close UI-wise.
I agree that a UI is well expressed as a tree, for the sake of accessibility and other reasons. I don‘t see why there is any reason to seperate the declaration of that tree from the application code. The flutter approach is bad, but all established desktop and mobile UI frameworks provide accessibility support as good or better than HTML.
In fact, HTML is ill equipped to express capital A Applications in an accessible form and needs ARIA as a bandaid to make it work.
The application runtime knows about the UI tree by the time the app is running and can tell accessibility tools about it. Wether you write it down explicitly or not doesn‘t matter. It only matters for web "pages" which are original not something that is running at all.
The problem I have with HTML is that it's only really any good at defining the semantic structure of a document, particularly the type of thing you might produce with a word processor. Half the stuff on a modern webpage—even those you'd still call documents rather than apps—can only really convey meaning via visual layout, and so break down when divorced from CSS/JS.
For example: I'm a big fan of reader mode in browsers, but so often they're tripped up by basic UI affordances like menus and image galleries. The renderer has to guess at what's content and what isn't, so half the time any sort of "widget" is rendered as a crappy-looking vertical list. Sure, that's technically what a menu or gallery is at its most basic level, but surely we can do better?
There probably are sensible defaults you can already follow—representing a menu as a <nav> containing <li>s, say. But it would be much easier if there was a <nav-item> tag. A <nav-item> inside a <nav> would semantically be a menu in the same way that <li> inside <ol> is semantically an ordered list—you don't need any CSS to render that in a sensible way.
Same goes for galleries; if we had a <gallery> tag that could contain <main-image> and <thumbnail>s, you'd still be able to do custom layout with CSS if you needed to, but at the base level you could sensibly render it with just the markup itself.
I dunno, I just find it weird that we added all these new tags for HTML5 years ago then just stopped bothering. I mean when was the last time a HTML element with behaviour was added?
In an ideal world a reader mode could be expanded to a "reader-friendly page mode" wherein the page still looked approximately like the normal webpage, just without all the user-hostile shit. Of course, that's usually diametrically opposed to the financial incentives of running a website, but it's nice to think about.
> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.
I've been manually crafting HTML/CSS websites since 2001. Since the arrival CSS flexbox/grid, I don't know anything easier to build layouts than HTML/CSS.
I like what Fluter offers but HTML/CSS is far cleaner/easier to read and simpler.
I’m sad at CSS but not HTML. If you look at other front end approaches by other communities they will have something similar to reusable components which can be nested as a DAG with some technique to pass state around, but which community is inspired by CSS?
I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going.
The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing.
Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.