I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
It's not either-or. There are many web component libraries with an FP flavour:
Just off the top of my head.
Web Components !== OOP
You don't have to give up your functional programming style to use web components!
More importantly:
React isn't the only functional UI framework
Preact works just fine with the DOM and has for years.
OP is about web compat, not flaming FP or OOP styles.
I dunno, are they really bigger or do they just have a louder bark? 🤔