2 ms·
Why slow down CSS with constructs that can be achieved by prior compilation and a few Makefiles?
by alexchamberlain 15y ago
Why slow down CSS with constructs that can be achieved by prior compilation and a few Makefiles?
- masklinn 15y agoWhy require adding a fiddly and complex toolchain making ramp up and usage of these features more complex than it has to be, and harder to troubleshoot, when it's something making production easier to maintain in the long run? Because unless you suggest adding source maps to CSS (even though they still are not in JS), a preprocessor generating CSS makes CSS far more annoying to debug or play around with than native constants support would (and even with source maps, the usability of devtools style inspectors and editors would be significantly inferior to native support)
- alexchamberlain 15y agoI wouldn't mind a Chrome/Firefox extension to play around with extended CSS, but in production, I'm on the side of higher performance in Web Browser, which comes from simple style syntax.
- masklinn 15y ago> I'm on the side of higher performance in Web Browser, which comes from simple style syntax. Constant parsing and replacement would add pretty much no overhead to CSS parsing in the grand scheme of things.
- deleted 15y ago[deleted]
- ma2rten 15y agoYou could still compile css to backwards compatible, compact css and test and debug in the browser without effort?