Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from doing something you can do in React, and Svelte/Vue make getting into a codebase far more accessible for people with a wider range of skillsets.
The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to.
Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.
> HTML and CSS not being first class-citizens as they are in other frameworks
In what ways are HTML and CSS less than first-class citizens in React? In my React codebases we've always written CSS (or SCSS) stylesheets, and components bottom-out in JSX (which is almost exactly just an HTML template with inserts)
In my experience the biggest barrier to (and most legitimate complaint about) React vs other frameworks is state management. It's always had special rules around that (even for experienced JS devs), and hooks turned that up to 11 (not without good reason, but still). While Vue at least has always had super simple state management: you modify normal JS values and the UI updates. Are you sure that hasn't been part of the divide you've observed?
(for the record it is also possible to retrofit React with state management more like Vue's (MobX, etc), but it'll be a compromised experience in some other small ways, and it may create some pain around some other library integrations that ship as hooks)
There is no built-in support for writing your styles alongside your JSX the way Vue and Svelte have. Both provide automatic component style scoping, escape hatches, deep selectors, etc. Vue passes classes given to a component instance into the top level element of that component. All of this makes styling with plain CSS and SCSS 1000x easier than it is in React.
Then there is the template side of things where it is much easier to read a basic conditional or loop in Vue/Svelte for someone who doesn't know JS.
How much have you used Vue or Svelte? It is a significantly better developer experience for building HTML and styling it because it doesn't force everything to be written in JS. In React JS is the only first-class language. There is no built-in support for SFCs, style scoping, etc. Thus the awfulness of CSS-in-JS was born.
There is definitely no built-in support for those things, but I don't think it's fair to call them second class citizens in the React world. AngularJS bundled an entire http client back in the day, but that doesn't make it more "first class" in the AngularJS ecosystem than in Vue or React!
My experience with Vue has been pretty mixed here, though. It's nice having everything in one file, sure, but it's also a pain having to create a new file whenever you want a new component. In JSX-based frameworks, I tend to start with a component in a file, then split it up into multiple components in one file, then finally into different components in different files as I'm going along - the same as I would do for normal Javascript functions. That's difficult to do in Vue, and I often find components tend to grow much larger and more unwieldy because it's easier to just add more to a single component than to split it into multiple components.
I also like the way CSS is built in, but I'm unconvinced that magic style scoping is all that helpful. I found myself fighting against it, and trying to remember the correct `::v-deep` incantation more often than I'd like. For me, the ideal abstraction here is CSS modules, where the class names are scoped, but the actual declarations behave like normal CSS. I never managed to get CSS modules to work with Vue, but we were stuck on Vue 2 for a long time, and that might have changed with more recent versions.
But I think that's the thing: there isn't really a clear "best in class" here. Different tools work for different people and in different contexts. You talk about the awfulness of CSS-in-JS, but last time I used it, I found it gave a really good balance between conventional CSS (albeit not in CSS format), while still being collocated with JS components. There are definitely downsides, but there are downsides in most of these solutions.
> For me, the ideal abstraction here is CSS modules, where the class names are scoped, but the actual declarations behave like normal CSS.
How is this different from Vue or Svelte scoped style blocks? Those are just normal CSS with scoped class names.
> Different tools work for different people and in different contexts. You talk about the awfulness of CSS-in-JS, but last time I used it, I found it gave a really good balance between conventional CSS (albeit not in CSS format), while still being collocated with JS components.
People think too much about how these things work for themselves and their own skillsets, not whether it prevents other great people from contributing as easily. I know HTML/CSS developers who are way better than the average React dev at building great clean and accessible UIs, but they aren't as strong in JS and end up struggling with unnecessarily complicated JS solutions to things that don't need them.
Besides the colocation what other benefits did CSS-in-JS provide you besides the familiarity of JS logic? This feels like again a solution to solve a limitation of React, not actually the best solution.
CSS modules work quite differently from scoped CSS. In scoped CSS, every element in a component is given an extra data attribute unique to that component. Then when you write your CSS, each declaration is given an implicit extra selector that scopes it so that it only affects elements in that component. As an example, the selector `.header > nav:hover` would be implicitly transformed into `.header > nav[data-535728]:hover`, and every element in that component would be generated with the `data-535728` attribute.
In contrast, CSS modules is far simpler: every class used in a CSS file is replaced with a random identifier (normally something deterministic), and any JS file that imports that CSS file will receive an object mapping the original class names to the new identifiers. Essentially, the only change from normal CSS is that class names are no longer global - everything else remains the same.
In my experience, I tend to run into far fewer surprising situations with CSS modules because it really is just CSS. If I target a class and all of its children, then I get what I expect, regardless of how the components are laid out in practice. In contrast, with scoped CSS, I tend to find that the scoping rules get in the way - my CSS is now tied to my components, as opposed to being able to be used and reused in multiple places. It's not a big issue (and I've used it plenty, and most of the time it's fine), but I always feel like it's an extra layer on top of CSS that I don't actually need.
Whereas, ironically, CSS-in-JS tends to feel closer to true CSS (and CSS modules) because there aren't any surprises. It's just CSS declarations (albeit often written in an unusual syntax), except that class names are locally scoped. In that sense, I can use my existing CSS knowledge and craft selectors however I want.
I understand the value of SFCs for people who don't feel as comfortable with the scripting side of things, but I do wonder if that's a bit of a false economy. At the end of the day, Vue is a tool for writing Javascript components. If you've got a team that doesn't want to write Javascript, then something like Alpine.js is probably a much better option - minimise the JS side of things completely and just concentrate on the HTML and CSS sides. But component-based web development is going to involve combining Javascript, CSS, and the DOM, and that involves understanding all three technologies, and not just specialising in one of them.
E: as a complete aside, I love the user name! I've just finished rereading the Watch books and I'm deciding which thread to go down next.
The difference between Vue/Svelte style scoped CSS and CSS modules isn't really that different in practice. When working with a larger team it is harder to enforce being careful with class name uniqueness, so the auto-scoping is beneficial but in a personal project I honestly don't mind turning off scoping entirely and just being strict about BEM class names. I LIKE the cascade part of CSS. So when working with a team Vue/Svelte-style scoping gives me the best of both worlds, global classes when I need them, scoped classes when I want to keep it component-specific.
The issue isn't that the companies/people I work with don't want to write JS, it's that they ONLY want to write JS. They don't hire the people that know HTML/CSS and accessibility better than their React devs so they don't even know what they are missing, they just think it is normal for implementation to be clunky, not match designs, and have poor performance. This is pretty much the standard at most early stage SAAS startups except the ones started by people who actually care about this stuff and understand it technically. At every company I have worked with (usually under 100 people) I as product designer have written more CSS than any front-end developer.
The point is to make codebases that are accessible to people who come from all sorts of backgrounds, not just JS developers. I have worked with designers who knew HTML/CSS well and they were so happy to be able to write simple template logic and plain old class names in Vue without having to figure out the correct JS syntax for modifying an array of style objects or writing a conditional and not leaving an accidental 0. Passing classes and props into child components and not having to explicitly tell it what to do with each one makes building JS components a LOT easier for people who aren't JS experts.
Discworld is a true joy, I miss Terry Pratchett! I read the books in publishing order, but I have had the urge to go back and read them as sets of related themes.
The main divide I've observed is whether you are encouraged to use JavaScript's built-in control flow and code reuse mechanisms or a less expressive DSL.
Hooks are pretty sweet but I think they should have launched with higher order hooks that used the same lifecycle as original React. That way you wouldn't need to think too hard about things like object identity (which I think is the state management issue you're getting at -- it wasn't a huge issue in the pre hook days)
What makes the svelte template language less expressive than JSX in your view?
Props and expressions will look similar in both (minus the useXX ceremonies), and the rest is all loops and if conditions. Writing simple inline conditions in JSX is painful, so it already starts with a negative score.
Can you be more specific? What is easier to do with JSX+JS that is harder to do in Vue/Svelte context? Or another take on the question, will it be easier to read and understand for someone new to the codebase or JS development?
Svelte's template language can evaluate JavaScript just fine. Svelte's template language doesn't need to compete with JSX + JavaScript, Svelte + JavaScript is what competes with JSX + JavaScript.
React is great and offers a lot of tunability in terms of performance but to me it often feels a lot like writing low level code.
When I use something like Vue, Petite-Vue, Svelte, Angular (flawed but underrated) - it feels like using something high level (like an ORM) that is designed to take something difficult and map it to something human readable.
The relationship between my changes in code/state ergonomically translate across to the template and that leads to very maintainable applications.
In reality though, despite the endless stream of blogs telling you how to write React applications, React isn't prescriptive on how you write it. You can create "view models" with proxy objects to implement primitive data-binding in components and use Context to inject dependencies.
In fact I once wrote a compiler that compiled html template syntax into `React.createElement()`, and along with a supplied runtime I was able to use React as a backend for a reactive template renderer.
> Svelte and Vue approach to SFCs
I have personally found SFC to be super annoying given they are not optional and require custom tooling.
A single file is nice sometimes but I don't really mind if a component is split into 3 files (js, css, html) as long as they are associated with each other somehow. I just want to ensure that my view renderer requires the least amount of tooling possible so my project will stand the test of time and I can be self reliant for updates.
Can I use my own test runner? Can I pick my version of TypeScript? Can I setup my own eslint? Can I set up my own css preprocessor? Can I use custom compiler configuration (like using SWC)?
To me, the fact that React doesn't require a compiler (aside from translating jsx) is its greatest asset, and Vue/Svelte and Angular's greatest shortfall.
It's just a shame that React is so fiddly to work with
I love having HTML/CSS/JS in one place, it means things never get detached from their immediately relevant context. Also thanks to nice extensions for VSCode (which wouldn't work across separate files) I can option-click any class name and get a mini-panel to edit the styles inline without hunting for the style section or a separate style file. I can also see when styles I have added are not being used in that component.
When I demo side projects and my own work to my coworkers they are always surprised "I didn't know you could do that!" and the thing is they can't because they are all stuck using React.
> they can't because they are all stuck using React
You can get most—if not all—of that behavior in React with JSS and TypeScript. All of your component code (HTML, CSS, and JS) can be colocated in one file, you can jump to the CSS class definition, TS ensures the class name is legit, etc.
Svelte and Vue provide a more batteries-included experience, but React is very flexible.
But it's a far worse developer experience, particularly for designers and HTML/CSS/A11y folks who aren't as JS focused. It's not like you really are getting that much benefit from writing CSS in JS besides familiarity with a language you prefer. It's harder to read and parse at a glance (even for the devs who wrote it, I see this in practice all the time when pairing and attempting to fix layout and style issues with my devs), harder to inspect from the browser, encourages practices that undermine many of the core benefits of CSS, etc.
My whole point is that we should not be finding worse workarounds just so we can stick with the familiarity of React. Even outside of HTML and styling it is easier to do stuff in other frameworks than it is in React. React is not providing some magical level of power other frameworks don't provide.
I don't hate React, I'm just sick of it being the defacto standard. We are creating a React monoculture in web dev and it absolutely has secondary impacts on how we write markup, styles, and how approachable and accessible our codebases are. So many major decisions being made just so a team can stick with React.
Why not pick a different framework and get better performance, easier to write JS logic, easier to write and read markup and styles, and a code that designers and others can engage with easily without having to be JS fluent?
It's great to argue for Vue/Svelte, but just to clarify - the entire point about HTML/CSS isn't really true, there's no difference in support between React or any other framework there.
And disagree on HTML/CSS skill loss being a thing, or being proximately caused by React. And no it doesn't have any div-soup causative effect either.
I get that templates are simpler for non-coders. Unfortunately, in all but the simplest cases the cost-benefit is towards the React model as you are just "using the platform" to build your views - ie, JS and not some arbitrary DSL.
How can you say there is no difference? What do you think Vue and Svelte SFCs are? Where does React have built-in component style scoping? Where does React have automatic passing of classes and properties to components? Can I write SCSS in a React JS file and have it just work? Nope.
The platform is more than just JS, and React has plenty of stuff going on that is "magic" enough to be no different for me than the abstraction of a DSL. How is the cost-benefit better for React when I keep seeing developers who actually try other frameworks have their minds blown at how much easier it is to do the same things?
The CSS skill loss is very real, particularly with the number of straight-to-React bootcamps that barely touch on it and the insistence on using CSS-in-JS which makes it way harder for people to explore a production website and learn the fun way. I'm not some HTML/CSS purist, and React was a big step forward for the industry, but now its time is past and we have way better alternatives.
No one believes the gospel of syntax, simplicity, and inline styles more than me [0]. I made that before Svelte was a thing and the Vue creator actually asked if he could borrow multiple ideas from that as he was making it.
But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the minimum importing CSS.
React has some of the most gorgeous style solutions around (I should know having built the best one) and has since forever ago. Svelte is less popular than many React starter kits with I'd argue much nicer DX.
CSS needed drastic changing too, and I think if you looked on average total CSS knowledge is higher than ever, you're just seeing frontend become popular and wide, different types of sub-specialties at this point.
> React has some of the most gorgeous style solutions around
Can you give an example?
> But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the minimum importing CSS.
Vast majority use Styled Components or another flavor of CSS-in-JS that continues the problem of making it harder for HTML/CSS experts to contribute to a JS-only codebase. Tamagui is exactly the issue I'm talking about. It's great for JS/React first devs, but doesn't actually do that much that a good HTML/CSS developer couldn't do without all this added tooling and with much easier to read clean code for people unfamiliar with the framework.
> I think if you looked on average total CSS knowledge is higher than ever,
Definitely not my experience. There are some great CSS devs out there, but it is always secondary to the skillsets that are actually highly paid (JS, React) and they mostly end up in large companies by happenstance of those companies hiring more people. Smaller tech companies make the consistent mistake of not hiring front-of-the-front-end devs and end up with poor UI and experiences because of it.
Tamagui is explicitly React Native and Web focused so yea you don’t learn CSS as directly, but that’s the point as there’s no CSS on native. It’s not really relevant since Svelte doesn’t do native (big downside and shows why maybe CSS extremism is not helpful).
The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to.
Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.