> after you have built probably your 5th component where you are going to start moving a whole bunch of shared logic into a base class that extends HTMLElement
I kind of thought this too at first, and started down that path several times. I actually wrote a whole framework similar to Lit early on, thinking the same thing.
What I've found over time, is 99% of that is YAGNI (You ain't gonna need it).
All my components just extend HTMLElement directly.
I explicitly dislike Lit because you lose control over the component lifecycle. I don't find it easier, I find it harder - especially when you're mixing in pure js libraries like draggable or whatever.
I prefer having to call render() explicitly, and controlling when/how that's done. At the end of the day, it's not actually any more code.
> a better job with a bigger team and access to browser engineers with thousands of existing users and a bigger test suite
Yeah, I don't need all that to show some interactive markup on the screen and organize code well. That's really what WC's are for me - just a convenient unit of encapsulation for vanilla JS/DOM stuff.
Lit is cool, so's stencil. I just don't need it.
lit-html, however, is probably my favorite piece of tech in the last 5 years. I've been using it since it was originally created and was only like 200 lines of code.
All that code I wrote is still working great, and hasn't needed any sort of update. On the other hand, if I'd gone with the Web Components Framework Of The Day, I'd have done Polymer and caused a massive headache for my clients.
Many people were making the exact same arguments you were about Polymer back then.
And then LitElement.
And then Lit.
Lit 2.0.
Now Lit 3.0.
Same story with <fill in your framework here>.
Angular 1.5 anyone?
Framework churn can kill a company.
I code to standards, keep it as vanilla as possible, and prefer libraries over frameworks (though sometimes the lines get blurry there - looking at you Ionic).
“For the *vast majority* of users there should be no required code changes to upgrade from Lit 2 to Lit 3. Most apps and libraries should be able to extend their npm version ranges to include both 2.x and 3.x, like "^2.7.0 || ^3.0.0".“
I kind of thought this too at first, and started down that path several times. I actually wrote a whole framework similar to Lit early on, thinking the same thing.
What I've found over time, is 99% of that is YAGNI (You ain't gonna need it).
All my components just extend HTMLElement directly.
I explicitly dislike Lit because you lose control over the component lifecycle. I don't find it easier, I find it harder - especially when you're mixing in pure js libraries like draggable or whatever.
I prefer having to call render() explicitly, and controlling when/how that's done. At the end of the day, it's not actually any more code.
> a better job with a bigger team and access to browser engineers with thousands of existing users and a bigger test suite
Yeah, I don't need all that to show some interactive markup on the screen and organize code well. That's really what WC's are for me - just a convenient unit of encapsulation for vanilla JS/DOM stuff.
Lit is cool, so's stencil. I just don't need it.
lit-html, however, is probably my favorite piece of tech in the last 5 years. I've been using it since it was originally created and was only like 200 lines of code.
All that code I wrote is still working great, and hasn't needed any sort of update. On the other hand, if I'd gone with the Web Components Framework Of The Day, I'd have done Polymer and caused a massive headache for my clients.
Many people were making the exact same arguments you were about Polymer back then.
And then LitElement.
And then Lit.
Lit 2.0.
Now Lit 3.0.
Same story with <fill in your framework here>.
Angular 1.5 anyone?
Framework churn can kill a company.
I code to standards, keep it as vanilla as possible, and prefer libraries over frameworks (though sometimes the lines get blurry there - looking at you Ionic).