DEV Community

Discussion on: What happened to Components being just a visual thing?

Collapse
 
brucou profile image
brucou • Edited

I can't agree more with a lot of the premises here. What is happening today of course happened before. We have seen decades ago how HTML was starting to include presentational markup and I am grateful that CSS was born to impede that. Let me quote Håkon Wium Lie, who developed CSS in 1994:

Determining the right abstraction level is an important part of designing a document format. If the abstraction level is high, both the authoring process and the task of formatting the document become more complex. The author must relate to non-visible abstract concepts. The benefit of a high abstraction level is that the content can be reused in many contexts. For example, a headline can be presented in large letters on printed sheets, and with a louder voice in a text-to-speech system.
[…]
Conversely, a low level of abstraction will make the authoring and formatting process easier (up to a point). Authors can use visually oriented WYSIWYG (What You See Is What You Get) tools, and the browser does not have to perform extensive transformations before presenting the document. The drawback of using presentation-oriented document formats is that the content is not easily reusable in other contexts. For example, it can be difficult to make presentation-oriented documents available on a device with a different screen size, or to a visually impaired person.
[…]
The introduction of presentational tags in HTML was a downwards move on the ladder of abstraction. Several of the new elements (e.g., BLINK) were meaningful only for particular output devices (how is blinking text displayed in a text-to-speech system?). The creators of HTML intended it to be usable in many settings but presentational tags threatened device independence, accessibility and content reuse.

Presentational tags crept into HTML for the same reason that components are acquiring more responsibilities or <Provider>, <Query> components appeared. One, it was possible. Second, it was the path of least resistance. You won't create a new language just to show something red right? By the moment you need to do more things, and a new, targeted language seems better, it is already too late to reverse course. This is the principle of incrementalism. Third, it was easy. Easy drives adoption.

Now because CSS is its own thing, it can be used completely independently of HTML and has been used to style web pages, pdfs, native apps, and more. That is what separation of concerns gives. Mastery of the concern. Reusability in different contexts.

In the same way, most components you see in a webapp cannot be reused because the more they do, the less it is likely that any other parts needs the same behavior. The smaller the component, the less concerns, the more reusable. This applies to any software component, be it React component, web component, activex controls, etc.

Just like CSS captures the styling concern, HTML (mostly) describes content. It does not describe how that content evolves over time in response to events, i.e. the application behavior. To do this you need to describe arbitrary computations, and here a Turing-complete language makes sense to address the general case. In specific cases, a DSL may suffice but that is domain-, application-dependent.

So JSX is that Turing-complete language, one trivial transformation away from JavaScript. It is a syntactic trick that makes things easy and triggered faster adoption of vDOM-based frameworks. The <For> tag is a step further in the syntactic tricks that are designed to make stuff look like HTML. As Håkon Wium Lie said, this is putting things that are at different abstraction levels at the same syntactic level (Determining the right abstraction level is important). It is easier (a low level of abstraction will make the authoring easier), it may also be confusing. <For> does not describe any kind of content, like say <title>. But some folks think that developers in general want to entertain the illusion that they are writing some sort of enhanced HTML, when they are actually writing JavaScript. Template languages do things much better as they have syntactic constructions that clearly differentiate what is HTML, what is data/parameters, and what is control flow.

Anyways, yes to separation of concerns, always. Yes to architecture, modules, and first principles. It is not like we just started to write software. There are good practices that are decades old that we regularly seem to forget.