Comment by moonchrome | Hacker News Reader

Comment by moonchrome | Hacker News Reader

Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem.

But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems.

Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers.

So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.

I don't know one single UI/UX development environment which is elegant and nice. From Android to iOS to Linux to Linux and Windows to browser UI kits. They are all complex and require constant searching for answers. The libraries are very big and require a complex tooling setup. You can never be an expert in all of them. At least not me.

My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon.

Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds.

Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats.

You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this.

A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.

I think you're spot on.

My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is.

I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.

This is probably a better comparison than one might at first think.

A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets.

That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.)

Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make.

All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.

> developers always vastly underestimate the difficulty of doing a UI framework or environment

Developers, managers, designers, executives, the whole process chain underestimates the complexity of building a stable and maintainable UI.

Everyone feels in their gut how complex building out a data processing pipeline or a scalable backend should be, but even people who should know better can't help but think of the UI as the "easiest" part.

In my experience, the only solution is forced minimalism. A sort of "Dogme 95" for UX. Force your UX to be a haiku, not an open-ended novel. This means pushing back hard on unnecessary complexity and focusing like a laser on what really matters.

In other words, the problems might be technical, but the solution are likely political.

https://en.wikipedia.org/wiki/Dogme_95

> Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats.

This gives me flashbacks to writing a Java applet (supporting the MS JVM!) in which my boss has decided AWT (no Swing lol) was verboten and implemented his own widgets. Which was great up until I had to implement dropdowns, because then you need a concept of z-ordering, which meant refactoring almost everything in order to include. And this pattern repeated several times for "simple" new features I was asked to add.

Writing a primitive windowing system with nested menus in GFA Basic and getting lost in a rabbit-hole browsing the Turbo Pascal object hierarchy as a teenager was a good way to teach me to not try and write my own UI library if I wanted to get anything else done :)

Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons.

As shitty as Android support matrix can be - it doesn't compare to IE6 web days (at least in terms of UI development, stuff like OS services is entirely next level - but you can't even start doing that in JS so it's not really a fair comparison) - and we're still paying for the technical decisions made in that era (how many people are polyfiling all the way back to stone age and including hundreds of KB of useless shit ?).

> Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons.

But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.

> recently even plugged the "no modules" hole

I haven’t heard about this. Do you have a link so I can read more?

Well, they added modules some time ago and now they're widely supported. Not quite sure what more there is to say about that. Aside from botched variable scoping, that was probably my biggest grip with JS (but `let` fixed scoping many years ago as well).

Majority of people using JS with these frameworks are using package management and bundling - and suffering because the ecosystem has such shitty tools for dealing with it.

If you're linking jquery from your favorite CDN and writing your code inside of <script> tags you're not dealing with the issues this article is describing.

Right. But that's their choice. I actually really like what Mithril.js did, regarding decisions on size, complexity, distribution as a single file, etc. Pretty much the only thing I'd like more would be if some similar library targeted both HTML5 web and Sciter (since Sciter does some things in its own -- and very efficient -- way and it would be interesting if something filled in the details in the web platform that web omits but Sciter does not to come up with something Mithil.js-like but also usable on desktop).

This. Use what works and is stable. I strongly dislike JS (PTSD, perhaps) but when it comes to minimal code to get the job done, jQuery is where it's at: the perl of JS frameworks.

Very few websites/frameworks/libraries support IE nowadays. And Edge being Chromium-based, means most of the polyfill issues have been resolved. You can reach 99+% of browsers by writing in modern web standards (HTML5/CSS3) without having to worry much. Web dev is probably nicer than it's ever been.

As somebody who followed both Android and web dev, Android UI development was much clunkier. A lot of the patterns in use today (like React's declarative patterns) started in web dev before being adopted by Android. Not to mention, Java's package system was much more annoying to work with than NPM.

I think WPF is nice and elegant. Although complex.

Was going to reply with WPF. The best I've used for UX dev

NCurses is pretty elegant in it's simplicity.

Reply on news.ycombinator.com