Syntaxually and philosophically. Implemention-wise it's more like MobX or Vue style reactivity without a Virtual DOM. It takes compiled reactivity past the localized component model of Svelte to new(ish.. the library has been around for a few years) heights in flexible templating with JSX and unparalleled performance.
The update cycle is the exact opposite to React Hooks. With React your Component needlessly re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Comoponent is a basic function that executes once closing over state with it's Hooks, which are the only thing that run over and over as needed when state changes.
One thing the article doesn't really dive too far into is that Svelte is template driven, while Solid is more about React's jsx-drive-components. As I've used both style methods for years, I think I'm growing fond of Svelte's template approach as the best general purpose solution. This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. Being able to keep all that static code as close to vanilla web really helps to reduce other overall complexity, with the added benefit of being able to copy html with css from anywhere into my project, and then add dynamic behavior without "rewriting" basic html into jsx (which can lead to subtle bugs).
We use JSX identical to a Template DSL more or less. We don't use JSX at all like React does. That's why Solid so performant. It does similar thing to Svelte. We don't compile it into HyperScript. You can copy and paste html with one exception (void elements JSX makes you close input tags etc). But otherwise I support all the standard stuff pre-adding the dynamic bits. Solid supports `class` and `for` and `style` strings etc..
My 2c of insight: I found Svelte's docs & examples greatly sweetened the on-boarding.
While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us.
The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.
I agree. I would love to do more. The truth is there is just so much to do. It's hard to find a balance between writing cleaner docs and say solving Async Hydration with Suspended Components. I had the luxury early on to prioritize the latter which is why Solid is so feature rich given how much of it needed to be researched and built from scratch. I always knew it would catch up with me. But that's a good problem to have.
Ahahaha I know it sounds like that. But I realize what a massive task that would be. Am I volunteering? No. I appreciate your invite.. I'll email you if I change my mind.
I think a cool thing would be if the docs site was made in it. Self documenting.
That is an interesting project. And looks like they beat me to Solid name by a few years. I usually refer to my project as SolidJS. But thanks for bringing this to my attention.
This is interesting (I’m doing something similar in a specific domain) but there is a bunch of issues: very scarce documentation, funded by Quatari money, and more importantly built on bloated, low adoption set of Semantic Web specs. Heck, the tutorial even acknowledges[1] "If all the above looks terribly complicated: that’s because it is."
Agree with the point about SemWeb. AFAIK, RDF/OWL/SPARQL is kindof a long-term pet project of TBL's, and now with SOLID IMHO he's kindof reusing parts of it as a 2nd chance to finally become mainstream (with weaving and creatively interpreting specs as is typical of SemWeb). What SOLID wants to achieve, though (a federated, less centralized web) is too important an initiative to let it become a case of puzzling out an utopian stack based on tech that has failed mainstream adoption, so unfortunately can't be taken seriously, and seems more like a project for fundraising TBL's pet project. Saying this as someone who has just recently worked with SPARQL and graph DBs in bioinformatics which is one of the domains where it actually has gained traction.
Can you use react components with it? All the libraries of beautiful components are the main reason why I use react. Like I know you can but with cross component comms and stuff.
Does the state thing have the same gotchas as react hooks? Not a big fan of how that's impl'd in react.
No Hook Rules. Hooks are an amazing feat by the React team as they basically come so close to emulating the behavior here with running through top-down VDOM reconciliation. But they can't be nested etc.. This reactive approach is similar to MobX or Vue Composition API and doesn't have those constraints.
That being said for the same reason. No React Compat. The library doesn't work even remotely similar. People have used them together, but this is no straight swap in.
Might be a good feature. One idea might be a standard way of wrapping a react component so that it uses an embedded iframe / postmessage to post messages back and forth with solid.
Tho personally I would like to see this approach to managing state win: https://github.com/colshacol/storage-changed
Solid doesn't re-render Components over and over.. so integrating React is as simple as wrapping a `createEffect` calling `React.render` on a ref. The other way around is a bit harder, but been at this for a while here is a codesandbox with a HOC for that: https://codesandbox.io/s/solid-react-hoc-8m2yd
Any comment on that storage-changed lib? I think that's a massively underrated abstraction for high level state / comms. I want it to be more popular. :)
It's interesting to wrap the persistence in there as well and it's lightweight so that's a plus. But someone also could use say Redux(or Storeon) and achieve a similar thing. The challenge of interopt is more with conflicting update/render cycle and props (especially children). For global storage any event emitter will do. Although one so browser native definitely has it's perks.
Fair enough. Keep in mind I've been working on this for close to 5 years. Basically around the time I realized KnockoutJS was going to die out and React was for good reason going to win. Here is an article about why this library exists: https://dev.to/ryansolid/why-solidjs-do-we-need-another-js-u...
For sure. Which is why in the early years I just did my thing. Win the benchmark battles and move on with my life. But then this whole React Hooks thing came about. And Vue Composition API. Even Svelte 3, and I was like.. there is a better way. I tried to convince those libraries of this but hit walls. So I just kept writing articles and demonstrating it. And here we are today. Some else posted it on here and for the first time I believe it is on the front page of Hacker News. Years later.
Dude, just let him have his fun and stop with the needless negativity. You don't know what the future holds and being rude for the sake of being rude, says quite a bit about you as a person.
I don't think I was being rude in any way. I agree that it is fun. But then its a slim chance that its going to be widely adopted. how come bringing that up is rude?
Don't worry I didn't find the initial comment rude. I get what you are saying and I respect not everyone has time to read a 9 min article. Just know that I'm very aware of it and reflect on it in that article and a lot of writing on Solid.
> If your library/framework/etc's goal is to make life slightly better, just don't do it.
> is fun and beneficial for the individual. YOu just have higher chances of staring a unicorn co, than creating a js library that is widely adopted.
OK, but this thing scored like 600 extra stars in 1 day. And already has over 2K stars. I get you're discounting that. But people like it and are using it. Some dude worked years on it. And you try to trivialize all of that positivity by saying well it's just fun for an individual, as if it's nothing more than fun, as if all the other people who like it don't matter. Which is a lie. He's made something that's more than just him. Something people like. And you're giving the advice, "Oh, all that you did, just don't." as if you're so much smarter than this guy who has created this amazing thing. And, yeah, I get you're dismissing that because it's not "as big as" whatever.
Sure, you're right from your perspective. But how useful is your perspective? And...holding that perspective, how can you really appreciate this work?
You dream of building something better than what is. In some area. Eng dreams. We can all relate.
In the framework space, does any tool really have all the answers? No. Improvements can be made. So make them. Totally good thing to do.
Seems you think you don't have a useful comment to offer, so you just land mean criticism. You know it's mean. That's your point. You feel low, then on HN and see this library written by this dude, get angry and unleash on here. Sure, you feel better for a time, but you hurt other people.
Yeah, I get that putting yourself above this work, and this guy, and dismissing and trivializing the guy and the work, makes you feel better, by comparison. But that's just about what you need to believe, in the moment, to feel good, as a result of whatever situation you're in. It's not about this guy, and it's not about the reality for people using it.
I don't know Ryan, but I've faced this sort of comments from the internet before. It hurts. It gets in the way. It makes you, the commenter, come across as...some sort of inhuman troll. Which of course, you're not!
I'm not trying to change your mind. I get the pain you're feeling to want to say stuff like that. Just trying to point out that what you're doing is bad. For you, and others. Yeah, I guess that's your point, but people can choose different things.
The way I see it, apart from being bad for trying to hurt others, being cruel like this is a huge disservice to you. That's my appeal to you.
I'm trying to read beyond the meanness in your comments to see your actual thoughts on this. And I think they're valid. Actually I want to know about your criticism of the eng landscape and what you think. But when you land this cruel hit, but leave off explaining how you actually think, you let everyone down. Including yourself. Because you do have something interesting to say. what you offer is not just meanness. I genuinely believe that.
Don't care if you don't.
What you did this time, is not great. Plus it's bad karma for you. Hopefully next time you only comment on someone's work if you make kind comments and share your true perspective. That would be valuable! Hope you have a good one :)
You could think of a library like this as an argument in a conversation about frontend. One that is demonstrated and backed by an actual implementation. As such, I'd say it is valuable regardless of npm download counts.
I'm sure he could also have spent that time at $company, helping to plumb gossip and cat memes a bit more efficiently. I'm sure that would have been more lucrative as well.
I'm skeptical about the way state can change from under you within the same execution of the rendering function. This type of mutability will prevent all the help that typescript normally gives for complex components.
Also if anyone has used it, do you have to use this pattern if you have derived state?
Feel free to shoot any issues or discussions on our gitter or reddit. You are correct because it doesn't work like that. It works more like MobX. There is no render function that runs repeatedly. Instead everything is split apart granularity and only those pieces update.
If you want to have derived state. Simply wrap it in a function or use it in a JSX binding.
Good thing this came about. I looked through various JS frameworks for web components a year or so back. I now can't remember did I find Solid had web component support then. I see it has this support now, with Solid Elements. I remember reading Solid articles at the time from Ryan's blog and being impressed. Now it's time to take another look.
Also, I see it's small in size and ES module friendly. Very nice.
Web Components were what originally led me to keeping the Component side light in Solid, which eventually influenced some of optimizations in that area. I hope you find things have progressed nicely in the last year.
I personally have only had substantial experience with react (and its hooks), but the replacements for hooks in this library look very exciting to me, though I'm not sure I fully understand them on a first reading.
One thing that react hooks require is the placing of hooks at the top level of a function, which precludes dynamically creating hooks in a loop, or lists of effects. While usually there is a way to achieve whatever you're trying to achieve anyway, it's still a bit of a restraint on what you can write with React. I haven't tried Solid yet, but if its hooks are nestable and composable as the Reactivity page says, then this could enable some patterns that were previously impossible with react hooks.
But it isn't something that completely gets abstracted. There is a reason it has been so difficult to make a non-virtual Dom version of React. It isn't impossible, but has yet to fully flesh out despite attempts by a few projects including members of the React team.
The link has been posted in another comment too, here are some chunks that may be relevant to you:
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. Behind the scenes we want to compute a patch operation that updates the DOM to look how we expect. So while the virtual DOM diff/patch algorithm is probably not the optimal solution, it gives us a very nice way to express our applications. We just declare exactly what we want and React/virtual-dom will work out how to make your scene look like this. We don't have to do manual DOM manipulation or get confused about previous DOM state. We don't have to re-render the entire scene either, which could be much less efficient than patching it.
Sort of. I don't think you can write off the virtual Dom. But this is basically my area of research. I'm saying that a specific approach to reactive programming is more performant. I have an article for that too: https://medium.com/better-programming/the-fastest-way-to-ren...
Thanks. The whirlwind of changing benefits of various frameworks can be rather confusing. I do wonder how much this matters for most apps and at what cost of complexity it brings. But advancements in the field is a obvious good thing.
From my perspective, the things are a bit like this:
1. Make all updates manually with jQuery. This is fast, but hard to keep track of.
2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change.
3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.
Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.
Ahead-of-time vs Just-in-time is a more accurate description.
In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests).
This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm up (a couple hundred executions before all the optimizations kick in). With the vDom, you warm up ONE set of code that then runs forever. With the precompile, it has to warm up for EVERY new component and potentially slightly different codepaths within the same component.
The JS framework benchmark reuses the same components for everything which is a huge advantage to precompiled frameworks while not having much impact on vDom ones (as the actual components in both cases usually won't optimize very much due to being polymorphic).
> In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests).
I mean I agree with most of your post, but I'm not sure I would necessarily make that highlighted claim from the benchmark results. I mean the +- seems to be pretty run dependent for most libraries on there. And while I agree that the differences in performance is neglible, there is one. Solid is clearly faster in most tests even if by a small amount. Anyone interested you can look at: https://krausest.github.io/js-framework-benchmark/current.ht... And then isolate Solid and Inferno and then do a comparison against one library. It will color highlight the degree of certainty the difference is between the libraries in terms of significance of the results.
> In this case, there's no evidence that precompiling is faster in theory -- let alone in practice.
It’s absolutely not because it requires far greater effort computationally. The benefit has nothing to do with performance but instead simplified state management.
I know people desire certain frameworks due to how they perform state management. I have never really understood that motivation myself though because managing state is incredibly simple. Here is a basic outline of how simple it is:
1) realize there are exactly two facets to every component: data, interface.
2) all components should be stored in common locations. A single object stores component data and a common DOM node for storing component interfaces.
3) pick a component facet to update, either data or interface, and never update the other. The other should be automatically updated by your application logic (reflection).
4) store your data on each change. That could be dumping it into local storage. In my current app I send the data to a local node instance to write into a file so that state can shared across browsers in real time.
5) be able to restore state. On a fresh page, or even page refresh, simply grab the stored data and rebuild the component interfaces from it.
My current application is a peer to peer Windows like GUI that works in the browser and exposes the file system (local device and remote devices) in Windows Explorer like interfaces. Managing state is the least challenging part of this. The slowest executing part are long polling operations against large file system trees (it’s about as slow in the native OS interface)
Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.
My annoyance with that talk is he never compared Svelte with multi-threaded React. It was the natural next thing to look at but it was like “okay my point stands let’s move on” haha.
Well maybe we should compare apples to apples. With React you go down a rabbithole of workarounds around their initial concepts (like hooks) until you wonder why you chose it in the first place.
I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time.
Now don't get me wrong I've benchmarked Hooks like crazy and I don't think they are much consideration on performance at all. It's just the mental model of always update on the outside with bubbles of things that don't update creating these closures is a little unnatural. By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. Wrap what needs to be updated. Done. There are no out of date closures. No inconsistent mental model. It's as straightforward as registering event handlers.
Still I have to admit the solution is genius. They have managed to get 90% of the benefits with simply repositioning things. At one point this was one of my biggest arguments against React. People didn't appreciate it before hooks. But can you imagine knowing you could write applications this way years ago and trying to convince someone using React classes there was a better way? I just sort of gave up and did my own thing.
thanks for the explanation! though i have to say i only have a vague idea of "fine-grained reactivity", any pointers for reading about this or systems that work this way?
in particular, i don't quite get this bit:
> By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update.
inside/outside of what?
PS. my yet undeveloped pet theory is that hooks are (somehow) something like half a monad/algebraic-effect-thingy... though they're probably too tied up with the render cycle to analyze them this way
There's no such thing as 'multi-threaded React'. JavaScript runs in a single thread unless you use web workers, which React doesn't (this was a popular idea a few years ago, but people have since come to accept that it adds overhead and complexity out of all proportion to the problem it's designed solve).
You're probably thinking of Concurrent Mode, which the talk does indeed address. Concurrent Mode is, among other things, a clever way of solving one of the problems introduced by the virtual DOM paradigm: that you have to rerun a lot of user code on every state change that will often block the main thread if you don't break it up into chunks.
I haven't seen proof that the output of these libraries is restricted in any meaningful way. Is there a case where some small input n yields !n code? Is there even any proof that all states can actually be tracked? In the case of a vDom, your code size is fixed and execution has a provable upper-bound.
Even if that could be proven, code bloat is still a problem. With a vDom library, the render engine size is fixed. Moreover, those functions are guaranteed to run enough that they will be optimized by the JIT while changing render functions for every component could mean your renders are optimized for this view, but back in interpreter land when rendering the next view.
VirtualDOM allows you to roughly code your UI as a function of state. It's never been a magic bullet to better performance, except perhaps compared to Angular.js 1.x's "change detection" methods.
VirtualDOM is a means to an end for React. People love that "end", but they do not love the means by which it is achieved.
Maybe one could argue that people love VirtualDOM because it allowed this "end" to be achieved, but I still think every React fan would much prefer it if was doable without VirtualDOM.
It is actually "doable" without vDOM but doing so would be much less scalable and require more care from the user of the library.
Some people thought they must use VDOM to get things done efficiently, because "All those updates to the DOM will make the browser repaint and everything will be slows! Oh no! We must use VDOM!"
This library apparently proves them all wrong, by using the normal DOM in a clever way.
For the life of me, I can't understand why there is so much emphasis on the virtual-dom and dirty checking.
DOM manipulation is expensive, so a check is made to see if it really needs to be done.
If you're guaranteed to need an update, then this check is pointless. But this depends on what you're doing. Its really not something that's tied to the technical identity of any library. React, vue, etc, could probably also skip this step if they wanted.
Also, this will almost never be the bottle neck. It's really low down on a long list of other things that will have a bigger impact. Web dev is in a really bad state - you're supposed to have something like 1.5k nodes according to lighthouse because of all junk that browsers have to do now. That's a puny number of checks for the cpu to do.
IME the Virtual DOM approach is not bad per se -- I appreciate that I can just instruct the library what final state I want and it figures out the details. It's just that for various reasons the algorithms used for "should we update this DOM node" don't scale well.
Of course, if everything was done perfectly I'd imagine an 80486 CPU should be able to render most of today's websites in 0.5 secs but... it's not done perfectly. :)
I like Svelte quite a lot, and I like the idea of the OP's library as well but I wouldn't count React dead just yet. It has a really good idea and the general ergonomics are there. But we shouldn't deny that it still has a room for improvement.
I recently rewrote a small toy project from Preact to Solid. It went from spinning my fans and consuming over 25% of my cpu to practically idling. Solid is legit. I could have optimized my Preact, but I didn’t have to think of it with Solid. Same is true of Svelte.
Edit: I see the author is here, and lots of typically negative comments are being thrown at him. Ignore them and keep up the good work! We need people like you to push performance forward.
This sounds like a really atypical project. Consuming 25% of your CPU is a lot! I hear people mention those kinds of numbers only for Slack, which does have a lot of functionality.
I'd just point out that for the average project, the main advantage is that with something like Solid or Svelte, it will load in less than a second, vs. a few seconds for React, especially for something simple like a blog where you don't want to think about perf or optimize much.
It is atypical, yeah. It's a speed-reading app, so it flashes a new word on the screen every nth of a minute, where n is how many words per minute you want to read.
Still, I'm tired of using a normal web application and feeling the UI lag when I type, etc. I suspect that if you start off with a project like Svelte or Solid, you'll have a longer runway on your app before you get to that level of suck.
Yeah JSX has its clear advantages. But I wanted to offer runtime only solutions as well. Tagged Template Literals is still the best runtime only solution for Solid, but I've got HyperScript too. Just remember it's reactive so wrap expressions in functions. JSX compilation sort of hides this detail from you.
Really cool, I should have a serious look at this non-virtual dom thing. All the examples make it look like this project is dependable. Sorry for the plug but I somehow explored similar path when creating the Blop language, maybe the author might be curious: https://github.com/batiste/blop-language
Maybe I should get rid of the virtual DOM lib. I use?
It's not unexpected at all. I've had several template library writers reach out to me about the potential here. And there is some. The challenge is figuring out how to hide the reactivity in a way that your end users would be happy with but still benefit. I think it is an interesting challenge.
It can be used with MST with a bit of interopt. As for native it's possible but would require different compiler output. I saw an approach with another library mind you that emulated DOM API over Native script and used the same compiled output for both. Probably not the best way but interesting.
I joined the Svelte camp a while ago so I'm unlikely to try Solid anytime soon, but had I started with it I wouldn't complain, because the value proposition is the same: an abstraction which is runtime-inexpensive both in terms of CPU usage and bundle size.
I think, the "3rd Age of JS" [1] of frontend libraries are running directly in the browser without a build step. Like in the beginning. ES modules in the browser paves the way.
Svelte and Solid are actually the pinnacle of the "2nd age of JS".
I read that article a few weeks back. It's interesting. I see the desire to lessen on tooling but it is going to be hard to match what these libraries are doing purely runtime. I know people want to get there again. But I think we are more likely to see lighter dev methods and then when it comes to actual production the real advantages of compilation and bundling.
It's an interesting thesis but feels a little cult-ish in mindset. The Neo-isomorphism prediction seems most interesting in terms of the benefits. Because honestly - I think we are MORE likely to see a shift towards containerization of services/apps rather than a module orientation.
Thanks. I get criticism like "Why even make this? just use React." But it's so different. Yet I didn't want to throw everything away. People forget React came up when there were tons of libraries with similar reactive approaches and won our hearts and minds. It does a lot of things purposefully and it does those things well. We need to learn from the past it we are doomed to repeat it.
Long answer: It is worse, and it all boils down to two phrases which I classify as "marketing speak". Marketing speaks aim is to impress and influence you, "technical speaks" aim is to inform and educate you. When shopping for a library or framework for your next feature or project, it helps to distinguish between the two. Usually any time you see a buzzword, you've stumbled upon some marketing speak. The buzz-wordy term "declarative" has been popularized by React, so I just thought I'd apply it to HTML and hopefully encourage someone to skill up on the web fundamentals (HTML, JS and CSS) before tackling JS frameworks to avoid disasters like this https://stackoverflow.com/questions/42464888/how-do-i-change....
> highly-interactive
What does this mean? Are you talking about video games? Because that is what comes to mind when I see the term "highly interactive".
> logic-driven
Aren't all programming languages logic driven? Or are there some feelings-driven apps?
Neither allow you to build interactive user interfaces besides what is provided by the browser.
I understand the sentiment about reinventing the wheel, but this is more like inventing tyres I suppose (fortunately they are made of rubber, so I can stretch the analogy pretty far, haha). The wheel is there, but there is something to improve to cover more use cases.
Explain the big picture abstraction differences between this and React in two sentences? I don't care about compiler vs interpreter implementation details.
With React your Component re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Component is a basic function that executes once closing over state getters with its Hooks, which are the only thing that run over and over as needed when state changes.
Awesome I think so too. I love exploring this space in general. It's really interesting to see how you can model problems this way. Reactivity isn't a solution to a single problem but a way of modelling any problem
Solid actually can work runtime only too but I do put most of my effort on the compiler since I can use it to overcome most of the classic shortcomings of the reactive approach performance wise (and DX wise) with a bit of consideration.
I've been working in this area. Solid now has string rendering on the server without DOM emulation. I'm just one person so I went with what was cheapest first.
The negativity in this comments section is astounding.
Personally, I was originally introduced to it by someone in the Mithril.js gitter chat, and think it's a great project. I wish the Solid team the best and look forward to trying out Solid in my next toy project. The performance benchmarks and relatively clean API are truly impressive.
Thank you for your kind words. It can a difference to have the kind words of a few strangers. I'm used to these sort of responses now. And welcome it to a certain degree. Insightful comment can lead to interesting discussion. Ignorant ones gives me a platform to educate.
But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback" on reddit if any at all.
Unfortunately, JS fatigue is real and it can be challenging for someone who has their hands full with just relearning new React idioms to also evaluate the dozens of other libraries out there, so it's easy to miss a gold nugget.
For those who are not seeing the value proposition here, think Svelte, but where the "reactivity magic" is encapsulated via Components to still allow React-like "it's-just-JS" component code, while also getting rid of a lot of runtime overhead and the complexities associated with trying to optimize a virtual dom (as has been the recent direction for React).
One great benefit over Svelte with this approach is that you can use Typescript in templates (something that Svelte still is not able to do).
Solid's performance claims to fame are also legit (i.e. it doesn't sacrifice good devexp, good engineering, unlike many of the top performers in the stephen krause's benchmarks).
The only thing I wish was better is docs. It starts off "spilling its guts", so to speak, and while that is an ok way to explain why Solid is different than others and to garner interest from library authors, it's also not super beginner friendly. One cannot, for example, easily find docs for `<For>` even though it's analogous to core syntax if we were to compare to a programming language. Putting a follow-along tutorial upfront would go a long way.
Is there dedicated DevTools support for Solid like there is for React, Vue, Svelte, and co.? If not, is there a convenient way to inspect state, props, and the component hierarchy?
There is an open issue for this. It's an area that needs work since I can't just repurpose existing tools like VDOM libraries do. The challenge that comes with pioneering an approach.
I actually think this is extremely important. One downside of these compilation-driven frameworks is that they would, I assume, make it much more difficult to track with exactly how your code manifests at runtime, and would therefore make it harder to debug. Even setting that aside, I'm a strong believer that "frameworks" (contrasted with "libraries") have a responsibility to bring their own tooling, because existing tooling is less likely to be useful against the new concepts they introduce.
It's easier to just open up and debug than say VDOM views since you can see your dynamic expression (what's not updating) and just drop a breakpoint. The template structure flattens so you don't have this issue of nested children and what you are debugging is the actual DOM nodes. It feels more like debugging jQuery. But it is no replacement for good dev tools.
I guess what I meant is that VDOM views (at least pure-functional ones like React) can have a much clearer separation between the view logic and the state logic. I don't have to understand how the VDOM works because it's never entwined with my code that might have a bug in it: I'm just creating a data structure and handing it off. If there's a bug, it's in the creation of that data structure, which is 100% my own code. That hard barrier exists even at runtime. Solid seems like it deeply entwines the two in a way that's very clever and has performance advantages, but would also, I expect, come with a cost.
Yes it's all the same thing. Your data is reactive and an be modularized. The renderer is reactive with the DOM basically being a side effect. There basically is no renderer just a reactive system with different types of data. It means there is an incredible amount of flexibility and raw performance.
The tradeoff is rendering isn't particularly special. So the systems consciousness of specific render specific concepts requires additional consideration. There is no "onMount". There are reactive lifecycles but they aren't particularly tied to DOM updates.
At this stage, web components is no more than a glorified template string + a way to fill it, it seems?
Now only name it template separate it out into its own file, and build an "engine" around it. Then we are almost back, where we came from with backend rendering, which we should be doing anyway.
I've yet to see the JS framework that takes usability seriously and outputs a noscript block (during development) for me to copy paste and get the functionality for anyone disabling JS.
As it stands many web devs only see the JS enabled side of things and then are too lazy to, or not capable of implementing the noscript part. Or they are not even aware of the white page one gets for their oh so cool React apps, once JS is deactivated. It is very unprofessional amd exclusive, I must say.
177 comments
[ 4.5 ms ] story [ 222 ms ] threadThe update cycle is the exact opposite to React Hooks. With React your Component needlessly re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Comoponent is a basic function that executes once closing over state with it's Hooks, which are the only thing that run over and over as needed when state changes.
If you're wondering how this is different from Svelte, the author has a Medium post on it[0].
[0]: https://medium.com/@ryansolid/javascript-ui-compilers-compar...
React can easily be used to render just the parts of the page that need it, with all the surrounding html done the old fashioned way.
While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us.
The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.
Also, polished product and polished code deserve a polished set of docs. Just sayin'!
I think a cool thing would be if the docs site was made in it. Self documenting.
(Disclosure: I work at Inrupt, the company started by Tim Berners-Lee to support the project's adoption.)
[1] https://solidproject.org/for-developers/apps/first-app/4-dat...
In 1983, a database was named SolidDB: https://en.wikipedia.org/wiki/SolidDB
etc. etc.
Does the state thing have the same gotchas as react hooks? Not a big fan of how that's impl'd in react.
That being said for the same reason. No React Compat. The library doesn't work even remotely similar. People have used them together, but this is no straight swap in.
If anything there is just so much to document.
YOu just have higher chances of staring a unicorn co, than creating a js library that is widely adopted.
If you're having fun, keep going. That's all that matters.
How is it different than what I said?
> is fun and beneficial for the individual. YOu just have higher chances of staring a unicorn co, than creating a js library that is widely adopted.
OK, but this thing scored like 600 extra stars in 1 day. And already has over 2K stars. I get you're discounting that. But people like it and are using it. Some dude worked years on it. And you try to trivialize all of that positivity by saying well it's just fun for an individual, as if it's nothing more than fun, as if all the other people who like it don't matter. Which is a lie. He's made something that's more than just him. Something people like. And you're giving the advice, "Oh, all that you did, just don't." as if you're so much smarter than this guy who has created this amazing thing. And, yeah, I get you're dismissing that because it's not "as big as" whatever.
Sure, you're right from your perspective. But how useful is your perspective? And...holding that perspective, how can you really appreciate this work?
You dream of building something better than what is. In some area. Eng dreams. We can all relate.
In the framework space, does any tool really have all the answers? No. Improvements can be made. So make them. Totally good thing to do.
Seems you think you don't have a useful comment to offer, so you just land mean criticism. You know it's mean. That's your point. You feel low, then on HN and see this library written by this dude, get angry and unleash on here. Sure, you feel better for a time, but you hurt other people.
Yeah, I get that putting yourself above this work, and this guy, and dismissing and trivializing the guy and the work, makes you feel better, by comparison. But that's just about what you need to believe, in the moment, to feel good, as a result of whatever situation you're in. It's not about this guy, and it's not about the reality for people using it.
I don't know Ryan, but I've faced this sort of comments from the internet before. It hurts. It gets in the way. It makes you, the commenter, come across as...some sort of inhuman troll. Which of course, you're not!
I'm not trying to change your mind. I get the pain you're feeling to want to say stuff like that. Just trying to point out that what you're doing is bad. For you, and others. Yeah, I guess that's your point, but people can choose different things.
The way I see it, apart from being bad for trying to hurt others, being cruel like this is a huge disservice to you. That's my appeal to you.
I'm trying to read beyond the meanness in your comments to see your actual thoughts on this. And I think they're valid. Actually I want to know about your criticism of the eng landscape and what you think. But when you land this cruel hit, but leave off explaining how you actually think, you let everyone down. Including yourself. Because you do have something interesting to say. what you offer is not just meanness. I genuinely believe that. Don't care if you don't.
What you did this time, is not great. Plus it's bad karma for you. Hopefully next time you only comment on someone's work if you make kind comments and share your true perspective. That would be valuable! Hope you have a good one :)
I'm sure he could also have spent that time at $company, helping to plumb gossip and cat memes a bit more efficiently. I'm sure that would have been more lucrative as well.
Also if anyone has used it, do you have to use this pattern if you have derived state?
If you simply do `const displayName = ...` in the component, will the component update properly?If you want to have derived state. Simply wrap it in a function or use it in a JSX binding.
Ex.
const displayName = () => `${state.user.firstName} ${state.user.lastName}`
return <span>{displayName()}</span>;
or:
return <span>{`${state.user.firstName} ${state.user.lastName}`}</span>;
or:
// this expensive to calculate:
const displayName = createMemo(() => `${state.user.firstName} ${state.user.lastName}`)
return <span>{displayName()}</span>;
Also, I see it's small in size and ES module friendly. Very nice.
Now JS libraries advertise themselves based having no VirtualDOM.
Can someone explain this to me?
But it isn't something that completely gets abstracted. There is a reason it has been so difficult to make a non-virtual Dom version of React. It isn't impossible, but has yet to fully flesh out despite attempts by a few projects including members of the React team.
The link has been posted in another comment too, here are some chunks that may be relevant to you:
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. Behind the scenes we want to compute a patch operation that updates the DOM to look how we expect. So while the virtual DOM diff/patch algorithm is probably not the optimal solution, it gives us a very nice way to express our applications. We just declare exactly what we want and React/virtual-dom will work out how to make your scene look like this. We don't have to do manual DOM manipulation or get confused about previous DOM state. We don't have to re-render the entire scene either, which could be much less efficient than patching it.
but theses next generation frameworks are showing that there's a better way to solve the same problem.
1. Make all updates manually with jQuery. This is fast, but hard to keep track of.
2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change.
3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.
In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests).
This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm up (a couple hundred executions before all the optimizations kick in). With the vDom, you warm up ONE set of code that then runs forever. With the precompile, it has to warm up for EVERY new component and potentially slightly different codepaths within the same component.
The JS framework benchmark reuses the same components for everything which is a huge advantage to precompiled frameworks while not having much impact on vDom ones (as the actual components in both cases usually won't optimize very much due to being polymorphic).
I mean I agree with most of your post, but I'm not sure I would necessarily make that highlighted claim from the benchmark results. I mean the +- seems to be pretty run dependent for most libraries on there. And while I agree that the differences in performance is neglible, there is one. Solid is clearly faster in most tests even if by a small amount. Anyone interested you can look at: https://krausest.github.io/js-framework-benchmark/current.ht... And then isolate Solid and Inferno and then do a comparison against one library. It will color highlight the degree of certainty the difference is between the libraries in terms of significance of the results.
It’s absolutely not because it requires far greater effort computationally. The benefit has nothing to do with performance but instead simplified state management.
I know people desire certain frameworks due to how they perform state management. I have never really understood that motivation myself though because managing state is incredibly simple. Here is a basic outline of how simple it is:
1) realize there are exactly two facets to every component: data, interface.
2) all components should be stored in common locations. A single object stores component data and a common DOM node for storing component interfaces.
3) pick a component facet to update, either data or interface, and never update the other. The other should be automatically updated by your application logic (reflection).
4) store your data on each change. That could be dumping it into local storage. In my current app I send the data to a local node instance to write into a file so that state can shared across browsers in real time.
5) be able to restore state. On a fresh page, or even page refresh, simply grab the stored data and rebuild the component interfaces from it.
My current application is a peer to peer Windows like GUI that works in the browser and exposes the file system (local device and remote devices) in Windows Explorer like interfaces. Managing state is the least challenging part of this. The slowest executing part are long polling operations against large file system trees (it’s about as slow in the native OS interface)
Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.
Now don't get me wrong I've benchmarked Hooks like crazy and I don't think they are much consideration on performance at all. It's just the mental model of always update on the outside with bubbles of things that don't update creating these closures is a little unnatural. By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. Wrap what needs to be updated. Done. There are no out of date closures. No inconsistent mental model. It's as straightforward as registering event handlers.
Still I have to admit the solution is genius. They have managed to get 90% of the benefits with simply repositioning things. At one point this was one of my biggest arguments against React. People didn't appreciate it before hooks. But can you imagine knowing you could write applications this way years ago and trying to convince someone using React classes there was a better way? I just sort of gave up and did my own thing.
in particular, i don't quite get this bit:
> By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update.
inside/outside of what?
PS. my yet undeveloped pet theory is that hooks are (somehow) something like half a monad/algebraic-effect-thingy... though they're probably too tied up with the render cycle to analyze them this way
You're probably thinking of Concurrent Mode, which the talk does indeed address. Concurrent Mode is, among other things, a clever way of solving one of the problems introduced by the virtual DOM paradigm: that you have to rerun a lot of user code on every state change that will often block the main thread if you don't break it up into chunks.
More on virtual DOM here: https://svelte.dev/blog/virtual-dom-is-pure-overhead
Even if that could be proven, code bloat is still a problem. With a vDom library, the render engine size is fixed. Moreover, those functions are guaranteed to run enough that they will be optimized by the JIT while changing render functions for every component could mean your renders are optimized for this view, but back in interpreter land when rendering the next view.
https://stackoverflow.com/questions/21109361/why-is-reacts-c...
I would bet a surprising portion of React's userbase wouldn't even know what the virtual DOM is.
I don't believe this is true.
VirtualDOM is a means to an end for React. People love that "end", but they do not love the means by which it is achieved.
Maybe one could argue that people love VirtualDOM because it allowed this "end" to be achieved, but I still think every React fan would much prefer it if was doable without VirtualDOM.
It is actually "doable" without vDOM but doing so would be much less scalable and require more care from the user of the library.
So, in theory, you get VDOM goodness, without the bloat.
DOM manipulation is expensive, so a check is made to see if it really needs to be done.
If you're guaranteed to need an update, then this check is pointless. But this depends on what you're doing. Its really not something that's tied to the technical identity of any library. React, vue, etc, could probably also skip this step if they wanted.
Also, this will almost never be the bottle neck. It's really low down on a long list of other things that will have a bigger impact. Web dev is in a really bad state - you're supposed to have something like 1.5k nodes according to lighthouse because of all junk that browsers have to do now. That's a puny number of checks for the cpu to do.
Of course, if everything was done perfectly I'd imagine an 80486 CPU should be able to render most of today's websites in 0.5 secs but... it's not done perfectly. :)
I like Svelte quite a lot, and I like the idea of the OP's library as well but I wouldn't count React dead just yet. It has a really good idea and the general ergonomics are there. But we shouldn't deny that it still has a room for improvement.
Edit: I see the author is here, and lots of typically negative comments are being thrown at him. Ignore them and keep up the good work! We need people like you to push performance forward.
I'd just point out that for the average project, the main advantage is that with something like Solid or Svelte, it will load in less than a second, vs. a few seconds for React, especially for something simple like a blog where you don't want to think about perf or optimize much.
Still, I'm tired of using a normal web application and feeling the UI lag when I type, etc. I suspect that if you start off with a project like Svelte or Solid, you'll have a longer runway on your app before you get to that level of suck.
Looks great!
Also, does lack of vdom mean a project like react-native could never really come from this?
I joined the Svelte camp a while ago so I'm unlikely to try Solid anytime soon, but had I started with it I wouldn't complain, because the value proposition is the same: an abstraction which is runtime-inexpensive both in terms of CPU usage and bundle size.
Svelte and Solid are actually the pinnacle of the "2nd age of JS".
[1] https://www.swyx.io/writing/js-third-age/
The closeness with the React design makes it better than svelte imo.
CSS - A declarative, domain-specific language for styling user interfaces.
Better?
Long answer: It is worse, and it all boils down to two phrases which I classify as "marketing speak". Marketing speaks aim is to impress and influence you, "technical speaks" aim is to inform and educate you. When shopping for a library or framework for your next feature or project, it helps to distinguish between the two. Usually any time you see a buzzword, you've stumbled upon some marketing speak. The buzz-wordy term "declarative" has been popularized by React, so I just thought I'd apply it to HTML and hopefully encourage someone to skill up on the web fundamentals (HTML, JS and CSS) before tackling JS frameworks to avoid disasters like this https://stackoverflow.com/questions/42464888/how-do-i-change....
> highly-interactive
What does this mean? Are you talking about video games? Because that is what comes to mind when I see the term "highly interactive".
> logic-driven
Aren't all programming languages logic driven? Or are there some feelings-driven apps?
I understand the sentiment about reinventing the wheel, but this is more like inventing tyres I suppose (fortunately they are made of rubber, so I can stretch the analogy pretty far, haha). The wheel is there, but there is something to improve to cover more use cases.
That link tag above, is not only the poster boy of interactivity, it the the foundation of the web.
> Neither allow you to build interactive user interfaces besides what is provided by the browser.
Neither does JS, or any framework built on top of it. All types of interactivity in a browser are provided by for by the browser.
Would love to compare notes - you can check out (very much WIP progress) at https://github.com/sreekotay/reefer
It's been only a few weeks of fun... but REALLY interesting problem space. I use a DOM memo-ish approach to help with performance...
Solid actually can work runtime only too but I do put most of my effort on the compiler since I can use it to overcome most of the classic shortcomings of the reactive approach performance wise (and DX wise) with a bit of consideration.
Doesn't sound very promising tbh.
Personally, I was originally introduced to it by someone in the Mithril.js gitter chat, and think it's a great project. I wish the Solid team the best and look forward to trying out Solid in my next toy project. The performance benchmarks and relatively clean API are truly impressive.
But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback" on reddit if any at all.
Unfortunately, JS fatigue is real and it can be challenging for someone who has their hands full with just relearning new React idioms to also evaluate the dozens of other libraries out there, so it's easy to miss a gold nugget.
For those who are not seeing the value proposition here, think Svelte, but where the "reactivity magic" is encapsulated via Components to still allow React-like "it's-just-JS" component code, while also getting rid of a lot of runtime overhead and the complexities associated with trying to optimize a virtual dom (as has been the recent direction for React).
One great benefit over Svelte with this approach is that you can use Typescript in templates (something that Svelte still is not able to do).
Solid's performance claims to fame are also legit (i.e. it doesn't sacrifice good devexp, good engineering, unlike many of the top performers in the stephen krause's benchmarks).
The only thing I wish was better is docs. It starts off "spilling its guts", so to speak, and while that is an ok way to explain why Solid is different than others and to garner interest from library authors, it's also not super beginner friendly. One cannot, for example, easily find docs for `<For>` even though it's analogous to core syntax if we were to compare to a programming language. Putting a follow-along tutorial upfront would go a long way.
Lack of devtools is expected for a new framework, however, it is worth asking for, especially if you are considering it for production
The tradeoff is rendering isn't particularly special. So the systems consciousness of specific render specific concepts requires additional consideration. There is no "onMount". There are reactive lifecycles but they aren't particularly tied to DOM updates.
Now only name it template separate it out into its own file, and build an "engine" around it. Then we are almost back, where we came from with backend rendering, which we should be doing anyway.
I've yet to see the JS framework that takes usability seriously and outputs a noscript block (during development) for me to copy paste and get the functionality for anyone disabling JS.
As it stands many web devs only see the JS enabled side of things and then are too lazy to, or not capable of implementing the noscript part. Or they are not even aware of the white page one gets for their oh so cool React apps, once JS is deactivated. It is very unprofessional amd exclusive, I must say.