21 ms·

Solid – A declarative JavaScript library for building user interfaces

373 points by revskill 6y ago

naikus 6y ago
@ryansolid What minimum browser versions does the library support
- ryansolid 6y ago
  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.
aleclarsoniv 6y ago
How hard would it be to get this working with React Native backend?
blickentwapft 6y ago
Essentially react without virtual dom?
- ryansolid 6y ago
  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.
hardwaresofton 6y ago
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-comparing-svelte-and-solid-cbcba2120cea https://medium.com/@ryansolid/javascript-ui-compilers-compar...
- jadbox 6y ago
  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 6y ago
    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..
  - schwartzworld 6y ago
    > This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. 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.
ryansolid 6y ago
Here is an introductory summary of SolidJS: https://dev.to/ryansolid/introducing-the-solidjs-ui-library-4mck https://dev.to/ryansolid/introducing-the-solidjs-ui-library-...
- pax 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        Volunteering?
        g8tor 6y ago
        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.
smarx007 6y ago
There is already a project named Solid led by Tim Berners-Lee: https://solid.mit.edu https://solid.mit.edu
- ryansolid 6y ago
  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.
- hombre_fatal 6y ago
  This SolidJS project already has more legs/traction than that's ever going to have.
- Vinnl 6y ago
  Note that that website is no longer the project home - it has spun off from MIT: https://solidproject.org/ https://solidproject.org/ (Disclosure: I work at Inrupt, the company started by Tim Berners-Lee to support the project's adoption.)
- tasogare 6y ago
  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-data-model https://solidproject.org/for-developers/apps/first-app/4-dat...
  - tannhaeuser 6y ago
    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.
grizzles 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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. :)
obilgic 6y ago
If your library/framework/etc's goal is to make life slightly better, just don't do it. This just looks like React.
- ryansolid 6y ago
  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-ui-library-1mdc https://dev.to/ryansolid/why-solidjs-do-we-need-another-js-u...
  - obilgic 6y ago
    Don't get me wrong, every technical endeavor 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.
    - ryansolid 6y ago
      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.
      - LockAndLol 6y ago
        Don't let him get you down, mate. These types of people who like tearing other projects down for the sake of it litter the internet. If you're having fun, keep going. That's all that matters.
        6y ago
ht85 6y ago
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 6y ago
 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 {displayName()}; or: return {`${state.user.firstName} ${state.user.lastName}`}; or: // this expensive to calculate: const displayName = createMemo(() => `${state.user.firstName} ${state.user.lastName}`) return {displayName()};
jarpineh 6y ago
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 6y ago
  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.
louisch 6y ago
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.
tarkin2 6y ago
People loved React because of VirtualDOM. Now JS libraries advertise themselves based having no VirtualDOM. Can someone explain this to me?
- deleted 6y ago
  [deleted]
- curist 6y ago
  VirtualDOM is more of an implementation detail IMO. What I love about React is for its declarative API and we can compose components easily.
  - ryansolid 6y ago
    I agree. I love that about React. I think all UI libraries could learn a ton from React.https://medium.com/@ryansolid/what-every-javascript-framework-could-learn-from-react-1e2bbd9feb09 https://medium.com/@ryansolid/what-every-javascript-framewor... 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.
    - tarkin2 6y ago
      So React needs VirtualDOM? Do people want React not to be dependent on VirtualDOM. Is there a reason/benefit?
      - dgellow 6y ago
        You might get some answers here, from an SO comment written by virtual-dom’s author: https://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode#23995928 https://stackoverflow.com/questions/21109361/why-is-reacts-c... 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.
preommr 6y ago
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 6y ago
  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.
- pdimitar 6y ago
  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.
christophilus 6y ago
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 6y ago
  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 6y ago
    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.
fouc 6y ago
https://github.com/ryansolid/dom-expressions/tree/master/packages/hyper-dom-expressions https://github.com/ryansolid/dom-expressions/tree/master/pac... Looks great!
- ryansolid 6y ago
  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.
batiste 6y ago
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 6y ago
  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.
antihero 6y ago
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 6y ago
  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.
Tade0 6y ago
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__ 6y ago
  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 6y ago
    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.
  - sreekotay 6y ago
    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.
quantummkv 6y ago
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 6y ago
  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.
orange8 6y ago
HTML - A declarative markup language for building user interfaces. CSS - A declarative, domain-specific language for styling user interfaces.
- andarleen 6y ago
  JS devs like to reinvent the wheel.
- mixedCase 6y ago
  Solid - A declarative JS library for building highly-interactive, logic-driven user interfaces. Better?
  - ryansolid 6y ago
    Probably. I lifted it from React when I opened sourced the project because I liked how generic it was.
  - orange8 6y ago
    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-the-background-color-of-the-body 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?
- kroltan 6y ago
  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.
dustingetz 6y ago
Explain the big picture abstraction differences between this and React in two sentences? I don't care about compiler vs interpreter implementation details.
- ryansolid 6y ago
  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 6y ago
    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 6y ago
      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.
k__ 6y ago
"Using JSDOM or similar we can run Solid on the server" Doesn't sound very promising tbh.
- ryansolid 6y ago
  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__ 6y ago
    Nice, thanks for the quick reply!
    - ryansolid 6y ago
      Warning performance there isn't stellar there yet but it is my current active area of research.
keb_ 6y ago
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 6y ago
 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 6y ago
 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.
broadwall 6y ago
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?
- ryansolid 6y ago
  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.
- irrational 6y ago
  This seems like a silly issue. At one time there was no DevTool support for any of those other tools you mentioned.
  - rk06 6y ago
    This is not a silly issue. Lack of devtools is expected for a new framework, however, it is worth asking for, especially if you are considering it for production
- _bxg1 6y ago
  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 6y ago
    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.
RyanGoosling 6y ago
All these transient JS libraries all for what? Making state updates... easier? It's already easy with what's available from the standards.
irrational 6y ago
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.
zelphirkalt 6y ago
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.
_bxg1 6y ago
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 6y ago
 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?
 - _bxg1 6y ago
 Well in React the rendering logic could still just be plain functions, though I guess technically those are considered "functional components".
 - amelius 6y ago
 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 6y ago
 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.
dzonga 6y ago
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.
deleted 6y ago
[deleted]
torb-xyz 6y ago
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).
- ryansolid 6y ago
  You can use HyperScript(createElement) version. You just forgo the advantages of compilation - better dx(less need for explicit wrapping), better performance(optimized code path), and smaller bundle size (more directed code). Solid's JSX does not compile to HyperScript like React. HyperScript is a different slightly de-optimized experience.
- mudge 6y ago
  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 6y ago
    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.
saiojd 6y ago
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?
- atfzl 6y ago
 state changes are not tracked by diffing, it is much more interesting. You can read about it here https://www.atfzl.com/understanding-solid-reactivity-basics https://www.atfzl.com/understanding-solid-reactivity-basics
 - saiojd 6y ago
 Thanks, that makes a lot of sense (basically Mobx but fine-grained). When I mentioned diffing, I meant for updating state objects like lists. Your `<For/>` element only updates if a new list is created, but only re-renders the changed elements. I assume this is accomplished by diffing the old and the new list?
 - ryansolid 6y ago
 Yes you are correct. Use diffing here actually very similar to VDOM libraries. It was more performant(and consistent) than just propagating the change purely through manipulation of a proxy. Especially if you consider things like batching.
sreekotay 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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.
aabbcc1241 6y ago
Solid looks like Surplus.js mix react.js
- ryansolid 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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.
carapace 6y ago
This looks very interesting! With new projects and languages and frameworks a good angle to evaluate is, "what's the debug story like?"
- ryansolid 6y ago
  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.
sdegutis 6y ago
> 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 6y ago
  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-explanation-of-mobservable-55995262a254 https://hackernoon.com/becoming-fully-reactive-an-in-depth-e...

373 points by revskill 6y ago

naikus 6y ago

@ryansolid What minimum browser versions does the library support

ryansolid 6y ago
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.

aleclarsoniv 6y ago

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

blickentwapft 6y ago

Essentially react without virtual dom?

ryansolid 6y ago
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.

hardwaresofton 6y ago

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

jadbox 6y ago
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 6y ago
  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..
- schwartzworld 6y ago
  > This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. 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.

ryansolid 6y ago

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

pax 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      Volunteering?
      - g8tor 6y ago
        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.

smarx007 6y ago

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

ryansolid 6y ago
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.
hombre_fatal 6y ago
This SolidJS project already has more legs/traction than that's ever going to have.
Vinnl 6y ago
Note that that website is no longer the project home - it has spun off from MIT: https://solidproject.org/ https://solidproject.org/ (Disclosure: I work at Inrupt, the company started by Tim Berners-Lee to support the project's adoption.)
tasogare 6y ago
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-data-model https://solidproject.org/for-developers/apps/first-app/4-dat...
- tannhaeuser 6y ago
  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.

grizzles 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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. :)

obilgic 6y ago

If your library/framework/etc's goal is to make life slightly better, just don't do it. This just looks like React.

ryansolid 6y ago
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-ui-library-1mdc https://dev.to/ryansolid/why-solidjs-do-we-need-another-js-u...
- obilgic 6y ago
  Don't get me wrong, every technical endeavor 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.
  - ryansolid 6y ago
    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.
    - LockAndLol 6y ago
      Don't let him get you down, mate. These types of people who like tearing other projects down for the sake of it litter the internet. If you're having fun, keep going. That's all that matters.
      - 6y ago

ht85 6y ago

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 6y ago
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 {displayName()}; or: return {`${state.user.firstName} ${state.user.lastName}`}; or: // this expensive to calculate: const displayName = createMemo(() => `${state.user.firstName} ${state.user.lastName}`) return {displayName()};

jarpineh 6y ago

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 6y ago
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.

louisch 6y ago

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.

tarkin2 6y ago

People loved React because of VirtualDOM. Now JS libraries advertise themselves based having no VirtualDOM. Can someone explain this to me?

deleted 6y ago
[deleted]
curist 6y ago
VirtualDOM is more of an implementation detail IMO. What I love about React is for its declarative API and we can compose components easily.
- ryansolid 6y ago
  I agree. I love that about React. I think all UI libraries could learn a ton from React.https://medium.com/@ryansolid/what-every-javascript-framework-could-learn-from-react-1e2bbd9feb09 https://medium.com/@ryansolid/what-every-javascript-framewor... 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.
  - tarkin2 6y ago
    So React needs VirtualDOM? Do people want React not to be dependent on VirtualDOM. Is there a reason/benefit?
    - dgellow 6y ago
      You might get some answers here, from an SO comment written by virtual-dom’s author: https://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode#23995928 https://stackoverflow.com/questions/21109361/why-is-reacts-c... 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.

preommr 6y ago

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 6y ago
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.
pdimitar 6y ago
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.

christophilus 6y ago

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 6y ago
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 6y ago
  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.

fouc 6y ago

https://github.com/ryansolid/dom-expressions/tree/master/packages/hyper-dom-expressions https://github.com/ryansolid/dom-expressions/tree/master/pac... Looks great!

ryansolid 6y ago
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.

batiste 6y ago

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 6y ago
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.

antihero 6y ago

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 6y ago
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.

Tade0 6y ago

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__ 6y ago
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 6y ago
  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.
- sreekotay 6y ago
  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.

quantummkv 6y ago

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 6y ago
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.

orange8 6y ago

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

andarleen 6y ago
JS devs like to reinvent the wheel.
mixedCase 6y ago
Solid - A declarative JS library for building highly-interactive, logic-driven user interfaces. Better?
- ryansolid 6y ago
  Probably. I lifted it from React when I opened sourced the project because I liked how generic it was.
- orange8 6y ago
  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-the-background-color-of-the-body 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?
kroltan 6y ago
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.

dustingetz 6y ago

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

ryansolid 6y ago
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 6y ago
  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 6y ago
    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.

k__ 6y ago

"Using JSDOM or similar we can run Solid on the server" Doesn't sound very promising tbh.

ryansolid 6y ago
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__ 6y ago
  Nice, thanks for the quick reply!
  - ryansolid 6y ago
    Warning performance there isn't stellar there yet but it is my current active area of research.

keb_ 6y ago

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 6y ago
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 6y ago
 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.

broadwall 6y ago

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?

ryansolid 6y ago
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.
irrational 6y ago
This seems like a silly issue. At one time there was no DevTool support for any of those other tools you mentioned.
- rk06 6y ago
  This is not a silly issue. Lack of devtools is expected for a new framework, however, it is worth asking for, especially if you are considering it for production
_bxg1 6y ago
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 6y ago
  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.

RyanGoosling 6y ago

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

irrational 6y ago

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.

zelphirkalt 6y ago

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.

_bxg1 6y ago

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 6y ago
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?
- _bxg1 6y ago
 Well in React the rendering logic could still just be plain functions, though I guess technically those are considered "functional components".
- amelius 6y ago
 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 6y ago
 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.

dzonga 6y ago

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.

deleted 6y ago

[deleted]

torb-xyz 6y ago

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

ryansolid 6y ago
You can use HyperScript(createElement) version. You just forgo the advantages of compilation - better dx(less need for explicit wrapping), better performance(optimized code path), and smaller bundle size (more directed code). Solid's JSX does not compile to HyperScript like React. HyperScript is a different slightly de-optimized experience.
mudge 6y ago
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 6y ago
  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.

saiojd 6y ago

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?

atfzl 6y ago
state changes are not tracked by diffing, it is much more interesting. You can read about it here https://www.atfzl.com/understanding-solid-reactivity-basics https://www.atfzl.com/understanding-solid-reactivity-basics
- saiojd 6y ago
 Thanks, that makes a lot of sense (basically Mobx but fine-grained). When I mentioned diffing, I meant for updating state objects like lists. Your `<For/>` element only updates if a new list is created, but only re-renders the changed elements. I assume this is accomplished by diffing the old and the new list?
 - ryansolid 6y ago
 Yes you are correct. Use diffing here actually very similar to VDOM libraries. It was more performant(and consistent) than just propagating the change purely through manipulation of a proxy. Especially if you consider things like batching.

sreekotay 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.

aabbcc1241 6y ago

Solid looks like Surplus.js mix react.js

ryansolid 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.

carapace 6y ago

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

ryansolid 6y ago
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.

sdegutis 6y ago

> 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 6y ago
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-explanation-of-mobservable-55995262a254 https://hackernoon.com/becoming-fully-reactive-an-in-depth-e...