ryansolid

There are a lot of React state libraries that do similar things with Proxies. I think the part that is not as emphasized is how that reactivity extends to the view. Instead of re-rendering components it uses that knowledge to directly update portions of the DOM. So while MobX, Valtio, Jotai, Recoil etc localize change in React, they still feed into the whole VDOM React cycle, instead of just updating exactly what changes. It's not a characteristic of these libraries but the fact they feed into React.

What does a reusable (ie import from another file) `useAutoCounter` look like in Svelte?

I'd also look at other repos. Admittedly for the core code it has been mostly me. I think there is an intimidation factor. When you create a library this performance oriented it is hard to get people comfortable working on the core.

But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors

We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.

Yeah this is correct. The trick to this is that the subscriptions happen in our JSX and hooks. And really is just a nested tree of `createEffects` if one ever re-evaluates or is disposed it releases its child computations. So while the lifecycle isn't tied to components it is still hierarchically structured. Ie.. places where logic can branch becomes the owning scope, like conditionals or loops. So Signals like count don't really matter where they live and will live as long as in scope or referenced, the rendering still largely defines how long things are around.

Reactivity like this predates React Hooks. It doesn't have the hook rules/stale closures etc... No dependency arrays, useRef, or useCallback. It's a very powerful model and very different. The similarities are surface level but aren't without benefit. Composable declarative data patterns, read/write segregation, traceable state dependencies.

Some people position it more like, "Solid makes Hooks the way they should have been in React". Personally understanding how React works this doesn't make sense. But I think it might be helpful for people just approaching the framework.

This is the article series for you (I wrote it so I'm biased): https://dev.to/ryansolid/a-hands-on-introduction-to-fine-gra...

More than likely it's the lazy loading of the REPL. Those code editors are heavy and when they scroll into view they need to load. If we load up front it would drastically tank the load performance for people just visiting the site. It's possible on mobile we should opt for a click to load strategy.

There is very little we can do about this once we do go to load, it's just the nature a heavy fully featured editor like Monaco.

Hey Solid's reactive system uses Signals which are different than streams but work in similar use cases. Streams are slightly more oriented to transformation than synchronization. Most stream libraries could be used with Solid with a bit of an adapter on the end to connect to the templates as they are a good tool for managing global state.

All that being said. If you are happy with Mithril stick with it. It sounds like it's done everything you needed. I have a lot of respect for it's minimalist approach and its author is one of the most insightful and helpful people I've come across since getting into JavaScript frameworks.

If you are interested in trying something different. Check out our tutorials on the site and see how you feel about it. It is a little bit different type of framework.

Something you don't need to think about until well, you realize reactivity leaves templates and you need to write a store. Or that you have large data and need things to only update piecewise. Or you need to hoist things out into functions. Svelte has done an amazing job with its compiler but there are considerations you need to understand with its reactivity.

Solid does not have Hooks or Hook rules. They look similar but execute more similar to say Svelte. Although Svelte still is about Component re-renders and Solid's reactivity is more granular hence the performance improvement.

This area of DSLs is very superficial for the most part. I think people have preferences and I'm exploring both sides between Marko and Solid but saying things like unintuitive I think mischaracterizes things. Maybe explicit, transparent, transferrable, and composable are better adjectives that apply more to Solid than to Svelte that you can use in the future.

Solid's diff algorithm generally is faster(or atleast very comparable) than Mithril's. We test very well in list benchmarks like: https://krausest.github.io/js-framework-benchmark/current.ht.... We are also fast at node creation using pre-compilation to prepare the nodes in a way that can be created more efficiently.

It's a bit like MobX but instead of re-running full components or subtrees it contains the updates granularly. Picture if your renderer was just MobX Autoruns wrapping specific DOM updates as depended upon. In so because the reduced of need for diffing and the compiler that transforms the JSX to this you can author components in a normal way yet get incredible performance.

Hmm.. Remix is based around their router. And a nested router is what we need to for Solid (see Solid App Router https://github.com/solidjs/solid-app-router). I think the challenge is that we don't render like React. Not at all. I've found most cases where that assumption exists to be incompatible.

That being said the work has already started on a starter with Nested Routing/Automatic File Based Routing + Code Splitting/Parallelized Data Fetching/Streaming SSR/Multiple deployment adapters. We're given it the same focus on performance that we've given the rest of Solid.

Here is the recent Vercel Edge Function demo we made with it: https://twitter.com/RyanCarniato/status/1453283158149980161

It's a fair question. Pre React Hooks I expected the proxy plain object approach to be more common. We definitely want consistency regardless if component consumer passes signal or literal, so I went that way. There are cases like with spreads where they are actual proxies too. But probably could have made all props are functions work and have them work with combination of proxies as well things just didn't play out that way.

Yeah I see the bug. Thanks for reporting. Looks like the code added for re-adjusting has mins set that weren't intended for smaller viewports. This has been a community effort(PR that added the feature: https://github.com/solidjs/solid-playground/pull/43) and we are continuing to improve things.

You can put createSignal anywhere. It isn't hooks based. It's reactive like MobX or Vue. Some of the primitives don't have much meaning outside of a render setting. What sets Solid apart is the rendering is just that. It's just `createEffect`s. We just compile JSX to it. See my React Finland talk: https://www.youtube.com/watch?v=2iK9zzhSKo4

Props are getters. They are shallow. It are stores that are actual ES proxies.

I think the term is used loosely here to suggest that they are wrappers on top of objects. It isn't so much about the specifics but to explain why destructuring should be avoided.

Virtual DOM came about since it offered a simplistic top down view = fn(state) model without terrible performance. Other top down renderers were terribly inefficient and this built on that. It was never innately faster than targeted direct DOM manipulation. It was just compared to other approaches that were innately built on diffing as well. And things like reading from the DOM can cause reflows and other terrible performance bottlenecks.

Fine-grained reactivity existed back then and was more performant for updates. Always was. Just had its own issues since pre-MobX we didn't see implementations in JavaScript which provide glitchfree execution guarantees. So Virtual DOM was a great invention but I think it was misrepresented early on. That's what got me to start working on Solid. I knew the performance was there without a VDOM from day one. I'd seen it. So when Knockout started waning in popularity 2015/2016 I started working on a replacement.

It's unlikely. Solid has had this performance profile since 2017. React hasn't really budged. Fundamentally different approach. There are different types of performance to explore but raw performance for small things is not something React is going to "catch up" on. Might be worth a read: https://javascript.plainenglish.io/javascript-frameworks-per...

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.

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.

Solid author here. Hmm don't see this on Firefox on Windows or on my Macbook air. From what you are describing it's probably the REPL acting up. I wouldn't use that as a measure of performance.

SolidJS is a UI library, that is basically a reactive state library first, renderer second. It happens to look like React by choice, since it chooses JSX for its flexible composability and React Hooks resemble reactive primitives. Cliff notes are reactivity is independent of components. Components are just functions that run once and wire up granular updates. Then only the things that change ever re-run.

Yeah it is sort of buried and probably not very clear: https://www.solidjs.com/guide#react.

And good point thank you about updating my profile.

It's awesome to see performance-oriented projects to find their way to SolidJS(https://www.solidjs.com). So satisfying to see success stories like this one. Great work.

Awesome to see replay get even better. More accessible the more we can do. Really excited by this release.

I am a JavaScript framework author, and was one of those fortunate to get early access and honestly it is the most useful tool I've ever used in the debugging space.

Sometimes things are complicated. Often there is a need to do digging to uncover the issue. Being able to move forward and backwards and even jumping between seemingly disjoint parts of the timeline are all at your disposal with Replay.

Replay has saved me hours of time. And that isn't hyperbolee. On a couple occasions due to laziness and familiarity I'd do stuff the traditional way and be stuck still after hours (sometimes days) on the same bug. With Replay I was able to shorten that time to about an hour on even the trickiest of bugs.

So stoked to now have Replay available to others to help record reproductions of their bugs.

It's surprising how little syntax is here. It's even less code than Svelte.

It's unfortunate because of all the platforms it is one that gets the most human interaction in terms of real thoughtful humans willing to discuss things. I've tried a lot of platforms and dev.to is the best as writer from this perspective. Medium has better stats but that is about it.

It's super unfortunate that the best place to write is also the place most blocked. HN isn't the only one. Reddit also by default blocks dev.to. There are plenty of low quality articles on both sides.

I think the moral of the story is that there is too much garbage out there and a computer algorithm is incapable of making the distinction. HN is fine risking being behind the curve if it saves it readers from wading through it. That's a fine tradeoff but means it leaves things on the table.

The problem is by then most of the damage is done. HN algorithms clearly work off some amount of time based decay. It basically suggests getting a stable of people to vouch when whenever you post something.

Would you say the same about medium.com too? Or any site that allow people to sign up and create blogs/articles?

Core team on Marko and author of Solid. Vite is exactly the sort of project we've been looking for.

Sure I love coming up with the perfect Rollup setups to produce the smallest application bundles. But Vite closed the loop we were looking for in terms of offering low config client/server applications with both ease of use and great flexibility.

You can see the focus and care put into Vite to make it easier to address the complexity of configuration. We still have plugins/starter templates for Webpack and Rollup, but for the average developer getting started with these frameworks Vite just gives so much out of the box. It really gives the ease of something like Parcel, with the ability to expand. This makes it far superior to solutions like CRA which forced monkey patching or ejection.

We've already seen through meta-frameworks like Next that there is a big desire here, and what at one point seemed like a huge undertaking for a historically single developer project like Solid, is suddenly becoming a reality. And others have the ability to build and share these setups as well.

Evan and the rest of those working on Vite have my thanks and my gratitude.