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.
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.
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.
It’s reaping so much benefit that these experts can easily make mobile apps without learning another way to describe UI.
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.
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.
[1] https://doc.qt.io/qt-5/qtquicklayouts-index.html
[2] https://developer.gnome.org/gtk3/stable/GtkContainer.html#Gt...
[3] https://docs.microsoft.com/en-us/windows/winui/api/microsoft...
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.
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.
Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"
QML (march 2009) is older than angular, react, vue which are all post-2010. And still they are all more complicated to use as a language
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".
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.
If in doubts think about Adaptive and Responsive Designs ( https://en.wikipedia.org/wiki/Responsive_web_design ) in regards of RAD.
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, a.k.a. UI-nailed-down-to-pixel-grid approach
That's really not what RAD was about.
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 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.
It's not dead though - C# development still has Visual Studio and it can be pretty good.
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.
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.
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.
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.
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.
ok I admit defeat on this. I can't barely believe I forgot that u_u;
Microsoft, FreeBSD, ARM collaboration on CHERI
https://msrc-blog.microsoft.com/2020/10/14/security-analysis...
Oracle with ADI
https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html
Apple with pointer authentication,
https://developer.apple.com/documentation/security/preparing...
The modern JavaScript/TypeScript is so amazing and probably the best language I have used.
I have extensive programming experience in other languages like Java, Scala, Python, Ruby, C, Lisp. But JavaScript definitely wins.
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.
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?
I think you are making critical mistake here.
IAccessible & Co. (https://docs.microsoft.com/en-us/windows/win32/api/oleacc/nn...) maps nearly directly onto HTML DOM tree. So no matter what CSS you have there your UI will accessible.
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.
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.
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 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.