[HN Gopher] Solidjs: Simple and performant reactivity for buildi...
___________________________________________________________________
Solidjs: Simple and performant reactivity for building user
interfaces
Author : lastdong
Score : 295 points
Date : 2025-04-19 07:50 UTC (4 days ago)
(HTM) web link (www.solidjs.com)
(TXT) w3m dump (www.solidjs.com)
| mightyham wrote:
| 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.
| mpalmer wrote:
| > 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.
| dkh wrote:
| > 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?
| __s wrote:
| 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
| mightyham wrote:
| 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.
| dkh wrote:
| 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
| bpev wrote:
| 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.
| FjordWarden wrote:
| The SolidJS ecosystem is smaller but generally has more high
| quality libraries and more integrated.
|
| Take a look at Solid Primitives:
| https://primitives.solidjs.community/
| koakuma-chan wrote:
| I've used Solid Primitives and white it's great,
| unfortunately it seems pretty dead. None of the primitives
| is "4 Accepted/Shipped" and many aren't even "3 Pre-
| shipping (final effort)".
| zamalek wrote:
| 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.
| hombre_fatal wrote:
| 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.
| ericyd wrote:
| 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.
| thenewem wrote:
| One of the best responses I have read on this topic. Thank
| you
| TimTheTinker wrote:
| It's also easy to confuse problems that arise from _failing
| to adequately manage the gotchas_ with problems _inherent
| in the tool itself_. There 's a subtle distinction there
| that's easy to miss, especially for those with a blame-the-
| system sort of attitude (which I don't entirely fault).
|
| One company I worked for had a very slow frontend. It was
| common there to blame the slowness on React. "React is just
| kind of slow."
|
| Another company I worked for had a _much_ larger React-
| based frontend, and it was fast-loading and snappy by
| comparison.
|
| The difference is that the second company had much more
| well-established good practices in its design system, the
| codebase, the enforced lint checks, and the general
| knowledge of its engineers. They avoided performance traps
| that caused multiple renders of things. (The first
| company's frontend would render a given screen 12+ times
| for some state changes.)
| someotherperson wrote:
| It's not that it's way too entrenched, it's just that people
| grew tired of constantly shifting frontend frameworks.
| Personally: I really didn't care who "won" that war, I just
| wanted to have a sane well-supported default without having
| to learn a new pattern every year to store page state or
| update an icon.
| math wrote:
| 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.
| steve_adams_86 wrote:
| 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
| erikerikson wrote:
| Looking for this?
| https://docs.solidjs.com/reference/components/suspense
| ryansolid wrote:
| 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.
| mightyham wrote:
| Wow, I never imagined you would respond to my comment, a
| little embarrassed ngl :D
|
| I understand that under the hood Solid's reactive system is
| not quite simple; though, the mental model needed to use it,
| is very simple, which I greatly appreciate when building
| complex application logic on top of it. That's really my main
| concern: that one-way "push" semantics are easy to follow and
| think about, and adding new mechanics complicates that
| picture. It seems deceptive that what presents itself, at
| least conceptually, as just a value access, might now cause
| arbitrary code execution (another way of putting this is that
| it feels like it violates the principle of least
| astonishment).
|
| As I mentioned before, I also haven't run into situations in
| practice where lazy memos seem like a desirable behavior. If
| I initialize a derived value, it's because I plan to use it.
| If some computation needs to be "delayed", I place it inside
| an if statement with a reactive condition, for instance,
| createMemo(() => shouldCompute() ? computeValue() :
| undefined).
|
| All that's said, you've done a fantastic job with Solid. I
| hope you continue to innovate and prove my objections
| misguided.
| jorroll wrote:
| I'll admit that hearing that "laziness" was something being
| explored for Solid 2.0 also made me uneasy. Like the OP, in
| my case I know it's because I'm worried that it will
| complicate working with Solid state in the same way that
| React's "concurrent mode" complicates working with React
| state. Really, I just _hate_ React 's "concurrent mode" and I
| really like the simplicity of working with Solidjs' state by
| comparison (if Solidjs has a similar concept to concurrent
| mode I haven't run into it yet).
|
| All of this is to say that my own worries aren't based on any
| concrete objections, but a general fear of change since I
| like the current approach (and haven't run into any
| performance issues with it). Also, without knowing exactly
| what you plan on changing, the idea of introducing "laziness"
| seams like it could be a euphemism for "async" which feels
| like it would definitely make things more complex. Anyway,
| reading your comment makes me hopeful that my ambiguous
| unease is misplaced.
| hinkley wrote:
| React is, I am convinced, the new Struts only client side.
|
| Struts was SSR before we needed a term for SSR. It had low
| productivity so it looked like it was doing well in the
| industry because there were so goddamned many jobs. But if you
| asked people you really couldn't find many that loved it, and
| if they did it was a sign that maybe their judgment wasn't that
| great, and you were going to be disappointed if you asked
| follow-up questions about what else they thought was a good
| idea.
|
| It was killed by JSTL, which was one of the first templating
| systems to get away from <% > syntax.
| morcus wrote:
| 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?
| Sn0wCoder wrote:
| 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
| thomasfromcdnjs wrote:
| 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?
| esperent wrote:
| > 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.
| n8cpdx wrote:
| 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...
| qudat wrote:
| Hard agree. It's all complexity and for what? SEO? So many
| products don't need SEO. API proxies with secrets? These are
| not super common use cases.
|
| The default should be SPA and purely static.
| btown wrote:
| 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-...
| sophiebits wrote:
| 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.
| btown wrote:
| 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!)
| sophiebits wrote:
| 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.
| hinkley wrote:
| Sounds like you need a 14th bundled but built with some
| liveview code.
| chabska wrote:
| > 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?
| technion wrote:
| 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.
| math_dandy wrote:
| I view create-vite-app with React presets as the spiritual
| successor of create-react-app, rather than NextJS.
| johnny22 wrote:
| 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.
| mvdtnz wrote:
| Really? So class components are still first class citizens
| and play well with existing ecosystem code?
| esperent wrote:
| > 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.
| jakelazaroff wrote:
| _> 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!
| owebmaster wrote:
| > React core has been exactly the same as it was ten years
| ago
|
| Are we not considering Hooks core yet?
| voat wrote:
| 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.
| dhruvrajvanshi wrote:
| 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.
| josephg wrote:
| 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> }
| thomasfromcdnjs wrote:
| 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.
| pests wrote:
| 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.
| maxloh wrote:
| You can just use styled-conponents on React.
| const Button = styled.button<{ $primary?: boolean; }>`
| /* Adapt the colors based on primary prop */
| background: ${props => props.$primary ? "#BF4F74" : "white"};
| color: ${props => props.$primary ? "white" : "#BF4F74"};
| ... `; render( <div>
| <Button>Normal</Button> <Button
| $primary>Primary</Button> </div> );
| re-thc wrote:
| It's officially deprecated.
|
| See: https://opencollective.com/styled-
| components/updates/thank-y...
| lelanthran wrote:
| > 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.
| richrichardsson wrote:
| > 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.
| snshn wrote:
| Nice, but Mikado is faster
| __float wrote:
| Performance is not necessarily worth maxing at all costs.
|
| Is that project even maintained still? GitHub looks...quiet.
| esafak wrote:
| ...when SolidJS isn't niche enough!
| henpa wrote:
| Here the creator of Solid compares it to Mikado:
| https://github.com/solidjs/solid/discussions/485
| bufferoverflow wrote:
| Deleight is faster than Mikado.
|
| https://krausest.github.io/js-framework-benchmark/current.ht...
| GolDDranks wrote:
| 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
| edoceo wrote:
| Amy thoughts on AlpineJS or RiotJS in this same realm?
| xoxosc wrote:
| What about mizu.js?
| rasso wrote:
| Alpine.js in tandem with alpine-ajax has made me a very happy
| developer the last few years.
| voat wrote:
| 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.
| 404human wrote:
| So is Solid kind of like React but easier to use?
| voat wrote:
| Solid js does basically the same thing as React (building UIs
| for websites) but the architecture and primitives are slightly
| different.
| ethan_smith wrote:
| 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.
| stevage wrote:
| That has been my experience.
| dsego wrote:
| 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.
| leeoniya wrote:
| 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
| zuck_vs_musk wrote:
| Has anyone used both Solid and Vue? How do the two compare?
| fastball wrote:
| 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.
| hombre_fatal wrote:
| 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
| ryansolid wrote:
| It isn't necessary. Solid has a similar custom renderer,
| with Pixi, three.js, terminal, etc... integrations. Solid
| is actually used a lot in embedded applications since it is
| low memory and performant. It powers Comcast's TV
| application applications like Peacock.
| MrJohz wrote:
| 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.
| stevage wrote:
| 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.
| MrJohz wrote:
| 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.
| conradfr wrote:
| As someone that likes Vue and prefers templates that lost me
| at JSX.
|
| Which is of course entirely a matter of preference.
| zuck_vs_musk wrote:
| > 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.
| MrJohz wrote:
| 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?
| seanwilson wrote:
| > Vue uses single-file components, SolidJS uses JSX.
|
| You can use Vue and JSX, it's mentioned on the official site:
|
| https://vuejs.org/guide/extras/render-function
| MrJohz wrote:
| That's true, but it's not usually recommended for most
| cases. You lose out on a number of optimisations, and I
| don't believe it'll be directly supported for vapor mode
| when that comes, although it looks like there's a plugin
| that will get them to play nicer with each other.
|
| If you want JSX and signals, I suspect you'll get more out
| of just using SolidJS, as that framework is focused on
| working well with JSX directly.
| rubyfan wrote:
| Ok, you've got my attention with documentation like this
|
| const [first, setFirst] = createSignal("JSON");
|
| const [last, setLast] = createSignal("Bourne");
| skeptrune wrote:
| 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.
| afro88 wrote:
| > 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?
| skeptrune wrote:
| 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.
| smt88 wrote:
| 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.
| skeptrune wrote:
| >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.
| ryansolid wrote:
| 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.
| hasperdi wrote:
| 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.
| skeptrune wrote:
| > 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.
| ryansolid wrote:
| 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.
| freeamz wrote:
| What about hono client side? Seems to have most React
| functionalities:
|
| https://hono.dev/docs/guides/jsx-dom ?
| cranberryturkey wrote:
| very few apps actually need reactivity.
| spirodonfl wrote:
| A shockingly underrated statement these days. Couldn't agree
| more.
| ivanjermakov wrote:
| Every app with state can benefit from reactivity. There are
| tradeoffs, that's for sure.
| jplusequalt wrote:
| I'm not sure how that's relevant to this post?
| seabass wrote:
| 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.
| vivzkestrel wrote:
| 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
| shhhhhplease wrote:
| Svelte is fun
| division_by_0 wrote:
| Yes, Svelte's DX is just great.
| loxs wrote:
| 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.
| imiric wrote:
| 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.
| division_by_0 wrote:
| 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
| loxs wrote:
| 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.
| imiric wrote:
| > 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...
| loxs wrote:
| Well, you can be a purist, or you can be practical. I
| write code, users run it, I get paid... While you are
| fixing the "modern web technologies". And I give you
| this, things are getting much better and I hope one day
| we'll run JSX natively in the browser without a build
| step ;)
|
| And no, knockout.js is not better than React :)
| julik wrote:
| I agree that JSX is a mistake, but I disagree with the
| "separation of concerns" part. The "separation" is useful
| when we know that separate people are going to be editing
| and changing the presentation versus the UI code. A bit
| like the .obc vs .h vs .nib files of older MacOS versions -
| you can carefully edit the .nib, and with any luck you
| don't want to touch the "actual" code.
|
| But for most modern SPA UIs, this is actually less useful -
| because what you output into the DOM and the behavior are
| so intertwined. With setups like HTMX, for example, easily
| half of your HTML attributes can be interactivity-related.
| Yes, someone may be editing those separately - but they
| hardly will be able to edit them without any care for
| preserving the attributes, preserving the correct nesting
| the template needs to support the UI code, and on and on.
|
| Hosting a "component" together with everything it needs to
| render inside one file is actually very handy, 90% of the
| time.
|
| Where JSX is an issue is in the language department. The
| single reason we were forced onto the Webpack bandwagon -
| with all the years of endless tweaking, debugging and
| suffering that followed - was JSX, as you would have to
| jump through hoops to use React without the foreign syntax.
| A default React component was not valid JS, point.
|
| So - expressing the DOM imperatively inside the component
| is fine. Shoehorning a syntax (which also requires
| workarounds like `className`) into another syntax and then
| requiring a preprocessor just for your code to work is...
| meh.
| ivanjermakov wrote:
| Btw, you can use Solid without JSX and any build steps:
| https://www.solidjs.com/guides/getting-started#buildless-opt...
| division_by_0 wrote:
| 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
| k__ wrote:
| 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.
| GolDDranks wrote:
| 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.
| ManBeardPc wrote:
| 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.
| division_by_0 wrote:
| 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
| ManBeardPc wrote:
| Thanks for the info. I'll definitely check Svelte 5 out.
| ryansolid wrote:
| To be fair by that metric Vue has the fastest now with its
| core built with Alien Signals. Raw reactivity benchmarks
| don't actually show very much because these systems are so
| fast that the quickest to the slowest reactive library
| doesn't even make a dent on a test that says render the
| DOM. And I say this as a benchmark enthusiast (and as that
| benchmark actually was crated by Milo from the SolidJS core
| team as part of our 2.0 research)
| division_by_0 wrote:
| That's good to know, thanks! Alien Signals is such a
| great name.
| ryansolid wrote:
| 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.
| division_by_0 wrote:
| 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
| alloyed wrote:
| 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
| iainmerrick wrote:
| I've tried both and I much prefer Solid. The key advantage for
| me is that it's just JS/JSX -- you can use it in both your UI
| code and JS utility functions and it works everywhere. Svelte
| seems a lot more magical; your UI code is in a special language
| that looks different and works differently from JS utility
| functions.
|
| _Edit to add:_ if you dislike JSX I 'd guess you would
| probably prefer Svelte over Solid.
| unlog wrote:
| 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.
| gitroom wrote:
| 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?
| ativzzz wrote:
| It's likely that your React codebase is huge (I assume it's for
| work) and you're messing around with a toy Solid project. I'm
| sure once you get to the same scale and complexity of a Solid
| project, you'd feel the same way about whatever next framework
| you find
| pandemic_region wrote:
| 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.
| tuzemec wrote:
| 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.
| exceptione wrote:
| 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.
|
| ---
|
| 0. https://mui.com/x/react-data-grid/row-grouping/
| voat wrote:
| Most of the modern front end frameworks can handle those use
| cases.
|
| Solid, Vue, Svelte all have capable SPA frameworks and
| component libraries
| exceptione wrote:
| 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.
| fkyoureadthedoc wrote:
| 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
| exceptione wrote:
| 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.
| fkyoureadthedoc wrote:
| 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.
| exceptione wrote:
| Good to hear, thanks for sharing.
| ericyd wrote:
| 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/
| exceptione wrote:
| Thank you. I remember I had a look at that. Made a quick
| look now at PrimeVue treetable [0], to compare it to MUI
| datagrid [1].
|
| There seems to be a wide gap in feature scope and depth.
| For example, column grouping in [0] seems to be not
| available (it is in PrimeVue datagrid, but that misses
| support for data hierarchy).
|
| ___
|
| 0. https://primevue.org/treetable/
|
| 1. https://mui.com/x/react-data-grid/features/
| nartho wrote:
| If you're interested in data grids specifically, Svelte
| has https://vincjo.fr/datatables/examples/client/hello-
| world
| exceptione wrote:
| Interesting! I need hierarchical data grids indeed (but
| they also seems to be the kind of shibboleth only the
| large libraries are able to speak).
| nartho wrote:
| https://www.shadcn-svelte.com/
|
| https://www.skeleton.dev/docs/get-started/introduction
|
| https://flowbite-svelte.com/
|
| https://www.melt-ui.com/
| exceptione wrote:
| Thank you! I have skimmed them, they look pretty and feel
| fast.
|
| Unfortunately they seem not to match mui in breadth and
| depth.
| erikerikson wrote:
| https://suid.io/ is MUI for SolidJs
| exceptione wrote:
| That is really interesting, thanks for sharing. Sounds
| almost too good to be true.
|
| I saw however an open issue [0] about performance
| problems that seems to indicate that component libraries
| in Svelte suddenly becomes really slow?
| Another update. I wondered whether this was really unique
| to SUID or if other component libraries also have this
| problem. So I included Park UI and Kobalte (which seem to
| be the only other mature options besides SUID).
| Kobalte runs in ~168ms, and Park runs in ~382ms. Even
| that seems too slow to me. Is there something inherent to
| component libraries that makes them slow in Solid.js?
| (Next up, I should probably benchmark the same setup in
| other frontend frameworks.)
|
| ___
|
| 0. https://github.com/swordev/suid/issues/208
| ryansolid wrote:
| Yeah it is an interesting one. There is definitely a
| slowdown due to the amount of wrapping that happens.
| These sort of libraries tend to put component in
| component in component etc.. so there is a lot of prop
| iteration, Object.keys calls in Object.keys calls etc
| which when used with proxies can add up a bit. The tricky
| part is no one actually knows how slow these libraries
| are in say React. My suspicion they are slow there as
| well but maybe not as stark of a difference because of
| how fast Solid to begin with comparatively.
|
| People who use Solid tend to measure stuff like this
| where as those who use React might have already
| reconciled themselves to performance issues.
| jmull wrote:
| 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.
| division_by_0 wrote:
| 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.
| exceptione wrote:
| 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: data-heavy, enterprise systems,
| business software => react webshop etc, "simple"
| consumer oriented => svelte, solidjs etc
|
| Correct me if wrong.
| division_by_0 wrote:
| 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.
| exceptione wrote:
| Good point. I don't know how much of the gap remains if
| one can settle for Preactjs, but Reactjs is not the
| fastest.
| Sammi wrote:
| The reason you don't see Svelte versions of common
| libraries as much as you do for React, is that with Svelte
| you can just use the vanilla js/html/css version and they
| work great. React has a hard time using vanilla approaches
| because the virtual dom and hooks aren't vanilla and don't
| work like vanilla. React is it's own world and therefore
| needs to have a React version of everything.
| exceptione wrote:
| I think I do not completely grok that, maybe I have to
| experiment with Svelte a bit more. As GP mentioned, in
| Svelte one does not reach for third party components, so
| you might be on to something.
| hombre_fatal wrote:
| 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.
| exceptione wrote:
| 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.
| WuxiFingerHold wrote:
| Vue has a large ecosystem. A lot of very good component libs
| like PrimeVue, Vuetify, Quasar, NuxtUI, ElementUi ...
|
| I have used agGrid and eCharts with Svelte. Doesn't get any
| simpler. With Solid, Vue and Svelte you can integrate vanilla
| JS libs easily.
|
| I tend to use Svelte without component lib or DaisyUI. After
| all, those libs are technical debt. Also, the native HTML 5
| elements / browser APIs are pretty complete these days (dialog,
| popover, ...). If I was to chose one I'd probably go with Vue
| and PrimeVue.
| only-one1701 wrote:
| This is a genuine question: is the main advantage of Solid over
| React that it's faster?
| tripplyons wrote:
| React has to maintain a virtual DOM, which slows it down.
| iamleppert wrote:
| The frameworks never care to show about what the debugging
| experience is like. When my code fails in an unusual way (or
| usual) way, am I going to have to crawl up the ass of some
| framework? Will I be knee deep in some crazy stack race that was
| run from an event loop, that hides my original event or action
| and forces me to retreat back to the stone ages of console.log
| statements? Do sourcemaps even work? Hell, have you even tried to
| debug your own thing? What's that like?
| subarctic wrote:
| The annoying thing about solid coming from react is that every
| prop for every component needs to be a function that returns a
| value instead of just a value, otherwise that prop can never be
| updated.
| iainmerrick wrote:
| That's not quite right! I made the same mistake in a Solid
| project.
|
| The deal is that your `props` parameter is reactive. If you use
| `props.x`, and the value of `x` later changes, that bit of your
| component will update.
|
| The catch is that you have to access it via `props` -- if you
| extract it, e.g. "const { x } = props", subsequent uses of `x`
| aren't reactive. Sometimes that's actually what you want,
| sometimes not.
|
| Like you, I ended up turning lots of props into accessor
| functions -- `props.x()` -- so it's clear exactly when they're
| being used. This isn't necessary if you're careful to access
| via `props` and not extract fields prematurely. But sometimes I
| like being explicit about it, so I still sometimes use function
| props.
| ryansolid wrote:
| Thank you for correcting this. I was going to come and
| respond when I saw this earlier but hadn't had a chance. Yes
| the annoying part is not being able to destructure but you
| definitely don't have to (and it isn't our recommendation) to
| pass accessor functions down as props. I wrote an article on
| our perspective here: https://dev.to/this-is-
| learning/thinking-locally-with-signal...
| machiaweliczny wrote:
| Is there equvalent to SvelteKit for Solidjs?
| iceIX wrote:
| Yes, what you're looking for is SolidStart
| (https://start.solidjs.com/)
___________________________________________________________________
(page generated 2025-04-23 23:01 UTC)