I also define a `render()` and extend my own parent, which does a `replaceChildren()` with the render. And, strangely, I also call the processor `html`
I'll still stick with mine however, my 'framework' is half-page of code. I dislike dependencies greatly. I'd need to be saving thousand+ lines at least.
Here, I don't want a build system to make a website; that's mad. So I don't want lit. I want the 5 lines it takes to invoke a dom parser, and the 5 lines it takes do define a webcomp parent.
It seems all these frameworks invent abstractions on top of how the browser works ('reactive properties', etc.) -- i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author.
Lit's HTML rendering code is mostly just safety and caching so re-renders only run code and mutate DOM nodes they actually need to - I read through the whole thing to get a feel for what it was doing and you might want to do the same to see if there's any ideas to steal.
Reactive properties aren't really an invented abstraction in any meaningful sense - they're mostly just sugar for creating a javascript property whose 'set' handler schedules a re-render if required - think
get prop () { this._prop }
set prop (value) { this._prop = value; this.scheduleRender() }
so to my mind that functionality -is- inherent in the tool, how magical it seems is mostly dependent on whether you've already gone to the trouble of learning the relevant corners of javascript.
I've done (smallish) things that use no build tool and just have two script tags, one to pull in a minimal lit, one to pull in the page's code.
I do agree that it's often easier to implement just the subset of functionality you need rather than using a dependency, but it's still IMO worth understanding the existing libraries to see if there's an idea in there you want to add to your subset, and dismissing lit because it -documents- using a build tool since that's the common approach these days strikes me as a mistake (learning how it works and -then- deciding you don't need that is completely fair, mind).
> i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author.
The abstractions in the browser are extremely bad, and you have to be very careful coding around them to get good performance out of them. But by that time you will hve invented your own framework.
I also define a `render()` and extend my own parent, which does a `replaceChildren()` with the render. And, strangely, I also call the processor `html`
I'll still stick with mine however, my 'framework' is half-page of code. I dislike dependencies greatly. I'd need to be saving thousand+ lines at least.
Here, I don't want a build system to make a website; that's mad. So I don't want lit. I want the 5 lines it takes to invoke a dom parser, and the 5 lines it takes do define a webcomp parent.
It seems all these frameworks invent abstractions on top of how the browser works ('reactive properties', etc.) -- i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author.