
Solid – A declarative JavaScript library for building user interfaces - revskill
https://github.com/ryansolid/solid
======
christophilus
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.

~~~
julianeon
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.

~~~
christophilus
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.

------
hardwaresofton
Solid is another smart-compiler, virtual-dom-less frontend component building
library.

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...](https://medium.com/@ryansolid/javascript-ui-compilers-comparing-
svelte-and-solid-cbcba2120cea)

~~~
jadbox
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).

~~~
ryansolid
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..

------
saiojd
I've been playing around with your library for the last hour and so far it's
excellent, pretty what I had hoped for after working with React for a while.
The performance of individual renders is one area of improvement but I think
the main contribution is the clarity the update model provides.

React works well until you try to avoid re-rendering and then it really falls
appart. For example, updating a context re-renders the whole component chain
from producer to consumer, and trying to block useless re-renders with
shouldComponentUpdate easily leads to mistakes where children don't update
when they should. Since React rendering use lazy evaluation of JSX
expressions, tracking who exactly updates and when is much harder than what it
might seem initially (akin to tracking mutations in a language with lazy
evaluation). As this library actually tracks dependencies and only re-renders
what you want, all of this bloat is avoided. One aspect that impresses me in
particular is that JSX expressions actually return real DOM nodes, making it
easy to keep references to them for imperative operations (not a big deal but
so much nicer than React refs).

I'm wondering why you opted for the setState API rather than a nicer
imperative API like Mobx. From what I can gather, state changes are tracked by
diffing? Why not just return a proxy?

~~~
ryansolid
I do return a proxy. It's just readonly. I really like the unidirectional data
flow and explicit read write segregation of react. This adds so much control
without having to add Framework like control mechanisms. I know it isn't easy,
but it something that makes the solution elegant in the end. I think that
passing data should also mean the choice of passing the ability to update it.
That is a problem I have with almost all reactive implementations in libraries
today. I think React has that part just right.

~~~
saiojd
I'm not sure I understand your argument in favor of setState correctly. By
splitting the state into two parts (a read-only view, and a setState function
to update it), isn't the opposite being accomplished? It is now possible to
pass the data without passing the ability to update it, or vice-versa. Which
could very well be desirable but could be accomplished by other means (i.e.
leaving to the parent the choice of passing a read-only or a mutable proxy).
Settings aside the superficial issue of syntax, the main thing I dislike about
the setState interface is for updating things like lists, where you need to
perform a full copy just to insert one element. That being said I haven't yet
looked into how exactly you handle lists.

~~~
ryansolid
I mean it's basically the same thing as you do with React. You create lens
functions more or less to handle get/set over the state object. Solid's
setState has a lot more capability than React's handling nested updates with
an ImmutableJS or Immer inspired API. The clever part here is immutable
libraries already have API patterns to describe mutation so I just apply them
here. So instead of spreading everything and cloning you keep the mutation
locality for performance but keep the control of immutability.

Also don't be worried about copying the array that much. I'm doing that in the
JS Framework Benchmark and it's still about the fastest with 10k items. The
real key is identifying where you don't need to update the list at all just
the items in it. That being said you can do an update without copying the
array like this:

setState('list', state.list.length, newItem);

Granularity of performance isn't a silver bullet. Being fine-grained doesn't
necessarily make everything faster (especially creation). The power is that
granularity is arbitrary so it can be maximized to the type of situation,
completely independent of component structure.

~~~
saiojd
That makes sense. It is mostly the O(n) rerendering which is expensive, not
the array copy. With regards to superficial/syntactic issues now, I just don't
see the advantage of:

`setState('list', state.list.length, newItem);`

over

`list.push(newItem);`

Considering that the two operations can be otherwise equivalent when using
proxies (from what I understand).

~~~
ryansolid
It comes down to control and immutability. I know not everyone agrees with
this but I believe it's fundamental.

You can use the "Immer" syntax of setState if you want:

setState(s => { s.list.push(data); });

But in some cases it is more expensive. Like a splice will per row will
trigger the proxy to tell you they've all shifted a position. Where as just
setting the array only hits the proxy once. Sure Solid batches the updates
from the call but it's still unnecessary tracking. Solid lazily decides
whether state should be made into a reactive atom based on whether it is
referenced in a tracking scope.

------
keb_
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.

~~~
ryansolid
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.

~~~
lhorie
Disclaimer: I'm that Leo ^ :)

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.

~~~
ryansolid
Thank you as always. Early days spent so much time justifying things,
everything became these expositions. Time to tighten up.

------
tarkin2
People loved React because of VirtualDOM.

Now JS libraries advertise themselves based having no VirtualDOM.

Can someone explain this to me?

~~~
cocktailpeanuts
People loved React because it solved a problem. They just happened to solve it
using virtual DOM.

but theses next generation frameworks are showing that there's a better way to
solve the same problem.

~~~
tarkin2
VirtualDOM allowed you to update the dom with better performance than before.
Is there now a better technique? Why is it better than VirtualDOM?

~~~
lukeramsden
This is a good talk on the matter from the creator of Svelte himself, if
you're interested:
[https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao)

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.

~~~
olah_1
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.

~~~
EGreg
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.

~~~
uryga
why do you consider Hooks a "workaround around [React's] initial concepts"?

~~~
ryansolid
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.

~~~
uryga
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

~~~
ryansolid
I have the article for you: [https://indepth.dev/finding-fine-grained-
reactive-programmin...](https://indepth.dev/finding-fine-grained-reactive-
programming/) It's a bit dense at times but I try my best to cover the whole
spectrum and how it relates to familiar libraries.

------
_bxg1
Maybe I just need to spend more time studying the material, but I struggle to
see how these precompiled frameworks can handle any arbitrary state change one
might write into their JS rendering logic.

For example: suppose I want to take an arbitrary JSON structure, walk the
entire JSON tree, and render it on the page as a tree of nested elements -
i.e. a new subtree of divs for each array or object. None of that layout is
known ahead of time, and it can take any shape - be any depth, breadth, etc.
Intuitively it seems like very little can be known ahead of time for
compilation purposes. Can Solid handle this case? Genuinely curious.

~~~
have_faith
It's my understanding that regardless of the complexity of your custom JSON
data at some point while parsing the tree you have a line that says "if obj is
of this type, then render this component for this node", all Svelte/Solid etc
need to know is that this is the line where a Component is being assigned to a
variable that is going to be rendered in the template.

Or are you saying you want a layout rendered from JSON without first defining
the possible components as Svelte/Solid/React components etc? As I think that
defining components explicitly is a central part of all of the front-end
frameworks, compiler or otherwise?

~~~
amelius
Consider the following pseudo-code:

    
    
        list2 = bubble_sort(list1)
        render(list2)
    

Now suppose the user deletes one item in list1.

The question is now:

Will the update trigger a new bubble sort?

Will the update do something smarter, like just delete the DOM element?

~~~
have_faith
There's usually no render function to call in these types of frameworks as far
as I understand (my experience being a little Svelte).

I imagine in your scenario the psuedo code to achieve what you want would be
written.

    
    
      list2 = bubble_sort(list1)
      removeItem = () => delete list2[random index]
      ...
      <for each list2 render div>
    

The compiler will see a change to the list2 variable anywhere that removeItem
is called and annotate the code to make the appropriate changes to the dom in
the function call and the bubble_sort line will never be re-run unless it was
explicitly added to the removeItem function.

~~~
amelius
Note that the item is deleted from list1. The framework should (I suppose)
track that list2 depends on list1 through bubble_sort(). Are the dependencies
implicit? Or should they be declared explicitly?

~~~
ryansolid
Generally implicitly either through proxy or get method read. Solid provides
an explicit API as well.

------
jarpineh
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.

~~~
ryansolid
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.

------
ryansolid
Here is an introductory summary of SolidJS:
[https://dev.to/ryansolid/introducing-the-solidjs-ui-
library-...](https://dev.to/ryansolid/introducing-the-solidjs-ui-library-4mck)

~~~
pax
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.

~~~
ryansolid
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.

~~~
g8tor
Clear Docs is important because they say we spend 1x developing a product and
10x marketing it. In the developer experience world, docs are marketing.

Also, polished product and polished code deserve a polished set of docs. Just
sayin'!

~~~
ryansolid
Volunteering?

~~~
g8tor
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.

------
Tade0
This (and similar libraries) is the way forward.

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.

~~~
k__
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".

[1] [https://www.swyx.io/writing/js-third-
age/](https://www.swyx.io/writing/js-third-age/)

~~~
ryansolid
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.

------
smarx007
There is already a project named Solid led by Tim Berners-Lee:
[https://solid.mit.edu](https://solid.mit.edu)

~~~
tasogare
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."

[1] [https://solidproject.org/for-developers/apps/first-
app/4-dat...](https://solidproject.org/for-developers/apps/first-app/4-data-
model)

~~~
tannhaeuser
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.

------
louisch
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.

------
dzonga
as an ex frontend developer. this looks like a great library. i'm sure people
won't understand, why this exists i.e JS fatigue. reason, being the current
libraries don't solve all problems. till you've libraries that have good cpu
performance, no build steps, great syntax. people will keep spinning out JS
libraries. anyways great big-up to the author.

------
quantummkv
I am digging this. The main issue I personally have with svelte is that it
goes into a completely different API design than React.

The closeness with the React design makes it better than svelte imo.

~~~
ryansolid
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.

------
grizzles
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.

~~~
ryansolid
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.

~~~
grizzles
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](https://github.com/colshacol/storage-changed)

~~~
ryansolid
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](https://codesandbox.io/s/solid-react-hoc-8m2yd)

If anything there is just so much to document.

~~~
grizzles
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. :)

~~~
ryansolid
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.

------
broadwall
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?

~~~
_bxg1
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.

~~~
ryansolid
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.

~~~
_bxg1
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.

~~~
ryansolid
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.

------
ht85
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?

    
    
        setState({
          displayName: `${state.user.firstName} ${state.user.lastName}`
        })
    

If you simply do `const displayName = ...` in the component, will the
component update properly?

~~~
ryansolid
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.

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>;

------
batiste
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](https://github.com/batiste/blop-language) Maybe I should get rid of
the virtual DOM lib. I use?

~~~
ryansolid
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.

------
irrational
I'm glad to see continued experimentation in this space. I'd hate to think
that React is the best we can come up with.

------
orange8
HTML - A declarative markup language for building user interfaces.

CSS - A declarative, domain-specific language for styling user interfaces.

~~~
mixedCase
Solid - A declarative JS library for building highly-interactive, logic-driven
user interfaces.

Better?

~~~
orange8
Short answer: worse.

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...](https://stackoverflow.com/questions/42464888/how-do-i-change-the-
background-color-of-the-body).

> 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?

------
preommr
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.

~~~
Aeolun
The problem is more in the huge number of renders react does if you don’t do
everything perfectly. In a large application it gets steadily slower.

------
fouc
[https://github.com/ryansolid/dom-
expressions/tree/master/pac...](https://github.com/ryansolid/dom-
expressions/tree/master/packages/hyper-dom-expressions)

Looks great!

~~~
ryansolid
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.

------
antihero
Can this be used with things like mobx/mobx-state-tree? Absolutely having a
blast with MST.

Also, does lack of vdom mean a project like react-native could never really
come from this?

~~~
ryansolid
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.

------
sdegutis
> Whenever any dependency changes the State value will update immediately.
> Each setState statement will notify subscribers synchronously with all
> changes applied.

If two things change that both trigger a third thing to change, how does this
efficiently prevent the third thing from updating twice needlessly? I'm
imagining this becoming an exponential problem in real apps, where hundreds of
components are re-updated needlessly at every UI interaction.

~~~
ryansolid
The reactive graph is a push/pull system as it updates similar to MobX. This
is a great article on the subject: [https://hackernoon.com/becoming-fully-
reactive-an-in-depth-e...](https://hackernoon.com/becoming-fully-reactive-an-
in-depth-explanation-of-mobservable-55995262a254)

------
torb-xyz
Is it possible to use Solid with just plain JavaScript/TypeScript (like using
createElement with React)?

I generally find those far more readable than JSX (and is one of the reasons I
think SwiftUI and Flutter code looks nicer than React).

~~~
mudge
It sounds to me that you are looking for Webscript:
[https://mudgen.github.io/webscript/docs/](https://mudgen.github.io/webscript/docs/)

Webscript does work with SolidJS nicely.

~~~
torb-xyz
Probably should have specified, but a big ting I'm looking for is sull
TypeScript support in this regard.

Webscript looks really cool, but it doesn't look very TypeScript-friendly.

------
sreekotay
One minor thing I might consider is more examples with animation in UI ---
it's a place where most apps want to go but have trouble doing
elegantly/performantly.

~~~
ryansolid
I agree completely. I left an early github issue open with some examples. It
just isn't my forte. I've worked with frontend guys who were mostly CSS
ninja's and we never relied on framework mechanisms beyond applying some
classes etc. I just lack the base knowledge to know what the expectation is
here. I know Svelte has a very impressive system. I could look at doing
something similar with Solid just not sure where to start.

~~~
sreekotay
It's a dumb example, animated lists transition are kind of a good go to...
[https://svelte.dev/tutorial/animate](https://svelte.dev/tutorial/animate) as
is [https://dev.to/buhrmi/svelte-component-
transitions-5ie](https://dev.to/buhrmi/svelte-component-transitions-5ie)

~~~
ryansolid
Yeah I guess I mean more I don't understand what it takes mechanically to
support those types of transitions. It makes sense to me but I also feel like
there would be a lot of details in a generalizable solution. Super interesting
though.

~~~
sreekotay
I think that's exactly right. it ends up being a LOT of super specific,
fragile code --- so kind of interersting thought to see if you can make them
elegant/easy/emergent in the library/framework itself.

------
carapace
This looks very interesting!

With new projects and languages and frameworks a good angle to evaluate is,
"what's the debug story like?"

~~~
ryansolid
Yep. I agree in practice Solid has some work to do here. The basics are think
are reasonable in that we are dealing with your expressions in the template
and real DOM nodes. So just drop a breakpoint in that sucker. Sort of return
to how simple that was in jQuery/Backbone days.

It never is that simple mind you. I have an open issue around Dev Tools etc...
We need to do better given the expectations of modern JS libraries.

------
blickentwapft
Essentially react without virtual dom?

~~~
ryansolid
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.

------
k__
_" Using JSDOM or similar we can run Solid on the server"_

Doesn't sound very promising tbh.

~~~
ryansolid
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.

~~~
k__
Nice, thanks for the quick reply!

~~~
ryansolid
Warning performance there isn't stellar there yet but it is my current active
area of research.

------
aleclarsoniv
How hard would it be to get this working with React Native backend?

------
naikus
@ryansolid What minimum browser versions does the library support

~~~
ryansolid
As is probably evergreen browsers to use all features. I use proxies which are
notoriously hard to polyfill. It is possible to avoid them but I was not
taking IE in mind after that. So while possible to support older browsers with
Babel unclear what all the polyfills that would be necessary.

------
aabbcc1241
Solid looks like Surplus.js mix react.js

~~~
ryansolid
Yep more or less. I was working with Adam, Surplus' author, for a bit before
he didn't have time to work on the project further. I've take a different tact
now with the reactive system and improved the rendering technique a bit. But
he definitely deserves the credit for pioneering the JSX approach 4 years ago
now. My initial JSX work was generalizing it for other reactive libraries and
then it just grew to this.

~~~
aabbcc1241
I see Solid uses proxy to 'get' and 'notice update' the state. This seems
providing a better DX than s-js. However, Solid require developer to
explicitly use 'react style/hook' to update the state.

Why not also use proxy to 'set' and 'notice update' on the state?

~~~
ryansolid
I'm big on read/write segregation and explicit mutation. With simple signals
you have this naturally. Once you move to a nested tree you can lose this.
Keeping this control allows us to adopt immutability patterns and enforce
unidirectional flow. To me this is the most sane way to deal complex
reactivity.

~~~
aabbcc1241
I agree, then the way to read and update state with dependency tracing in
solid seems meeting the sweet spot of the s-js and elm/react style.

------
RyanGoosling
All these transient JS libraries all for what? Making state updates...
_easier_? It's already easy with what's available from the standards.

------
dustingetz
Explain the big picture abstraction differences between this and React in two
sentences? I don't care about compiler vs interpreter implementation details.

~~~
ryansolid
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.

~~~
sreekotay
Very cool work! And great performance. Funny - during quarantine I've been
playing with the OPPOSITE. A no build, runtime only reactive JS engine...

Would love to compare notes - you can check out (very much WIP progress) at
[https://github.com/sreekotay/reefer](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...

~~~
ryansolid
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.

------
zelphirkalt
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.

