The comparison is good. Humans are also stacked in volumes and we still measure population density over a surface because the third dimension is less significant in this context.
Europe was able to impose policies to Greece because Greece was requesting loans from Europe. Those loans were required because other investors were unhappy that Greece had hidden the real state of its finance in its reports.
There is no way to measure awareness. We can only know we are aware ourselves. For all we know trees or rocks might have awareness. Or I could be the only being aware of itself in the universe. We have no way to prove anything about it. Therefore it is not a useful descriptor of intelligence (be it human, animal or artificial).
This is factully wrong. You are confusing react with nextjs. React produce html documents, and the first usecase was reactdom, a pure client rendering library.
We can only speculate one the difficulty of the fixes. I am not an expert but I believe culling and LoD are two big things for engines. Not being able to use existing implementations is really unfortunate. I guess the "tricks" are well-known but I don't think the implementation is easy.
The only way to know is to go to the page and inspect it using devtools. No Ide will be able to infer which rule is going to apply to any given element.
But the problem is that you need to make sure that a given css change is going to affect only a specific set of component. So you need to check all components. Since it will be too time consuming, you will probably skip this step and hope for the best (and do some QA to check that nothing is obviously broken).
A lot of applications have a long lifetime. They are not shipped only once. If I want to add a new feature, say allow users to perform a new operation in an existing screen, I will have to update a few components for this.
You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.
The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.
It is still coupled because the css will need to know the html structure in order to work. If you update the html, you probably need to update the css.
This section is what I am talking about. You compare two methods of writing components and then declare that the tailwind version is tightly coupled but the semantic version is loosely coupled. In programming lingo this means tailwind is bad and semantic is good.
But you don't explain why the tailwind version is tightly coupled and the semantic version is loosely coupled. And you don't do it because it is simply not the case. The coupling between html and css is not tighter or looser. It just goes in a different direction.
> The semantic version, allows you to change the design of the gallery freely. You name the component and style it externally. With Tailwind the style cannot be separated from the structure.
Same with tailwind. You update your component to update its style. With semantic you can update the css rules without touching the html, but you don't know if this css change won't break another part of your design. If you have a simple html structure like a blog with very few components, then semantic works (but so does anything really). If you have lots of components and you need to update them in order to add new features, then semantic will bring more issues.
No this article is flawed. It fails to recognize the fact that css and html are always coupled in one direction or another. With tailwind the css is fixed and the html is designed around it. With semantic the html is first created and then you write your css around it.
The fact is that updating css in a big project and a big team is very difficult. Rules are scoped globally. It only takes a junior making a few design mistakes
and now you don't what you are going to break if you update anything.
With tailwind the css is fixed and will never change. So you just change your html and you know what to check/what to test again. For any medium to large project this is a big QA & time boon.
"just use code review, naming convention, xxx best practice". This argument is similar to "just don't make mistakes". Mistakes will be made. With semantic css you will suffer.