Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
It lacks some usages that have been used in the industry for some years, i mean scoping styles (not necessarily for styling the element itself).
For example:
#products {
//Selectors for child elements of products id
}
This avoid unnecessary overrides, or adding extra unneeded classnames to elements with boilerplate such products-content-block, then you simply scope content-block inside #products.
This is more efficient on parsing and painting terms as CSSOM will find an ID instead seeking for all classnames on the entire project and then apply to matching elements which happens without IDs.
It's also meant for scalability as you will be able to find and edit quickly (and without overrides) an element inside a given scope on your project (specially when it grows a lot).
It will make your styles applying to .content-block only work inside #products, it's true, so it's your job to define styles that apply to all .content-block on the project and scope those who are specific from products page. Then you have custom styles when needed and global styles when needed.
This could seem a little bit disappointing at the beginning or with the mind on a little project, but avoids tones of issues when on a big project or a project that growth much more than expected.
I'm actually maintaining and developing over an e-commerce that receives more than 100k views a day. It was made with a customized prestashop and we need to apply this to all the entire project (which weights 1Gb of code approximately) because it was impossible to handle.
The reason was the same than always with CSS... Overrides, overrides over overrides, conditionally overrides due to redesigns and more redesigns... Now with the css scoped using page IDs and few script tweaks, the performance increased 15 points on pagespeed, the loading times decreased in 6 seconds (wow) and the user experience is much better. We started creating components too (migrating to a microservice architecture) so we can perform this practices from the beginning, and all styling is scoped inside each view component id attribute. No one of us (senior devs) thank for a moment on not using them for this purpose and junior devs understood quickly why to use them (as they needed to modify things on the old project too) 😂
I think your CSS system is literally the reason why you have to use IDs. IMO, a redesign shouldn't be a big problem if your CSS system is strong and flexible. The IDs scoping may fasten the project of re-writing the CSS but it is just a temporary fix. As the project gets bigger, keep using IDs for scoping would result in a messy CSS base. I don't know exactly what is your product component looks like but for me, using some classes is enough to create various styles of the product component (BEM-like CSS naming does very well on handling these cases). In your example, the same result can be achieved using classes like .product .product__content-block {}. Thus, I don't think using ID, in this case, is a good idea. However, for frameworks like ReactJS where you can write CSS separately for each component, using IDs for scoping is understandable.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
How many years of experience do you have on the industry?
When you make a project by yourself it's all nice, when you manage a project with 10+ devs, and during developments on it some left the company, some come in and so it's nearly impossible to keep all the code clean.
On the other hand BEM is nice but not perfect: lacks the ID scoping performance and make devs write more words for doing the same. Of course you can combine different methodologies into a single one which usually works better and it's more realistic.
It's the same situation on people developing microservices without thinking if it fits into their needs. Sometimes you'll need services, connected to microservices and maintaining a monolithic application that tbh could make no sense on refactoring it into a service/microservice architecture.
I asked you about your experience because juniors and students usually take the idea that those methodologies are meant to bring perfection and must be used "as is". Then, on a real world you can code the perfect architecture and methodology and when you end with your app the paradigm changed and you are outdated. This does not mean you need to recode all entire application to fit the trends, this mean you need to learn and understand deeply the reason to exist of this methodologies and discern which part could be useful for your project.
I've to remember a fact many times and I'm doing it again: IT is a science, this means try, combine, recombine, take conclusions and repeat.
It's like if you say me that water boils at 100°C and I could tell you well, this is approximately true at sea level but not on the everest or in a hole at 5km below sea level, also incorrect on other planet and so.
There's no perfection, there's no such a thing that works well everything, you always need context.
To conclude i need to answer your comments last part, BEM is understandable, but it olds bad on hughe projects. You will end with too large classnames and with multiline HTML declarations.
Also you don't need a js framework to build components, you can do it easily without js making a dispatcher and discerning where to show some html files (which has it's own css attached).
Moreover on some js frameworks you can make your css for being included on the same output element so it will make a non sense on scoping css using IDs because you already have your styling isolated. This is the only situation where i would not use IDs for scoping (because it's scoped already).
It lacks some usages that have been used in the industry for some years, i mean scoping styles (not necessarily for styling the element itself).
For example:
#products { //Selectors for child elements of products id }This avoid unnecessary overrides, or adding extra unneeded classnames to elements with boilerplate such products-content-block, then you simply scope content-block inside #products.
This is more efficient on parsing and painting terms as CSSOM will find an ID instead seeking for all classnames on the entire project and then apply to matching elements which happens without IDs.
It's also meant for scalability as you will be able to find and edit quickly (and without overrides) an element inside a given scope on your project (specially when it grows a lot).
It will make your styles applying to .content-block only work inside #products, it's true, so it's your job to define styles that apply to all .content-block on the project and scope those who are specific from products page. Then you have custom styles when needed and global styles when needed.
This could seem a little bit disappointing at the beginning or with the mind on a little project, but avoids tones of issues when on a big project or a project that growth much more than expected.
I'm actually maintaining and developing over an e-commerce that receives more than 100k views a day. It was made with a customized prestashop and we need to apply this to all the entire project (which weights 1Gb of code approximately) because it was impossible to handle.
The reason was the same than always with CSS... Overrides, overrides over overrides, conditionally overrides due to redesigns and more redesigns... Now with the css scoped using page IDs and few script tweaks, the performance increased 15 points on pagespeed, the loading times decreased in 6 seconds (wow) and the user experience is much better. We started creating components too (migrating to a microservice architecture) so we can perform this practices from the beginning, and all styling is scoped inside each view component id attribute. No one of us (senior devs) thank for a moment on not using them for this purpose and junior devs understood quickly why to use them (as they needed to modify things on the old project too) 😂
I think your CSS system is literally the reason why you have to use IDs. IMO, a redesign shouldn't be a big problem if your CSS system is strong and flexible. The IDs scoping may fasten the project of re-writing the CSS but it is just a temporary fix. As the project gets bigger, keep using IDs for scoping would result in a messy CSS base. I don't know exactly what is your
productcomponent looks like but for me, using some classes is enough to create various styles of theproductcomponent (BEM-like CSS naming does very well on handling these cases). In your example, the same result can be achieved using classes like.product .product__content-block {}. Thus, I don't think using ID, in this case, is a good idea. However, for frameworks like ReactJS where you can write CSS separately for each component, using IDs for scoping is understandable.How many years of experience do you have on the industry?
When you make a project by yourself it's all nice, when you manage a project with 10+ devs, and during developments on it some left the company, some come in and so it's nearly impossible to keep all the code clean.
On the other hand BEM is nice but not perfect: lacks the ID scoping performance and make devs write more words for doing the same. Of course you can combine different methodologies into a single one which usually works better and it's more realistic.
It's the same situation on people developing microservices without thinking if it fits into their needs. Sometimes you'll need services, connected to microservices and maintaining a monolithic application that tbh could make no sense on refactoring it into a service/microservice architecture.
I asked you about your experience because juniors and students usually take the idea that those methodologies are meant to bring perfection and must be used "as is". Then, on a real world you can code the perfect architecture and methodology and when you end with your app the paradigm changed and you are outdated. This does not mean you need to recode all entire application to fit the trends, this mean you need to learn and understand deeply the reason to exist of this methodologies and discern which part could be useful for your project.
I've to remember a fact many times and I'm doing it again: IT is a science, this means try, combine, recombine, take conclusions and repeat.
It's like if you say me that water boils at 100°C and I could tell you well, this is approximately true at sea level but not on the everest or in a hole at 5km below sea level, also incorrect on other planet and so.
There's no perfection, there's no such a thing that works well everything, you always need context.
To conclude i need to answer your comments last part, BEM is understandable, but it olds bad on hughe projects. You will end with too large classnames and with multiline HTML declarations.
Also you don't need a js framework to build components, you can do it easily without js making a dispatcher and discerning where to show some html files (which has it's own css attached).
Moreover on some js frameworks you can make your css for being included on the same output element so it will make a non sense on scoping css using IDs because you already have your styling isolated. This is the only situation where i would not use IDs for scoping (because it's scoped already).
Ah ye, you are right.