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 "...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Congrats, godspeed, many happy returns and all that!
Great work!
This is great. Excited to play with it and try to incorporate react query for data fetching.
I'd love to see that. Solid does have an underlying primitive
createResourcethat I think would be the key to that sort of API but I don't if it is 100% compatible. But the end result would be it would instantly work for Suspense and Streaming SSR.Congratulations on this amazing milestone! Amazing to see Solid come through all this way over the years.
Looks great, syntax looks very pleasant to work with. I'll have to try it out sometime.
Amazing! Will try for sure!
Congratulations 🎉👏🎉🎉
Out of topic, does the HMR for solid-element (webcomponent wrapper) works in Vite?
Ahh.. I have no clue. Probably not as written. It was setup for non-ESM HMR like Webpack style. I've found that those differ a bit.
Are there any component libraries available for SolidJS?
There are a few ones in the works. Active development is being discussed in the Discord if you want to check it out. I expect to see the first few in the coming weeks.