Full CSS support for JSX without compromises (by vercel)

Styled-jsx Alternatives

Similar projects and alternatives to styled-jsx

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better styled-jsx alternative or higher similarity.

Suggest an alternative to styled-jsx

Reviews and mentions

Posts with mentions or reviews of styled-jsx. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-11-13.
  • How to achieve this in Next.js Built-In CSS/SCSS Support?
    1 project | | 17 Nov 2021
  • CSS modules in next.js
    3 projects | | 13 Nov 2021
    On I used styled jsx for styling my components. I preferred that to other css-in-js frameworks (like JSS) because of it actually using CSS syntax instead of JavaScript objects.
  • Using Nx Workspace generators to scaffold new blog posts
    7 projects | | 12 Oct 2021
    "style": { "description": "The file extension to be used for style files.", "type": "string", "alias": "s", "default": "css", "x-prompt": { "message": "Which stylesheet format would you like to use?", "type": "list", "items": [ { "value": "css", "label": "CSS" }, { "value": "scss", "label": "SASS(.scss) [ ]" }, { "value": "styl", "label": "Stylus(.styl) [ ]" }, { "value": "less", "label": "LESS [ ]" }, { "value": "styled-components", "label": "styled-components [ ]" }, { "value": "@emotion/styled", "label": "emotion [ ]" }, { "value": "styled-jsx", "label": "styled-jsx [ ]" } ] } }, ...
  • Which framework do you use at work
    2 projects | | 19 Sep 2021
    styled-jsx; it's vanilla CSS (in JS) with built-in scoping/CSS modules. Pretty happy with it, aside from the occasional specificity bug. Goes nicely with our React (Next.js) code base.
  • CSS in TS
    1 project | | 28 Apr 2021
    I used to not like CSS in JS until I worked with style-jsx, which imo is a lot better than styled-components and a lot of other CSS in JS libraries. If you know CSS, you can literally pick this up in just a few minutes and start using it.
  • Trying to implement language injection for template literals: CSS inside of ` `
    2 projects | | 31 Mar 2021
  • My really small (but powerful) React CSS-in-JS library
    1 project | | 17 Mar 2021
    What would happen if you used a to style a component which is already styled internally? Would precedence work correctly, or would the outer style have to artificially bump selector precedence?

    styled jsx handles this—you have to use css.resolve instead of an ordinary style tag to customize/override a component's styles.

    I’m not actually sure what you mean by “inline critical css”. But I also am curious? Can you point me to the place in the styled-jsx docs?

    I may be wrong here, but I think styled-jsx inlines "critical-path CSS" when you set optimizeForSpeed: true in its configs. But that may not be the case and it may just be other optimizations.

    I like this part, though:

    “starting here, and ending here, there is styling happening”

    That sounds intuitive—like a hybrid of styled-components and styled-jsx.

  • I Don't Like Tailwind CSS
    6 projects | | 11 Mar 2021
    And so, his recommendation is to use styled-jsx which is pretty much abandoned (despite of what they say) [1] and not even themselves are using it [2]


  • What is the best way to deal with styling in React ?
    2 projects | | 21 Feb 2021
    If you're a fan of styled components, check out styled-jsx. It's better in almost every way, imo, and was made by the folks over at Vercel (Next.js). Your CSS is written inside a template literal string (just like with styled-components) but inside JSX. It's super easy to learn and more developer-friendly than styled-components because there are no weird prop callback patterns to learn. Everything is just CSS.
    2 projects | | 21 Feb 2021
    Not sure about styled-components, but libraries like styled-jsx are actually really fast. The critical CSS is loaded on demand and inlined for performance. It also combines the best of both worlds: CSS in JS, but also with CSS modules built in (so that your CSS in one component doesn't tamper with styles anywhere else).
  • Why I Don't Like Tailwind CSS
    3 projects | | 17 Feb 2021
    As far as libraries go, I'm a big fan of styled-jsx. It was created by Vercel, the company that also brought us Next.js, and it's one of the best CSS-in-JS libraries I've worked with to date. I find this remarkable, considering that I was, for the longest time, adamantly opposed to using CSS-in-JS. But styled-jsx is an absolute delight to work with.
  • I completely rewrote my personal website using as a CMS
    2 projects | | 3 Feb 2021
    The website was styled using styled-jsx, which can be a pain to maintain and IMO is a bit messy. At the moment I'm using Tailwind CSS and so far loving it and its utility-style nature; I wanted my personal website to reflect this.
  • Ask HN: What is the defacto tech stack for a startup now?
    2 projects | | 12 Jan 2021
    The "defacto" today is to use React on top of a nodejs/Elixir/Go backend in a monorepo deployed across microservices in a custom kubernetes infrastructure.

    Hope you read enough of this comment to avoid going this way, and prevent your team from going with this "defacto" way of doing things.

    The above stack, which is what many companies are doing, is a total mistake in my opinion. It creates a LOT of work which is not related to your business.

    It also involves a TON of discussions about how to do things, what state management library you will use, what router library, what ORM (oh wait, we favour no ORM in this language because ORMs are bad blah blah), what validation library you will use in the backend, what validation library on the frontend, a bunch of different testing frameworks (some for the backend code, some for the frontend code), a way to do CSS-IN-JS or similar, etc.

    Moreover, those decisions are not something you can decide and be done with it. Those decisions come back every X months to bite your ass, because they get deprecated or their developers just moved to something else and just ignore you when problems arises (it's ok, they're not paid after all..). So you end up with some part of your system that now are unmaintained[1] [2]. In this world, things get quickly out of fashion, such as using classes for React components. Now despite they say in their docs it is perfectly fine to still use classes, this community is driven mostly by fashion, so nobody will want to use classes and a lot of time will be invested in rewriting perfectly working code into whatever the new trend is.

    Then you have the equivalent crazyness at the infrastructure level. Teams of engineers playing with Kubernetes (because it is the React of the infra folks), which is a very low level tool, upon which they will build an TON of custom tooling and scripting and processes, etc,etc and cross your fingers so that they never leave your company because if they do, you'll be in a very bad situation. If you're lucky, you will end up with something which is about 25% of what you get from AppEngine, or any other similar service, except that an order of magnitude more expensive (because of the salaries of the people building this).

    Let's not talk about all the work required to coordinate different services, document APIs from Backends For Frontends (TM), gRPC for communication between services because, hey, REST is overkill and non-performant, GraphQL which is the current trend and might not be tomorrow, etc.

    I'm not saying all of this is useless and wrong for every situation. Those tools are great and serve in the RIGHT context. If you're a big company, with tons of employes, it is better to have to do more work if that allows you to split the work across people.

    In a startup, or a small/mid sized company, there is nothing that beats a full stack solution such as Ruby On Rails. The libraries are stable and maintained because they're being used by a lot of companies. You have almost every decision already made for you, you might like it or not, but the set of decisions included in it are guaranteed to work well together. It is a lot more unlikely that some part of it will go unmaintained, you don't need to build an API for a separate frontend, you will get frequent updates, you have clear patterns and recommendations for how to do things. Deploy this on Heroku until the price goes to the salary of one or two engineers. That's a LOT. Would be more expensive to have somebody building a half assed version of it in-house. If it gets expensive, move to AppEngine or any similar, managed service. As long as you keep it using SQL and Docker you can move anywhere.

    You might have more difficulty hiring people which, nowadays, want to work with Rails and do templates, etc. But the benefit is that you will need a lot less people for building an equivalent product. And probably you will find yourself with less people hyped by building kubernetes microservices on React with Monorepos and RXjs redux on top of Rust because "that's the defacto" and "ruby doesn't scale".

    Please, CTOs of the world, let's get back to sanity. I just can't stand anymore seeing the time we're wasting with all of this.

    Of course, at some point you will be a big company and then it might make more sense to do some of this. But think twice about all the trade offs until you get there.

    Hope it helps.



Basic styled-jsx repo stats
20 days ago

vercel/styled-jsx is an open source project licensed under MIT License which is an OSI approved license.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
Find remote JavaScript jobs at our new job board There are 18 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.