7 ms·

In modern web applications, it's pretty self evident that components are the right solution I often see this argument of "self evidence" made by develo

In modern web applications, it's pretty self evident that components are the right solution I often see this argument of "self evidence" made by developers who claim that some modern "best practice" approach is the right one. In my experience it is an indication that the proclaimed "better" approach is actually inferior. And the author had to resort to the argument of "obvious self evidence" because there are no better arguments around. I think it is driven by what I call "tool religion". Developers who invested significant amount of time into learning a tool become religiously attached to it. Because they now want to be an "expert" of the "best way". Not just "Some guy with a preference".

inglor 6y ago
Not going into the CSS vs. inline bit (I think CSS modules solved this for components years ago) but I think composing components is a reasonable abstraction and it _is_ self evident because it's what we've been doing everywhere else. "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.
- krageon 6y ago
  You've outlined a preference, but you haven't informed the reader why your preferred solution is superior other than by saying that it makes your problems "trivial" (which in any moderately complex problem space is extremely unlikely). 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?
- ximm 6y ago
  > components are pretty uncontested these last few years 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.
  - j-krieger 6y ago
    SSGs use templates with template arguments. How is that different from a component?
- mosselman 6y ago
  > Also - components are pretty uncontested these last few years. Throwing buckets of shit out the window was uncontested for years in medieval times as well. > is basically just With this you are basically just paraphrasing 'self evident'. > 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). MVC isn't the alternative to components. You are comparing apples and oranges. You don't need MVC to compose large UIs in web apps. 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. Whatever you do in the V is what we are talking about, you still need places for M and C in an SPA. > just "functions composing other functions and calling each other in a top-down flow with bottom-up updates through framework state" 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, it isn't something you _need_ or an alternative to how things were done before, you are making it sound like it is. Alternatively to using something like React, you could render HTML and go from page to page, redirect after handling a form, etc. In that case you don't need any stack of functions that need lots of passed down data and state management at all. I am not saying either is better in all cases. I am trying to point out some inaccuracies in what you are saying.
  - dragonwriter 6y ago
    > MVC isn't the alternative to components. 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.
gizmo 6y ago
Every CSS rule is effectively in global scope. And as the complexity of web apps increases regression testing becomes a bigger and bigger challenge. Being able to insert components multiple times and not having to worry whether an innocuous CSS change can result in "spooky action at a distance" really helps. 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.
- FreeHugs 6y ago
  Every CSS rule is effectively in global scope. We had this problem in programming forever. These days, you can put your function in a class in a namespace ... still the namespace sits in global scope. But we never came to the conclusion that we should make all code inline to solve it. Fortunately. So if you make a CSS rule to make links in your userlist red: .gizmosUserlist .name a { color: red } Then yes, it will apply to other .gizmosUserlist instances. 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.
- onion2k 6y ago
  Every CSS rule is effectively in global scope. 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.
  - rgossiaux 6y ago
    Yes indeed. Say you're creating a new component, and this new component will contain (among other things) some existing component, but the existing component needs to be styled slightly differently in this particular context. How do you deal with this with inline styling? Threading around this information between the components in JS to make the old component aware of the new one seems clearly wrong. A good old-fashioned style sheet handles it easily and relatively cleanly. 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.
nardi 6y ago
There's another very good reason to make a claim of "self evidence" besides not having any good arguments, which is if the proposition actually is self-evident to the target audience, and you want to focus on something else rather than dive into a long justification for the proposition. 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.
- wtf_srsly 6y ago
  -
  - monsieurbanana 6y ago
    This is only discussing about whether the premise that components is the right abstraction is self-evident. 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.
- FreeHugs 6y ago
  I think we should spend a minute on what is meant with "components" in the article. Would you say that this very site - Hacker News - is using this type of "components"?
  - IfOnlyYouKnew 6y ago
    The latest possible start date for components on the web was when PHP/fi (or whatever it was called) allowed you to ```include``` other files. 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.
davnicwil 6y ago
This is a good call - 'self evident' isn't the best wording. This was just meant as a statement that the component model is dominant in modern web development. 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.

inglor 6y ago

Not going into the CSS vs. inline bit (I think CSS modules solved this for components years ago) but I think composing components is a reasonable abstraction and it _is_ self evident because it's what we've been doing everywhere else. "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.

krageon 6y ago
You've outlined a preference, but you haven't informed the reader why your preferred solution is superior other than by saying that it makes your problems "trivial" (which in any moderately complex problem space is extremely unlikely). 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?
ximm 6y ago
> components are pretty uncontested these last few years 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.
- j-krieger 6y ago
  SSGs use templates with template arguments. How is that different from a component?
mosselman 6y ago
> Also - components are pretty uncontested these last few years. Throwing buckets of shit out the window was uncontested for years in medieval times as well. > is basically just With this you are basically just paraphrasing 'self evident'. > 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). MVC isn't the alternative to components. You are comparing apples and oranges. You don't need MVC to compose large UIs in web apps. 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. Whatever you do in the V is what we are talking about, you still need places for M and C in an SPA. > just "functions composing other functions and calling each other in a top-down flow with bottom-up updates through framework state" 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, it isn't something you _need_ or an alternative to how things were done before, you are making it sound like it is. Alternatively to using something like React, you could render HTML and go from page to page, redirect after handling a form, etc. In that case you don't need any stack of functions that need lots of passed down data and state management at all. I am not saying either is better in all cases. I am trying to point out some inaccuracies in what you are saying.
- dragonwriter 6y ago
  > MVC isn't the alternative to components. 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.

gizmo 6y ago

Every CSS rule is effectively in global scope. And as the complexity of web apps increases regression testing becomes a bigger and bigger challenge. Being able to insert components multiple times and not having to worry whether an innocuous CSS change can result in "spooky action at a distance" really helps. 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.

FreeHugs 6y ago
Every CSS rule is effectively in global scope. We had this problem in programming forever. These days, you can put your function in a class in a namespace ... still the namespace sits in global scope. But we never came to the conclusion that we should make all code inline to solve it. Fortunately. So if you make a CSS rule to make links in your userlist red: .gizmosUserlist .name a { color: red } Then yes, it will apply to other .gizmosUserlist instances. 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.
onion2k 6y ago
Every CSS rule is effectively in global scope. 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.
- rgossiaux 6y ago
  Yes indeed. Say you're creating a new component, and this new component will contain (among other things) some existing component, but the existing component needs to be styled slightly differently in this particular context. How do you deal with this with inline styling? Threading around this information between the components in JS to make the old component aware of the new one seems clearly wrong. A good old-fashioned style sheet handles it easily and relatively cleanly. 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.

nardi 6y ago

There's another very good reason to make a claim of "self evidence" besides not having any good arguments, which is if the proposition actually is self-evident to the target audience, and you want to focus on something else rather than dive into a long justification for the proposition. 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.

wtf_srsly 6y ago
-
- monsieurbanana 6y ago
  This is only discussing about whether the premise that components is the right abstraction is self-evident. 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.
FreeHugs 6y ago
I think we should spend a minute on what is meant with "components" in the article. Would you say that this very site - Hacker News - is using this type of "components"?
- IfOnlyYouKnew 6y ago
  The latest possible start date for components on the web was when PHP/fi (or whatever it was called) allowed you to ```include``` other files. 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.

davnicwil 6y ago

This is a good call - 'self evident' isn't the best wording. This was just meant as a statement that the component model is dominant in modern web development. 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.