More like 70's best practices [1]. Reusable GUI components were first (? citation needed) used on the Alto machine developed in 1974. The developments of the Xerox PARC team were a huge inspiration to Steve Jobs, who later would create Objective-C and the NeXT system (with NeXTSTEP as the component based GUI) in the late 80s.
> Those who cannot remember the past are condemned to repeat it. To covet truth is a very distinguished passion. -- George Santayana
You're right, you can read about them on the XDE developers environment for Mesa, the experience report about Mesa/Cedar, the three canonical Smalltalk books and some Interlisp-D related papers.
Lots of interesting Lisp work in UIs that continued into the 90s but then got memory holed with all the other Lisp innovations... I wonder if component-based web apps will ever rediscover the idea of meta protocols. A rather enjoyable presentation from Gregor Kiczales I watched not too long ago discusses the issue of mapping dilemmas (your rich window frame component is great but I can't just reuse a grid of them to have a rich spreadsheet app because of performance) and various attempts at providing controls to clients to resolve them. https://youtube.com/watch?v=5l2wMgm7ZOk
Thanks for that link, I didn't know about that video. I read his "The Art of the Meta-Object Protocol", which provided me fundamental insights. Wrote just some weeks ago about that [1]
Well, I think (and many of my fellow engineers as well), that we were making good progress in UI design and abstractions until AJAX and the modern web came about. I've said this before and I will say it again: the web has brought modern software development practices back in time by at least 20 years. Everything had to be reinvented: usability, interaction patterns, accessibility, quality control, component-based GUI design, supportability and so much more.
And in many ways we have gone backwards. Interaction patterns vary wildly from site to site. Most don't have undo/redo functionality. A failure of one component often means a failure of the whole. Accessibility on the web is terribly poor for the vision impaired. Interaction response time has gone up, not down even though our machines have many orders of magnitude more power than the 90's. Most websites cannot be properly maintained due to lack of coding standards and abidance of best-practices.
Ok, just an old fart rant. Don't get me wrong: I think we have made leaps of progress when it comes to distributed computing, machine learning and mobile application development. The web, however, has turned into a huge dumpster fire.
This is completely spot-on (well, disagree some about the coding standards and best practices part) and just calling it an old fart rant is way underselling yourself :)
The irony is that the current/next generations who have never seen/used/built a non-stock desktop app will not know of this big-step-back that happened, and will think that this is how things always were.
With so much moving to mobile, this comparison is becoming more irrelevant though. And on mobile native apps are very much still alive, due to many of the reasons you brought up.
You're right: coding standards have improved. Still, I wonder if we might be biased. From my perspective I see a lot of well engineered code (Scala, Rust), but the majority of the code produced is probably not that clean.
The move to mobile has really opened up new opportunities and it seems this discussion is less relevant. Then again, loads of apps are web-apps underneath.
Of course, another example of how React is the software engineering paradigm shift of this decade. Comparable to last decade's shift from desktop to web apps.
Interesting that React is fundamentally an invention at the level of programming language design, an insight about how to best express UI behavior. This means we could have had it (or any mainstream functional reactive programming) much earlier or later than we did. It came on the scene at an arbitrary unpredictable time.
I don't know. It reads to me like they are rediscovering what e.g. Visual Basic and Delphi did in the nineties: UI component libraries. Particularly VB used to have a pretty lively component ecosystem. Also, the web is littered with attempts to have reusable javascript components for things like menus, combo boxes, and other cruft people end up wanting in their web sites.
This article reads a bit like a blast from the past in that sense. I think if I dig a little I might be able to dig out some papers from the sixties and seventies advertising the virtues of functions, modules, and even components with very similar language as in this article.
There is some progress here of course. Internalizing CSS is a good thing. Having that as a separate thing to manage and align is just too painful to keep in a maintainable state. I think some people are still disagreeing with this but I've seen some examples of css increasingly being driven from javascript instead of shipping as a separately loaded and created artifact. Web components sort of formalize this in html/javascript and allow you to isolate components from each other, which is another good thing. Separation of concerns and isolation are good things.
Also good is the shift to typescript, a language with a bit stricter semantics than javascript and of course better typing. The article does not mention this but given the speed and confidence with which they did this, I suspect they'd be pretty happy Typescript users.
Other than that, I think React is mostly a variation of the same kinds of design patterns that have dominated UI development for the past decades. I did some Swing development in the nineties and I still think that was a pretty nice framework to deal with relative to the current madness that is modern web development. The web can still learn a few new tricks. I have good hopes for WASM bringing some more choice and options to the scene.
The 90s GUI world was also a bit different in aim. Shorter in scope. Basically winforms, buttons, menus, sliders. But I believe the web added some new usages (shape shifting widgets, merging, way more animation [for better or worse], more dimension also).
I don't assume Microsoft was innovating at any point since the 90s, wasn't WPF a response to Mac OS X compositing layer ?
Also I didn't mean to glorify the web. But I really think that it was the main driver of new mainstream desires in terms of UI (not to my taste). Even more than native iphone/ipad application no matter how sleek and sophisticated because of how few dev and users they had compared to web apps.
Sure, you can use it for good and for evil. I expect this as well. Sadly, there seem to be a few annoying limitations that browser makers seem to be stuck on for the immediate future (e.g. garbage collection, simd, threads, and a few other things).
Still, wasm is good enough for pretty sophisticated stuff.
I was playing a version of doom 3 ported to wasm a few days ago; with decent frames per second even and quite playable: https://news.ycombinator.com/item?id=18817278
No, componentization is only one of the major concepts of React. Declarative reactive re-rendering is key, as opposed to having to imperatively code the details of how UI parts transition from one state to the next. For example, iOS UI development had componentization, yet it was still necessary for them to launch SwiftUI this year to get on the React(ish) bandwagon.
I find it amazing how many different software development frameworks are out there.
After all these years I still haven't bothered to look up what React is, and I probably will never need to.
I will probably never get to maintain a codebase that uses it.
So if being 'up-to-date' isn't something I will go for, how do I measure myself as a developer? I think I will go for something like 'having made a lot more regular people happy than I have frustrated'.
Yeah I spent some time with raw javascript, jQuery and angular, but React is the first web framework which actually feels like a decent solution to the problem of how to build interactive web applications, rather than just being another hack.
> "...at one point, the button component’s API had become highly customizable to a fault. Developers could specify the label color, background color, and border color independently, which made for a very large set of possible button looks. One of our principles is to make opinionated components that support visual consistency so in this case we opted to distill those three options into a single choice, a type field that only allows choosing from a predefined set of valid button appearances."
This reminds me of buttons in macOS vs. iOS.
Mac's UI component library AppKit was inherited from NeXT and redesigned for the OS X "Aqua" look in 2000 with incremental updates ever since. It had a very limited set of button styles, with each style having a specific use case. Customizing a button's appearance used to mean creating a subclass and doing your own vector drawing.
When iOS came on the Cocoa scene, it introduced a new component library called UIKit. It supported more flexible customization similar to that described in the Twitter blog post (freely selectable colors for everything as easily applied properties).
The downside of UIKit's customizability was the propagation of absolutely hideous third party UIs that broke every rule of visual accessibility and Apple's own Human Interface Guidelines. So Apple tried to rein it in with the "flat" iOS 7 redesign in 2013. Even though the redesign was quite unpopular in tech circles, it ultimately succeeded in unifying the look of iOS apps compared to the '90s style pandemonium that reigned before.
When iOS developers try to make Mac app in AppKit, it seems 99% of the time their first complaint is: "Why is it so hard to customize a button?"
The answer is that there is great value in UI consistency, as Twitter also discovered. It's more important on the desktop than on mobile simply because there are multiple apps visible at once on the Mac, and it sucks if each of them defines its own crazy branded look.
What the hell, so web developers were somehow reinventing basic UI elements like buttons at every use site? How is that even feasible?
Making reusable self-contained UI widgets is a menial task that can be solved by just throwing more money at the problem. We could pump out hundreds of widgets every week if we wanted to. The hard part is coming up with a way to easily compose them and share state, not just on one level but widgets that are composed of other widgets that are again composed of other widgets.
At yazz.com we are actually building something which allows web apps to be built from Visual Basic style components, but with Javascript instead, and designed to be deployed to containers
