11 ms·
Solidjs: Simple and performant reactivity for building user interfaces
- morcus 1y agoI'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 1y agoLooks 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 https://github.com/solidjs/solid/discussions/2425
- vaporwarex 1y ago[flagged]
- mightyham 1y agoHaving 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 1y ago> 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 1y ago> 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 1y agoNot 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 1y agoI'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 1y agoCool. 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
- zamalek 1y agoReact 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.
- gawrkura00 1y ago[dead]
- hombre_fatal 1y agoI 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 1y agoVery 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 1y agoOne of the best responses I have read on this topic. Thank you
- TimTheTinker 1y agoIt'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.)
- sensiblecarrot7 1y ago[flagged]
- lelanthran 1y agoWhat 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?
- math 1y agoI'm using SolidJS for Infumap (https://github.com/infumap/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.
- sensiblecarrot7 1y ago[flagged]
- Philpax 1y agoYour 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.
- math 1y agoI was not expecting to loose karma for this comment! I have a couple of years familiarity with SolidJS and thought the two key insights that came to mind from building a large project in it would have positive value. Apparently not!
- steve_adams_86 1y agoIs 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 1y agoLooking for this? https://docs.solidjs.com/reference/components/suspense https://docs.solidjs.com/reference/components/suspense
- steve_adams_86 1y agoHa! I’ve used this, too. I guess I’ve reached the senility phase of my mid life. Thanks for pointing me to that
- ryansolid 1y agoI'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 1y agoWow, 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 1y agoI'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.
- sveinnthorarins 1y ago[dead]
- hinkley 1y agoReact 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.
- thomasfromcdnjs 1y agoPortions 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 1y ago> 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 1y agoDon'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...
- deleted 1y ago[deleted]
- qudat 1y agoHard 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.
- snshn 1y agoNice, but Mikado is faster
- __float 1y agoPerformance is not necessarily worth maxing at all costs. Is that project even maintained still? GitHub looks...quiet.
- esafak 1y ago...when SolidJS isn't niche enough!
- henpa 1y agoHere the creator of Solid compares it to Mikado: https://github.com/solidjs/solid/discussions/485 https://github.com/solidjs/solid/discussions/485
- bufferoverflow 1y agoDeleight is faster than Mikado. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- deleted 1y ago[deleted]
- GolDDranks 1y agoAt 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-reactivity-4lk4 https://dev.to/ryansolid/marko-compiling-fine-grained-reacti... https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d https://dev.to/this-is-learning/marko-for-sites-solid-for-ap... https://www.youtube.com/watch?v=Z1dd09rxny4 https://www.youtube.com/watch?v=Z1dd09rxny4
- voat 1y agoI'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 1y agoSo is Solid kind of like React but easier to use?
- voat 1y agoSolid js does basically the same thing as React (building UIs for websites) but the architecture and primitives are slightly different.
- ethan_smith 1y agoSolid 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 1y agoThat has been my experience.
- gawrkura00 1y ago[dead]
- dsego 1y agoFrom 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 1y agoi'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 https://github.com/localvoid/ivi
- zuck_vs_musk 1y agoHas anyone used both Solid and Vue? How do the two compare?
- fastball 1y agoIf 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 1y agoOne 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://r3f.docs.pmnd.rs/getting-started/introduction - https://github.com/pixijs/pixi-react https://github.com/pixijs/pixi-react
- ryansolid 1y agoIt 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.
- rubyfan 1y agoOk, you've got my attention with documentation like this const [first, setFirst] = createSignal("JSON"); const [last, setLast] = createSignal("Bourne");
- skeptrune 1y agoI 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 1y ago> 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 1y agoLow 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 1y agoThis 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 1y ago>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.
- tzebco 1y ago[dead]
- cranberryturkey 1y agovery few apps actually need reactivity.
- spirodonfl 1y agoA shockingly underrated statement these days. Couldn't agree more.
- ivanjermakov 1y agoEvery app with state can benefit from reactivity. There are tradeoffs, that's for sure.
- jplusequalt 1y agoI'm not sure how that's relevant to this post?
- seabass 1y agoIt’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.
- sensiblecarrot7 1y ago[flagged]
- vivzkestrel 1y agosvelte 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 1y agoSvelte is fun
- division_by_0 1y agoYes, Svelte's DX is just great.
- loxs 1y agoFunny. 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 1y agoJSX 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.
- gawrkura00 1y ago[dead]
- k__ 1y agoGenuine 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.
- gawrkura00 1y ago[dead]
- GolDDranks 1y agoI 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 1y agoSolijS 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 1y agoYes, 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 https://github.com/sveltejs/svelte/discussions/13277 [1] https://covary.xyz https://covary.xyz
- notgraham0x00 1y ago[dead]
- notgraham0x00 1y ago[dead]
- unlog 1y agoSolidJS 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 1y agoI 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 1y agoIt'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 1y agoAs 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 1y agoMy 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 1y agoCan 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/ https://mui.com/x/react-data-grid/row-grouping/
- voat 1y agoMost of the modern front end frameworks can handle those use cases. Solid, Vue, Svelte all have capable SPA frameworks and component libraries
- exceptione 1y agoI don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
- erikerikson 1y agohttps://suid.io/ https://suid.io/ is MUI for SolidJs
- exceptione 1y agoThat 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 https://github.com/swordev/suid/issues/208
- only-one1701 1y agoThis is a genuine question: is the main advantage of Solid over React that it's faster?
- tripplyons 1y agoReact has to maintain a virtual DOM, which slows it down.
- seabass 1y agoTo me, no. It’s in the developer experience where Solid really shines.
- iamleppert 1y agoThe 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 1y agoThe 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 1y agoThat'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 1y agoThank 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-signals-3b7h https://dev.to/this-is-learning/thinking-locally-with-signal...
- machiaweliczny 1y agoIs there equvalent to SvelteKit for Solidjs?
- iceIX 1y agoYes, what you're looking for is SolidStart (https://start.solidjs.com/ https://start.solidjs.com/)
- deleted 1y ago[deleted]
- andraaspar 1y agoSolid has a different take (from React) on how to tackle application state. I love this. It is refreshingly simple. (Look ma, no keys! Deep state! No reducer!) Yet, it is unpolished. It commandeers not only the `use`, but also the `create` prefix for no apparent reason. (We understand it works differently from React, but still... this just adds friction when porting.) The community is unhelpful. Questions go unanswered. The docs are lacking. Dev tools are alpha / unusable. Every update happens in sync, so you get odd errors that React devs are not familiar with. Some parts of the API must be avoided, but you have to learn this the hard way: Suspense (don't ever introduce this and you'll be fine), createUniqueId (not very unique, not configurable), SolidStart routing (occasionally very slow, no workaround, no support). Expect rough edges. Not a good fit for all teams. For a small team of experienced devs it can be a great DX improvement though.