3 ms·

I'm still shocked at the decades it took for web technology to "discover" component based architectures. It's the main reason I steered clear of JS and web tech

I'm still shocked at the decades it took for web technology to "discover" component based architectures. It's the main reason I steered clear of JS and web tech as much as I could, with a small dalliance to Echo2 in 2007.

Yoric 6y ago
To be fair, mozilla had a component-based architecture for the web since 1997 (called XUL). Some things were a bit odd to use but it worked pretty well and for the next ~20 years, it was way ahead of HTML & co. in just about everything, including localization, accessibility and performance.
- toyg 6y ago
  XUL made one big mistake: RDF. It's basically a law: anything RDF touches, will fail to get adoption.
DaiPlusPlus 6y ago
The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enough. But what about a checkbox-list? And how does that component accept data for data-binding purposes? Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. I compare the situation to the component ecosystem for VB6 and WinForms - which to be fair was a lot worse as consumers often had little to no control over how those components rendered, appeared or behaved - but (no pun intended) elements of the same problem exist today. Another example is WPF - which has major unaddressed issues still - which to be fair is worlds apart from WinForms in terms of what it’s templating system is capable of. A nice thing about WPF was that a component (Control’s) XAML was transparent and editable at design-time in VS, so the consuming application’s developer could get what they want out of it, the catch was that WPF templates are horrendously complex: getting VS to expose the XAML for even a <Button> would dump 50KB+ of markup into your application XAML because it was an all-or-nothing system and you needed XAML for every button state and behaviour - right down to the pulsating button glow effect that was only ever used in Windows Vista...
- nateroling 6y ago
  Isn’t the answer... more components? If the more complex components are themselves composed of a small number of simple components, you can replicate them with your own tweaks.
- claviska 6y ago
  It's not always easy to provide a good dev exp with complex components, but it's not impossible. Using composition wisely can offer endless flexibility while maximizing code reuse. For example, Shoelace's <sl-select> component mimics the browser's <select> component. It has single select, multi-select, size variations, shape variations, type-ahead selection, validation states, etc. This component is a composition of <sl-dropdown>, <sl-input>, <sl-menu>, etc. and its entire source is less than 500 LOC (including doc comments and prettier formatting). This is significantly less than many independent <select> alternatives I've seen, and the component itself doesn't have to worry about positioning, styling, etc. because that's handled by lower-level components. > Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. With web components, slotted content stays in the light DOM and is therefore controlled by the user. It's actually kind of a pain point when building them because, internally, you don't have that much control over arbitrary markup. (You can access markup through slot.assignedNodes() and style things with ::slotted() but it's not what I'd call a first-class experience for component developers.)
ng12 6y ago
The difficulty was not discovering it but implementing it. The DOM was not built for abstractions like components -- it's a fundamentally global, imperative API.

Yoric 6y ago

To be fair, mozilla had a component-based architecture for the web since 1997 (called XUL). Some things were a bit odd to use but it worked pretty well and for the next ~20 years, it was way ahead of HTML & co. in just about everything, including localization, accessibility and performance.

toyg 6y ago
XUL made one big mistake: RDF. It's basically a law: anything RDF touches, will fail to get adoption.

DaiPlusPlus 6y ago

The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enough. But what about a checkbox-list? And how does that component accept data for data-binding purposes? Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. I compare the situation to the component ecosystem for VB6 and WinForms - which to be fair was a lot worse as consumers often had little to no control over how those components rendered, appeared or behaved - but (no pun intended) elements of the same problem exist today. Another example is WPF - which has major unaddressed issues still - which to be fair is worlds apart from WinForms in terms of what it’s templating system is capable of. A nice thing about WPF was that a component (Control’s) XAML was transparent and editable at design-time in VS, so the consuming application’s developer could get what they want out of it, the catch was that WPF templates are horrendously complex: getting VS to expose the XAML for even a <Button> would dump 50KB+ of markup into your application XAML because it was an all-or-nothing system and you needed XAML for every button state and behaviour - right down to the pulsating button glow effect that was only ever used in Windows Vista...

nateroling 6y ago
Isn’t the answer... more components? If the more complex components are themselves composed of a small number of simple components, you can replicate them with your own tweaks.
claviska 6y ago
It's not always easy to provide a good dev exp with complex components, but it's not impossible. Using composition wisely can offer endless flexibility while maximizing code reuse. For example, Shoelace's <sl-select> component mimics the browser's <select> component. It has single select, multi-select, size variations, shape variations, type-ahead selection, validation states, etc. This component is a composition of <sl-dropdown>, <sl-input>, <sl-menu>, etc. and its entire source is less than 500 LOC (including doc comments and prettier formatting). This is significantly less than many independent <select> alternatives I've seen, and the component itself doesn't have to worry about positioning, styling, etc. because that's handled by lower-level components. > Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. With web components, slotted content stays in the light DOM and is therefore controlled by the user. It's actually kind of a pain point when building them because, internally, you don't have that much control over arbitrary markup. (You can access markup through slot.assignedNodes() and style things with ::slotted() but it's not what I'd call a first-class experience for component developers.)

ng12 6y ago

The difficulty was not discovering it but implementing it. The DOM was not built for abstractions like components -- it's a fundamentally global, imperative API.