Full CSS support for JSX without compromises (by vercel)

Styled-jsx Alternatives

Similar projects and alternatives to styled-jsx based on common topics and language
  • GitHub repo Tailwind CSS

    A utility-first CSS framework for rapid UI development.

  • GitHub repo history

    Manage session history with JavaScript (by ReactTraining)

  • Scout

    Get performance insights in less than 4 minutes. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.

  • GitHub repo

    My personal website

  • GitHub repo styled-components

    Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress 💅

  • GitHub repo emotion

    👩‍🎤 CSS-in-JS library designed for high performance style composition

  • GitHub repo Fela

    State-Driven Styling in JavaScript

  • GitHub repo react-enterprise-starter-kit

    Highly Scalable Awesome React Starter Kit for an enterprise application with a very easy maintainable codebase. :fire:

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


Posts where styled-jsx has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-02-21.
  • What is the best way to deal with styling in React ? | 2021-02-21
    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. | 2021-02-21
    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 | 2021-02-17
    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 | 2021-02-03
    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? | 2021-01-12
    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
11 days ago

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