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.
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'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.
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 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.
So solid didn't solve one of the biggest problems you have but you like it. It's fine that you like it and the philosophy, but can you expand on "I ended up writing my own virtual DOM diffing code, a primary facet of React"? It's like saying I like Solid but I had to roll my own on what React does best and it's not very convincing... Easy to circumvent something makes no sense when you could have chosen something else that does it out of the box?
For all we care React could solve 70% of these problems 2 years later. Or maybe another project that's entirely React compatible and perfect migration is facilitated by AI will come up.
You literally said AI is more compatible with React as a counterpoint to using Solid? I think not using something because AI is good at is a good thing for humanity, but what are you talking about in terms of an argument for Solid.
Nobody cares.
I mean well.
I don't mean to offend you and I think Infumap is cool, but I think for the reasons above you need to be more mindful about what you say. Don't try to please everyone -- most people don't care and the people who are most loyal to you don't care. Nobody cares what Infumap is built with: they care about what Infumap does for them and WHY you built it. The what is irrelevant.
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
It's extremely frustrating these days when someone makes any claims about sizes/scale without providing actual numbers.
Your "largish" could be 10000 daily active users, which is my medium, and small for someone else.
Or maybe your "largish" is 1000000 for a site with mostly static, cachable parts, but the the same people were to build the same thing for a different audience that require a lot of interactivity and things that are different to say they wouldn't make the same claims.
What are you doing and what is the HN community doing.
Sure, React has its own problems and I choose not to use it outside of my job now. But if you're to convince someone else that something is worth switching to in terms of TECHNOLOGY, we need more than feels, vibes, and anecdotes.
It's not that I think you're right or wrong. However, if you are going to go out of your way to make a technical comment to make the world better place (I hope that's what you want to do), it requires more than a 2007 effort for people who care enough to make a difference now: otherwise you're just another person defending what they like most without any real data.
Don't forget that anyone who has any real experience as a software engineer knows that every day is about making trade-offs. Think deeply about what why I say this and what this means. If you don't know why, I hope you will find out or you will stop sprouting cult-like nonsense until you know why.
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.
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.
> 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...
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>
}
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.
> 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'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.
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!
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.
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.
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.
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.
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).
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.
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.
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.
I use React for work but I don't like React probably for the same reasons you don't.
But like... can we stop having these reasonabe takes that's like "I like this better but oh no I need to remind you that in the real world it's tough until it's get real traction but I like it anyway" kind of argument?
Just say what you like and what you don't like and be done with it.
Nobody gives a damn about what you like what you don't like.
But everyone will give a damn about your opinions that consistently make their lives better.
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.
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.
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.
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 ;)
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).
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.
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 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.
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.
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.
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'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.
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
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 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.
So solid didn't solve one of the biggest problems you have but you like it. It's fine that you like it and the philosophy, but can you expand on "I ended up writing my own virtual DOM diffing code, a primary facet of React"? It's like saying I like Solid but I had to roll my own on what React does best and it's not very convincing... Easy to circumvent something makes no sense when you could have chosen something else that does it out of the box?
For all we care React could solve 70% of these problems 2 years later. Or maybe another project that's entirely React compatible and perfect migration is facilitated by AI will come up.
You literally said AI is more compatible with React as a counterpoint to using Solid? I think not using something because AI is good at is a good thing for humanity, but what are you talking about in terms of an argument for Solid.
Nobody cares.
I mean well.
I don't mean to offend you and I think Infumap is cool, but I think for the reasons above you need to be more mindful about what you say. Don't try to please everyone -- most people don't care and the people who are most loyal to you don't care. Nobody cares what Infumap is built with: they care about what Infumap does for them and WHY you built it. The what is irrelevant.
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
It's extremely frustrating these days when someone makes any claims about sizes/scale without providing actual numbers.
Your "largish" could be 10000 daily active users, which is my medium, and small for someone else.
Or maybe your "largish" is 1000000 for a site with mostly static, cachable parts, but the the same people were to build the same thing for a different audience that require a lot of interactivity and things that are different to say they wouldn't make the same claims.
What are you doing and what is the HN community doing.
Sure, React has its own problems and I choose not to use it outside of my job now. But if you're to convince someone else that something is worth switching to in terms of TECHNOLOGY, we need more than feels, vibes, and anecdotes.
It's not that I think you're right or wrong. However, if you are going to go out of your way to make a technical comment to make the world better place (I hope that's what you want to do), it requires more than a 2007 effort for people who care enough to make a difference now: otherwise you're just another person defending what they like most without any real data.
Don't forget that anyone who has any real experience as a software engineer knows that every day is about making trade-offs. Think deeply about what why I say this and what this means. If you don't know why, I hope you will find out or you will stop sprouting cult-like nonsense until you know why.
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.
> 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...
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:
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.
You can just use styled-conponents on React.
It’s officially deprecated.
See: https://opencollective.com/styled-components/updates/thank-y...
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.
> 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.
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!
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.
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.
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.
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...
https://www.youtube.com/watch?v=Z1dd09rxny4
Amy thoughts on AlpineJS or RiotJS in this same realm?
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.
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.
Ok, you've got my attention with documentation like this
const [first, setFirst] = createSignal("JSON");
const [last, setLast] = createSignal("Bourne");
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.
I use React for work but I don't like React probably for the same reasons you don't.
But like... can we stop having these reasonabe takes that's like "I like this better but oh no I need to remind you that in the real world it's tough until it's get real traction but I like it anyway" kind of argument?
Just say what you like and what you don't like and be done with it.
Nobody gives a damn about what you like what you don't like.
But everyone will give a damn about your opinions that consistently make their lives better.
So stop these "reasonable take" stuff ffs.
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
Svelte is fun
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.
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.
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 ;)
https://github.com/solidjs/solid/discussions/2425
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).
https://github.com/localvoid/ivi
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.
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.
As someone that likes Vue and prefers templates that lost me at JSX.
Which is of course entirely a matter of preference.
> 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?
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.
very few apps actually need reactivity.
A shockingly underrated statement these days. Couldn't agree more.
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.