I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in.
customElements.define('my-element', class MyElement extends HTMLElement { ... })
I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this feature and that - maybe not - but do we need all those features. Programmers like to write code, so every framework always gets bigger and more complicated.
I understand and respect the problem react is trying to solve, I just don't see it as much different than the js world before async/await and fetch, etc.. callback hell - which I saw as much more prickly issues.
Mithril or Svelte should be all you need. If you're coming from React, I'd recommend trying Mithril first. I've been using it heavily for 5 years now and I'll likely stick with it for at least another 15.
Mithril is reactive out of the box, and just works. It smokes React in every category, but still has an optional JSX integration if that's what you're comfortable with.
If we’re talking about class-based components then I agree with you. React doesn’t do much… maybe some performance benefits, and maybe you can avoid some complex DOM manipulation here and there, but with the extra abstraction required that all might be a wash.
But with functional components I think React gives you something substantially more debuggable than an object instance with random method calls that manipulate the DOM.
React functional components (with hooks) mandate a very specific control flow that probably halves the debugging surface for any given bug, saving time.
You do have to exercise restraint when incorporating third party libraries, but if you can do that it can be a very rapid development environment.
I'm not sure if I'm following, are you saying that class-based components (whether React or not) could be characterized as "an object instance with random method calls that manipulate the DOM", and thus React functional components offer an advantage to them?
Iirc correctly the hooks in functional react are classes under the hood (maybe I’m wrong and it’s functions, been awhile.) The advantage functional react has over class based is reusability. You could reuse classes before and functions within them but it gets harry keeping a clean architecture.
With functional components you can write hooks that allow you to reuse all state logic between components.
I pursued this idea pretty aggressively for a while. What I found is that it was a wonderful fit for small projects, and then became a real drag as the scale/complexity grew, which led me to start thinking in terms of a budget-matching principle [1]
>"having a tough time finding why shouldn't use just custom elements with no framework"
This is exactly what I do on SPA front ends for many of my customers. Of course we use some libs but those have nothing in common with the frameworks, just narrowly scoped solutions. Saves gobbles of time and money.
React itself really hasn't gotten significantly bigger. It's more of a rendering library than a framework.
Custom elements are really neat, and may very well do what you need. The big pain point that React solves (for me at least) is that you get to define your views declaratively instead of imperatively.
Custom elements are just a way to define tags. React solves everything that's inside that class you wrote... and in a better way IMHO. E.g. with custom elements there's a difference between an attribute and a property and it's a PITA.
Last time I used them, web components were incredibly slow. They were so slow to render, after using maybe 2 or 3 of them I realized why nobody is trying to build apps this way. Just isn't there yet. Probably won't be until HTML Imports are merged with JS Imports.
This is a surprising perspective, since we're using web components top-to-bottom to build photoshop on the web, & some of that decision was driven by performance comparisons where web components outperformed react.
It's possible that very naive implementations of web components would render as slowly as you describe - like if you rebuilt the whole DOM tree at every level on every change.
Here is a performance-oriented talk about rendering web components via browser-parsed template literals via Lit (which is how we do it):
I understand and respect the problem react is trying to solve, I just don't see it as much different than the js world before async/await and fetch, etc.. callback hell - which I saw as much more prickly issues.