styled-jsx

Full CSS support for JSX without compromises (by vercel)

Stats

Basic styled-jsx repo stats
1
6,223
5.0
about 2 months ago

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

Styled-jsx Alternatives

Similar projects and alternatives to styled-jsx

  • GitHub repo Tailwind CSS

    A utility-first CSS framework for rapid UI development.

  • GitHub repo headlessui

    Completely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS.

  • GitHub repo history

    Manage session history with JavaScript (by ReactTraining)

  • GitHub repo craco

    Create React App Configuration Override, an easy and comprehensible configuration layer for create-react-app

  • GitHub repo virtual-event-starter-kit

    Open source demo that Next.js developers can clone, deploy, and fully customize for events.

  • GitHub repo tree-sitter-javascript

    Javascript grammar for tree-sitter

  • GitHub repo eslint-plugin-tailwind

    ESLint rules for Tailwind CSS

  • GitHub repo wallis.dev

    My personal website

  • GitHub repo class-types.macro

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

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-03-31.
  • Trying to implement language injection for template literals: CSS inside of ` `
    reddit.com/r/Atom | 2021-03-31
    https://github.com/vercel/styled-jsx#syntax-highlighting
  • My really small (but powerful) React CSS-in-JS library
    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
    news.ycombinator.com | 2021-03-11
    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]

    [1] https://github.com/vercel/styled-jsx/issues/688

  • What is the best way to deal with styling in React ?
    reddit.com/r/webdev | 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.
    reddit.com/r/webdev | 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
    dev.to | 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 Dev.to as a CMS
    dev.to | 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?
    news.ycombinator.com | 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.

    [1] https://github.com/vercel/styled-jsx/issues/688