Ryan Carniato

Hello, congrats on the release of your framework! I myself also wrote a reactive library for my own projects long ago when jquery was still widely used. Anyways, these days I moved from React to Solid.js so I know a bit how Solid works. 1. Solid.js also has "stores" and "createMutable" which allow deep tracking of objects and are also built on Proxy objects. Signals are great for single values, but Solid stores and createMutable are for more complex data. 2. Solid.js doesn't redraw entire components. (It's not like React.) It is fine grained and only updates the minimal exact DOM nodes required. This is why it is so fast and topped benchmarks when it first came out. https://dev.to/ryansolid/introducing-the-solidjs-ui-library-4mck I found https://blog.theodo.com/2023/07/solidjs-beginner-virtual-dom-signals which might be a good intro explanation to it. > Yeah, until you want to add some loops and conditionals in there. That's what regular programming languages are really good at. But it's a trade-off for sure. Solid's <For> and <Show when={}> and <Switch> tags are actually quite nice and very easy to parse visually. Regarding the "gaslighting" comments, I kind of feel the same way as the grandparent. No offense meant and I support everyone coding new open source frameworks, but it does kind of feel like that. I suggest doing a deep dive into Solid and even checking Ryan's blog https://dev.to/ryansolid or YouTube channel. There are a ton of concepts and good ideas to…

Reactivity is magnitudes simpler and more performant than react style state diffing, it's also much harder to write bad performance code because there's no react style re-rendering. The basic form of signal can be just function signal(value) { const subs = [] return { get: () => value, set: (newValue) => { value = newValue subs.forEach(f => f(value)) }, sub: (action) => subs.push(action), } } For building UI, when the component constructor sees a signal object being passed either to a property / children they'll automatically subscribe to the updates of this signal, and update the HTML property / children when there's an update to the signaled value. With this there's almost no overhead beyond setting those stuff yourself with vanilla JS (except for list updates, those still require diffing). Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p

> I'm curious what the problems are with web components that you see? Bitesized explanation from Rich Harris, the author of Svelte: https://twitter.com/Rich_Harris/status/1198332398561353728 It's from 2019, but all the issues are still there. When/If they are going to be solved, it will be by increasingly complex standards that require more and more Javascript for them to just barely function (like they couldn't even participate in form events without additional Javascript). See also a larger discussion by the author of Solid: https://youtu.be/BEWkLXU1Wlc?t=5837 (if the link doesn't open at the timestamp, skip to "Failed Promise of Web Components" at 1:37:17). It's a bit rambling because it was unrehearsed and on stream, but still good. He also shows and discusses other articles like Rich Harris' https://dev.to/richharris/why-i-don-t-use-web-components-2cia and his own https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh You can read them directly, but Ryan gives excellent additional context.

Honestly, SolidJS is one of the most exciting options on the horizon. The creator wrote the vanillajs implementation for the frontend framework benchmarks so he really knows a lot about the performance implications of implementation details. The great thing about Solid is that it's a lot closer to react with hooks and jsx (I feel like Svelte is learning too much non-js stuff). The problem is that it also has its gotchas. It's much "smarter" than react about re-rendering, which means that it memoizes nodes all over the place and doesn't rerender the entire tree and diff all the time. Instead, it's only rerendering the node that changed (and not even the children of that node unless you set up the children correctly—gotcha). But look at the benchmarks... it's solid! I asked Rich Harris (author of Svelte) this: https://twitter.com/jamescuenod/status/1326747369480871941?s=20 Ryan Carniato (author of Solid) makes some comparisons to Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-js-framewor… and also here: https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961c1125a6719…

You can start with the Web Components Community Report: https://w3c.github.io/webcomponents-cg/2022.html Or with opinions like this: https://dev.to/ryansolid/web-components-are-not-the-future-48bh O if you want to go down the technical rabbit hole, you can search for all the issues people have with them, e.g.: https://x.com/Rich_Harris/status/1841467510194843982

At some point, the creator of SolidJS, Ryan Carniato did a stint helping developing Marko.js, a fine-grained reactive / compiled / a bit HTMX-like system, and blogged about that. It's a framework that originated from eBay. I'm now quite interested about the next version of Marko.js, Marko.js 6, and I'm gonna try it for my new project. I'm interested in fine-graned reactivity so Svelte and SolidJS have been on my radar, but the HTMX-style approach appeals to me. Here's something to munch on: https://dev.to/ryansolid/marko-compiling-fine-grained-reactivity-4lk4 https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d https://www.youtube.com/watch?v=Z1dd09rxny4

This is not entirely like the original signals, but using event emitters instead. I found https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p to be a much better ‘from scratch’ example. This is by the maker of SolidJS

> From my perspective, the post-React frameworks have all converged on the same foundational ideas... Using reactivity (e.g. signals) for DOM updates. For an intro from the OG, consider this 6 minute video from Solid [0] or this blog post [1] by Solid's author. 0: https://www.youtube.com/watch?v=cELFZQAMdhQ 1: https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p

From the creator of SolidJS (heavily inspired by Knockout.js by his own confession) & worked on eBay's Marko framework: https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh

Nice to have a connection! It looks like Marko v6 is going to perform incredibly fast, up there with vanilla javascript and solidjs, ahead of Vue, React, and Angular. https://dev.to/ryansolid/marko-compiling-fine-grained-reactivity-4lk4 What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.

As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-ssr-3i94 https://dev.to/this-is-learning/conquering-javascript-hydration-a9f

This is the article series for you (I wrote it so I'm biased): https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-react…

Svelte is so 2020, the new hotness is SolidJS. https://dev.to/ryansolid/solidjs-official-release-the-long-road-to-1-0…

This prompt to check on current Svelte and Solid-js alternatives, resulted in new posts on Marko[1], and OT, on Mini Apps.[2] Thanks! :) EDIT: Hmm, a few minutes later, the Marko post is blank, or not, depending on whether I'm logged it. That's... unexpected. Maybe a rate limit? The working url is https://dev.to/ryansolid/what-has-the-marko-team-been-doing-all-these-… . Too late to delete the post to leave the url clear for someone else to post. :/ [1] https://news.ycombinator.com/item?id=27676785 What Has the Marko Team Been Doing All These Years? Jun14 By Ryan Carniato of Solid, now on ebay's Marko. The interesting discussion at the end (including why Marko didn't catch on) turned up: [2] https://news.ycombinator.com/item?id=27676743 Mini apps: A web developer's exploration into mini apps — apps that are built with web technologies but that do not run in browsers.

There have been many that have hit the front page over the years. If you're not aware of a technology's shortcomings then you're a bad proponent of said technology. They're also almost the antithesis of what the HTMX crowd also preaches as "the one true way" and meanwhile, Wordpressers will continue developing the majority of the world's websites blissfully unaware that either technology even exists. https://dev.to/ryansolid/web-components-are-not-the-future-48bh https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://daverupert.com/2023/07/why-not-webcomponents/ https://paularmstrong.dev/blog/2023/03/11/why-we-do-not-write-web-comp… https://nolanlawson.com/2024/09/28/web-components-are-okay/ https://www.zachleat.com/web/good-bad-web-components/ https://mayank.co/blog/web-components-considered-harmful/ https://adamsilver.io/blog/the-problem-with-web-components/ https://web-highlights.com/blog/are-web-components-dead/ along with some criticisms from very knowledgeable people: https://x.com/youyuxi/status/1839833110164504691 (author of Vue) https://x.com/Rich_Harris/status/1839785839036887361 (author of Svelte) Web Components solve a few problems and introduce a few others, use them when they make sense for your needs.