13 ms·

Re: “‬How does writing CSS in JS make it any more maintainable?”

• andrewmcwatters 8y ago
  I'm always curious about what the largest magnitude of a UI codebase someone has maintained when they make comments like this.
  • symboltoproc 8y ago
    The author works at Facebook. I'd argue that Facebook's UI is pretty complex.
    • brianvaughn 8y ago
      Sunil has also worked at Yahoo on maps.yahoo.com, specifically on tooling to manage styling.
  • tracker1 8y ago
    I'd like to see you maintain a codebase of thousands of components with CSS in JS vs another management solution via CSS build (like scss) and see how many buggy/hacky issues you have with each. I've worked in codebases of significant size managed both ways. If you want the most simple example, look at most apps based on bootstrap. They only start with the baseline/generated CSS, then apply hack patches throughout an application. Yes, you should use the source and generate yourself, for your application. But nobody does in practice. Even worse, a lot of the "bootstrap components" from third parties are also using hack css on top of the baseline, and require even more patches in actual structure. I'm not bashing bootstrap, only pointing out how I've seen it used, which is poorly. Component based CSS in JS has even been a bit of an issue. Other developers on my team will put magic values into a given component instead of using values out of the theme that gets injected. I've had to go through again and again to correct this. The difference is the former yields unexpected behaviors, while the latter is just a bit of inconvenience.
    • andrewmcwatters 8y ago
      This isn't even a statement about either technology, it's just a commentary on bad developers, and trying to alter or minimize the damage they do because they're bad, using a different technology. The former yields expected behaviors, and if you deviate, what do you expect? While the latter means that any time your product experiences a redesign, you have to manually change everything. Not only do you manually change everything, and every component is isolated, you end up writing repetitive styles, and then you're stuck with a codebase with 5 different buttons, 4 different drop-downs, 7 different color schemes. Nah, there's a reason why sites like Bootstrap Expo existed. CSS in JS doesn't just fail to prevent you from writing expensive to maintain code, it also makes it harder to evolve a product over time.
      • tracker1 8y ago
        You can share style portions at the component level.. you can bring in portions of style definitions from the parent or even the theme level... import baseStyles from './section.styles.js'; const styles = theme({ baseline: { ...theme.components.foo, ...baseStyles.foo, // customizations here }, variantState: { // dynamically controlled style alterations for // a different state ...baseStyles.variantState }, }); You can totally reuse styles, it's just controlled at the component level. Beyond this, options for the theme itself can be injected by default, release, application settings in the app, and user configurable settings in the application. export theme = async () => { const {env, app, user} = getThemes(); return deepMerge(base.theme, env, app, user); };
    • andrewmcwatters 8y ago
      Uh, bullshit? Thousands of components? Yeah, okay. You create a single new component for every permutation, route, and derivation? Where are these projects with thousands of components? What open-source projects can we use for reference? Are they all commercial and therefore private? That'd be convenient wouldn't it? Bootstrap lists 21 individual ones, not counting layout, content, utilities, or other classes. Lets say you have a SaaS project with a couple hundred individual routes, and you count them as individual components, you still haven't reached the magnitude you're talking about.
  • dang 8y ago
    Would you please stop breaking the site guidelines? You've done this many times, we've asked you repeatedly to stop, and you keep doing it. In particular: "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• weego 8y ago
  "In an SPA/component world, where assets like scripts and styles are loaded asynchronously, you can’t guarantee style sheet loading order, which means you have to lean on some form of runtime composition to guarantee a shape, else you end up with !important rules even if you follow a given architecture" I'm sorry, this guy is so far down the rabbit hole he can't even see the ridiculousness of his mental gymnastics.
  • whyonearth 8y ago
    The thread makes me want to quit the industry. One person disagrees and gets "I vote for this statement to be nominated for Worst Sentiment of 2018", while the gist-er is congratulated with "instant classic" and "you're my hero." The JS cargo-culting insanity is becoming unbearable and dissenters are mocked as noobs.
    • ryanmccullagh 8y ago
      In my 2 years of experience, this guy does not represent "the industry".
    • icholy 8y ago
      Just get off the front end. Things are pretty sane everywhere else.
      • oftenwrong 8y ago
        I stopped doing front-end dev for this reason. I told my manager I no longer wanted to do anything on the front-end, and they were fine with that. Since I've gone 100% back-end only, my work life has been far more sane.
      • deleted 8y ago
        [deleted]
      • rjplatte 8y ago
        Agree. I'm trying to right now. I think it has more artsy types, which means more drama.
• aphextron 8y ago
  Having tried every alternative imaginable, component based CSS is the way to go. There's a legacy in web development of viewing CSS as something separate from structure and logic because of what the web used to be; a collection of static pages with style sheets for typography and layout. But as soon as you start building any kind of non-trivial application, this model breaks down. The only way to do it is small, atomic, composable components with fully self contained styles and minimal inheritance.
  • weberc2 8y ago
    Could you elaborate on what component-based CSS is for the uninformed? A cursory Google search indicates that it's a technique for using CSS in JS, but I'm not sure how I would go about doing it. Does it imply some web component framework?
    • matte_black 8y ago
      Instead of having files that apply styles globally to your application, the styles live down in files or data structures as close as possible to the component it applies to, where it belongs.
    • arethuza 8y ago
      Perhaps something like Styled Components? https://www.styled-components.com/ https://www.styled-components.com/
    • Spivak 8y ago
      It's not super complicated, just apparently controversial. In your $complex_app you probably have JS generating most (if not all) of the HTML seen on the page. CIJ just says that the JS should generate the styles as well so that each component in your page is self-contained.
      • JustSomeNobody 8y ago
        Not a FE dev, so this may be naive but CSS cascades which means these components may rely on external css state. How is that handled and still qualify as self-contained?
• matte_black 8y ago
  I find that the people with the most vitriol reserved for css-in-js concepts tend to be those who have exclusively developed front ends for the web and never on any other platform. I wonder if others have made the same observation. Perhaps they should expand their minds.
  • andrewmcwatters 8y ago
    The alternative is imperative UI design à la Win32, so I'm not sure what there's to expand on. Unless you really think writing a couple hundred lines of code to set position and apply event callbacks is a good idea.
• ex3ndr 8y ago
  CSS in JS turned into a nightmare in our project once we decided to make it fast. CSS in JS usually do next things for each component mount: 1) Parse CSS 2) Hash styles object 3) Serizlize and auto-prefix CSS back (or just write to StyleSheets API) That is actually a nightmare for performance. You can say that you can export static styles via babel and everything will be fast again (since 90% of your styles are static), but styled-components, glamorous, emotion and friends all ditched static styles exporting feature. On the other side we thought that composing styles is a good thing, but it turns out to a complete mess where you have 100s of style overrides across the code instead of building a small component with appropriate API. On the last side i personally came from mobile world. Most of mobile (native) devs tried to build their own "css" or manage styles in some "special" way that it used to be (constants in some static class). It turns out it adds almost zero profits and too much of maintenance. They are not helping you to simplify things if you wish to change something "everywhere" beside very simple things (dividers, borders, backgrounds, tint color) and everything is just became useless. Building real components is much much better. Well, considering all this we have only one (!) CSS in JS library that satisfy this requirement: https://github.com/jsxstyle/jsxstyle https://github.com/jsxstyle/jsxstyle It is fast, performant and completely static if it possible but it is not "fancy" in frontend community. As usual in frontend there are not much sense everywhere and popular libraries are usually a complete crap if you really value your users.
  • matte_black 8y ago
    Can you give an objective example of the magnitude of difference in performance?
    • ex3ndr 8y ago
      We have built our own jsxstyle-like library and we got about 10-100x improvement. It is really super fast since all your layout is compiled to a simple divs with a classNames whenever possible (almost always) and it became zero-runtime styling and this is awesome, this is the only way to build fast app - do nothing in your app if you can.
  • vcarl 8y ago
• janpot 8y ago
  Pure the use of JS vs. CSS is not what makes CSS-in-js more maintainable. It's "scoping styles locally to a component" that makes it more maintainable. As well as having easier interaction between them, like theming or dynamic behavior.
• coding123 8y ago
  Css is a write only language. There is no read mode.
  • wvenable 8y ago
    You can read it the browser using the developer tools; 99% of my reading of CSS comes from there. I add/tweak in the browser and then I go to the source and re-apply the changes there.
• danShumway 8y ago
  One major problem I've run into is that CSS in JS usually lacks support for pseudo-classes and browser breakpoints. The recommendation from communities in frameworks like React is that you should use JS and extra elements to polyfill that behavior. This is both less performant and less semantic. It really doesn't work particularly well if you're used to leveraging CSS in powerful ways. Stuff like :first-of-type, sibling selectors, and so on are extremely useful. You give them up when you start manually attaching inline styles, and both JS performance and JS complexity to replicate those features will pretty much always be worse. Doing animations in JS is usually a step too far even for the React community, so the recommendation I see there is often that you should define normal CSS classes and dynamically apply them. But now you're starting to mix CSS and CSS-in-JS, which is do-able, but can come with own set of subtle consequences. It also significantly lessens the benefit of CSS-in-JS, which is that you get to stop worrying about conflicts. It's not a dealbreaker, but it means you're somewhat back to managing the same name conflicts and typos that you were before. I started out as much more open to CSS in JS than I am now. I was cautious about it and usually avoided it for personal projects. After doing a little bit more work on projects that use this pattern, I now feel like it's probably a bad idea, and advise other people to be careful about using it, even if I'm not willing to take a hard stance quite yet. It's not that component-based CSS is a bad idea, I'm much more friendly now towards BEM than I used to be. And it's not even that CSS outside of JS doesn't have problems (the authors point about loading order is a particularly good example, albeit one that really shouldn't be coming up very often in a component based world. Also yeah, testing). I'm just less convinced that CSS in JS is a sufficiently scalable solution to those problems, or that it doesn't have significant problems of its own.
  • vcarl 8y ago
    We use styled-components, which is one of the most commonly used css-in-js libraries, and it supports both pseudo-classes and browser breakpoints. I'm not sure how applicable this argument is, my experience runs counter to the premise. I've also done animations in JS using react-motion and react-flip-move and had a pleasant experience with both.
  • Cu3PO42 8y ago
    I think you're missing an important point. Not all CSS in JS solutions attach styles as inline styles. Some of them, such as Styled Components [1] and Emotion [2] (and many more) will actually generate proper CSS Stylesheets and attach them to the document, thereby enabling usage of all CSS features—including, for example, pseudo-classes. This may incur some additional runtime cost when the page loads (which is definitely nothing to dismiss), but should be (roughly) as performant as "native" styles after. They still come with other disadvantages (and advantages), so I'm not saying you should definitely use them, but maybe you should take a look at some implementations you might not have seen yet. Personally I arrived at the conclusion that they're not for me and that I'll just stick to SCSS. [1] https://www.styled-components.com https://www.styled-components.com [2] https://emotion.sh https://emotion.sh
• preommr 8y ago
  Honestly, what the hell are we talking about here? CSS is one thing and JS another. It's typically better to use CSS for styling because it's declarative and simple. If your use cases are more complicated then use css preprocessors to resolve issues like variable names (something brought up in that twitter convo). If you want to do things at runtime then you need something procedural like js. If you decide to forego css even for simple cases and use js because you think it'll be easier to maintain then obviously you'll need some tooling and conventions in place. If you have those, go for it. If people want to put js in css (again, something brought up in the twitter thread), then that's fine too if various vendors supported it and there was a reason for it over js. There currently isn't, so again, I don't know what the hell we're talking about. Also: > The facebook codebase has thousands of !important statements, despite being written by competent engineers with solid engineering practices and deep relationships with design teams. lol
  • danabramov 8y ago
    > lol "I'd rather assume other people are incompetent than accept that maybe maintaining tens of thousands of components presents unique challenges that I could learn from."
    • hombre_fatal 8y ago
      You can click into any web-dev related discussion on HN to find someone trotting out their thinly-veiled assumption of "everyone is incompetent except for me". When I read the title of the submission, I immediately envisioned the typical "I thought we learned CSS belongs in its own file, why are web developers idiots?" comment. Everyone is always trying to unmask each other as incompetent because it spares them the effort of being open-minded, of resisting the tempting repulsion of new thoughts, and of understanding why someone might prefer something else.
    • preommr 8y ago
      lol because it's a meaningless statement not the least because it implies smart people always produce perfect code. I don't think it's ever a good idea to bring into question people's competency when discussing software design principles. It's hard to quantify, difficult to verify and not usually relevant. I am not assuming they're incompetent. I am disagreeing with the idea that their failure comes from just the technology and not in anyway from the actions of a developer. Whether it's because time constraints or just because shitty things happen like they do in any project regardless of how much money or how top tier the talent is.
• InGodsName 8y ago
  Is scoped CSS different from CSS in Js? Sorry for the noob question.
  • tracker1 8y ago
    Yes, all CSS operates via selectors... scoping generally means applying a className to a component, and then generating all CSS for children relative to that. The issue at play is when you start nesting, or using components together, and child naming blows up. .myComponent is fine... but when you have: .myComponent button { ... } .myComponent .x and then you have conflicting rules, and your css gets overridden in unexpected ways. with JSS, the tooling can generate unique component selectors, and since it's all generated at a component level, you have less risk of applying conflicts.
• dccoolgai 8y ago
  Short answer: It doesn't unless you follow some light "Design by Contract" principles... unfortunately that flavor never really caught on.
• gambler 8y ago
  Moving CSS to JS because of selectors? Hm, I often do the exact opposite. I effectively move JavaScript logic into CSS queries and data into corresponding tags/attributes. When I started doing that, my scripts became far more enjoyable to write, trivial to reuse across projects and orders of magnitude easier to analyze/debug (just run the query and see what it finds, mostly). All things considered, CSS is a pretty good language. Selectors are a great query language, as long as your tags have well-expressed information. CSS definitely needs something to address specificity, though. Maybe HTML needs an explicit tag or attribute to denote context, so that styles from higher level contexts would not apply to nested contexts. Purely from syntax perspective this could be addressed in CSS queries themselves, but I doubt such implementations would be efficient. Another things CSS needs is some way to analyze it from scripts. It's amazing that there is no way to query/modify CSS rules from JS. It would solve so many issues with very little client-side code. You could implement CSS variables, for example. I'm talking about interacting with actual styles. E.g. let x = CSS.forSelector('article p').getRule('font-weight'); or maybe: let x = CSS.activeRules['article p']['font-weight']; CSS.forSelector('article p').setRule('font-weight', '10'p); You can fake the last one by dynamically generating CSS on the page, but that approach has many issues that would be avoided if there was a clean programmatic interface. With an API like this you could trivially post-process styles, extend core CSS functionality and even do some cool runtime analysis, like finding which rules aren't used on a page. --- General CSS note. One thing I advise everyone to try is getting rid of any BEM classes for your components and replacing them with custom attributes. The idea is that each component (block in BEM) gets its own attribute and all the elements and modifiers go inside that attribute. So instead of BEM <div class="block__element block__element--modifier"> you get this: <div a-block="element modifier"> or this: <div a-block="element-modifier"> (By convention, custom attributes should always have dashes, so you never run into conflicts with core HTML standards and so that everyone can tell they're custom from the first glance. I never thought I would miss XML namespaces, but they sure would come in handy here.) Not only it's shorter and nicer to look at, it expresses more useful information and can be queried in ways that's impossible with BEM. To use this, you need to be aware of the following CSS selectors: [attr~=val] [attr|=val]
  • frosted-flakes 8y ago
• AchieveLife 8y ago
  Next on HN: Why Javascript is the future of voting machines
• quantummkv 8y ago
  So we have gone back to the days of Java and WinForms where everything from the UI layout to styles to business logic was in the same damn language in the same damn file and many times in the same goddamn function. Why? Why in the world would you ever willingly want to go back to that? Has the JavaScript community collectively lost it's mind? Or has all that kool-aid gone to its head and everyone is under the impression that they can do no wrong? What happened to all that talk and bluster that Java and JavaScript are different? Even .Net and Java have moved away from that convention with XAML and JavaFX. Those who don't remember the past are condemned to repeat it. My only hope is that the JavaScript community comes to it's senses before it is too late and they take down a good language and platform because of their inability to look outside the bubble.
  • tracker1 8y ago
    It's not quite the same... styling conventions can still be followed, inherited style structures can also be passed from a global theme, or higher order components. You get the added advantages of a more flexible configuration that more easily integrates with the rest of the application as a whole. When developing a website with mostly static or cms type content, it's fine to establish a common layout structure that targets css output like sass, less, pre/postcss etc. When developing an application with components, it's generally best for component styling to stay closer to the component. CIJ is simply an option that works very well with all the advantages of per-component styling. But over separate .scss files has the added advantage of easily injected runtime/configuration values. It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application.
    • quantummkv 8y ago
      > inherited style structures can also be passed from a global theme, or higher order components. Correct me if I am wrong, but isn't this the whole point of Cascading Style Sheets? > It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application. Isn't this exact problem solved by custom css properties/css variables? Why recreate CSS in JavaScript with all of the compile-time and run-time overhead when you can write a small function to manipulate css variables?
• iooi 8y ago
  I use CSS modules coupled with postcss (mainly for minimization and autoprefixing) and sass-loader almost exclusively. The one benefit from CSS-in-JS I can think of is when the JS needs to know of a value that would otherwise exist in CSS only. For example, I'll usually have a constants.scss file that I @import in other files, which for example will have a $max-modal-width: 600px; I have run across use cases where I want to read that value from JS, but I could never figure out how to do that and resorted to duplicating the constant's value in my code. CSS-in-JS would make this trivial.
  • tracker1 8y ago
    CIJ also has the advantage of being able to more easily inject different configuration values for different builds/deployments... Client X deployment has a primary color of blue, client Y is red. And it can go much deeper where a theme is used globally and each component creates its' own styling based on that theme. With SCSS/Less, it's actually painful to try and inject these values in to the build, and more prone to error. In your example, say deployment A has a $max-modal-width of 600px, B is 550px. Or colors are different, fonts, other styling.
  • phpnode 8y ago
    for your specific example - you can declare SCSS variables in a JSON file, that makes the definitions accessible to both JS and SCSS.
    • iooi 8y ago
      This sounds pretty interesting, thanks for sharing. Do you have an example you can share? Are you using node-sass-json-importer?
      • phpnode 8y ago
        Using sass-vars-loader for this which is a webpack plugin: https://github.com/epegzz/sass-vars-loader https://github.com/epegzz/sass-vars-loader
  • 8y ago
• vinceguidry 8y ago
  It doesn't. But what it can encourage you to do is to stop writing CSS that has effects outside of the component it's attached to. Devs doing front-end have this tendency to treat styling a page as some unsavory thing that they want off their plate as soon as possible. So they don't do any refactoring, and don't take any time to try to figure out the underlying concepts behind CSS. So you get these giant, append-only stylesheets that have no real rhyme or reason behind them. Putting CSS in your JS has the side effect of hopefully forcing you to think more carefully about what rules go where. It's no magic bullet of course, but localizing all the code to one component in one file can make everything just a slight bit more maintainable. There are real tradeoffs, of course. CSS in JS just isn't as mature as existing template solutions, and they don't yet let you do anything you want with them. Maybe it's a good thing.
  • exogen 8y ago
    While that is a benefit, I think that's underselling it a bit. It certainly enforces more organization & discipline, but some benefits are more concrete and technical. :) For example: sending down only the critical styles needed to render a page. Many CSS-in-JS approaches get you this for free. If a component isn't rendered on the page, its CSS isn't on the page either. That can be technically challenging even if you follow the strictest, most disciplined patterns when writing your CSS in a traditional way. Another is guaranteeing no naming clashes. You could be extremely disciplined, but let's say there are 80 developers working on different parts of your large site/application. How are they going to know that some other developer in another group isn't adding selectors for another component with the same name, even if it's a very specific name and follows best practices? Solutions that mangle the class names to guarantee uniqueness automatically fix this. There are more, but those two come to mind immediately.
    • vinceguidry 8y ago
      Agreed, thanks for elucidating.
• btown 8y ago
  I strongly disagree with the CSS in JS movement, because philosophically it gives false hope about isolation. The thing is, no matter how you try to isolate a scope, things are going to cascade! You could have someone above you change the font weight and not visually QA all your code paths, and now your subcomponent's entire layout could be messed up. BEM, SCSS, and standardized namespacing get you 90% of the way there, and force you to think about the cascade when writing.
  • gambler 8y ago
    I disagree with it for another reason. I'm tired of developers solving language design problems by piling on more and more complexity, tools and libraries. This is a self-defeating approach, because those tools and libraries often have their own issues, and instead of fixing those, people pile on even more tools and libraries. The process goes on and on. It may feel like progress, but it doesn't really go anywhere. Java was a good example of this. Instead of fixing core language issues, people used increasingly sophisticated IDEs and put more and more things into XML. Instead of adding essential functionality to the standard library, everyone said "just download this great third-party JAR". At the time Java community said the workarounds were good enough. Right now it's obvious that they were completely wrong, the pileup of complex tools wasn't sustainable and that the language itself needed improvements.
    • tracker1 8y ago
      The DOM has styling primatives... many CSS in JS libraries use them... others compute CSS from the JS object structure used to define (based on JS DOM interfaces for styles).
  • tracker1 8y ago
    You can definitely handle potentially cascading issues with styling... const styles = theme => ({ myComponent: { ...theme.typography.body1 }, });
• tboyd47 8y ago
  > Further, it’s extremely hard to statically analyse selectors to see whether any rules are broken (or even a typo!) this means constraints have to be enforced via code reviews and education, which is a harder problem to solve and scale. We should use a computer's assistance us on this, and not rely on humans being infallible (they’re not!) Is there a more general name for the argument in defense of a technological movement on the grounds that it prevents users of said tool from making a certain mistake, and that mistake is so disastrous that we see it necessary to implement a drastic change with wide-ranging demands on an entire class of users or eliminates them entirely from the user base? I see this kind of argument prop up all the time in these types of discussions and something about it just fundamentally irks me, but I can't put my finger on it. It's kind of like Google's AMP, where instead of making incremental changes to the technologies in question, we'd rather draw an arbitrary line between "good" and "bad" uses of that technology and create a fork or subset of that tech where only the "good" uses are allowed. For a less controversial but equally relevant example, see Crockford's "Javascript: the Good Parts," which irked me at the time as well for the same reasons, even though it became universally accepted (although not-so-universally applied). I'm trying to come up with an example from my favorite language (Ruby) and I can't. Ruby's approach seems to be to discourage "bad" use cases by making them ugly (ex. instance_variable_get) rather than preventing them outright.
• rglover 8y ago
  As a former purist who's adopted the styled-components implementation of CSS-in-JS, I can say 100% that maintaining styles has become an absolute dream. It's not terribly different from CSS (meaning, if you need to extract a stylesheet it's just a few lines of code) and its ability to do autoprefixing and Sass-style nesting out of the box is a massive time saver. Coupled with CSS variables, it's an ideal toolset for authoring styles. I've spent over a decade fighting with CSS. Sass was a welcome upgrade. CSS-in-JS is a welcome next step.
  • jf- 8y ago
    What's the advantage to this over sass modules? You have the same scoping but with better separation of concerns, that seems the superior choice.
    • rglover 8y ago
      The biggest one? Not having to wrangle class names. Like the author points out here, that becomes increasingly difficult over time. Sass is wonderful (I still rely on it in some older projects), but when I'm working with JS/React, CSS-in-JS just feels smoother and tidier.
      • jf- 8y ago
        Sorry but I don’t get what you mean, and I can’t see where in the article you are referring to. What do you mean by wrangling with classnames? Do you mean clashes? That’s what modules do, they scope your scss so that you don’t get clashes between components.
        • exogen 8y ago
          I'm going to assume that SASS Modules are a SASS adaptation of CSS Modules, because it seems like "modules" might have multiple meanings in the SASS world? So please tell me if this is wrong! I've used CSS Modules and enjoyed them a little bit, but they aren't as "automatic" as many CSS-in-JS solutions, for example: 1. You still need to come up with class names, they're just not the ones ultimately used in the output because of the mangling. But you are technically still coming up with them in your source code, which is a little bit of effort. 2. You still need to manually map the local/source names from the module to the DOM elements that they apply to. Basically you are keeping multiple files in sync: decide on the local/source names in the SASS files, then import those in some other file, and remember to apply all the same names in the right places. The output names will be different, again, but you still need to do this work to keep the local/source names in sync. For (1), with some CSS-in-JS approaches, you choose only a component name and the matching class name is decided automatically, so there aren't multiple files to keep in sync. With other CSS-in-JS approaches you don't even need to come up with the component names either, you just get a `css={...}` attribute and can skip any naming work altogether. For (2), with approaches like styled-components, the class names are applied to the right DOM elements automatically because they are fundamentally tied together – so you aren't writing `class={...}` everywhere, which is still necessary with CSS Modules. Not to say that SASS Modules are bad, but those are some reasons one might prefer other solutions.
• threepointone 8y ago
  How do I blacklist my own urls from this website?
• jpochtar 8y ago
  In about 5 years, we're all going to be on inline styles in JSX (or equivalent), flabbergasted that we ever thought CSS was a good idea. Calling it now.
• tracker1 8y ago
  Regarding most of the dismissive comments on using JS for styling... 1. you can't inherit... 2. I don't want it in the same file... // component.style.js import base from '../base.style.js';\ export style = theme => ({ ...theme.typography.body1, ...base.component.foo fontFamily: theme.fonts.serif, }); // component.js import { style } from './component.style'; ... I'll see your objections, and raise you one... // theme-builder.js import deepMerge ... import { get } from './api-client'; export default async _ => { const [base, client, application, user] = await Promise.all([ get('/styles/default'), // default options get('/styles/site'), // client/deployment options get('/styles/application'), // in-application configured options get('/styles/user'), // in-application user options ]); return deepMerge(base, client, application, user); }; I'm currently working on an application that has those needs... doing that per-user means building styles at the server every time... using JSS, I just deepMerge some JSON/Objects and it all just works. I've built applications both ways, BEM, generated selector replacement, other techniques, and JSS... I'll take JSS.