Live data from Hacker News

Why I Write CSS in JavaScript

mxstbr.com

201–210 of 255 posts

Re: Why I Write CSS in JavaScript

#201
post #128

Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation. After you've done this perfectly, your app…

This is sad. All because people are not able to think of one simple prefix and stick with it when naming CSS classes. How hard can it be? Just use some part or abbreviation of the company name and be done with it. Or better yet: Let third party do that. I always hated that, when someone used Bootstrap on a website and Bootstrap f'ed up all future styling, by assuming it was the only one player in the game. So stupid.…

People want an interface such that a folder represents all they want to know at that moment about a component. But then someone else may want an interface such that a folder can represent all the styles across the app.

Otherwise I do think that the naming collision problem is really easily fixed.

Re: Why I Write CSS in JavaScript

#202

Earlier quoted context omitted.

> and has a very wierd concept of how objects work in JS. What is so weird about it? I personally find Vue vastly more approachable than React is, especially once you have to start writing all the plumbing to get all the libraries you need to go along with it to write a real world app. > ] It's a templating system with its own rules and mini-DSLs that ends up being compiled into JS. Vue has the option to use Webpack…

> What is so weird about it? I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 > Vue has the option to use Webpack to compile html compliant templates to JS functions just like JSX Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. > JSX (which BTW is not JavaScript and not HTML compliant and is also a separate concept that needs to be learned…

> JSX is a very thin DSL on top of Javascript.

With its own syntax. Which looks like HTML but isn't.

Re: Why I Write CSS in JavaScript

#203

Earlier quoted context omitted.

This is sad. All because people are not able to think of one simple prefix and stick with it when naming CSS classes. How hard can it be? Just use some part or abbreviation of the company name and be done with it. Or better yet: Let third party do that. I always hated that, when someone used Bootstrap on a website and Bootstrap f'ed up all future styling, by assuming it was the only one player in the game. So stupid.…

People want an interface such that a folder represents all they want to know at that moment about a component. But then someone else may want an interface such that a folder can represent all the styles across the app. Otherwise I do think that the naming collision problem is really easily fixed.

You can get the beat of both worlds by having one folder for one component and then a ‘common’ folder.

SASS seems to solve most of the problems i would have with writing basic CSS.

Re: Why I Write CSS in JavaScript

#204
post #166

Earlier quoted context omitted.

It's not a limitation. It's different.

Its different and it a poor lang. The only people advocating for css only are privacy freaks. They're often the least return producing customers, hence ignored.

As far as I understand there are very good sides of CSS, as a declarative constraint language. More than being a poor language it looks like it is hard to use it for modern web development.

Re: Why I Write CSS in JavaScript

#205
post #166

Earlier quoted context omitted.

It's not a limitation. It's different.

Its different and it a poor lang. The only people advocating for css only are privacy freaks. They're often the least return producing customers, hence ignored.

> The only people advocating for css only are privacy freaks.

This just is not true. It may be your opinion, but it is objectively false, particularly in the context of this discussion.

Re: Why I Write CSS in JavaScript

#206
post #124

Earlier quoted context omitted.

> Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months" Because that last sentence is just rubbish, CSS in JS is great. I'm using it for large projects already 4 years. If your experience is bad you must be doing something wrong. CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to ju…

> CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to juggle with classnames. I completely disagree. Time and effort creating frontend design systems, will result in a set of CSS files .. but will also enable efficiency, flexibility, accessibility, maintainability and extensibility. These qualities just aren't going to be as available if you use CS…

There's nothing expressly better about SCSS over CSS in JS that you have demonstrated.

CSS In JS is mostly using similar structure, but often the JS dom interface naming... so fontFamily instead of font-family. It's also far easier to introduce codified variant functions or variable injection in JS than it is in SCSS.

I'm not saying don't use SCSS if it fits your model better... I've been very happy using react-jss via material-ui ... I've extended the baseline theme and that gets used throughout the application with each component defining its' styles that get injected.

Sharing can be a little more awkward, but it's easy enough, just call the same style method(s), or extend the baseline theme that gets injected.

The only thing you mention that might be better with (S)CSS directly would be efficiency and even that's relative. You can absolutely do all the rest with CSS in JS.

Re: Why I Write CSS in JavaScript

#207

Earlier quoted context omitted.

CSS is a tool used by web developers to style their websites. Whether technically it's a programming language or not is tangential.

People implement Doom in CSS. It's clearly more than just some style notes for the browser.

I think you may be confusing that with something else. You can't create a complex game with just CSS. I'd love to be wrong but provide a link.

Re: Why I Write CSS in JavaScript

#208

Earlier quoted context omitted.

> What is so weird about it? I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 > Vue has the option to use Webpack to compile html compliant templates to JS functions just like JSX Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. > JSX (which BTW is not JavaScript and not HTML compliant and is also a separate concept that needs to be learned…

> JSX is a very thin DSL on top of Javascript. With its own syntax. Which looks like HTML but isn't.

Considering the differences lean towards the DOM interface names for given attributes and properties, I wouldn't exactly call it NOT JS.

It's actually an XML abstraction that closely resembles HTML + JS-DOM, and is then converted into function calls and arguments.

It's also about as close to E4X as an abstraction that I've seen and something I wish was cross browser over a decade ago when it was first introduced by Mozilla and Adobe, but that's a long side-track. In the end, it's very effective and works well imho. Yes there are some more complexity points in some places, but I don't think anything else does it better. Vue imho is comparible, but I don't like it as much and I feel that Angular is far worse in practice.

Re: Why I Write CSS in JavaScript

#209

Earlier quoted context omitted.

I didn’t say I did not spend time, I said - could not. Same applies for most people in the team. I think we had coupe folks who were spending a lot of their time explaining CSS. My theory is that CSS was something that was treated as a task. Make a lot of client/server side development and then make these freaking lines align perfectly. So, most of time engineers were avoiding styles, applying them was the most tedio…

I agree with you re: the task comment, there is a difference between JavaScript developers and Front End UI developers. It's almost like the full stack discussion but just in the front end ecosystem.

They significantly overlap, so wouldn't say they are different. I would suggest that most "JavaScript developers" in the box you'd put them in are backend developers that only know a minimal amount of JS and don't really know JS well and by extension the browser itself.

Re: Why I Write CSS in JavaScript

#210

I understand the "pit of success" idea, particularly when it comes to more junior devs. But I don't necessarily agree that you need stringent processes to get most of the gains you cite from using something like SCSS or even regular CSS these days. It's really easier than ever. 1- append only? No, each module/feature/widget gets its own CSS file, imported to the main app CSS file. Delete the widget? Delete the file.…

All three of the points raised are just dismissing the root of the problem and offering a "solution" using plain CSS classes that relies on everybody following some bespoke convention to work around the problem rather than addressing it head-on like CSS-in-JS solutions do. 1. and 2. attempt to address the lack of modularity in CSS through convention when you can have guaranteed modularity through auto-generated CSS c…

Yes, it's dismissing the root of the problem because I am not convinced the "cost of doing CSS" is enough to justify moving to something like CSS-in-JS. Again, as I said above - it's a strong opinion, but weakly held - given enough evidence, I'd reconsider my position.

My point with the examples I gave was just to show that it's possible to handle the issues the author wrote about. I'd prefer to see efforts to fix the issues in CSS instead of discarding it completely in favor of a JS solution.

I'm not saying I can specify how to "solve" CSS issue in a couple paragraphs. As regards #3, that's specific to the kinds of dynamic styles I find most often in web apps. Very rarely do I see styles generated dynamically where it isn't effectively a choice between a couple of options (in my experience, of course). And when you do, you can just write out styles from the JS into the template (and I've definitely done fully dynamic styles in that way when it is necessary). Dynamic styles would be a place where I could see a fit for CSS-in-JS, btw.

The global namespacing this is something I believe is being worked on in the CSS Modules specification, but again, that is really easily solved. I can say loading external libraries can mess that up (i.e. Bootstrap and the ilk).

I don't care what people use, I'm glad the argument is what the author (who co-wrote the styled components lib) was what he liked. But I am really concerned that some proponents promote their way as the only way forward. Personally, I haven't found a situation yet where CSS-in-JS would materially benefit the application over a careful, convention-based approach. And I want to make sure people know there are other options that work.

Post reply on HN