hckrnws
Solidjs: Simple and performant reactivity for building user interfaces
by lastdong
Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future.
This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points of Solid's design. I've never run into a real world scenario where delaying computations seemed like an optimal way of solving a given problem.
I'm curious which part of laziness are you concerned with? Is it delayed execution in events? It is just most lazy things run almost immediately during creation anyway, and on update everything is scheduled anyway. The only lazy thing we are looking at is memo's which while impactful isn't that different as the creation code runs. I guess the push/pull propagation is harder to follow on update then simple multi queue but in complex cases we'd have a bunch of queue recursion that wasn't simple either.
Wow, I never imagined you would respond to my comment, a little embarrassed ngl :D
I understand that under the hood Solid's reactive system is not quite simple; though, the mental model needed to use it, is very simple, which I greatly appreciate when building complex application logic on top of it. That's really my main concern: that one-way "push" semantics are easy to follow and think about, and adding new mechanics complicates that picture. It seems deceptive that what presents itself, at least conceptually, as just a value access, might now cause arbitrary code execution (another way of putting this is that it feels like it violates the principle of least astonishment).
As I mentioned before, I also haven't run into situations in practice where lazy memos seem like a desirable behavior. If I initialize a derived value, it's because I plan to use it. If some computation needs to be "delayed", I place it inside an if statement with a reactive condition, for instance, createMemo(() => shouldCompute() ? computeValue() : undefined).
All that's said, you've done a fantastic job with Solid. I hope you continue to innovate and prove my objections misguided.
I'll admit that hearing that "laziness" was something being explored for Solid 2.0 also made me uneasy. Like the OP, in my case I know it's because I'm worried that it will complicate working with Solid state in the same way that React's "concurrent mode" complicates working with React state. Really, I just hate React's "concurrent mode" and I really like the simplicity of working with Solidjs' state by comparison (if Solidjs has a similar concept to concurrent mode I haven't run into it yet).
All of this is to say that my own worries aren't based on any concrete objections, but a general fear of change since I like the current approach (and haven't run into any performance issues with it). Also, without knowing exactly what you plan on changing, the idea of introducing "laziness" seams like it could be a euphemism for "async" which feels like it would definitely make things more complex. Anyway, reading your comment makes me hopeful that my ambiguous unease is misplaced.
React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.
I think it's just the lifecycle of craftsman tooling in general.
When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools.
Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.
React always had gotchas, but the question is how tolerable are those gotchas compared to the gotchas of what you were doing before. And how tolerable are Solid's gotchas going to be once you discover them. Sometimes it's a better set of gotchas and sometimes it isn't.
It's also easy to confuse problems that arise from failing to adequately manage the gotchas with problems inherent in the tool itself. There's a subtle distinction there that's easy to miss, especially for those with a blame-the-system sort of attitude (which I don't entirely fault).
One company I worked for had a very slow frontend. It was common there to blame the slowness on React. "React is just kind of slow."
Another company I worked for had a much larger React-based frontend, and it was fast-loading and snappy by comparison.
The difference is that the second company had much more well-established good practices in its design system, the codebase, the enforced lint checks, and the general knowledge of its engineers. They avoided performance traps that caused multiple renders of things. (The first company's frontend would render a given screen 12+ times for some state changes.)
Very balanced response, but in my case it's less about gotchas and more about APIs. I just think other frameworks have more intuitive APIs than react. Maybe this falls in the same category as a gotcha, but I feel it's a little different.
One of the best responses I have read on this topic. Thank you
It's not that it's way too entrenched, it's just that people grew tired of constantly shifting frontend frameworks. Personally: I really didn't care who "won" that war, I just wanted to have a sane well-supported default without having to learn a new pattern every year to store page state or update an icon.
[dead]
> I've never run into a real world scenario where delaying computations seemed like an optimal way of solving a given problem.
And even when it might be, Solid has always exposed fairly low level reactive primitives for those who want more control. Hopefully if laziness is added, it's in the form of new optional primitives.
> Having used Solid on a largish web product for over a year
I am curious about your experience in this regard. I've been aware of Solid for quite a while (and plenty of other non-React alternatives that on paper seem "nicer") but the problem I usually quickly run into after exceeding the complexity of a contrived demo app is the ecosystem not yet having a number of components, library wrappers, integrations, etc. that I use all the time.
Have you found the Solid ecosystem sufficient for whatever your needs are, is it fundamentally easier with Solid to integrate things that don't exist yet, or did you go into it less spoiled/tainted as I by reliance on React's ecosystem?
I've found the ecosystem to be perfectly serviceable for every complex piece of functionality I needed to bring in: remote state, forms, tables, and routing, come to mind. Complex state management can easily be handled using the library's standard reactive primitives and the community "solid primitives" project has a ton of well made utilities so you don't have to reinvent the wheel for common use cases.
I'm not going to sugar coat it though, SolidJS is not necessarily a batteries included ecosystem. There is a severe lack of components/component libraries. Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.
Cool. I am a bit of a minimalist (one reason I've never felt the most comfortable with React compared to some other things) and equally not interested in bloat and differing opinions/principles from using component libraries for everything (and I almost never use them for UI) but, yeah, I also don't want to have to write my own high-performance basics. A few years ago when using Vue for something, I had to detour a lot to writing things like virtual list components because at the time they were not available. (I see Solid has a few of those.) Not ideal for a tiny team or as a solo dev trying to make a dent in something in my off hours
> Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.
Good to know. I expect to need to write my own wrappers for certain things that are more niche, but some frameworks definitely make it easier than others, and I do tire of wrapping the same 153 events and properties and such for some component yet again when [framework of the month] has an annoying way of doing this
For what it's worth, ecosystem is a valid concern, esp compared to React, and esp if dealing with more niche features. Even for something fairly generic like Virtual List implementations. Virtual Lists do exist for solid (specifically tanstack is the most fully-featured, albeit under-documented), they aren't as battle-hardened or as well-documented as their react counterparts. Specifically, I have thought about digging into VirtualList internals, because of a couple issues that I haven't seen in some other framework impls (granted, of most the complex generic ui components, virtual-list is literally the one issue I had with ecosystem).
Also, you'll definitely start seeing edges faster. Things like touch event libraries, animation libraries, maplibre/dataviz/etc. I'd say that the solid ecosystem is at the point where you'll see 1-2 libraries for most things, but if those libraries aren't quite right for you, you can very quickly find yourself digging deeper than you'd like.
That being said, as parent stated, integrating vanilla libs isn't so hard. And also, there is a... solid... amount of people building headless libraries specifically for the ecosystem, which are quite useful (For example, I recently came across https://corvu.dev, which I've started integrating here and there). What I mean to say is less that solid has a poor ecosystem, and more that there isn't the infinite easy-access vibe-code-able pop-in-lib-to-solve-your-problem ecosystem of react.
Even with the shallow ecosystem, solidjs has been quite enjoyable to me. Also, in the two years I've been using it, I think I've built up enough of my own personal ecosystem that I don't really need to reach towards external dependencies all that much, which feels very nice.
[dead]
Not op, but I converted an online card game etg.dek.im from React to Solid. What helped is that I don't use any of other React libraries
Used to use redux, got rid of it. Used to use react-spring, got rid of it
The SolidJS ecosystem is smaller but generally has more high quality libraries and more integrated.
Take a look at Solid Primitives: https://primitives.solidjs.community/
I've used Solid Primitives and white it's great, unfortunately it seems pretty dead. None of the primitives is "4 Accepted/Shipped" and many aren't even "3 Pre-shipping (final effort)".
Is laziness intended to offer primitives for suspended UIs?
I haven’t used Solid for a while and can’t recall if there’s a Suspense counterpart already. If not, this seems like a reasonable feature to add. It’s a familiar and pretty intuitive convention
Looking for this? https://docs.solidjs.com/reference/components/suspense
Ha! I’ve used this, too. I guess I’ve reached the senility phase of my mid life. Thanks for pointing me to that
[dead]
[flagged]
What does number of users have to do with it? That's a backend concern, largely.
When evaluating front-ends, wouldn't the concern be more "number of components active at a time", or "complexity of application state", etc?
React is, I am convinced, the new Struts only client side.
Struts was SSR before we needed a term for SSR. It had low productivity so it looked like it was doing well in the industry because there were so goddamned many jobs. But if you asked people you really couldn’t find many that loved it, and if they did it was a sign that maybe their judgment wasn’t that great, and you were going to be disappointed if you asked follow-up questions about what else they thought was a good idea.
It was killed by JSTL, which was one of the first templating systems to get away from <% > syntax.
I'm using SolidJS for Infumap (https://github.com/infumap/infumap), which is getting pretty big.
Two main comments that come to mind:
Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i've not felt the need to do it anywhere yet.
The AI training data set for React is much larger. The models seem to do fine with SolidJS, though I suspect there is meaningful benefit to using React from this point of view.
Overall, I'm happy with where I'm at and I prefer the SolidJS way of thinking, though if I were to do it all over again, I'd probably just go with React for the above two reasons.
I was not expecting to loose karma for this comment!
I have a couple of years familiarity with SolidJS and thought the two key insights that came to mind from building a large project in it would have positive value.
Apparently not!
[flagged]
Your tone sucks. You're being rude about them not answering questions they weren't asked yet. There are much nicer ways of going about this.
Edit: Oh. All of your replies are like this. Please take a chill pill.
Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc
I personally don't like that direction so looking forward to exploring new frameworks.
What I've generally liked about React/Next setups is that the code is generally explicit and less magic (I also have gripes with hooks feeling like magic). Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.
Does anyone know if SolidJs projects are fully js?
One of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop between, say, a RSC "backend" and a non-JS-based frontend (or crawler/scraper), or to have a non-JS backend emit RSC-compatible updates. Or to be able to allow people to iterate on it with fresh JS server-side code, rather than needing to build around a bundler.
If I want to make an Erlang or Rust based system that emits RSC-compatible updates (which itself is an undefined statement) in real time, say - there's no way to do that without either having a JS layer as a separate microservice, or calling the code from JS in some way.
The PHP analogy is very much earned, in my view. It doesn't make it a bad choice for all projects, but it will tend to isolate the ecosystem from new directions.
[1] https://overreacted.io/jsx-over-the-wire/#server-and-client-...
Nothing about the RSC format is privileged in the React client (i.e., react + react-dom). You can always make your own serialization format as long as it can represent React elements and promises somehow. You can of course also use the RSC wire format and pin to a specific client version (or vendor/fork it) but it’s not a stable format today because it’s not clear if many people would use one and we want to leave room to improve the format as new optimization opportunities arise.
Though you do lose a lot of the magic if you don’t have JS on the server at all. Part of the core proposition of RSC is that it’s easy to move logic across the boundary as your app evolves. What goes over the wire can be a performance decision instead of a “that’s too much of a pain to move to the other side I’ll just leave it” decision. For that reason I’d generally make a thin “backend for frontend” in JS that talks to an Erlang/Rust/etc backend. It’s conceptually part of the frontend but runs on your server.
That's fair, though IMHO some marketing from Vercel does make it difficult for someone not versed in the internals to understand what is "privileged in the React client" and what is not. That's their prerogative as a leading maintainer, of course.
And completely understand that freezing a format causes all kinds of difficulties, and semver alone doesn't solve for the resulting community frustration. So I understand why the decisions were made - it's just all a bit foreign to me compared to the groundbreaking simplicity of React's APIs in its earliest days, where if you understood a render cycle the entire world was your oyster. The internals of the renderer were always fine to be "off limits" - but wire formats just feel quite different to me.
(Also, just want to say you're an absolute hero of mine, and my hopefully-gentle nudging on this is because I love everything the React team has created, and I want React to see its full potential!)
It’s fair, the docs could be better! And there are certainly subtleties with hooking up the router and bundler and everything. However I will say that really there is no funny business going on.
Basically the entire elaborate RSC apparatus just ultimately outputs a tree of plain React elements with promises and <Suspense> to make it streamy. Sounds like groundbreaking simplicity to me! I kid a bit but really I’m not sure that the RSC wire format is any easier as an output target than the existing public React client API.
Maybe I should make a little demo to show that.
But anyway the point is that the wire format is an implementation detail because the two sides of the wire are actually the same program. Even if they’re running on two different computers.
Sounds like you need a 14th bundled but built with some liveview code.
> I personally don't like that direction so looking forward to exploring new frameworks
I personally am becoming dissolutioned with React because of this, as a former strong advocate.
Next.js and Remix - or whatever the hell it's called this week - are both over-engineered messes.
Yes, I'm aware that I don't have to use them, but they are where the momentum and energy of the community is being spent in recent years. And I do want a monolithic framework, I just want one that focuses on simplicity and ease of development rather than one designed to funnel me into using Vercel.
Don't worry, we're only four or five years out from the react community discovering/inventing a totally fresh UI paradigm where the entire app is run on the client, no server rendering at all.
It will be totally fresh and solve all the annoying problems of legacy react server pages. Of course then 6 months later they'll discover a need to make it work with SEO...
Comment was deleted :(
Hard agree. It’s all complexity and for what? SEO? So many products don’t need SEO. API proxies with secrets? These are not super common use cases.
The default should be SPA and purely static.
next.js totally is overengineered and feature-bloated. But working with remix in the last 3 years (now called React Router: framework mode) I would never label it as overengineered. I'm not sure what you are talking about. If anything, it still misses features (Middleware still in beta, websockets native support, etc.). This weeks flavor is TanStack Start - which looks quite promising and not yet overengineered as well.
I've been using solidjs (via solidstart) for awhile on a medium sized project.
> Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc
Solidstart definitely pushes you to use their magic server functions. I used them at first - but increasingly I've been moving back to writing a normal, real REST interface on the server side. It still works fine, its just a few more lines of code to do it yourself. The biggest benefit is that I can control my HTTP verbs and headers. This lets me set up caching correctly, both in the browser and any intermediate caches.
> Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.
Solidjs doesn't mash css and JS together. You usually use normal, real CSS or CSS modules. Eg:
import styles from './style.module.css'
function BannerComponent {
return <div style={styles.bannerBar}>Banner</div>
}Thanks for the answer.
And http caching is definitely a huge factor for me too, graphql gives me similar sorts of pain. Sure, you can cache anything if you hack around for long enough, but in a real world engineering org (not the unicorns or uniquely positioned tech giants), it's so much easier for me to tell the CEO I can put some cache headers in by end of day and move on.
Yeah.
To be clear, solidstart also makes it very easy to set up a REST API server endpoints. They're ~10 more lines of code compared to their magic RPC handlers. They work great.
https://docs.solidjs.com/solid-start/building-your-applicati...
> Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.
I personally found Svelte much more intuitive than React.
Code first, then markup, then style.
React I have always just found a bit confusing and annoying.
> I personally don't like that direction so looking forward to exploring new frameworks.
I have a proposal for a new approach to front-end components. Even used it at a big client in production.
Want to put it on arxiv[1] before showing it to the world, but it's largely impossible to find an endorser unless you're active in academics already.[2]
Academics in a nutshell: the largest number of papers are authored by recent graduates with little to no industry experience.
Now, remember just how clueless your recent MSc graduate was when they started their first job in your organisation? Yeah - those are the types of authors driving state-of-the-art in SE.
---------------------------------------
[1] I have my reasons. If you're an endorser for software engineering, DM me.
[2] Academic gate-keeping got stupid, then pushed past to ridiculous, and appears to be now accelerating over the madness event-horizon.
Yep. Solid js stays true to js. A div is literally a div. And you can use Solid without jsx, and used tagged templates if you so desire.
You can use React without jsx too. JSX is just a very thin wrapper over React.createElemental
``` const h = React.createElement
h('div', { id: 'foo' }, [ h(MyComponent, props) ])
```
Of course the props to divs are a bit different and event listeners/styles can be written inline, but none of this is JSX specific.
Never did I ever once think React would one day be compared to PHP.
Reading that post the other day and seeing modern terminology being applied to old backend rendering was quite the experience. "Imagine on initial page load it returns the complete screen UI with all props and components already hydrated".
I remember those days but I remember some of the bad as well. I really started to hate that every UI change in the template/HTML meant changing the page controller to handle the new data. I specifically remember wanting some technology that allowed the UI to dictate what data it needed.
The pendulum swings though and it seems we are reversing course lately. Perhaps we land on a solid middle ground finally.
The point of RSC is that you get the behavior you’re describing without the dev pain points you are describing, and with a high degree of flexibility in customizing what code gets run/sent over the wire where.
HN likes to dunk on React but I think the paradigm is pretty cool and I hope that other meta frameworks beyond NextJS find ways to support it in simpler to follow ways - Tanstack Start has a promising looking philosophy, excited to see where they land on.
You can just use styled-conponents on React.
const Button = styled.button<{ $primary?: boolean; }>`
/* Adapt the colors based on primary prop */
background: ${props => props.$primary ? "#BF4F74" : "white"};
color: ${props => props.$primary ? "white" : "#BF4F74"};
...
`;
render(
<div>
<Button>Normal</Button>
<Button $primary>Primary</Button>
</div>
);It’s officially deprecated.
See: https://opencollective.com/styled-components/updates/thank-y...
> I personally don't like that direction so looking forward to exploring new frameworks.
Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core.
Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases, so why would that affect you?
Much of the official documentation now refers to server components as the "right" way to do certain things. Cra is end of life, with the replacement nextjs being heavily biased towards server components.
Your tooling certainly has changed in that you won't use cra any more, and I wouldn't agree that this direction does not detriment previous use cases.
I view create-vite-app with React presets as the spiritual successor of create-react-app, rather than NextJS.
I'd already switched to vite due to the lack of customization that one has with CRA.Even if create-react-app was still maintained, I'd never go back to it.
Vite all the way....until that gets deprecated and forced to move to nextjs
> React core has been exactly the same as it was ten years ago
Are we not considering Hooks core yet?
Hooks were introduced in 2018. We're in 2025.
It's not 10 years yet, but we're pretty close to that.
Yes, time flies.
Really? So class components are still first class citizens and play well with existing ecosystem code?
> So class components are still first class citizens
Yes
https://react.dev/reference/react/Component
> play well with existing ecosystem code?
That's not something the React team has any control over so it feels like an unfair complaint.
However, besides external libraries that are specifically designed to work with hooks, I'd say quite a lot of things would still work. And you can always just use older versions of things, nobody is forcing you to upgrade.
Anyway, React has been using hooks for about 6 or 7 years now. Not quite the ten years claimed in the previous comment but not so far off either.
> That's not something the React team has any control over so it feels like an unfair complaint.
Sure it is — they could let you run hooks from within class components. Not only do they not allow that, they actively discourage you from writing class components in the documentation.
Even if they didn’t have control over that, though, how does the complaint feel unfair? When I buy into a tool, I’m buying into the ecosystem as well. If the ecosystem moves in a direction I don’t like, that’s a strong disincentive to using that tool!
At some point, the creator of SolidJS, Ryan Carniato did a stint helping developing Marko.js, a fine-grained reactive / compiled / a bit HTMX-like system, and blogged about that. It's a framework that originated from eBay. I'm now quite interested about the next version of Marko.js, Marko.js 6, and I'm gonna try it for my new project.
I'm interested in fine-graned reactivity so Svelte and SolidJS have been on my radar, but the HTMX-style approach appeals to me.
Here's something to munch on:
https://dev.to/ryansolid/marko-compiling-fine-grained-reacti...
https://dev.to/this-is-learning/marko-for-sites-solid-for-ap...
Amy thoughts on AlpineJS or RiotJS in this same realm?
Alpine.js in tandem with alpine-ajax has made me a very happy developer the last few years.
What about mizu.js?
I love Solid so much. It has feature parity with React and is faster. However, most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term.
React is unreadable and bloated with 20,368 commits and seemingly unstable with the maintainers always pivoting it around. I like it's semantics, but don't want to deal with updating it long term as a dependency.
> most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term.
Genuinely curious: why does a low number of commits, and mostly commits from one person, give you confidence to keep it around long term?
Low count suggests that the project has an intentionally built core and doesn't undergo churn or feature creep. It's also a good sign that commits per week have decreased substantially over time.
Contributions being mostly from a single developer lends further credence to that idea, because it implies everything is fueled by one person's relatively opinionated vision and taste.
This conclusion is deeply divorced from reality.
A single(-ish) author is the strongest smell for a library. I've been burned countless times by a project's "BDFL" moving on to something else. Sometimes a new maintainer will take over, but it's rare.
Low commit count also suggests unresponsiveness to issues that are filed, especially for a TypeScript or JavaScript project.
This thread single-handedly convinced me not to start a Solid project.
Low Commit count suggests nothing other than maybe lower traffic. I've been able to keep issues the main repo under 50 issues most of its life. I admit work towards the next major version has let this slip upwards. Also effort is split among multiple repos. Repos where I'm far from the biggest contributor. The core is small and manageable. Which is a good place to be 9 years in (7 of those open to the public).
Yeah exactly 7 years tomorrow. Wow time flies.
>Low commit count also suggests unresponsiveness
SolidJS (Ryan mostly) is very responsive, so the low count is more a sign that there are not many issues which require code changes in the first place. Which is good!
>Sometimes a new maintainer will take over, but it's rare.
SolidJS really doesn't need a full-time maintainer at this point. One or more community members fixing severe bugs and keeping it up to date is plenty enough.
What about hono client side? Seems to have most React functionalities:
Sorry, but number of commits don't say anything about the quality and direction of a project.
React has been around for much longer than Solid, and also much much more popular, with many more contributors. It's also the pioneer of virtual DOM reactivity, when you're a pioneer there bound to be some trial and error.
It can also be argued that SolidJS has a higher bus factor, as it's still very dependant on the creator (Ryan Carniato).
Sharing my experience... A while ago, I wanted to build an app using SolidJS 1.4 but got stuck because of a list mapping bug, ie. child list not updating IIRC. I reached out to Ryan, he said that he knew about the bug and had a fix coming in the next release. I couldn't wait, so I had to port what I had to React and call it a day.
I wonder how long by comparison you would have had to wait for React to fix a bug of that nature. Obviously no comparison on maturity given difference of user base size, especially 3 years ago. I appreciate you sharing as I think stories like that are good example of responsiveness of the project.
> When you're a pioneer, there are bound to be some trials and errors.
The higher number of commits is, to some extent, empirical evidence that trials and errors were encountered.
> SolidJS has a higher bus factor.
For me personally, the higher bus factor is a feature, not a bug. Ryan has brought the project to a state of relative "completion." I can rest easy knowing that SolidJS would only need to be maintained, not "developed," if he were to leave.
Can a SolidJS or an other non-React user chime in to explain what their experience is when using a more `modern|unorthodox` framework for a data-heavy SPA that uses lots of components?
For react you have got Mui(x). Especially the datagrid with the myriad of options is something which I cannot fathom to rebuild myself. I mean, look at this [0], which just is about the grouping options.
When I see other component libraries I think: nice, this is only 10% of what I need. So I am curious if and how people use non-React stuff to build `heavy` SPA applications. Maybe I can learn something.
For me the selling points for React are:
- functional: components are pure functions
(with caveats 1. as much as possible; 2. from a dev experience)
- large component libraries. High quality, battle tested, and well documented.
With Svelte anyway, a third-party component just gets in the way.
You just make whatever it is you want in HTML and make it reactive (put it in a file with the right extension and add the svelte-specific reactivity you want).
It's simple/straightforward, does exactly what you want, and instead of spending time mastering the API of some component, you mostly spend time using the HTML/JS/CSS you already know.
Yes, and you will probably get a little better at HTML/JS/CSS if you do not have to spend time learning a third-party component's API. Third-party components can also become unbearable if you have a very clear idea of what you want to archive.
Thanks. If that is the common approach in Svelte to third party components, than I learned something.
> You just make whatever it is you want in HTML and make it reactive
> ... instead of spending time mastering the API of some component,
If I were to achieve a reasonable amount of flexibility, I would have to redo the work of that library: create a flexible component from scratch with a good api. That is my concern at least.
So when I see the other frameworks libraries, I get the impression that possibly the target audience differ in needs, like so:
data-heavy, enterprise systems, business software => react
webshop etc, "simple" consumer oriented => svelte, solidjs etc
The reason you don't see Svelte versions of common libraries as much as you do for React, is that with Svelte you can just use the vanilla js/html/css version and they work great. React has a hard time using vanilla approaches because the virtual dom and hooks aren't vanilla and don't work like vanilla. React is it's own world and therefore needs to have a React version of everything.
I think I do not completely grok that, maybe I have to experiment with Svelte a bit more. As GP mentioned, in Svelte one does not reach for third party components, so you might be on to something.
I think the best case for using Svelte or Solid over React is when performance is critical, e.g. in big and/or fast data contexts.
Good point. I don't know how much of the gap remains if one can settle for Preactjs, but Reactjs is not the fastest.
Not much is going to compete directly with React's ecosystem maturity.
But, of course, there's the option you have when using a non-React library in React: on mount, you instantiate the library in a ref, and then you use effects to turn reactive state updates into library invocations.
For example, wrapping https://datatables.net/ if there were no React adapter.
Wouldn't you mean that the other way around? So you have a Svelte/SolidJS application, and you use some React components like from MUI to fill the gaps.
Vue has a large ecosystem. A lot of very good component libs like PrimeVue, Vuetify, Quasar, NuxtUI, ElementUi ...
I have used agGrid and eCharts with Svelte. Doesn't get any simpler. With Solid, Vue and Svelte you can integrate vanilla JS libs easily.
I tend to use Svelte without component lib or DaisyUI. After all, those libs are technical debt. Also, the native HTML 5 elements / browser APIs are pretty complete these days (dialog, popover, ...). If I was to chose one I'd probably go with Vue and PrimeVue.
Most of the modern front end frameworks can handle those use cases.
Solid, Vue, Svelte all have capable SPA frameworks and component libraries
I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
Solid indeed does not have the same number of options that React has when it comes to UI component libraries. I've only used Solid on small throwaway projects, but I do like it better than React.
However, like you've pointed out, there's going to be things that you have to do yourself that in React you could likely depend on someone else for.
For tables though, I haven't used this in Solid, but it's pretty nice in general https://tanstack.com/table/latest
When I researched Tanstack, it looked flexible. But a recurring theme with users was that some options are not compatible with each other, while the documentation is silent about what functionalities are compatible with each other. Did you experience that?
For me such a thing is a red flag: incomplete documentation, feature gaps and unpredictability. Also, how difficult is it too fill the feature gap. Even if one succeeds, how maintainable would it be if changes are not accepted upstream.
No, but my use of it was fairly simple stuff, so I probably just didn't run into that. I do use react query and their router regularly and haven't had any major issues with it.
Good to hear, thanks for sharing.
Thank you! I have skimmed them, they look pretty and feel fast.
Unfortunately they seem not to match mui in breadth and depth.
We are using PrimeVue at my work and are very happy with it. I'm not super familiar with Mui so can't directly compare.
Thank you. I remember I had a look at that. Made a quick look now at PrimeVue treetable [0], to compare it to MUI datagrid [1].
There seems to be a wide gap in feature scope and depth. For example, column grouping in [0] seems to be not available (it is in PrimeVue datagrid, but that misses support for data hierarchy).
___
If you're interested in data grids specifically, Svelte has https://vincjo.fr/datatables/examples/client/hello-world
Interesting! I need hierarchical data grids indeed (but they also seems to be the kind of shibboleth only the large libraries are able to speak).
https://suid.io/ is MUI for SolidJs
That is really interesting, thanks for sharing. Sounds almost too good to be true.
I saw however an open issue [0] about performance problems that seems to indicate that component libraries in Svelte suddenly becomes really slow?
Another update. I wondered whether this was really unique to SUID or if other component libraries also have this problem. So I included Park UI and Kobalte (which seem to be the only other mature options besides SUID).
Kobalte runs in ~168ms, and Park runs in ~382ms. Even that seems too slow to me. Is there something inherent to component libraries that makes them slow in Solid.js? (Next up, I should probably benchmark the same setup in other frontend frameworks.)
Yeah it is an interesting one. There is definitely a slowdown due to the amount of wrapping that happens. These sort of libraries tend to put component in component in component etc.. so there is a lot of prop iteration, Object.keys calls in Object.keys calls etc which when used with proxies can add up a bit. The tricky part is no one actually knows how slow these libraries are in say React. My suspicion they are slow there as well but maybe not as stark of a difference because of how fast Solid to begin with comparatively.
People who use Solid tend to measure stuff like this where as those who use React might have already reconciled themselves to performance issues.
Thanks for chiming in.
React doesn't win speed races, but the mentioned slow-downs are rather extreme and would be noticeable.
I agree that one should benchmark against React-MUI as the baseline. In fact, that would give Solidjs a meaningful (less synthetic) benchmark, as in this case we have a wide range of non-trivial one-for-one components to compare with. A goldmine for performance testing.
If SolidJS could outperform React in these kind of workloads you would have a great proposition.
My full time job is with React and my side projects are build with Solid.
I gave a presentation in the office about Solid a while ago and one of the guys said: "So this looks like React, it's easier to understand, it's faster, smaller, with more build in stuff... why are we not using it?"
Ryan, the creator of Solid, mentioned in one of his interviews that the fact Solid is gaining traction slowly is actually a sign that the web has matured. People are no longer as quick to jump to the next flashy thing - and I agree.
Ok, you've got my attention with documentation like this
const [first, setFirst] = createSignal("JSON");
const [last, setLast] = createSignal("Bourne");
I'm a big fan of Solid. It's a very influential community, however it's not widely used. All the pieces are there. I just don't see tons of marketing or real app/product/dx focus from them.
Look out for their upcoming 2.0 release, it's supposedly gonna be something special.
It’s been an absolute joy to write Solid the last few years. After a workday of writing React, it always feels so liberating to come home to my personal solidjs code. When used with solid-primitives it feels very expressive and powerful. But mainly I think reactivity just jives with my mental model better than React’s top-down “rerender everything unless it’s a memo” approach. All that said, concerns about the solidjs ecosystem are valid. For example, if you want to use trpc your options are either to use v10 with an unmaintained adapter, or use v11 but not have the built-in support for tanstack-query that you would get with an adapter. Similarly, if you want to use framer motion, you’ll be a few versions behind the React folks. As someone who loves building my own stuff, usually ecosystem limitations don’t bother me too much, but it can feel frustrating to not get to use all the latest things available in the react ecosystem.
[flagged]
I've been interested on dipping my toes in Solid for a while, but I've heard there's a 2.0 coming soon and I don't want to bother learning Solid in detail if there's going to be a lot of breaking changes soon.
Does anyone know the status of 2.0?
Looks like its still in the discussion phase, did not see a timeline but also did not read super close. Did learn about the tanstack-router which I had never heard of, so that was worth looking this up right there ;)
[flagged]
SolidJS and dom-expressions are the best things that have happened in the front-end since React, it is influencing the whole ecosystem, from templating to Signals. It will be very, very hard to come up with better ideas, it may not be that popular, but it's leading the way.
Genuine question:
Why would you use Solid instead of Svelte?
I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.
Ironically, mechanically Vue and Svelte historically were much closer to React. Vue has a similar VDOM and Svelte while compiled still had a rerun component model. It was only the past year about 6 years after Solid showed the way Svelte 5, and Vue Vapor got away from that and now compile down to what more or less Solid has been doing all along. Of course this is under the surface. But in many ways while Solid itself has stayed relatively small it has profoundly impacted the rest of the ecosystem in a way we haven't seen since React. From Vue, Svelte, to Angular, Preact, and Qwik all using Signals now. The average user of these frameworks probably has no idea but everyday all the non-React frameworks work more and more like Solid.
I love Svelte, but you are absolutely right about Solid's influence. Svelte's Signals implementation seems very performant compared to other Signals-based frameworks. [0]
SolijS is just JS without much magic. It's simple, small and very fast.
You can use signals and effects outside of components and it just works. You can even use a signal from the global scope within a component. Tracking of signals for effects and derived values is automatic. It looks very similar to React, but it's better in every way. Honestly the first time I'm happy with this kind of library. Don't need much more.
Edit: As for Svelte: like it too, but at least before Svelte 5 there were some footguns and differences between components and "normal" JS code. I haven't tried Svelte 5 yet, only watched some videos. From the looks of it would consider it as a good alternative.
Yes, Solid is very fast, but Svelte's Signals implementation seems to be even more performant. [0]
I just loved the simplicity of using $: for deriveds and effects in Svelte 3 and 4. But after building a correlation matrix [1] and a work project with Svelte 5, I have to say that I really like it.
To be fair by that metric Vue has the fastest now with its core built with Alien Signals. Raw reactivity benchmarks don't actually show very much because these systems are so fast that the quickest to the slowest reactive library doesn't even make a dent on a test that says render the DOM. And I say this as a benchmark enthusiast (and as that benchmark actually was crated by Milo from the SolidJS core team as part of our 2.0 research)
That's good to know, thanks! Alien Signals is such a great name.
Thanks for the info. I’ll definitely check Svelte 5 out.
I've tried both and I much prefer Solid. The key advantage for me is that it's just JS/JSX -- you can use it in both your UI code and JS utility functions and it works everywhere. Svelte seems a lot more magical; your UI code is in a special language that looks different and works differently from JS utility functions.
Edit to add: if you dislike JSX I'd guess you would probably prefer Svelte over Solid.
I would not necessarily. It depends.
They are pretty close in mindset (how state works), but Svelte is more established, better polished, has better docs, with a larger community, and of course, great animation / transition support. Svelte 5 does not have dev tools at the time of this writing, just like Solid. SFC is great, Solid has no comparable offering. It also has robust error handling, better than Solid.
That said, Solid has a way better Tanstack Query implementation. (No idea why we still don't have a proper Svelte 5 version today.) It is reasonably close to React that you may feel it should be easy to switch – though that is deceptive. Most of the work is not in the templates but in how the state works, and for this reason it is easier to port Solid code to Svelte or Vue than to React. Developing in Solid is smoother, because it is not a custom template, but just TypeScript. Less concepts to learn, if you are well versed in React.
Both can be good choices for different use cases. And then sometimes React is the right choice.
so i managed to convince my company to try solid on a new project, pretty much on the basis of "this looks like react but solves many of our existing problems with react". since the JSX and project structure is basically the same, we could take our (pretty tiny at the time) demo project and do a 1:1 diff and show the differences inline. and it was pretty compelling! the code was simpler, and faster, and we still got to keep lots of the unique patterns/other stuff we were used to when creating react apps
I haven't used Solid yet, but it is commonly said to have "fine-grained" reactivity, compared to React, and better performance.
I also think that Svelte, having a compiler, seems like that it would have an edge in theory.
[dead]
As with nutritional products, I feel that every JavaScript framework of library should have a 'Best before' date stamped on it somewhere. I apologize for the snark, but as an outsider to the JS ecosystem it really looks like a jungle from the Cretaceous period.
I think it's kinda wild how much more fun I have with Solid after slogging through React stuff all day - you think tech like this actually stays small by design or is it just hard to get people to switch?
It's likely that your React codebase is huge (I assume it's for work) and you're messing around with a toy Solid project. I'm sure once you get to the same scale and complexity of a Solid project, you'd feel the same way about whatever next framework you find
The frameworks never care to show about what the debugging experience is like. When my code fails in an unusual way (or usual) way, am I going to have to crawl up the ass of some framework? Will I be knee deep in some crazy stack race that was run from an event loop, that hides my original event or action and forces me to retreat back to the stone ages of console.log statements? Do sourcemaps even work? Hell, have you even tried to debug your own thing? What's that like?
This is a genuine question: is the main advantage of Solid over React that it's faster?
To me, no. It’s in the developer experience where Solid really shines.
React has to maintain a virtual DOM, which slows it down.
The annoying thing about solid coming from react is that every prop for every component needs to be a function that returns a value instead of just a value, otherwise that prop can never be updated.
That's not quite right! I made the same mistake in a Solid project.
The deal is that your `props` parameter is reactive. If you use `props.x`, and the value of `x` later changes, that bit of your component will update.
The catch is that you have to access it via `props` -- if you extract it, e.g. "const { x } = props", subsequent uses of `x` aren't reactive. Sometimes that's actually what you want, sometimes not.
Like you, I ended up turning lots of props into accessor functions -- `props.x()` -- so it's clear exactly when they're being used. This isn't necessary if you're careful to access via `props` and not extract fields prematurely. But sometimes I like being explicit about it, so I still sometimes use function props.
Thank you for correcting this. I was going to come and respond when I saw this earlier but hadn't had a chance. Yes the annoying part is not being able to destructure but you definitely don't have to (and it isn't our recommendation) to pass accessor functions down as props. I wrote an article on our perspective here: https://dev.to/this-is-learning/thinking-locally-with-signal...
i'm personally a fan of ivi-js.
it has blindingly fast perf (edges out Solid by a bit), top-down data flow, with fine-grained diffing, tagged template syntax, real closure state without rules-of-hooks weirdness and waste, super efficient mem use, and no special reactive primitives like signals/observables/proxies to get that performance, so you could use it with complex serialized/able state over wire (which is not something you can do with reactive primitives).
svelte is far far superior to this. Instead of the verbose JSX or whatever that weird syntax is called, you literally write plain HTML in svelte and feels absolutely natural to do so
Funny. To me JSX is a much superior language compared to HTML templating. And I would say it's provably so. You can do JSX-in-JS-in-JSX recursively in a way that is "natural" and "safe" and "maintainable". And with TypeScript you get great IDE support, ability to refactor and whatnot.
No need to trust my word, just look at the huge amount of code in JSX that the world is maintaining at the moment.
I would say the only problem is the performance cost that we have to pay for this - the shadow DOM and (as a result) the hooks mess that we have in React. But it feels more like a problem that needs to be solved in order to use the much superior way of writing code (JSX). Not the other way around (sacrifice JSX for performance)
And I get that it can be overwhelming if you still haven't made the "jump", it just doesn't sound fair to criticize something that you don't understand.
JSX is a huge conceptual mistake, IMO.
Sure, it gives you expressiveness, flexibility, and templating for "free", but this comes at the expense of the separation of concerns principle, which is a bad tradeoff.
HTML is concerned with the content and structure of the page. JS is concerned with behaviour and interactivity. Using JS, or any programming language for that matter, to control how HTML is rendered introduces reasoning problems about the content and structure that just wouldn't exist if you wrote plain HTML. Yes, modern web pages are almost always dynamic, but the correct way of implementing this is via the data model, or an intermediate controller layer.
That is, JSX enables the programmer to violate the MVC/MVVM model, which is a far superior approach of building applications.
I can't count the number of times where I've stared at a JSX file and had no idea what the "component" was actually doing. Reviewing any changes to it is practically impossible because you need to keep all the layers in mind, and essentially interpret the logic and rendering in your head.
This just doesn't happen with the MVC/MVVM approach. Every layer has a specific concern, and you can clearly trace the data flow, from when the data is read, to how it's used and manipulated, to how it's finally rendered. This is a major win for building maintainable applications, and disregarding this has made frontend web development an absolute hell.
It gets even worse when CSS can be written in JS as well... This "everything in JS" trend is an abomination.
Svelte does the right thing here and at least conceptually separates the layers, but at the end of the day, you're still writing in a DSL that gets compiled into JS, which has its own quirks and issues.
The frontend industry needs a hard reset that takes us away from this gigantic pile of abstractions and back to using native web technologies, which are quite capable on their own by now. Recently I've found Nue and Datastar to be the much needed steps in the right direction.
Well, I guess personal preference is also a thing. But I would say that the "market" doesn't agree with your thoughts on the matter (and I don't also, but my opinion matters way less).
You can write MVVM as an unmaintainable mess also. From my experience as a freelancer, I have had much harder time fixing badly written Angular projects (all versions) than such written in React. It seems that people as a whole tend to produce much better React than any other UI code that I have encountered ever. (and I have done my share of Desktop/Mobile too). Flutter is great, but it's also practically React in a proper language.
> I would say that the "market" doesn't agree with your thoughts on the matter
I'm well aware. :) But it wouldn't be the first time that large-scale groupthink has led an industry or society in the wrong direction.
The problem is that there is now an entire generation or two of frontend developers who are "senior" based on years of experience who have only known web development post-React. They're not really aware of working with anything other than a framework, what these frameworks and libraries initially set out to solve, whether those same problems still exist today, or what is possible with modern native web technologies. They in turn go on to invent new frameworks and libraries to address some of the shortcomings of what they're used to working with, but without considering the possibility that these massive frameworks might not be needed at all. This is why we need developers with experience in the early days of the web, those with different backgrounds, and those who are willing to rethink the modern approach from first principles, to guide the industry towards saner development environments, and more maintainable and performant projects.
Datastar, for example, takes a radically different approach, and while I can't say whether it's the right one for every project, the results speak for themselves. It powers projects that would be a nightmare to build, if not outright impossible, with any other framework, with incredible performance, all with a tiny fraction of code and complexity. It's not that Datastar is somehow magical—the author simply took a step back and used technologies that already exist, which no one else thought to put together in the same way.
> You can write MVVM as an unmaintainable mess also.
I don't disagree, but it's much harder to do than with most mainstream frontend frameworks. JSX by definition mixes different concerns, and leaves the door open to not care about this separation at all. The only unit of organization in a modern frontend framework is a "component"; a concept so nebulous to be practically useless. When everything is a component, nothing is, and you might as well not use it at all[1]. The only reason we do, is because we want to avoid code duplication. That on its own doesn't encourage designing applications with a sane structure in mind, and doesn't emphasize the idea that using different layers with separate concerns helps with reasoning and long-term maintainability. These are not novel ideas, mind you. They've existed for decades, yet after React we collectively decided to throw them out the window.
IMO frontend web development peaked around 2010 with Knockout.js. It provided just the right amount of abstraction to allow us to build highly interactive web apps without the maintenance problems of jQuery, and without the insanity of JSX, virtual DOM, diffing, reconciliation, SSR, bloat and supply chain vulnerability issues of incomprehensibly large dependency trees, etc.
[1]: You can see this confusion here[2]. They suggest separating components into "container" (or "controller") and "presentation" components, but then confusingly also say: "[container components] may contain both presentational and container components* inside", and that double asterisk is never addressed... Huh?
In practice, in all the React and Vue projects I've worked on (which admittedly isn't many; I don't consider myself a frontend developer), I've never seen this separation being followed, and components end up being a dumping ground for loosely-related content, behavior and style of things that exist on the screen.
Turns out that even the 2015 Dan Abramov article they link to[3] has an update from 2019 where he backtracks the separation suggestion. Wat. "Hooks" are supposed to be the modern solution... Yeah, sure, I'll trust you _now_, Dan.
But wait, actually, "signals" are the modern _modern_ solution![4] JFC, this is like a carousel from hell...
[2]: https://handsonreact.com/docs/component-architecture#contain...
[3]: https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
[4]: https://javascript.plainenglish.io/signals-a-performant-alte...
Well, you can be a purist, or you can be practical. I write code, users run it, I get paid... While you are fixing the "modern web technologies". And I give you this, things are getting much better and I hope one day we'll run JSX natively in the browser without a build step ;)
And no, knockout.js is not better than React :)
I totally agree about Svelte and the benefits of layer separation. I would say that philosophically, Svelte not only separates the layers, but gives HTML a special place among them, calling it "The Mother Language". [0]
Will check out Nue and Datastar.
I agree that JSX is a mistake, but I disagree with the "separation of concerns" part. The "separation" is useful when we know that separate people are going to be editing and changing the presentation versus the UI code. A bit like the .obc vs .h vs .nib files of older MacOS versions - you can carefully edit the .nib, and with any luck you don't want to touch the "actual" code.
But for most modern SPA UIs, this is actually less useful - because what you output into the DOM and the behavior are so intertwined. With setups like HTMX, for example, easily half of your HTML attributes can be interactivity-related. Yes, someone may be editing those separately - but they hardly will be able to edit them without any care for preserving the attributes, preserving the correct nesting the template needs to support the UI code, and on and on.
Hosting a "component" together with everything it needs to render inside one file is actually very handy, 90% of the time.
Where JSX is an issue is in the language department. The single reason we were forced onto the Webpack bandwagon - with all the years of endless tweaking, debugging and suffering that followed - was JSX, as you would have to jump through hoops to use React without the foreign syntax. A default React component was not valid JS, point.
So - expressing the DOM imperatively inside the component is fine. Shoehorning a syntax (which also requires workarounds like `className`) into another syntax and then requiring a preprocessor just for your code to work is... meh.
> practically impossible because you need to keep all the layers in mind…
> …with the MVC/MVVM approach. Every layer has a specific concern…
Do we need to keep all the layers in mind, or not?
Separation-of-concerns is not a virtue. It’s a trade off between separation-of-concerns and locality-of-behavior. SoC can be a benefit, if it matches your team structure. But also, any abstraction has a cost of increased cognitive load (and even worse is premature, wrong abstractions).
If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way (and in a small team, there’s almost no room for that to happen).
I can’t prove this obviously, but if I were betting, I’d expect more businesses have failed due to lack of velocity from over-engineered SoC apps, while the LoB monolith that’s easy for a small team to reason about found the right abstractions and won the market share (and later got rewritten as a SoC app, e.g. Instagram).
> Do we need to keep all the layers in mind, or not?
With MVC/MVVM? Yes, but not all at once. That is, you focus on one layer at a time. You think about its inputs and outputs, and how it interacts with other layers. Then you follow the data to the next layer, and so on.
With JSX, or any project that disregards SoC, you're forced to think about all layers at once. You have to think about how the JS processes the data, and at the same time how this impacts the content and final rendering.
It would be like if on the backend you would mix business logic and data processing layers, or more accurately, put business logic AND your views inside your database. There are developers who don't mind or even argue for this approach, but most developers would agree that this is an insane way to build applications. Yet on the frontend, for some reason, everyone is fine with this.
To give a concrete example, take a look at this page from the React docs[1]. Ask yourself this: what is the structure of the page at any point in time? Is any component modifying data? What happens if it does? What happens if a component renders a structure that is incompatible with other components?
This is a trivial example, so some of the answers are evident, but in a real-world application these and many other questions are very difficult to answer. Especially by staring at the code during a review. I've found that the only reliable way to review code in a modern frontend framework is to run it locally, see what the behavior and rendering is, and correlate that with the changes. And, of course, since there is usually a complete disregard for UI and E2E testing of any kind, this process is error-prone and regressions are common.
> It’s a trade off between separation-of-concerns and locality-of-behavior.
These are often seen as opposing principles, but it's possible to have both. A single HTML file can contain HTML, JS and CSS. Each section has a single concern, but would you argue that LoB isn't preserved?
> any abstraction has a cost of increased cognitive load
None of these principles or models are abstractions. They're design patterns that suggest a certain way of thinking about and organizing an application that makes reasoning about it and maintenance easier.
> If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way
Again, SoC is not about putting things in different files. It's about a logical separation between different parts of the codebase. Whether that happens in a single file or multiple is up to the team to decide.
Yes, it feels super natural, which is actually a good way to describe Svelte's overall DX. Part of the reason it feels so natural in relation to HTML is that Svelte treats it as "The Mother Language". [0]
Btw, you can use Solid without JSX and any build steps: https://www.solidjs.com/guides/getting-started#buildless-opt...
Svelte is fun
Yes, Svelte's DX is just great.
Solid has a different take (from React) on how to tackle application state. I love this. It is refreshingly simple. (Look ma, no keys! Deep state! No reducer!)
Yet, it is unpolished. It commandeers not only the `use`, but also the `create` prefix for no apparent reason. (We understand it works differently from React, but still... this just adds friction when porting.)
The community is unhelpful. Questions go unanswered. The docs are lacking. Dev tools are alpha / unusable. Every update happens in sync, so you get odd errors that React devs are not familiar with. Some parts of the API must be avoided, but you have to learn this the hard way: Suspense (don't ever introduce this and you'll be fine), createUniqueId (not very unique, not configurable), SolidStart routing (occasionally very slow, no workaround, no support).
Expect rough edges. Not a good fit for all teams. For a small team of experienced devs it can be a great DX improvement though.
Comment was deleted :(
Is there equvalent to SvelteKit for Solidjs?
Yes, what you're looking for is SolidStart (https://start.solidjs.com/)
Comment was deleted :(
Has anyone used both Solid and Vue? How do the two compare?
If you want to compare Solid to Vue, I think it is easier to just compare React to Vue. If you like React better, then you can compare React to Solid and see which you prefer. SolidJs is 90% similar to React in terms of DX, with only a coupler major differences.
Things the same as React in Solid: function-based components with hooks, JSX, overall "JS-first" (vs Vue which I'd describe as "HTML first")
Things different from React in Solid: "signals" instead of state (observer pattern), built-in components for rendering control flow (<Show />, <For />, etc), direct manipulation of the DOM. All these differences combine to the overall main difference, which is that React kinda revolves around an immutable re-render cycle where a function is re-run in its entirety to create a new vDOM representation each time, while Solid renders a component once then only selectively re-reruns parts of the component / mutates the DOM.
So I'd say pretty much the only similarity between Vue and Solid (contrasted with React) is the built-in components for control flow. Everything else is the same differences or similarities that Vue has with React.
I disagree, both Vue and SolidJS share the same underlying signal mechanism. Vue hides it a bit more, and has different default primitives, but they're both doing essentially the same thing under the hood. In both, you can think of a component as an entity that exists continuously for as long as it is mounted, and connects sources (i.e. signals) to outputs (i.e. HTML values).
React, on the other hand, is very much focused around the `UI = f(state)` paradigm, where the `f` (i.e. the component/render function) gets called afresh every time the state changes. You can avoid that somewhat via memoisation etc, but this is conceptually an optimisation rather than how the framework works.
The JSX vs SFC aspect is still significant, and SolidJS definitely tries to use some of the affordances that React developed initially. But the core idea in the framework is much closer to Vue than to React.
One interesting benefit React's tree + diffing system is that you can use a custom reconciler to do more than just create and update DOM nodes.
And a good example of that are React libraries that turn stateful imperative APIs into declarative nodes:
It isn't necessary. Solid has a similar custom renderer, with Pixi, three.js, terminal, etc... integrations. Solid is actually used a lot in embedded applications since it is low memory and performant. It powers Comcast's TV application applications like Peacock.
Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime.
Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new files with boilerplate. But the boilerplate also provides some standardisation which might be useful for larger teams.
Vue has a much larger ecosystem. Partly that's about pre-built components and utilities, but it's easy enough to build things yourself in both frameworks, and SolidJS in particular makes it very easy to incorporate vanilla JS libraries when necessary. However, if you've got a weird setup, it's more likely that someone in the Vue ecosystem has tried out that setup before and either documented it or raised all the necessary bug tickets to get it working.
Personally, I really like SolidJS - it's pretty small, it's very simple to understand once you've got your head around signals, and it scales up well from single interactive elements on a page to complicated applications. (Specifically: one project I work on at the moment is an Excel-esque application where SolidJS handles both the UI and the underlying reactivity of the application. I have only needed to think about performance in a couple of cases, the vast majority of the time, SolidJS can handle hundreds of thousands of cells without issues.)
That said, if you're working with newer developers or on a larger team, or if you're new to web development yourself, I'd probably recommend Vue just because there's so many more resources out there for it.
> Vue uses single-file components, SolidJS uses JSX.
You can use Vue and JSX, it's mentioned on the official site:
That's true, but it's not usually recommended for most cases. You lose out on a number of optimisations, and I don't believe it'll be directly supported for vapor mode when that comes, although it looks like there's a plugin that will get them to play nicer with each other.
If you want JSX and signals, I suspect you'll get more out of just using SolidJS, as that framework is focused on working well with JSX directly.
As someone that likes Vue and prefers templates that lost me at JSX.
Which is of course entirely a matter of preference.
Yeah, I've heard a few people say that. Tbh, I think that (plus a few philosophical approaches) is probably the biggest difference between the two frameworks at this point. Both use signals, both use an optimising template compiler, but in one you write the templates as JSX and in the other you write the templates as SFCs.
Can I ask why you prefer SFCs to JSX?
> As someone that likes Vue and prefers templates that lost me at JSX.
Thank you very much. I once said, "I cannot stand JSX", and two front-end engineers went silent for the rest of the meeting.
Vue is my framework of choice but currently working on a project with SolidJS. It's fine. To me it feels like React with the most objectionable parts removed. I haven't found too many painful bits, though there are some odd gotchas about destrecturing params losing reactivity.
So is Solid kind of like React but easier to use?
From my modest understanding it turns how you use hooks on its head. React will run the functional component to render each time state updates, and you need hooks to cache and sync things (eg useCallback, useMemo, useEffect). Solid is the opposite I think, it executes only once, and you use hooks to set up bindings which run updates on the component.
Solid is fundamentally different from React - it compiles reactive primitives to direct DOM updates with no virtual DOM or re-rendering, whereas React re-renders components when state changes.
Solid js does basically the same thing as React (building UIs for websites) but the architecture and primitives are slightly different.
That has been my experience.
[dead]
very few apps actually need reactivity.
Every app with state can benefit from reactivity. There are tradeoffs, that's for sure.
A shockingly underrated statement these days. Couldn't agree more.
I'm not sure how that's relevant to this post?
[dead]
[dead]
[dead]
[dead]
Nice, but Mikado is faster
Here the creator of Solid compares it to Mikado: https://github.com/solidjs/solid/discussions/485
Deleight is faster than Mikado.
https://krausest.github.io/js-framework-benchmark/current.ht...
...when SolidJS isn't niche enough!
Performance is not necessarily worth maxing at all costs.
Is that project even maintained still? GitHub looks...quiet.
Crafted by Rajat
Source Code