I think this is a reversal of the best practice of complex CSS class hierarchies. Having flatter and fewer CSS classes and more inline CSS will result in redundant style information, but having fewer CSS rules apply to nodes is a win overall.

They are, and that's why sibling and child selectors exist. If you only ever define simple classes with no thought about how they'll work in the overall app then you're in for a bad experience with styles cascading to things they're not meant to affect. If you actually use CSS the way it was designed then you have complete control over exactly what styles are applied to which elements.

A good rule in component based development is to define a class name for the component and use ".unique-component-class-name > .class-for-things-in-this-component" to limit the application of styles to that component. This takes a bit of discipline but it's pretty obvious when you get it wrong.

I've seen that inline CSS seems to be the latest trend, but I haven't really read up on why myself. Is this post really the current thinking? I find it completely uncompelling.

See my other comment in this thread (https://news.ycombinator.com/item?id=24221241) for how I'm tackling that sort of problem at the moment. tl;dr Work out what the dev should be able to override in the style at runtime and make it a CSS var that's set inline in the component. As I said there, it might not be the best approach especially in very large apps, but it does seem to be working well for me.

    Every CSS rule is effectively in global scope.

So if you make a CSS rule to make links in your userlist red:

    .gizmosUserlist .name a { color: red }

Shadow DOM is a way to prevent it if you want.

Personally, I think it is a good thing, that you can make all links in all gizmosUserlists red if you like and can target a specific one with a more specific selector if you like.

Nobody bats an eye when a compiler unrolls a loop, and you get N copies of the same code in assembly. In the same sense, nobody should care how clean the "assembly" of the web is (CSS+HTML).

I think the author is justified in saying that designing with components in web development has become self-evidently better than not. All new web frameworks are component-based. Web Components were added to HTML. Pretty much all web developers agree on this.

Are you a web developer? Do you disagree that the benefits of components in web programming are self-evident? If so, that is definitely surprising to me, and probably to the author.

Would you say that this very site - Hacker News - is using this type of "components"?

Realistically, people were probably doing the same with perl scripts before that.

And any definition of component is going to find it hard to exclude standard html elements, other than by specifying that it's users being able to define new ones, and not just browser vendors.

Incidentally, CSS was the original implementations of user-defined components: it allows defining certain behaviours once, for a "class" or group of similar elements, then using it repeatedly.

I don't have the feeling that what he really means with "Inline CSS works better in a component world" is "Inline CSS is the better choice since the 90s".

Your question is slightly nonsensical, because components are not a design language, and it's not something you can see by looking at a rendered web page. To know whether Hacker News is using components, I would need to look at the source code, because components are a programming paradigm.

If you're asking me to comb through HN's JavaScript to see if they use that paradigm, well, no thank you.

    This definitely leads me to believe that
    you don't have much experience with modern
    web frameworks

That's all, nobody else in this particular thread said anything about whether that means inline styles is the way to go.

You might want to post your question to the author of the blog post, or as a top-level question.

"Component based" is basically just "functions composing other functions and calling each other in a top-down flow with bottom-up updates through framework state". It's "evident" that it's the correct abstraction because the alternatives (things like managing app state and UI interactions through MVC, MVVM and MVP) are mostly not needed or are not the right level of abstraction for composing large UIs in web apps (where components make it trivial and shift the complexity to stitching the state manangement <-> component interop when you need to break the abstraction).

Also - components are pretty uncontested these last few years.

If I can't see it given that I have actual experience with what you're talking about and can reasonably be expected to have the background to understand, how is someone from a different field supposed to understand what you wrote?

I don't think so. Many people still use traditional frontends, i.e. static or server-rendered HTML and CSS.

Components are newer and there is still more to talk about, so they naturally are more prominent on sites like hacker news. That doesn't mean they are uncontested in practice.

MV(C/VM/P) is in fact one of the front-end alternatives to components.

> You don't need MVC to compose large UIs in web apps.

As the argument was that components were the obviously correct solution to that, I think the poster you are responding to would agree you do t need MVC, etc., for that, but they are still used for it.

> You use the MVC pattern to separate concerns: fetching data from the database (M), presenting said data (V), handling requests and managing sessions (C) and because the pieces of code live in different places: MC on the server, V in the browser.

Classical MVC was for local GUI apps, an the later original web MVC had all three components on the backend. (View being the conponent that rendered final HTML, or XML/JSON for APIs, often from templates + objects from the controller.) In web frontend, the M usually interacts with APIs rather than DBs, the V still renders HTML, and the C, VM, or P does it's usually role.

> The whole "top-down..bottom-up" thing is a mechanism that only makes sense when you have decided that you want to have some sort of SPA,

Sure.

> it isn't something you _need_

I'm not sure what want/need distinction you are trying to make here.

> or an alternative to how things were done before

Both having a SPA and using components vs other approaches for a SPA are alternatives to what was done before. You seem really only to be disagreeing with the latter, but HTML+JS apps that were SPAs (even if the name wasn't originally in use) are almost as old as JS, and much older than component based approaches.

> I'm not sure what want/need distinction you are trying to make here.

What I feel is happening in these discussions is that people take the issues they run into when creating SPA with component frameworks (state management, making calls to back ends and error handling to name a few) and present them as fundamental issues of creating web applications.

When React first came out, you quickly ran into the issue that, for a bigger application, you needed to pass too many parameters through the whole stack to reach the outermost components just to update something like a counter badge, etc. Then came Redux and it 'solved' this.

This issue of passing parameters down the component stack is only an issue within the context of using a stack of components. It isn't one of the issues that exist when building a web application using server side rendering. So what I mean with 'you don't need' state management in the front-end is that the issue of managing state is completely inherent to building a UI with components, it isn't an absolute problem of creating web applications.

The rest though is not what I intended to get across. I've done it both ways, the inline way works better for the component model is what I'm saying. If a different model comes along in future, there may be a better approach and I may switch to that.

This isn't about there being one right way, just more appropriate ways for different paradigms.