Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solidjs – JavaScript UI Library

solidjs.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Solidjs – JavaScript UI Library

#11

Post by ryansolid »

eatonphil wrote: post #7

> In Solid, props and stores are proxy objects that rely on property access for tracking and reactive updates. Watch out for destructuring or early property access, which can cause these properties to lose reactivity or trigger at the wrong time. From the docs; does SolidJS provide a way to lint or warn on this? I've been getting more and more scared of destructuring and ... copying recently since, for example, you l…

It could potentially if we do analysis to identify components. It's kind of like React's rules though in that sometimes you want to access things in an untracked context on purpose. A simple linting rule that is ignorable would probably help.

Re: Solidjs – JavaScript UI Library

#12

Post by brendan-csel »

I've just completed porting react-bootstrap to SolidJS and the process was fairly painless.

Having components only run once really simplifies things ...no need to stash useRefs and useCallbacks everywhere. Refs are simply the elements themselves.

Mostly porting required a fairly repeatable pattern of removing awkward React code and using a couple of Solid functions to keep props reactive when splitting them up to spread across JSX elements.

A+ for Solid developer experience (coming from 5+ years working with React). Oh, and performance/size are added benefits.

Re: Solidjs – JavaScript UI Library

#13

Post by elias94 »

rektide wrote: post #2

not the submitter but saw it recently mentioned as the small library powering asciicinema's 3.0 rebuild[1]. [1] 4x smaller, 50x faster, https://blog.asciinema.org/post/smaller-faster/ https://news.ycombinator.com/item?id=29387761

Yes, I found it from the article. I think that is an interesting library. Is pretty fast and developed/used for 5 years.

I cannot understand how some libraries are so popular without changing that much and others are not popular at all.

Re: Solidjs – JavaScript UI Library

#14

Post by ryansolid »

elias94 wrote: post #13
rektide wrote: post #2

not the submitter but saw it recently mentioned as the small library powering asciicinema's 3.0 rebuild[1]. [1] 4x smaller, 50x faster, https://blog.asciinema.org/post/smaller-faster/ https://news.ycombinator.com/item?id=29387761

Yes, I found it from the article. I think that is an interesting library. Is pretty fast and developed/used for 5 years. I cannot understand how some libraries are so popular without changing that much and others are not popular at all.

To be fair the first few years I wasn't really promoting it. Honestly just was content entering benchmarks and using it for my own purposes. Then React announced Hooks and it was like looking in a mirror. At that point I realized that people might actually use this library so I started promoting it. Honestly bigger players have so much inertia behind them it takes years to make a dent. We released 1.0 in July and things are just getting going.

Re: Solidjs – JavaScript UI Library

#16

Post by acemarke »

jaequery wrote: post #15

Is this backward compatible with other React packages? Otherwise, I’m afraid it may just turn out to be Yet Another Js Framework.

No, because it's _not_ React-based at all. It's a completely different framework.

It's got some syntax similarities, in sort of the same way that most of the C-family languages look similar (for those languages, curly braces, if statements, semicolons, declaring data types; for Solid and React, function components and JSX syntax), but that's it.

FWIW, from my own viewpoint in the middle of the React ecosystem, I think Solid looks like a fascinating approach and it has a bunch of reasons to be worth considering in its own right. Doesn't mean it'll magically gain adoption or ever be considered one of the major players in the web framework space, but it's definitely far more than just a random toy project.

Re: Solidjs – JavaScript UI Library

#18

Post by keyle »

no_wizard wrote: post #3

Heck of a library, and its creator, Ryan Carniato, is a very smart engineer who works on both Marko[0] and solidjs. He's really patient and answers my random questions on Twitter pretty reliably, I have to say I appreciate it! The performance that SolidJS eeks out of the DOM is really next level. I think it could use a small augment in the docs about migrating from React to SolidJS, but all around the project is very…

Interesting but your comment on doco and the fact that you need to ask the dev on twitter is a huge turn off.

Documentation > performance for most business applications, because it's developer performance. I don't have time to reverse engineer some uber nerd's SIMD optimized world wonder, I have things to ship.

Re: Solidjs – JavaScript UI Library

#19

Post by skc »

Such a pleasant library to use, and coming from Vue I was somewhat surprised by that as Vue was the first lib I used where I could just intuit how something worked and was very often correct or close.

Great job.

Re: Solidjs – JavaScript UI Library

#20

Post by nightski »

eatonphil wrote: post #4
no_wizard wrote: post #3

Heck of a library, and its creator, Ryan Carniato, is a very smart engineer who works on both Marko[0] and solidjs. He's really patient and answers my random questions on Twitter pretty reliably, I have to say I appreciate it! The performance that SolidJS eeks out of the DOM is really next level. I think it could use a small augment in the docs about migrating from React to SolidJS, but all around the project is very…

> The performance that SolidJS eeks out of the DOM is really next level. Kind of a weird way of putting it. Intuitively any framework abstracting concepts on top of DOM manipulation has to be slower than direct DOM manipulation. But yes in comparison to other frameworks, the benchmarks they make do look impressive. Now I'm curious to do some benchmarking of my own.

That's kind of why the entire virtual DOM concept came about, because it was faster than direct DOM manipulation. Essentially batched updates to the DOM were faster than ad-hoc updates.

Now React is 8 years old and browsers have improved a lot since then so I imagine the gains might not be what they used to be. But at the time it was huge.

Post reply on HN