It's been a long road to get here. It's been so long I can't even remember when I started. I logged on to an old private Bitbucket Repo and found "initial commit" on a repo aptly named "framework" from August 21st 2016. But I'm pretty sure that was my second prototype of a Reactive JavaScript Framework that would eventually become SolidJS.
So I can safely say a stable release has been 1000s of hours and at least 5 years in the making. But I'm sure the commenters on Reddit/HN won't even read this far before getting in with "Another day, another new JavaScript Framework". Seriously, don't let me down. I keep a scorecard.
What is Solid?
It's a JavaScript framework, like React or Svelte. What makes it unique is that it flies in the face conventional knowledge to deliver what many have said to be impossible.
A reactive and precompiled "Virtual DOM"-less JSX framework with all the flexibility of React and simple mental model of Svelte.
A framework that values the explicity and composability of declarative JavaScript while staying close to the metal of the underlying DOM. It marries high level and low level abstractions. Simply put, it is anything that you want it to be.
A few people have suggested that Solid is the future.
But it is also firmly rooted in the past when JavaScript Frameworks were simpler and you had real DOM nodes at your finger tips.
When your JSX elements are just real DOM nodes:
const myButton = <button
onClick={() => console.log("Hello")}
>Click Me</button>
// myButton instanceof HTMLButtonElement
When your control flows are runtime JavaScript:
<div>{ showComponent() && <MyComp /> }</div>
// custom end user created component
<Paginated
list={someList()}
numberOfItems={25}
>
{item => <div>{item.description}</div>}
</Paginated>
When you can compose and build your primitives how you want:
function App() {
const [count, setCount] = createSignal(0);
// custom primitive with same syntax
const [state, setState] = createTweenState(0);
createEffect(() => {
// no need for that dependency list we know when you update
const c = count();
// yep I'm nested
createEffect(() => {
document.title = `Weird Sum ${ c + state() }`;
})
});
// Did I mention no stale closures to worry about?
// Our component only runs once
const t = setInterval(() => setCount(count() + 1, 5000);
onCleanup(() => clearInterval(t));
// other stuff...
}
Well, you feel like you are cheating. And not just at benchmarks😇. You are not supposed to get your cake and eat it too. Full TypeScript support. A wonderful Vite starter template. All the modern tooling and IDE support you get for free by using JSX.
Why you should be excited
It isn't just the amazing developer experience. Solid is fully featured.
Powerful Primitives
Solid is built on the back of simple general purpose Reactive primitives. Solid embraces this like no Framework before having its very renderer built entirely of the same primitives you use to build your App. After all, are these really any different?
const el = <div>Initial Text</div>
createEffect(() => {
el.textContent = getNewText();
});
// versus
render(() => <MyGiantApp />, document.getElementById("app"))
Every part of Solid is extensible because every part could be developed in user land. You get the high level abstractions that make you productive but you don't need to leave them to get low level capabilities people enjoyed back when jQuery was king.
Solid has a compiler but it's there to help you not limit you. You can compose behaviors everywhere and use the same primitives. It's all one syntax.
Solid has even brought Directives to JSX.
// directive using the same primitives
function accordion(node, isOpen) {
let initialHeight;
createEffect(() => {
if (!initialHeight) {
initialHeight = `${node.offsetHeight}px`;
}
node.style.height = isOpen() ? initialHeight : 0;
})
}
// use it like this
<div use:accordion={isOpen()}>
{/* some expandable content */}
</div>
Sophisticated Stores
Since Solid will likely never have React compatibility it is important to integrate well with the ecosystem that is already there.
Stores both bring an easy in-house method of state management and bring Solid's pinpoint updates to solutions you might already be familiar with like Redux and XState.
Stores use nested proxies, with opt in diffing for immutable data, that lets you update one atom of data and only have those specific parts of the view update. Not re-rendering Components, but literally updating the DOM elements in place.
No need for memoized selectors, it works and it works well.
Next Generation Features
Solid has all the next generation features. How about Concurrent Rendering, and Transitions to start?
We've spent the last 2 years developing out a Suspense on the server with Streaming Server-Side Rendering and Progressive Hydration. This setup works amazingly well even when deployed to a Cloudflare Worker.
Best in Class Performance
I was going to let this one go as people get tired of hearing it. After all, this news is several years old at this point.
Solid is the fastest(and often the smallest) JavaScript Framework in the browser and on the server. I won't bore you with the details you can read about it elsewhere.
But we did a survey recently and it seems our users are happy with our performance as well.
Who voted 1? There was more than one of you.
What's Next
1.0 represents stability and commitment to quality, but there is a lot more yet to do. We are working on Solid Start a Vite-based Isomorphic Starter that has all the best practices and Server rendering built in, with the ability to deploy to multiple platforms.
We are also excited to work with Astro. Work has already begun on an integration. There are so many great build tools out there right now and new ways to leverage frameworks like ours. This is a really exciting time.
And while I started this alone 5 years ago. I'm hardly alone now. It is only through the dedicated work of the community that we have a REPL, countless 3rd party libraries to handle everything from drag and drop and animations, to Custom Elements that render 3D scenes.
Solid has been seeing adoption in tooling for IDEs with work being done on Atom and serving as the engine behind Glue Codes. And an early adopter(and perhaps influencer) of Builder.io's JSX-Lite.
Honestly, there are too many people to thank. Those that have come and gone but left a mark. From the early adopters who said encouraging words in our original Spectrum channel that kept me motivated, to the growing team of ecosystem collaborators and core maintainers. A project like this is dead in the water without others believing in it. So you have my deepest thanks.
But I do want to take a moment to make special shoutout to @adamhaile, the creator of S.js and Surplus.js who developed the initial core technology approach used in Solid. It was his research that made this possible and gave me direction to continue to push boundaries.
There is a lot more to do. But in the meanwhile, check out our website, solidjs.com with docs, examples and 40 new tutorials. And come and say hi on our Discord. It's never been easier to get started with Solid.
Top comments (44)
I was always a bit wary of transpiling frameworks, because they usually introduce some magic that adds difficulty to understand what happens. The first incarnation of Angular was the worst I had formerly encountered.
With that in mind, I was ready to dislike SolidJS when I found it two days ago.
However, of those frameworks with magical functionality, SolidJS seems to be the most straight forward, one could even say, solid. Even the transpiled code is easily readable. I've yet to toy around with it a bit more, but for now I like it.
Same! When I first encountered Solid, after years of curmudgeonly disdain for the mystifying effect of JSX, I grudgingly admitted to myself: in this particular instance, I can see the benefit.
Really impressive work @ryansolid ! What was it that signalled the culmination of the first major release?
Honestly it was time. I was going to do this almost 2 years ago and then people were like you gotta do SSR. Once I looked into it I realized it was a fundamental consideration. So I spent 2 years developing out SSR techniques ensuring support for streaming and Suspense on the server. I was finished that around the new year, it's just taken me this long to finish Documentation. Months.
You are not alone. The svelte team predicted SvelteKit would be out in weeks instead of months, and here it is a year later with git issues only growing.
I feel that one especially. I am working on a very similar project and it is an undertaking. The incentive is worth it though. Server rendering configuration and coordination is hard. It is really appealing to have a solution that takes care of those details. I was never one for starters but trying to explain how to get the perfect SSR setup. The problem is there is no one size fits all solution but if we can narrow it down to a couple simple decisions it is hugely beneficial.
Yeah, writing code that is both flexible enough for in-the-wild edge-cases and simple enough for normal use is damn hard.
It sounds like you have wrestled with the same issues, in particular, the ability to deploy to serverless environments.
I always steered clear of SSR as of dubious worth compared to increased complexity, but then I found Sapper and found I was gaining the simplicity of everything being self-contained, and the SSR benefits.
I'm looking forward to trying out what you've got going for Solid SSR.
Working on an article covering AlpineJS right now. Solid is up next. Good timing with the 1.0 release.
(infoworld.com/author/Matthew-Tyson/)
@ryansolid , I'm getting started on the SolidJS article.
Thinking about doing a modest question-and-answer with you.
Let me know if you are interested.
Yeah I'd be down to Q&A style. If possible send me a DM on Twitter or Discord.
Thank you. The reason for it I think is people were basically hand writing stuff like this a decade back. Solid's declarative structure makes it easier to organize your code, but the compiled output is almost exactly what a human would write to optimize some Vanilla code. There are no classes or lifecycle really, just an event system with some scheduling. The only code that gets compiled is the JSX, so your code remains yours. Brutally efficient, brutally simple.
You're right: I did handwrite stuff more or less like that a decade ago. Since there are not too many ways to manipulate the DOM, the result is mostly the same. Though I have to admit the scheduling is quite clever.
I also like that it is very expressive, like using
<For each>seems such an obvious solution once you've seen it.This is great news. I just did a demo yesterday of a SolidJS app I built for internal use at a bank (they don't know it's Solid yet -- they're a React shop). The demo went awesomely, despite having been rushed and the code needed a major refactor. I began that refactor last night.
The new
createStoreis much better than the oldcreateState. That's one of the first things I'm swapping around.I've found a couple of bugs in the docs. I'll report them as soon as I confirm that they're bugs, not just my misunderstanding.
BTW, coming from React and even after having built production Svelte apps more than a year ago (Sapper), I found getting out of the React mindset a lot more difficult than I'd expected. Plenty of frustration around state and signals and when things will re-render. The new documentation is awesome. I snuck back downstairs after my partner went to sleep last night just to get a bit further into the tutorial. Numerous revelations. Thanks!
The future is nuance, rather than there being one perfect tool for every job.
People who were saying React/Redux was the one true way several years ago seemed unaware of the needs of complex, demanding UI applications like digital audio workstations, which need fine-grained reactivity and deep mutable state to perform well enough. (Ableton Live, for instance, is written in Qt, which supports fine-grained reactivity).
On the other hand these things require some rigamarole in terms of getting raw data into the reactive primitives, and that surely affects the debugging experience as well. So I'm sure that top-down immutable state management will remain better for simpler use cases.
It was easier. Seriously.
I had done Templates before that and it just allowed me to keep JavaScript scope and you eventually pull in JavaScript parsers anyway. The truth is no one wants just HTML they want something with JavaScript in there. I knew that as one developer leveraging an existing toolset would be infinitely easier than creating my own almost HTML thing. Like good TypeScript support, Syntax Highlighting, Code formatting. Like Solid code snippets look good on every platform. And no need to maintain my own Parser or Transformer. I literally picked up Babel and was good to go. Everything just works.
Then there are the other aspects. I wrote an article about this but Single File Components I'm not the biggest fan of. You get this sort of overhead of forcing separate files to break things up. There mechanisms to do this. Like Marko has a
<macro>tag but frameworks like Vue and Svelte don't.Also ease of composition patterns of components. I've always like React for that. Things like Render Props. Being able to have a syntax to describe things like For loops without it being a specialized syntax makes it extensible. Like if you've ever tried to use "scoped slots" or "slot props" and equivalent in Vue or Svelte you will sort of see what I mean. It's where the ugliness of these templates come out as there is no syntax for passing variables out and you need to disambiguate like variable scope things like refs and nested scope things like slots. With simply attributes you are forced into series of namespaced keywords that hold special meaning but provide not syntaxtual indicator of their purpose. Like the subtle difference between
this:variableandlet:variable.I think it can be done with an HTML language. Marko is probably the closest to having the full capability. But for a developer working by themselves on a new project. It was a no brainer.
Cool! I'm hopeful about Solid.js becoming a new standard for simpler front-end coding. I've been creating awareness for it since a few months ago to a few communities, albeit I still know little about it.
Quick question. What's the SEO state of Solid.js? Does it basically behaves as a SPA or can I add custom properties and do some cached SSR?
Thank you that is awesome.
You can pre-render pages and then have them hydrate in the browser. It takes a little bit more config. I have some really basic examples in solid-ssr repo. But it's the type of thing we probably need better tools built around to make it easier.
After reading some of your excellent posts I wanted to try SolidJS but chose Svelte instead partly because your promotion of Marko//Fluurt as well confused me. On initial glance they appeared to be competing frameworks - "Wait, what, which one does he want me to use?" I knew nothing about any of them would need to do some research - " or I can just get started with Svelte "
Congrats on the release of 1.0 - it's given me some impetus to give it a try but I am now comfortable with Svelte. Just a heads up that for newbies like me who just want to get started the decision to chose one framework over another can be as simple as that.
Of course. Marko is incredibly good where it's good (MPAs), but JavaScript server rendering is still a topic that is challenging to explain to newcomers.
This won't be the last time you choose to learn a framework. If you had asked me I probably would have directed you to React or Svelte, pre 1.0. Svelte is a great choice for people new to JavaScript Frameworks. The important part is to keep reading and keep learning.
Thanks! Actually I will start learning SolidJS - I have time.
I've been thinking about developing something using JSX or like React, but quicker and lighter and Solid seems to be what I was thinking about. Excited to try it out!
Idea: I was unable to find an
awesomepage like github.com/sindresorhus/awesome for solid. maybe having it below the solid org would be, well, awesome.Awesome to hear. I think the combination of reactivity and JSX makes Solid pretty unique in capability.
Yeah David who handles the community has some ideas here he's been working on the resources section in the website (solidjs.com/resources)
Historically I've been collecting stuff here: github.com/solidjs/solid/blob/main...
But I admit as I've been distracted I haven't been keeping it up to date.
Congratulations on the milestone! You definitely went the extra miles to deliver something very polished, feature-complete and well-documented. Great work.
If I'm being honest though, I am hot and cold on the approach. Mainly because this does not appear to have JavaScript semantics.
I look at the code examples and think, "this can't possibly work" - and obviously, if this were "just JavaScript", it couldn't. I look at the examples and the compiled output, and it looks complicated - to the point that it's not obvious to me how or why this works.
I don't really want to learn the innards of a compiler, and I expect most of the people who will be drawn to this won't want to know and don't care either. Like Vue or Angular, for most people, this will probably be a black box that you have to trust without really understanding how it works.
That's not meant as a criticism per se. There are obviously frameworks that greatly succeed under the same conditions, and this definitely fills a different space than Vue or Angular, avoiding custom syntax and leveraging the developer's existing knowledge of JavaScript. With that one caveat... that it doesn't really work like JavaScript.
Most people won't care, and there's a good chance this framework will be a success. But for me, personally, I don't like using something I can't explain. The traditional JSX transform is very easy to explain, but this is probably as difficult to explain as, say, Svelte, and feels confounding to me, much like Svelte.
I welcome this framework to the crop, but I hope there is still room in the future for frameworks that achieve reactivity without a compile step - something more like Sinuous, but with the S.js magic made more explicit. I know there are ergonomic trade-offs to something like that, and Solid syntax is definitely very visually appealing and feels familiar to React.
For me, personally, I continue to wish for something that achieves reactivity within the confines of JavaScript semantics.
I mean Sinuous started as a fork of the HyperScript version of Solid. You can use Solid exactly the same way. I just strongly don't recommend using Solid that way. You pay the cost not only in ergonomics, but in performance and size. Sinuous has done work to mitigate the latter but it comes at cost of the first 2.
Unfortunately Im not sure without creating a language for it that you can make reactivity cleaner. That was my goal initially to see if reactivity could be reduced to a point where it had a simple onboarding but all the depth to do what is needed. I decided templating was the awkward part. More potential work on compiled DSLs could maybe take this further but I fear it won't satisfy your goal.
When comparing Solid and Sinuous, the only real concern for me is ergonomics. When it comes to performance and size, they are both in the category of "small and fast" - they are both substantially faster and smaller than mainstream frameworks like React or Vue, so a marginal performance difference of 5-10% isn't a deciding factor for me.
Gen Hames (whom I believe you know as heyheyhello on github) is working on something called haptic, which might improve on the ergonomics of reactive state management, making it more explicit and transparent vs e.g. S.js and Sinuous. We'll see if this goes anywhere, but I'm hopeful.
Although I try out and use many of these frameworks on private/hobby projects, when it comes to "work work", my go-to choice is and remains Preact. I can explain to a junior how this works, end-to-end, in an hour - and while, in some ways, there is non-obvious complexity inherent in a framework like this that you have to deal with, such as JSX expressions returning VNodes rather than Elements, what the framework does is very easily explainable.
That simplicity, to me, in a work setting, has tremendous value. Understanding the inner workings of it is empowering - I get a sense of confidence when I see someone unlocking something like Preact or Sinuous when I explain it to them. Whereas with frameworks like Vue or Angular, I get the sense that most people don't really understand (beyond the superficial "it makes HTML") how these work, and either aren't very confident, or sometimes overconfident and disinterested in how it works.
The latter isn't necessarily a problem, if the main objective is to churn out code. But from personal experience, I find the confident developer, who works with tools they can understand, and who can pass on that knowledge, is generally happier, more motivated, and contributes to the team experience in perhaps less tangible ways than just churning out code.
Choosing software components, to me, is as much about the human experience as it is about the technical.
I'm not saying any of this to say anything about your framework, by the way - I'm just trying to explain where my personal angle on this might be coming from.
The amount of effort you've put into tutorials and documentation alone makes your project much more complete than most of the open-source efforts in this space, and worthy of real consideration. 🙂
I guess I don't get it. Or I agree with you except I see Solid as the example of what you are getting at.
I never saw Sinuous doing anything different than Solid except shaving some size on the HyperScript version. Maybe I haven't made it clear. But they have identical ergonomics if you so choose to use Solid that way (other than reactive API, but that's swappable).
But I actually find the compiled output from Solid's JSX much clearer what's going on as less is hidden inside the library. The DOM operations are out in the open and resemble the input code. Almost as if you weren't using a templating engine at all.
Solid came about from my experience maintaining and training people on a large production Knockout app over most of a decade. And a lot of the same lessons learned. Balancing abstraction with control.
This is awesome news. Congrats!
Congrats.
Heads up: The playground is a blank page.
I'm not seeing the same thing. Is this still happening for you?
Yeah, but I think it's because I'm visiting friends and I'm using a chromebox.
Here's the error in console:
Uncaught TypeError: Failed to construct 'Worker': Module scripts are not supported on DedicatedWorker yet. You can try the feature with '--enable-experimental-web-platform-features' flag (see crbug.com/680046)
at new Ht (index.d05cdade.js:1)
at index.d05cdade.js:1
at index.d05cdade.js:1
at index.d05cdade.js:1
at O (index.d05cdade.js:1)
at p (index.d05cdade.js:1)
at index.d05cdade.js:1
at index.d05cdade.js:1
Thanks. I see environments without workers are going to be problematic. I wonder if it has issues with other REPL's since I imagine most use workers. Not sure what a good solution is here.
I shared it internally with the core team. I doubt we can do anything because it seems the issue is a lack of worker support. Maybe we can gracefully degrade the need. Thanks for mentioning it though.
Interestingly, svelte.dev/repl/hello-world?versio... seems to be working ok.
But chromebox is probably left-field enough to not worry about.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.