
Using component-based design helps us build faster - stablemap
https://blog.twitter.com/engineering/en_us/topics/infrastructure/2019/buildingfasterwithcomponents.html
======
pjmlp
Also known as, Web development keeps re-discovering 90's best practices of
native GUI development.

~~~
edejong
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

[1] [https://www.classic-computing.de/wp-
content/uploads/2016/01/...](https://www.classic-computing.de/wp-
content/uploads/2016/01/A_History_of_the_GUI.pdf)

~~~
pjmlp
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.

~~~
Jach
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](https://youtube.com/watch?v=5l2wMgm7ZOk)

~~~
edejong
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]

[1]
[https://news.ycombinator.com/item?id=20233215](https://news.ycombinator.com/item?id=20233215)

------
Liron
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.

~~~
jillesvangurp
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.

~~~
agumonkey
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).

~~~
pjmlp
All of that available on WPF, introduced with .NET 3.5 on Windows Vista, about
10 years old now.

~~~
agumonkey
Few points:

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.

~~~
pjmlp
Not at all, given that a composition engine and a full blown UI framework are
not the same thing.

And regarding innovation, CSS now has a grid layout thanks WPF engineers
initial contribution.

------
pavlov
_> "...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.

------
pedro1976
Worth mentioning Brad Frost with his wonderful formalized approach for
componetized UIs, called Atomic Design [0]

[0] [https://bradfrost.com/blog/post/atomic-web-
design/](https://bradfrost.com/blog/post/atomic-web-design/)

~~~
chrismorgan
Go for [http://bradfrost.com/blog/post/atomic-web-
design/](http://bradfrost.com/blog/post/atomic-web-design/) instead. His site
over HTTPS uses a self-signed certificate that expired over eight years ago.

------
tsss
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.

------
zubairq
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

