3 ms·
I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with th
by Fahata 3y ago
I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with then-ancient abstractions. The JavaScript of a well-written web component should be as valid now as it will be in 10 years, as you're just using the platform.
- troupo 3y agoThis year I pulled class-based React component into a greenfield React project. Worked without a hitch, even though its a 10-year difference between approaches. Meanwhile, "use the platform": - all form components written before form participation landed in browsers are broken - all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM - ... you may continue this list at your own leisure ...
- mardifoufs 3y agoYeah I don't get the comments either. React has been there for a decade now, is pretty stable and very backwards compatible. You can't really go wrong with it and it's a super lightweight "framework" (I know, it's not a framework, maybe a library would be a better term) all things considered. The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.