7 ms·

Author here, happy to respond to any questions. AMA!

• CiPHPerCoder 8y ago
  How do you plan to accommodate NoScript users?
  • ervine 8y ago
    You generate a css file with something like webpack.
  • mxstbr 8y ago
    During server-side rendering CSS-in-JS returns a <style> tag with all the CSS inlined. If you do not server-side render, it does not matter whether you put your CSS into JavaScript or not—your JavaScript app is not going to render anything anyway.
  • osrec 8y ago
    I know this will be unpopular, but after a certain point, noscript users just get a bad experience and that can't be helped. If a developer wants to provide a rich experience, then there will always be certain platform requirements. Without them, you will have a lacklustre experience. It's like saying "I want to have all the whizzy functionality of your app, but I want to access it using a standard, run of the mill, mud-laden potato" - it's just not going to be possible.
    • deleted 8y ago
      [deleted]
    • dictum 8y ago
      I know how the sausage is made, so I know that making a full web app work without JS isn't at reach for most teams/products. By knowing how the sausage is made, I'm also aware that the line marking the aforementioned certain point is often drawn too early, at informational (i.e. document) stuff where HTML and CSS are fully capable on their own.
      • osrec 8y ago
        You underestimate developers; they can make it work without JS if they have to. But why should we constrain ourselves?! I mean, there is nothing wrong with JS when used properly. In fact, JS is extremely useful in the browser. It adds to the richness and interactivity of webpages. We must collectively appreciate this, and stop denying this! Even HN is a better experience with JS. Some sites do give JS a bad name, and poorly used JS is something I hate too, but JS as a concept is something that I wholeheartedly support. Thankfully, the web is mostly opt-in - if you don't like the way a site employs technology, just don't visit it. Simple.
    • madeofpalk 8y ago
      noscript users certainly signed up for a subpar internet experience, but its not just them that should be thought about. Slow internet connections are a reason to think about the experience when loading JS is slow and/or failed. It's not just 'poor people' who have slow internet - 'rich people' on inflight wifi or on the internet on the train can result in things not loading.
      • osrec 8y ago
        There isn't much that can make an in-flight connection seem quick, but we've tried with our PWA (https://usebx.com/app https://usebx.com/app) and to a certain extent, succeeded. Ok, we do assume that you have visited our webpage at least once in an area of strong signal, however, once you've done that, all the JS is cached and all we transmit back and forth are lightweight, gzipped json payloads, often less than a kilobyte. I use my own PWA regularly, and found it actually quite usable in-flight.
      • thedaemon 8y ago
        I think this is a big issue with such JavaScript and load heavy web-sites & apps. They forget that they have users without 1GB connections and who can't afford, weather financially or location based, the download the 500MBs of data required to load their web-site. That and hiding CSS inside of JS feels like a sneaky tactic to keep people from editing it? Or does it actually create the CSS on the fly? I wasn't quite sure after reading the article.
        • ringaroll 8y ago
          No regular JS only website/app required 500mb of data. Please stop exaggerating. It does not make your point valid.
  • yodon 8y ago
    NoScript users are almost always economically irrelevant to the business posting the page. They tend to be extra aggressive blockers of ads (and therefore ad revenue) and are sufficiently far from the center of the bell curve technologically that they are both a tiny minority and their product needs and wants tend to be edge cases that are not economically efficient for the business to pursue. I get why NoScript users want to run NoScript, but it's the most powerful signal a web visitor can provide a business to say "focus your resources on the needs of others ahead of mine."
  • davnicwil 8y ago
    React apps have to be deliberately engineered to work without JS at all, via server rendering. Assuming that's done though, the CSS in JS can just be server rendered too. It's rather easy too if you're using a (great) library like styled components - this functionality is built in and just works with a couple of extra lines of code. The deeper question here is will the app work at all without JS. That's quite hard to achieve (every client side interaction must have a server rendered equivalent accessible via a url or url params, essentially) but the CSS part is easy.
  • bfrydl 8y ago
    The only reason I know of to bother supporting NoScript users is so that when you announce your site on Hacker News you don't have to read that one angry privacy guy talking about how bloated your site is because it requires 200 KB of JS.
  • ggregoire 8y ago
    Does he need to? I know my users don't use NoScript.
  • bastawhiz 8y ago
    It doesn't really matter how the JS components are styled if NoScript users aren't loading JS, though I assume you know that and are just trying to make a point that sites shouldn't be using JavaScript.
  • ringaroll 8y ago
    They're economically irrelevant so they're ignored. Their demands tend to be edge cases. NoScript users are like the customer that demands the most but pays least. After some rants of such customer, they're ignored.
• kowdermeister 8y ago
  - Were there moments when you cried back SASS or vanilla CSS? - In your react example, I see you created <Title> as styled.h1, but that's an awkward way of bootstrapping a component. Even if I used SC, I would still put the style information outside my component code in the same directory. At this point I don't see the benefit over doing something like: import * from './login.scss'; What can SC do that regular CSS or SASS can't?
  • ervine 8y ago
    The big win for me is if you're making an SPA, all the knowledge of the app state is already stored in JS (redux, or local state, or handed down as props if using React). So instead of toggling styles on a class, you just hand the state to the styled component, since it's just a function that returns css.
    • kowdermeister 8y ago
      Toggling styles is a good question. I have sometimes multiple classes that have to work together. For example to open a panel, I use some translate/transform, different positioning. How do you compose different styles for a single component? How do you deal with mobile, where sometimes I have to override dozens of declarations with media queries?
  • mxstbr 8y ago
    - No! I have not missed class name collisions and specificity wars at all, and I have enjoyed being able to dynamically adapt my styling as necessary. - This ties into a broader point of having "style components" like <Grid /> and <Row />, which is a very nice way of working in React. styled-components (the library) simply takes that pattern and enforces it across your application. See style-components.com for links to some more resources about this pattern!
• pbiggar 8y ago
  Can you say how this affects the classes and ids you add? I'm guessing you use classes and IDs a lot less because you don't need things to match the css against?
• akuji1993 8y ago
  Honestly, I think the CSS-in-JS approach is not for me and we haven't used it except for times where there was no other way to do something. Instead we have used CSS Modules (https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules), first by including it manually in webpack, now it's already built into create-react-app so I just have to install node-sass and call my Sass files ComponentName.module.scss and I can use them the same way in my .tsx/.jsx files that you use CSS-in-JS. IMO that's a lot less messy and makes your jsx files smaller and better to read. Also it's easier to write Sass and have the pros of that language on top. Did you consider this approach at all and what did you not like about it?
  • daliusd 8y ago
    Bonus point: you get hot reload while editing CSS.
  • exogen 8y ago
    While different from Styled Components, many people still consider CSS Modules to be squarely in the realm of CSS-in-JS. It literally generates a JavaScript module that you must import into another JavaScript module in order to actually use the CSS classes you write, after all. Having some experience with CSS Modules myself, I thought they were interesting and definitely an improvement, but still left a lot to be desired. For example: needing to use a helper like `classnames` to join/toggle many dynamic classes together was very ugly and cumbersome. There is also no way to "directly" tie variable state/props to CSS rules – you're still required to use this indirection where a state/prop relies on there being a predefined class/modifier in the CSS file. e.g. font-size: ${props => props.size}px; color: ${props => props.special ? 'red' : 'blue'}; With solutions closer to the "fully JS" end of the spectrum like Styled Components, there are no extra "modifier" CSS selectors to come up with to handle the above situation.
• Touche 8y ago
  Why do you think CSS-in-JS has only caught on in the React community?
  • chooseaname 8y ago
    Herd mentality. RDD (resume driven development). Cargo culting. Ooooh shiney! "I'm not confident enough to make my own decisions, so I'll let the 'community' decide for me."
  • dmitriid 8y ago
    Probably because it's the only one among major popular frameworks that doesn't use weird compile-to-js templates, and relies on JS only. Others (I'm thinking Angular and Vue) have their own templating systems that they compile to JS anyway.
• daniel_warner 8y ago
  Your reasons sound similar to those given for standardizing on in-line styles as much as possible. Both methods are ways to subvert or work around the cascade. I would like to hear from you why you think the cascade works the way it does, and what aspects should be preserved so as to not 'throw the baby out with the bathwater' while adopting these new methods. Thank you!
• iSnow 8y ago
  Honestly, it sounds like you now have a write-only site, as you will have a hell of a time 5 years down the road when the CI changes. Personally, I find the Vue.js concept much nicer, but even given that, I define my styling in LESS (SASS...) to benefit from inheritance/mixins on the level of styling. Semantic approaches like BEM or Bulma make a lot more sense to me. It seems to me React has made a feature out of a flaw, much like the intermingling of code and HTML back in the days with ASP/JSP/PHP.
  • woah 8y ago
    BEM is just a weird hand-cobbled way to add scoping to CSS