solid-docs VS webcomponents

React has introduced measures like batching state updates, background concurrent rendering and memoization to tackle this. My opinion is that the best way to solve the problem is by improving their reactivity model. The app needs to be able to track the code that should be re-run on updating a given state variable and specifically update the UI corresponding to this update. Tools like solid.js and svelte work in this manner. It also eliminates the need for a virtual DOM and diffing.

Similarly to Promises/A+, this effort focuses on aligning the JavaScript ecosystem. If this alignment is successful, then a standard could emerge, based on that experience. Several framework authors are collaborating here on a common model which could back their reactivity core. The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

Solid.js is a very performant web framework that shares some similarities with React. For example, both use JSX, utilizing the function-based approach to components, but instead of using Virtual DOM, it converts your code to vanilla JS. Still, it is more famous for its approach to fine-grained reactivity by utilizing signals, memos, and effects. Still, the signal is the simplest and most known primitive of Solid. They contain value along with their getter and setter functions, allowing the framework to observe and update the changes as needed in the exact location in the DOM, unlike React, which re-renders the whole component.

Two well-known JavaScript frameworks and libraries used for creating user interfaces are React.js and Solid.js. Solid.js, a lightweight reactive library, prioritizes fine-grained reactivity and efficient rendering through a reactive programming model. However, React.js, which was developed by Facebook, is well known for its declarative architecture based on components and its handling of the virtual DOM (Document Object Model). Different approaches to state management and reactivity set these tools apart, even though they both enable developers to create dynamic and interactive web apps.

Solid.js like Svelte is quite new when compared to React, Angular, and Vue however it might be that pocket Hercules we've all been ignoring because we are so addicted to other frameworks. Solid.js is an interesting framework that deserves to be a part of this discussion. Solid.js pioneered the concept of signals when other Javascript frameworks made reactivity and state management a nightmare for developers, a factor that has contributed to the growth of Solid. Solid.js is incredibly easy to adopt and it aims for a simpler syntax and learning curve compared to other frameworks. It emphasizes the use of pure Javascript functions and avoids concepts like hooks.

React Server Components are the poster child for that trend, but other frameworks such as Solid or Qwik rethink client-server interactions from the ground up.

If you aren't married to the react paradigm, I had a great time with solid.

Frontend : SolidJs.

It's not all that shiny. Web components have global names (you should pretty much apply a prefix/namespace if you want to work with others) and managing multiple version of the same component in the same page is an issue in any non trivial codebase (either use a different name per version or fix all breaking changes at once during the upgrade, unless the draft about scoping web elements became standard https://github.com/WICG/webcomponents/blob/gh-pages/proposal... )

I've recently just started playing with Web Components without a build environment. Meaning, no npm, no bun, no webpack, etc, and no dependencies; in typescript. Intellij can autocompile down to js and the browser view injects a small onchange handler for live updates when developing. So far no problems.

The only thing holding web components back seems to be HTML Modules; being able to link to a .html file instead of a .js file to import a web component. Because of this if you want to use templates or anything more complicated you need to do the ugly inject of .innerHtml = `...`, which I thought would be a problem but the IDE parses the template string very nicely. It would be great to make a component in HTML and any javascript you would put in a tag. It seems like there a lot of bureaucracy involved in getting HTML Modules out the door since its been eight years.<p><a href="https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md#high-level-summary">https://github.com/WICG/webcomponents/blob/gh-pages/proposal...</a>

We're trying to advocate for greater flexibility in cross-component styling. One proposal is "open styleable shadow-roots" which would be an opt-in to let styles from above a component to apply to it's shadow root. I think this would help migration in situations where app teams are currently using global stylesheets.

Feedback and support of the need for something like this would help a lot: https://github.com/WICG/webcomponents/issues/909

))

Part 1.

> I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it

Of course not. None of the criticism towards Web Components ever mentions "connectedCallback", or how it should be named differently.

Do you know the actual reason so few are using them? Let's skip the atrocious not-really-high-level not-really-low-level imperative API that they offer.

How about:

- 13 years after introduction they still need 20 more specs to try and patch just some of the holes in their original design: https://w3c.github.io/webcomponents-cg/2022.html

- Shadow DOM is infecting every spec so that the actual useful specs like Scoped CSS have to be delayed almost indefinitely to try and figure out how to work with this abomination of a design

To quote the report linked above, "many of these pain points are directly related to Shadow DOM's encapsulation"

- The amount of specs that are required to make them work, barely, and be "good web citizens". And the amount of APIs.

Oh, you want your custom input to a) be able to send its data in a form, and b) be accessible to a label outside of your component? Well, there's a separate API for a) and there's some separate future API for b). And meanwhile your custom button won't be able to submit your form, sorry, it's a 4-year old issue with no solution: https://github.com/WICG/webcomponents/issues/814

And all that despite the fact that there are already a dozen specs covering web components, and dozens more on their way.

- Web Components ar HTMLElement. It means you cannot use them inside SVGs.

This is impossible:

The lit-plugin in for VS Code offers syntax highlighting, jumpt-to-definition, etc: https://marketplace.visualstudio.com/items?itemName=runem.li...

Prettier already supports HTML in html`` strings, likewise, CSS.

> Is there a way in Lit to write the templates in regular HTML rather than a string?

This would require a compiler. You would need to load the HTML into the JS module graph and JS can't do that yet, though there is a proposal for it: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Template in HTML also have the problem of the data not being in scope as it is in JS, and there not being an expression language. So you ned up having to re-implement a lot of JS embedded into the HTML syntax, which then preferences a compiler-based approach to make fast. It turns out to be a lot simpler to embed HTML in JS.

It's more than just sugar now. You can't even write web components functionally: https://github.com/WICG/webcomponents/issues/587

gzip/brotli handles this very well, but it still is text to parse through.

Some form of declarative CSS module scripts would help a lot. A feature request for that here: https://github.com/WICG/webcomponents/issues/939

In the past I've seen this one:

https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Perhaps there are more recent versions.

I liked the spirit of the proposal, but never studied it.