They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way).

There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself:

https://github.com/WebReflection/domdiff

https://github.com/WebReflection/uhtml

The JS framework benchmark shows these two are among the top performers.

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

Thanks for the insights though, I wasn't aware they were doing all of that.

> Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues.

Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.

> I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.

I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon.

Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.

Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.

Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.

This is a good start:

https://reactjs.org/docs/faq-internals.html

https://reactjs.org/docs/reconciliation.html

Thanks.