5 ms·

I've been using inline everything since templates (ejs) came into existence. Once you have templates you're only editing one location anyway. The biggest prob

by PhrosTT 11y ago

I've been using inline everything since templates (ejs) came into existence. Once you have templates you're only editing one location anyway. The biggest problem with CSS is it's really easy to add, and close to impossible to delete (detecting potential repercussions is hard). Sure there's performance issues, but most of the time your developer/maintenance time is worth the the extra bytes.

Roboprog 11y ago
Sounds like an opportunity for IDE makers. Add plugins to track CSS/HTML/templating, "where used" tools, and refactoring to push frequently repeated styles up into a main CSS file, or rarely used styles down into the few elements using it. Hopefully, there are few enough classes and styles injected from a long js code chain that you can manually check the things the IDE misses. JetBrains IDEs are surprisingly good at finding things connected via common libraries in code, so I'm hopeful that IDE makers could recognize common patterns in libraries such as React and Angular (e.g. - ng-class)
- overgard 11y ago
  I doubt IDE's could really do much with it -- adding and removing classes dynamically means it can answer the question "is this used?" but it can never answer the question "is this unused?" Plus there's about 4000 template languages being invented every second, that the IDE would need to not just highlight, but intelligently parse.
Dillybob 11y ago
But, is that extra development time worth the time your visitor loses whilst page rendering? If it's a significant amount, I would say no.
dcherman 11y ago
It's not actually that terrible, but then again it depends on what you're building I suppose. Where I work, I made a fairly robust image diffing utility that runs using Selenium/WebDriver on all browsers that we support. Combined with a robust test suite of many different scenarios, we can make changes to our stylesheets with a pretty high amount of confidence that if anything changed, it'll fail the build.
- Roboprog 11y ago
  That sounds like a lotta work, but that's a good thing to have when the appearance is an important part of what you are doing. (cost-benefit, risk management and all that)

by PhrosTT 11y ago

Roboprog 11y ago

Sounds like an opportunity for IDE makers. Add plugins to track CSS/HTML/templating, "where used" tools, and refactoring to push frequently repeated styles up into a main CSS file, or rarely used styles down into the few elements using it. Hopefully, there are few enough classes and styles injected from a long js code chain that you can manually check the things the IDE misses. JetBrains IDEs are surprisingly good at finding things connected via common libraries in code, so I'm hopeful that IDE makers could recognize common patterns in libraries such as React and Angular (e.g. - ng-class)

overgard 11y ago
I doubt IDE's could really do much with it -- adding and removing classes dynamically means it can answer the question "is this used?" but it can never answer the question "is this unused?" Plus there's about 4000 template languages being invented every second, that the IDE would need to not just highlight, but intelligently parse.

Dillybob 11y ago

But, is that extra development time worth the time your visitor loses whilst page rendering? If it's a significant amount, I would say no.

dcherman 11y ago

It's not actually that terrible, but then again it depends on what you're building I suppose. Where I work, I made a fairly robust image diffing utility that runs using Selenium/WebDriver on all browsers that we support. Combined with a robust test suite of many different scenarios, we can make changes to our stylesheets with a pretty high amount of confidence that if anything changed, it'll fail the build.

Roboprog 11y ago
That sounds like a lotta work, but that's a good thing to have when the appearance is an important part of what you are doing. (cost-benefit, risk management and all that)