What incredible impact.
- DSL for UI (Forms) - fast native compiler that produced self sufficient binaries - great component library and many open source libraries - Object Pascal was extended to fit perfectly the needs of UI programming
What happened is also changing hardware, UIs that need to adapt to changing screen sizes, different needs, theming, and many more.
(Big asterisk: mostly Windows-only and has recently lost product direction coherency)
https://docs.microsoft.com/en-us/visualstudio/get-started/cs...
Is that any better now?
The problem is that outside of the iOS ecosystem, there are too many subtle differences in behavior to really trust the results. And because a lot of software gets worldwide distribution these days, it's economically worth it to squeeze that last bit of performance & user friendliness out of the framework. So most professional programmers learn how to do things programmatically and only use the interface builder if they're doing a quick internal tool.
People keep saying that as if that is this new thing that wasn't ever heard of before the web or smartphones.
Open any desktop app and resize it. Boom, you've got "changing screen sizes".
And yeah, "needs are different, and we need theming is this new thing that never existed before the iPhone ".
Imho, the real reason we don't see stuff like this for the Web is that the web isn't designed for modularity. CSS, Javascript, and HTML IDs are all global.
Programming 101 lesson 1 is "don't use globals" and the Web is the perfect object-lesson in why not.
> Imho, the real reason we don't see stuff like this for the Web
Where are you looking on the web? tab-indexes and extending native web components gives you responsiveness and accessibility. The browsers provide theming capabilities for light and dark mode, and OS level color preferences (I use "red" for selected on Mac) easily show themselves on CSS `outline` etc
> Globals
No one uses globals on the web. This isn't 2000, or even 2013.
Now everyone strives to make as beautiful websites as <insert big blue with their genius web framework>
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
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)
It's probably not this particular feature of the web browser matters but the fact that web browsers come preinstalled with new computers.
I mean, if not pedantic, then perhaps grinding an axe - he said 'there is a lot of Javascript that is getting "downloaded and installed"' as if that has anything to do with the user experience I was referring to
> any application (not just a browser) could provide the same download-interpreted-code-then-run-it functionality
I have never heard of such a platform besides the web. That is why the web became the dominant platform. I do not know what theoretical could've would've should've has to do with the reality of technological evolution
> It's probably not this particular feature of the web browser
... yes, it's not the ease of use that makes users like web, it's that computers in 2021 come with browsers installed that makes users prefer web over bloated desktop applications without good accessibility anyways!
I have no clue what your comment is meaning to get at.
Steam comes to mind.
> ... yes, it's not the ease of use that makes users like web, it's that computers in 2021 come with browsers installed that makes users prefer web over bloated desktop applications
Wasn't comparing to "desktop applications." I was saying that the reason that the download-code-then-run-it functionality was shoved into the browser rather than coming in some other form, was that the browsers were already on all the desktops.
See Flash.