Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
https://developers.google.com/web/fundamentals/ https://web.dev/rail/
There are a few, but my concerns are mainly centered around performance. The most popular CSS-in-JS libraries result in larger JS bundles for at lest two reasons I’m aware of: - Runtime JS to convert style objects to real CSS - Your app-specific style objects Generally, as you add features to an app, styles come with it. When these two concepts are tied together, they are unable to scale independently. Similarly, this will affect caching and resource download timing as well (ie: downloading one big JS file with everything vs a smaller JS file downloading in parallel with the CSS file). Then there’s the implication on debugging. In my experience, the use of something like emotion’s css prop on the React devtools introduces a lot of extra noise in the component tree. I know there are filtering capabilities, but still.Ultimately, I have found that most apps can get by with plain CSS for ~95% of the time and the rest of the time using whatever framework’s mechanism for doing inline styles based on runtime data. I get the DX benefits of going fully dynamic, but it ignores the impact on end users.FWIW, I’m not totally against CSS-in-JS as a concept, just in the outcomes that many of the popular ones impose. My preferred best of both worlds is https://vanilla-extract.style which emits plain CSS while retaining a lot of the DX of traditional libraries and is not React specific.