Live data from Hacker News

Solidjs: Simple and performant reactivity for building user interfaces

solidjs.com

81–90 of 190 posts

Re: Solidjs: Simple and performant reactivity for building user interfaces

#81
post #76

Genuine question: Why would you use Solid instead of Svelte? I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.

SolijS is just JS without much magic. It's simple, small and very fast.

You can use signals and effects outside of components and it just works. You can even use a signal from the global scope within a component. Tracking of signals for effects and derived values is automatic. It looks very similar to React, but it's better in every way. Honestly the first time I'm happy with this kind of library. Don't need much more.

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#82

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…

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…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#83
post #69

svelte is far far superior to this. Instead of the verbose JSX or whatever that weird syntax is called, you literally write plain HTML in svelte and feels absolutely natural to do so

Funny. To me JSX is a much superior language compared to HTML templating. And I would say it's provably so. You can do JSX-in-JS-in-JSX recursively in a way that is "natural" and "safe" and "maintainable". And with TypeScript you get great IDE support, ability to refactor and whatnot. No need to trust my word, just look at the huge amount of code in JSX that the world is maintaining at the moment. I would say the onl…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#84
post #76

Genuine question: Why would you use Solid instead of Svelte? I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.

Ironically, mechanically Vue and Svelte historically were much closer to React. Vue has a similar VDOM and Svelte while compiled still had a rerun component model. It was only the past year about 6 years after Solid showed the way Svelte 5, and Vue Vapor got away from that and now compile down to what more or less Solid has been doing all along. Of course this is under the surface. But in many ways while Solid itself has stayed relatively small it has profoundly impacted the rest of the ecosystem in a way we haven't seen since React. From Vue, Svelte, to Angular, Preact, and Qwik all using Signals now. The average user of these frameworks probably has no idea but everyday all the non-React frameworks work more and more like Solid.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#85
post #57

Earlier quoted context omitted.

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'…

[flagged]

Your tone sucks. You're being rude about them not answering questions they weren't asked yet. There are much nicer ways of going about this.

Edit: Oh. All of your replies are like this. Please take a chill pill.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#86

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…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#89
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.
Post reply on HN