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 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.
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.
> 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.
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.
> 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.
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
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>
}
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.
> 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.
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!
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.
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.
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.
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.
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,
I am not sure if that would be a win. The API of the component is actually a selling point, because the component gets used in many different ways across the application. Possibly under influence of user configuration.
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:
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.
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.
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.
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.
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.
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.
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 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?
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 ;)
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.
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
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
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]
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.
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.
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]
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...
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).
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.
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.
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.
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.
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.
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.
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 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.
One of the best responses I have read on this topic. Thank you
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.
[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.
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.
> 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
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.
[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.
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
[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?
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:
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.
> 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.
> 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.
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.
You can just use styled-conponents on React.
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.
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!
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:
---0. https://mui.com/x/react-data-grid/row-grouping/
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.
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.
Thanks. If that is the common approach in Svelte to third party components, than I learned something.
I am not sure if that would be a win. The API of the component is actually a selling point, because the component gets used in many different ways across the application. Possibly under influence of user configuration.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:
Correct me if wrong.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.
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.
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.
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.
https://primevue.org/
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.
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?
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:
https://hono.dev/docs/guides/jsx-dom ?
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.
[flagged]
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.
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.
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.
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?
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
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]
[0] https://github.com/sveltejs/svelte/discussions/13277
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.
[0] https://github.com/sveltejs/svelte/discussions/13277
[1] https://covary.xyz
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]
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
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]
[0] https://github.com/sveltejs/svelte/discussions/10085
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.
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.
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.
[0] https://github.com/sveltejs/svelte/discussions/10085
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...
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
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.
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:
- https://r3f.docs.pmnd.rs/getting-started/introduction
- https://github.com/pixijs/pixi-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.
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.
[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.