Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
If only Linaria wasn't React-only. As far as I can tell, it doesn't support anything else.
Otherwise, yes I prefer CSS-In-JS because I can dynamically update styles using S.js signals (I use Surplus, not React).
Webpack is also shit, though. Slow, bloated and the ecosystem encourages non-standard things such as importing weird filetypes (e.g. css or images) into javascript.
There are much better ways of packaging. The problem is, most of them are terrible right now (e.g. just tried snowpack and I'll never touch it again - I'm working to remove it entirely from the one project I've tried it on). -
@wackOverflow CSS-In-JS generally separates the CSS bits and the component bits. The upside is that the entire file contains everything necessary to render the component, and usually the sections are so visually distinct that they don't collectively create a bloated mess.
Note that this is for when you use a CSS-in-JS framework like JSS, NOT when you use the style property directly on elements - in which case, I agree with you. -
@junon if it can be written in a style sheet then put it in its own file. React/Jsx feels like it’s devolved into early html with defining css classes inside the component they way someone writing html can put a <style> tag in the head of the doc. I’d rather read 3 separate small files than spank control + f all day trying to find what I need.
-
On the other hand, CSS modules are hard to maintain because they turn your class names into grabled mess. There has to be a better way on large scale using global styling.
Less is a good choice in my opinion for writing large scale global styles because, unlike scss and sass, it just works and you can write hierarchies to aid against collisions.
The other way is of course web components because you then have shadow dom. Trouble is, they are simply annoying to create. -
Anyone here using https://caniuse.com/css-variables ?
Looks like they are widely supported now. -
@theuser
> On the other hand, CSS modules are hard to maintain because they turn your class names into grabled mess.
Not JSS. -
@kiki The documentation only mentions React and compatibility with CRA - maybe I didn't read enough. I'll look at it again.
If it can replace jss 1:1 with only an extra build step, then I'm all in. -
@theuser I use none of those things. That's my issue.
I don't use Webpack because it's bloated and slow. I don't use React because it's bloated and slow. I don't use CRA because it's React, and also because it's bloated and slow.
As for separation, that means separate files, so that means you have to look in multiple places to understand a single component, which is an absolute deal-breaker for me - and should be for anyone else, too, in my opinion. -
@Oktokolo Yeah I started using them 1 year ago on all new projects and some old projects that don't need IE support, they work really well
I hate Sass.
When installing all NPM dependencies with npm i, it's always quick, but not with sass. Ooooh myy goood. It starts compiling. It always misses something. Your node version is always not what sass needs. It pulls out gyp which requires some native shit. The build is never reproducible, it always fails with some horrible two mile long poorly-formatted stacktrace that is just gibberish.
More than that, sass is just poorly designed tool used by frontend fuckboys to write imperative, nonstandard, non-maintainable styles. If you know shit about css, you don't need sass.
I'm so happy it's going to die along with gulp. Webpack and css modules are here.
Yes, css-in-js that has a runtime penalty is also shit. If you like its syntax but dislike everything else, use Linaria. It has no runtime penalty and looks just like other css-in-js solutions.
rant