Comment by vrodic

Yeah I feel that in a way, the best time to be a developer was back in the 1980s/90s. Your tools were limited but those constraints took away a lot of the "overhead" thinking about what frameworks to use and you could just focus on functionality. You didn't have Google or StackOverflow, but had a few books on your desk that covered pretty much everything you needed to know. Or if you were working on Unix, you had man pages, K&R, and Kernigan and Pike's The UNIX Programming Environment

In the same way that Visual Basic offered simple, drag & drop interface builders.

What happened is also changing hardware, UIs that need to adapt to changing screen sizes, different needs, theming, and many more.

> Fast forward to today and we are in this clusterfuck, where everyone keeps reinventing the wheel and complexities just keep growing

Yes, it is quite funny to see how no toolkit exists to simply produce Web UIs in a meaningful way.

However, the complexity has grown largely from externalities that didn't exist during the time of effortless interface builders, which is screen sizes and aspect ratios and pixel densities of all sorts. To handle this, you need to have some lower level primitives, and of course any time you have to go to a lower level you surface more complexity.

Final point - as a person who develops web UIs professionally for 7 years now, I think that the "reinventing the wheel" has been actually quite beneficial to tame this complexity. Previously, untyped JS had to be bent into surfacing type-style error messages, and good luck with boundary crossing data. Now, TypeScript lets you describe every key in your application and have incredible confidence that a fully-typed piece of UI or logic (which of course must avoid `any`) will deliver exactly what you intended. GraphQL & codegen has given us the ability to type our boundary crossing data straight from our DB or resolvers without any runtime reflection. Runtime reflection tools like io-ts also bridge that gap admirably to program defensively in the situations it's needed. It's obviously been accompanied by a lot of churn, but with strictly typed component libraries, a bit of reusable layout logic, and Hasura, I can make sexy fully-themable UIs strictly typed all the way to and from the data source without significant effort. The complexity in my new paradigm is entirely in application-level tricks like UIs visually informing users of all the async actions, animations / transitions, avoiding dynamic content causing bad layout blips, and ensuring user input is never lost. I think this kind of thing wouldn't have been easy in any oldschool toolkit because it inherently requires some wiring that isn't easy to surface

> where everyone keeps reinventing the wheel and complexities just keep growing

Cue XKCD "Standards" comic. People look at an existing framework and declare "this is total shit, I can build a better, easier to use version!" They then start building the better-easier and realize why the old version is so hard to use--because it's a difficult fucking problem begetting awful complexity + shitty code.

This repeats itself every 18-24 months, giving us the current clusterfuck of JavaScript libraries. Lather, rinse, repeat for the past 30 years (n.b. XWindows Athena -> Xt -> Motif/Lesstif -> ...<aeons pass>... -> Qt -> Electron)

Please, you must not be pedantic in this way, it's clear that I mean there's no install wizard and OS-native interactions the user must go thru, they just provide a string URL and immediately begin application-style interactions after a brief load

It doesn't, but that doesn't help us now.

See Flash.