[HN Gopher] Real-world CSS vs. CSS-in-JS performance comparison
___________________________________________________________________
Real-world CSS vs. CSS-in-JS performance comparison
Author : ______-
Score : 112 points
Date : 2021-06-08 18:24 UTC (4 hours ago)
(HTM) web link (pustelto.com)
(TXT) w3m dump (pustelto.com)
| MatekCopatek wrote:
| Can someone explain the appeal of CSS-in-JS? I've used scoped
| styling in .vue components extensively, at a quick glance it
| seems to offer similar benefits (lives right in your component
| and is scoped to it), but most importantly it can be extracted to
| a plain CSS file when building frontend assets.
|
| Is there something extra these React libraries do that prevents
| them from doing this?
| [deleted]
| dheera wrote:
| Considering CSS is Turing complete I suppose we could also do
| JS-in-CSS.
| troll_v_bridge wrote:
| Css-in-js helps minimize context switching for logic related
| styling, believe this is one of the main advantages from a
| developers perspective. It also allows javascript developers to
| colocate their CSS where they want, separate file, inline, same
| file, etc. This is more flexible than a .vue file in that
| sense.
| lwhi wrote:
| I've never really been comfortable with the idea, as I was
| raised on the idea that separation of concerns is good thing.
|
| I think one of the main appealing aspects is the idea of never
| having a styling conflict with other components ever.
|
| Less macro-level management and organisation required.
|
| --
|
| Edit: sorry, just realised you're talking about a specific
| implementation.
| The_rationalist wrote:
| Css modules totally solve this without any css in js
| tobobo wrote:
| I don't see CSS-in-JS as a rejection of separation of
| concerns. In fact, one of the big advantages of CSS-in-JS is
| that it lets you decide how best to separate your concerns.
|
| Using hand-tuned CSS will undoubtedly be the most performant
| option, but it leaves you with very difficult problems at the
| boundary of your styling and content/structure concerns. If
| you have even a sliver of dynamic content in your website, it
| will quickly become near-impossible to verify that your
| content and styles work together as expected, or even to
| verify that your class names match between your CSS and HTML.
|
| On the other hand, if you use CSS-in-JS, what you lose in
| performance you gain in compatibility guarantees between your
| concerns, regardless of how you prefer to separate. Are you
| putting your styles in the same files as your layout
| components to fully separate one feature from another? Great,
| you can unit test those components and be reassured that the
| elements are styled as expected. Are you isolating your
| styles to only a certain subset of components that deal
| directly with styling concerns? Also great--if you're using
| TypeScript, you can guarantee correct use of those styles at
| build time.
|
| For a large enough team, those guarantees really pay off. If
| you have lots of customers using 2G/3G networks and want to
| hand-roll your CSS, I commend you! For most products, I think
| there's a better way to make that tradeoff and your users
| won't mind a slightly slower experience that has fewer bugs.
| lwhi wrote:
| If you want to replace all the styling in your project,
| because you've had a rebrand; I would argue that CSS in JS
| makes your life more difficult.
|
| If you want to share styling between your app and your
| website; I would also state that this process is made more
| difficult.
|
| If you want to create, implement and maintain an atomic
| design system to build in consistency and reuse .. again,
| more complicated that it might have been.
|
| To add to that, this article suggests that there's a
| performance deficit.
| stevebmark wrote:
| CSS and Javascript aren't concerns, they're technologies, and
| separation of technologies isn't a software engineering
| principle. "Concern" is pretty undefined in general. If
| anything, they're all part of the "view" concern. It's the
| same reason why JSX doesn't violate separation of "concerns."
| rimliu wrote:
| Moving goalposts is not a concern either. CSS and
| Javascript are concerns, becaus HTML is of
| content/structure, CSS is for styling and JS is for
| behaviour. Of course somewhere along the road devs thought
| that HTML and CSS are to primitive to spend any time
| learning them properly, because of that they later found
| them to bee too complex and we ended up in the mess we are
| right now, when we try to hide the lack of understanding
| under multiple wraps of abstraction.
| vgel wrote:
| > CSS is for styling
|
| The web has never lived up to that ideal. Sometimes you
| need to add a wrapper div with no semantics to make your
| layout work. Sometimes you need some Javascript to do a
| special layout CSS doesn't support or work around some
| other limitation. I've never seen a project that actually
| had meaningful "separation of concerns" based on
| technology, whereas almost every componentized project
| has at least decent separation of concerns along the
| component axis -- where you can drop a component into a
| design without thinking about it's internals at all.
| lwhi wrote:
| We are not living in a world of absolutes. To put it
| simply, being able to replace the presentation layer
| _easily_ is a benefit to many projects
|
| > I've never seen a project that actually had meaningful
| "separation of concerns" based on technology.
|
| With respect, you just need to look a little harder.
|
| I've used react libraries which are fundamentally tied to
| their styling, due to the fact they use CSS in JS.
|
| Applying custom styling has been more difficult than it
| should have been.
| stevebmark wrote:
| I don't think it's that clear cut, you can define all
| sorts of behavior with both HTML and CSS, and there's no
| semantic meaning in `<div>`, which itself changes page
| style due to its layout properties. I don't know what
| goalposts are being moved, React/css-in-js have never
| violated separation of concerns. After all, css-in-js
| produces CSS, and React produces HTML. Separation of
| technologies isn't a principle, but DSLs are a well
| established pattern.
| lwhi wrote:
| Is complexity a drawback?
| lwhi wrote:
| I agree, I don't know why you're being downvoted.
| lwhi wrote:
| I disagree.
|
| You're being obtuse. JavaScript is used for more than
| presentation.
| rajangdavis wrote:
| If you want to have a range of applicable values for some CSS
| property or state-based styling, CSS-in-JS can be a good tool
| for expressing that as opposed to writing JS that updates some
| styling declaratively.
|
| For example, I've used it on a personal app to allow adjusting
| the placement and opacity of controls. I prefer the CSS-in-JS
| approach because the code is simple to understand, I can reuse
| the code in multiple areas, and I can pass state to some
| function to generate the styling. I also imagine that I could
| also write some spec to support it, but it's not something that
| I plan on quite yet.
|
| It's not a technique that I would use for ALL styling, but I
| think for the use-case I mentioned above, it works great.
| runarberg wrote:
| There are number of techniques that can fit that. State based
| styling can be achieved with simple class name toggles or CSS
| animation + the `animationend` event. If you don't like
| toggling classes with JS there are number of selectors
| (including the attribute selector) which you can use instead.
|
| For making code easier to understand you can set a CSS custom
| property instead of specific style values, and the CSS will
| be really straight forward.
| rajangdavis wrote:
| To be clear - when I need to toggle a basic state with a
| class or set of classes, that is the strategy I use.
|
| Where that technique fails is when you have _hundreds_ of
| possible values that can occupy a given state.
|
| If I want to set the rotation or opacity for a control and
| I want to use a range of values, there is nothing native in
| CSS to allow me to do that.
|
| You can use SCSS to dynamically generate the CSS class
| declarations for every possible value, but I would only
| ever use that solution if I needed the performance boost
| and that was _the only way to get it_.
| runarberg wrote:
| I see what you mean. For that I would use a CSS custom
| property: .rotatable {
| transform: rotate(var(--rotation-angle)); }
|
| ...and set it directly with JavaScript
| document .querySelector('.rotatable')
| .style.setProperty( '--rotation-angle',
| `${angle}deg`, );
| rajangdavis wrote:
| And that's why I wrote:
|
| If you want to have a range of applicable values for some
| CSS property or state-based styling, CSS-in-JS can be a
| good tool for expressing that as opposed to _writing JS
| that updates some styling declaratively_
| The_rationalist wrote:
| Css variables can be exported and modified in js through some
| libraries and without having the constraints of css in js.
| runarberg wrote:
| You don't even need a library. Modifying a CSS variable is
| as easy as: myElement.style.setProperty('
| --my-custom-property', 'some-value');
| thoughtpalette wrote:
| Main thing that I think would prevent it is the ability to use
| React Props/Arguments in your CSS.
|
| e.g. const Container = styled.div` width: $props => props.width
| `
| eckmLJE wrote:
| If you have a lot of dynamic styles that respond to application
| state, then even with vanilla CSS you are often writing JS to
| manage class declarations to get the right CSS combinations.
| With styled-components, instead of adding/removing/combining
| class names, you can write javascript inside your declarations
| that use the state variables.
|
| For me, writing javascript that directly sets css properties
| based on state variables is a more powerful and clearer
| approach to managing dynamic styles than manually managing
| class names.
|
| Further, when combined with typescript, you can type a theme
| object in the styled-components theme provider and get auto-
| complete in your editor on your style tokens like colors,
| spacing values, timing in ms, etc.
|
| So it has many benefits beyond scoping styles to a component.
| lwhi wrote:
| > For me, writing javascript that directly sets css
| properties based on state variables is a more powerful and
| clearer approach to managing dynamic styles than manually
| managing class names.
|
| I'd argue there's a lot more flexibility available if you
| choose to use classes.
|
| Sure, it's more complicated and involves more work; but to
| say it's less powerful just isn't true.
| iaml wrote:
| > there's a lot more flexibility available if you choose to
| use classes
|
| That is simply not true. Apart from what was described in
| the post above, in JSS frameworks such as styled-
| components, you usually have ways to hook directly into css
| parser, allowing you to implement custom expansions,
| replacements or basically whatever logic you want. This is
| not possible unless you write your own language and
| transform it to css.
| lwhi wrote:
| We'll have to agree to disagree.
| runarberg wrote:
| I've had great luck achieving that with CSS custom
| properties. I assign a custom property to a style rule and
| then change that property with JavaScript when needed.
|
| I also find much state has a nice selector (e.g. :hover,
| :checked, :invalid, :empty, :focus-inside, etc.) or media
| queries `@media (prefers-color-scheme: dark)` which I can
| change the custom property values inside. So it is really an
| exception when I manually need to change the value of custom
| properties with JavaScript.
| TimTheTinker wrote:
| We're migrating to styled-components at my current company.
| It's nice for abstracting components -- either into shared
| libraries or separate micro-clients that are composed together
| at runtime.
|
| In those scenarios, there are a few benefits: (a) no worries
| about accidentally trampling on someone else's styles, or
| styles from elsewhere overriding your styles; (b) build
| configuration is simpler; and (c) no worries about how CSS/SCSS
| is referenced/loaded - all references are handled in plain JS
| with no special loaders or anything.
|
| I wouldn't use it everywhere (I've used other approaches that
| have worked just fine), but for some scenarios it makes sense.
| 11235813213455 wrote:
| like you say, the benefit is to easily attach styles to
| components (in the same programming language, compared to
| scss/css modules)
|
| note: @emotion/styled is equivalent to styled-components,
| lighter and easier to set up for SSR (it works out of the box
| https://emotion.sh/docs/ssr#default-approach)
|
| When using server-side rendered pages, there's no performance
| loss on the client-side, maybe a little more processing
| server-side, not sure if significant
| alexchamberlain wrote:
| Doesn't SCSS support CSS modules to prevent trampling on each
| others styles?
| jahewson wrote:
| For highly dynamic styles it allows me to avoid all the logic
| around coming up with class names and applying them. Think of
| it less like traditional CSS and more like a super version of
| inline styles.
| jfengel wrote:
| I'm afraid I don't get it either. To me, the big disadvantage
| of css-in-js is that the browser doesn't display it neatly.
|
| If I write plain CSS, it's easy to make changes right in the
| browser and have it react instantly. Or I can make them in the
| .css file, and webpack (or whatever it is) will automatically
| redisplay them without having to restart the app.
|
| Perhaps if I had much larger projects I'd see more headaches
| that drives people to css-in-js. But I manage fairly large
| things and don't have too much grief with plain css.
| lwhi wrote:
| You need to implement an alternative stylesheet for people
| with increased visual needs (e.g. high contrast).
|
| How would you go about doing this?
|
| --
|
| Edit: to the person who downvoted me for asking a question.
| Classy.
| easrng wrote:
| I'd use CSS variables for colors and write another
| stylesheet, using the cascade so I only override the styles
| I need to.
| notoverthere wrote:
| Switch the `<link href="">` value to point to a high
| contrast stylesheet.
|
| Or alternatively, apply a class to the body tag - e.g.
| `<body class="high-contrast">` - and declare CSS rules
| accordingly. Specificity should take care of overriding the
| 'normal' style rules where needed.
| mekkkkkk wrote:
| I've worked on and off with React since its inception, and the
| main reason I would use it is simple ergonomics. If you are
| working with an MVP or a small widget project, you gain a lot
| of velocity. You don't need to worry about scoping, naming
| collisions, class toggles, etc. and as long as you use decently
| small components, it all fits snuggly in the same file as the
| component definition.
|
| The price you pay comes in the way of performance and
| maintainability. Since the line becomes very blurry between
| styling and markup, it's up to the dev(s) to bring order to
| potential chaos.
|
| For any bigger project, my go to solution is SCSS modules. It's
| by far the most versatile solution I've tried if you want to
| roll your own CSS and not rely on a CSS framework. You don't
| need to worry about scoping, the bundle process is excellent,
| you have access to all of your normal SCSS shenanigans and most
| important it's a solution that makes it dead easy to collect or
| break down parts into logical units.
| WorldMaker wrote:
| Some of the React libraries do support CSS extraction to plain
| CSS files.
|
| styled-components does not, and I'm not sure exactly why. It
| may be related to that they support runtime variables inline as
| React props and/or that they didn't want to complicate the
| build pipeline more than they already complicate it. (Many of
| the libraries like Vue's have necessarily tighter coupling with
| webpack or whatever other packer they use to get the extraction
| automated.)
| iaml wrote:
| Nobody mentioned this, but for me big benefit is that you can
| remove everything related to css from webpack, and no
| dependency on ruby/dart/whatever else. Oh, also autoprefixer
| out of the box.
| Kiro wrote:
| I love not having to come up with class names. That's it.
| The_rationalist wrote:
| Yay let's loose semantic meaning aka understandability and
| reuse
| the__alchemist wrote:
| I think there's a conflation that confuses this: We have CSS in
| SPA components vs CSS, and inline CSS in HTML. In the latter,
| you may prefer inline to prevent flipping between files, and
| creating reusable data structures that are used once. In the
| former, you may have the same, or additional reasons like
| programmatically changing styles.
| stephen wrote:
| We have a "write tachyons/tailwinds CSS-in-TypeScript" project
| [1] that can sit on top of any CSS-in-JS runtime (emotion and
| fela are both supported).
|
| I'm hoping to eventually find one of these build-time CSS-in-JS
| frameworks that is smart enough to partially eval ~80% of our
| `<div css={Css.m4.black.$}>` expressions to be zero runtime.
|
| And, if/when this happens, do this as a seamless upgrade to our
| existing codebases, i.e. without any lines of
| `css={Css.m4.black.$}` in our app need to change.
|
| Basically we're using our Truss DSL both for atomic/utility class
| names today + a decoupling layer to switch CSS-in-JS libs in the
| future if/when needed.
|
| I think Linaria and https://github.com/twstyled/twstyled (based
| on/forked from Linaria) are the closest to doing this eval during
| compilation, but haven't had to dig in so far (runtime emotion
| has been fast enough for us so far).
|
| [1]: https://github.com/homebound-team/truss/
| nwienert wrote:
| I wrote SnackUI[0] to solve this exact problem.
|
| It gives you in my opinion a nicer style syntax (flat style props
| on the component) while avoiding the downsides of CSS-in-JS by
| extracting everything but the most dynamic parts to pure CSS.
|
| The optimizing compiler part was a large investment to get right,
| especially with theme and media query support. But the main claim
| to fame is that it also works on React Native, and optimizes
| there as well, so you get for the first time a really performant
| way to style native and web apps at once.
|
| [0] https://github.com/snackui/snackui
| paulintrognon wrote:
| Why the downvotes?
| mrwnmonm wrote:
| I noticed this a while ago. Some people with the ability to
| downvote, downvote some comments for no reason, other than
| hating the comment somehow. They try to release their hate
| through the downvote, which is funny actually.
| alesso_x wrote:
| The website is being rate limited, here's a google cached version
|
| https://webcache.googleusercontent.com/search?q=cache%3Ahttp...
| theschmed wrote:
| or you can read the source markdown here:
|
| https://github.com/Pustelto/personal_web/blob/master/src/blo...
| leetrout wrote:
| What is the author doing that a static site is rate limited in
| cloudflare?
| zoover2020 wrote:
| Tailwind haters ;-)
| e12e wrote:
| Google cache gives me a 404 (maybe because mobile?). This works
| for me:
|
| https://web.archive.org/web/20210608190243/https://pustelto....
| lucas_codes wrote:
| If largest contentful paint is over 6 seconds, is Css-in-JS
| really the problem?
| tonerow wrote:
| I had the same thought at first, but after re-reading it I
| think it's because of the Slow 3G network throttling.
| z3t4 wrote:
| I'm not a fan of web frameworks such as React and CSS in JS, but
| to be fair, you should not stare blindly on first-time-load
| times! Imagine if you would include download and install time
| when you measured native app performance... You should also take
| into account repeat use performance! While most "users" will just
| load the app once and leave, those who actually _use_ the app
| will spend hours clicking around and doing stuff, and that 's
| where aka "single page app" have an advantage over full reloads.
| Measure things like click latency and re-render times!
| [deleted]
| trinovantes wrote:
| > You cannot access this site because the owner has reached their
| plan limits. Check back later once traffic has gone down.
|
| First time I've seen this Cloudflare error. Doesn't their free
| plan have almost ~1TB buffer before they take notice and ask you
| to upgrade?
| j03b wrote:
| Cloudflare Workers are billed separately, 100k requests/day on
| their free plan.
|
| https://developers.cloudflare.com/workers/platform/limits#wo...
| jonorsi wrote:
| This is an apples to oranges comparison -- a run-time compiled
| stylesheet vs. a statically-generated stylesheet. Styled
| Components has options for statically-generating their
| stylesheets (https://styled-components.com/docs/advanced#server-
| side-rend...), so why wouldn't you compare those?
| NegativeLatency wrote:
| Might not be a fair comparison, but there are people who are
| looking at changing up how their css is written so it makes
| sense to be aware of the differences in performance.
| andrewingram wrote:
| You linked to server side rendering, not static extraction of
| styles, did you mean something else?
|
| The point of static extraction (something the current wave of
| new CSS-in-JS libraries seem to be focusing on), is to generate
| all the style sheets at build time and serve them as regular
| CSS files -- so that your styles don't inflate your JS bundles
| (a problem most older CSS-in-JS libraries have).
| vpfaulkner wrote:
| My gripes with traditional CSS styling are:
|
| - Styles are global
|
| - Styles are targeted via brittle, untyped, and opaque "magic
| strings" basically. This means mistakes are more likely to be
| caught at run time than compile time. Eg, I wouldn't get a
| compile time error if I did `position: oops` or `class="oops"`.
|
| - Styles are often "far away" from their target which makes
| mistakes more likely; ie this deeply nested HTML element in one
| file is coupled to a deeply nested style sheet in another file
|
| - It is easier to perform complex manipulation of styling if it
| is made up of JS objects. Eg, if I wanted to do math or I wanted
| one style to be a function of another (eg `marginLeft:
| PAGE_MARGIN`)
|
| That being said, I'm sure there are some better ways of doing
| traditional CSS since I last tried it that I'm unaware of...
|
| As far as the performance trade off, I'd love it with styled
| components did not come with this but, at least for my use case,
| it is usually worth it
| lstamour wrote:
| "Styles are global" is changing :)
|
| https://youtu.be/jUQ2-C5ZNRc?t=683 Looks like the spec is at
| https://drafts.csswg.org/css-scoping-1/ with examples like
| https://drafts.csswg.org/css-scoping-1/#example-f1503361 and
| more details at https://css.oddbird.net/scope/
|
| Still experimental of course, but could be very useful if
| implemented alongside Shadow DOM. Note this isn't 2012's scoped
| CSS: https://caniuse.com/style-scoped
|
| If we get this the only thing I'll continue to dislike about
| Web Components would be the global namespace of web components
| and that Web components HTML attributes can't be rich objects
| or arrays natively. (I'd love it if web browsers simply
| implemented JSX, for example, or a syntax that looks like DOM
| but is actually a function call that can produce DOM. Bonus
| points if they also implement Markdown or MDX as an HTML
| element of some kind.)
| postalrat wrote:
| I keep going back and forth on this one. Right now I believe
| it's best to not fight against CSS and use it as it's meant to
| be used.
|
| I try to focus on writing nice HTML often multiple relevant
| class names. Then later make things look the way I want in CSS.
|
| I find it hard to think in CSS in translate that to HTML but a
| lot of developers I know tend to work that way.
| seumars wrote:
| Complex manipulation can easily be done with a preprocessor.
| You can work around the other issues you mention by just, well,
| learning css instead of fighting against it.
| diob wrote:
| I've really enjoyed tailwind after using styled for a while.
|
| At least for my applications, the computers my users run on
| can't handle the performance implications of styled.
|
| But beyond the performance, I legitimately build faster using
| tailwind. I also find it easier to understand the components
| others build as well.
| gherkinnn wrote:
| Completely agree.
|
| This whole discussion feels silly after a day building things
| with Tailwind. The system, defaults, docs and tooling are
| excellent.
|
| And dev speed is ludicrous.
| zoover2020 wrote:
| Fully agree. It's usually the people that have never worked
| with it that share their opinion, always ending with "why
| do we need this"
|
| Can encourage others to give it a try as well. Dev
| productivity through the roof indeed :)
| aidos wrote:
| We're making the switch at the moment and, after a bit of a
| learning bump, everyone is flying along with it now. It's
| basically inline-styles++ with having all the context right
| there but not having the edge cases that require breaking out
| into classes to use media queries etc.
|
| It was a little struggle at first with our previous setup,
| but I spent a week or so moving everything over to Vite with
| hot module replacement which has been life changing.
| paulintrognon wrote:
| You can address points 1 and 3 via (s)css modules.
|
| But point 2 and 4 stand.
| kolme wrote:
| You can also kind of address 4 by using `calc` and custom
| properties in CSS.
|
| (eg: `margin-left: var(--page-margin);`)
| charrondev wrote:
| We started using CSS in JS a few years ago because we
| couldn't, and still are unable to use CSS variables (some
| of our customers still require IE11 support and we can't
| drop it until 2022).
|
| The main issue I still see with CSS variables is IDE
| support and static validation. With my CSS written in
| typescript I know that every variable I've imported works
| statically.
| dimal wrote:
| CSS modules with TypeScript solves the first three items pretty
| neatly. You write CSS that lives alongside tour component, then
| import the file into your component and apply the classname to
| your elements. It compiles to unique classnames that cannot
| conflict with any others. And with TS, you'll get a compile
| error if you use a class that doesn't exist. The last point is
| possible either with CSS vars or Sass vars. calc() can handle
| some pretty complicated math. You can also do plenty of math in
| Sass.
| uyt wrote:
| In theory there's nothing CSS can do that JS can't, as long as
| the browsers provide the equivalent API for it. Any other
| performance difference will go away once they devote some
| resources to optimizing it.
|
| The real question is whether we want styling/theming to be in
| it's own domain specific language. From an ergonomics standpoint,
| CSS is such a bad language we would rather write JS instead. But
| the downside of not having it in a more restricted language is
| that it's much harder to build tooling for it. For example, you
| won't be able to open up _any_ webpage and know you can inspect
| and change the style of things. Instead you need to know the
| specific JS class for that component or ThemeProvider and modify
| that instead. Every ui framework is going to do things slightly
| differently which will be a huge blow to user customizability.
| oblak wrote:
| I mean, I can appreciate some basic stuff like this but how about
| measuring rendering performance on low end devices? Like having
| large, medium, and small css files vs having the same thing BUT
| moving state changing things to js so that some specific styles
| are applied inline.
|
| Somewhat superficial content but might spawn a few interesting
| discussions.
| pcthrowaway wrote:
| For others seeing a rate-limit message:
| https://web.archive.org/web/20210608190243/https://pustelto....
| mrwnmonm wrote:
| <3
| hudixt wrote:
| A 4 year experienced react dev here. I have had decent time
| working with different styling
|
| I'll try to answer few common things for everyone's context
|
| Why even use CSS in JS?
|
| - SPA bundling usually loads all CSS at once and all styles
| collide. You need to be super good at naming stuff/or load CSS
| based on module. So your CSS will be conflicting, so scoping is
| helpful here.
|
| - Not having to jump from your component file to CSS file. Save
| some context switching or few strokes.
|
| - Dynamic control over style. Basically your stylesheet is JS
| function returning style. You can do anything here. See this
| https://github.com/styled-components/styled-components/issue...
|
| - Support for JS reference in color, font sizes, etc with editor
| support. It'll lead to more consistent design system.
|
| - More cleaner API when using media queries, pseudo states. eg-
| https://emotion.sh/docs/media-queries
|
| Another alternative is Emotion, also I find it to be much more
| cleaner in code perspective. (Good performant library in terms of
| layout and painting).
|
| Why is export option not available for most CSS in JS (some
| suggested this as solution)?
|
| Read this https://github.com/emotion-
| js/emotion/blob/bcf40cf2c20153481...
|
| Is it worth it?
|
| - Depends a lot on context and your perfonal objective. Generally
| I personally feel it's worth it as it's good tooling.
|
| - CSS in JS is lot better than what it used to be. Styled
| component had good perf bump in last few years.
| seumars wrote:
| It depends a lot on the context if that context is React. CSS
| in JS in retrospect looks like a shim for react developers who
| couldnt rewrite their code to single-file components like in
| Vue and later Svelte. You dont have to be a genius to know how
| to name and structure dom elements, though being good at it
| lets you reuse css and reduce overall app size better than any
| bundler ever will - but its just easier to install Tailwind.
| onion2k wrote:
| _You need to be super good at naming stuff /or load CSS based
| on module._
|
| You don't need to be _that_ good, and there are methodologies
| that can help eg BEM.
| gentleman11 wrote:
| Whenever you talk to somebody about how ridiculous it is to
| need a preprocessor to do basic sane things in css, you hear
| about how "css isn't designed for that, it's better this way.
| Use a preprocessor!". Preprocessors are a workaround, not "the
| way it should be." There's no good reason why a @media query
| can't take a variable for a min-size value, it just makes
| things error prone. Yet, the css spec is so proud of itself it
| has declared that there will never be a css 4
| stevebmark wrote:
| CSS modules solves all of these problems (except the separate
| file), and also lets you write vanilla CSS, and not have to
| hack around the limitations of css-in-js. Dynamic styles are
| easy with React's `css` prop, or simply passing in an
| additional class name.
| mikewhy wrote:
| React doesn't have a CSS prop.
| frank_nitti wrote:
| Must be referring to the style prop for jsx elements whose
| argument conforms to the React.CSSProperties interface
| mikewhy wrote:
| Hard to say, for instance the very popular styled-
| components package does add a `css` prop magically to all
| elements.
| hudixt wrote:
| Added one more point on API. Also, you'll probably end up
| using one more library called classname for better classname
| management.
|
| https://www.npmjs.com/package/classnames
|
| In the end, I generally prefer to use tailwind + emotion. My
| goals usually is to save time and make system more consistent
| rather than perf gains, which isn't that much on new systems.
| nicoburns wrote:
| Indeed. Worth noting that classnames is a _tiny_ library.
| lhnz wrote:
| I've heard that `clsx` is faster:
| https://github.com/lukeed/clsx
| nicoburns wrote:
| Looks like a well designed library (and it is only 40
| lines long - but then the original isn't much bigger).
| But it's hard for me to imagine code where this is a
| bottleneck.
| epigen wrote:
| > Don't use runtime CSS-in-JS if you care about the load
| performance of your site. Simply less JS = Faster Site. There
| isn't much we can do about it. But if you want to see some
| numbers, continue reading.
| toadkicker wrote:
| Studies show computers running less code perform faster
| dorianmariefr wrote:
| loop {}
| topspin wrote:
| Great effort and I have no dispute with the methodology. The
| conclusion, however, is naive. Specifically this part:
|
| "Great developer experience shouldn't come at the expense of the
| user experience."
|
| Great developer experience can conceivably deliver better user
| experience. A more capable, responsive and lower defect
| application that load 10% slower may be a net improvement.
|
| I'm not arguing that CSS-in-JS actually delivers that. Only that
| load times aren't the only variable in the "user experience"
| equation.
| forgotmypw17 wrote:
| >A more capable, responsive and lower defect application that
| load 10% slower may be a net improvement.
|
| The problem with this approach is that this 10% is not a one-
| time fee, but is collected on a regular basis, with
| compounding.
| cosmotic wrote:
| I very much agree that load time is not the only metric that
| should be measured. Unfortunately, it's one of the easiest to
| measure. It's also one which does not sacrifice any other UX
| metric like low completion time leading to less satisfaction
| sort of corruptible metrics.
|
| Although, in my experience, usage of react is not indicative of
| a more capable, responsive, or lower defect application. Quite
| the opposite (for me) actually. React is a good (but not
| absolutely reliable) indicator of slow, unresponsive (in terms
| of response time, not resolution scaling, buggy, and
| frustrating UX.
|
| From the code examples of the suggested library, it looks like
| a pretty simple drop in replacement for many (if not all)
| cases. 10% for free would be a slam dunk.
___________________________________________________________________
(page generated 2021-06-08 23:00 UTC)