4 ms·

How do you feel about web components as a solution in this space?

solardev 2y ago
Well, if you're talking about the official web API (https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...), they seem a little clunky to me, and I've never personally seen them used by any of the orgs or clients I've worked for. Their scope is too limited and they don't really seem to be able to replace the frameworks/libs like React they were competing against. I'm not really one of those HTML purists, and I actually think React and especially JSX is a huge improvement on the traditional DOM model. Although I grew up in the 90s, I would not willingly go back to that style of web dev... it's just not a good use of time when you're building more complex apps as opposed to documents, IMO. But if "web components" can also mean "reusable components" in general, then I use and really love UI kits like MUI: https://mui.com https://mui.com. It's very well thought out, implemented, and documented, and using it was what made me fall in love with modern frontend dev. To expand on this a little: A single reusable component on its own isn't very useful to me (unless it's for a specific use case, like a complex calendar or something). We already had those with drop-in ActiveX, Flash, or jQuery widgets back in the day, but they often created a disjointed, buggy mess of a site since you're just clobbering together different libs and widgets from different authors, each with their own idiosyncrasies, input shapes, etc. In contrast, having a cohesive framework (like React + Next/Astro/Vite/etc), UI kit (MUI, Chakra, Ant, or similar), and internal style guide (brand assets, colors, typography, flows, etc.), coupled with a well-defined state and routing model, makes modern web development so much more consistent and pleasurable to work with. I can compose a useful dashboard in 10% of the time it used to take me, with a state tree I can easily reason about, and I can cleanly separate client and server renders (on purpose). A Web Component on its own doesn't really do any of that except provide a reusable HTML snippet. It feels a bit like a serverside include to me (popular in the PHP days), but doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc. A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project, AND (via UI kits) still includes reusable components that work well with the rest of the system, from logic to styling. Visual Studio and the Winforms model, along with various Windows APIs, did all of that for desktop development long before the Web was popular. If you wanted to make a Windows app, you could just drag and drop UI widgets in a cohesive way inside a responsive layout (windows were resizable long before smartphones), share properties and styling across them programmatically, etc. Modern web frameworks and UI kits bring a similar integrated dev experience (minus the WYSIWYG part, sadly). I guess if you were a purist and wanted to eschew frameworks and had an app that doesn't have much complexity, maybe a Web Component would help you make it in a more reusable way? But honestly if a site were that simple, I'd just build it in Wix or Squarespace or Wordpress to begin with. I struggle to think of a scenario where a client or business would want to build up such a thing using HTML/DOM primitives instead of just reaching for either a low-code/no-code editor or a full-blown frontend with all the glorious framework bloat. Maybe there's room in the middle there for simple hobbyist websites, it's just not what people typically pay me for (as a frontend dev). -------- Zooming out a bit, my personal opinion (that's all this is) is that the Web and JS official specs move way too slowly to keep up with modern needs. WHATWG is an improvement over the W3C, but the ECMAscript standard lib is still pretty barebones compared to other high-level languages, and both move reaaaaaally slow. I think that's why we end up with things like jQuery and lodash and React and Next, a billion third parties trying to improve the developer ergonomics in a trillion different ways, none compatible with each other. It's resulted in some significant improvements, yes, but also a lot of obsolescence. It's exhausting to try to keep up and I wish we just had a FAANG Web UI standards group that could choose one path and rapidly iterate it instead. Hard to imagine the React, Angular, and .NET folks getting together to hash all that out cooperatively though... =/
- mejutoco 2y ago
  > A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project Managing updates for the framework is also something to evaluate. Going from a big angular update, or the recent nextjs changes can easily take up those saved weeks. > doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc. Style scoping comes for free with web components. That is much better than an html template, and makes them composable. Typing you can organize as you want by using typescript, also making them composable. In regards to state management I usually use component attributes (they are standardly defined in a web component, so they are easy to find in a codebase). That goes a long way. If tgat is not enough, an elm-like state management (one big switch with events and types for the payload) is easy to implement. I find it much easier than using redux. For routing, I feel like a component is not really the place to do routing. It feels like a bit of a hack, but convenient. Again, I find a single centralized definition of routes usually works. This is how routing components are used anyway IMO. For a long-running project, avoiding dependencies and updates is huge, compared to npm package problems and the constant wheel reinvention of React, for instance.

Well, if you're talking about the official web API (https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...), they seem a little clunky to me, and I've never personally seen them used by any of the orgs or clients I've worked for. Their scope is too limited and they don't really seem to be able to replace the frameworks/libs like React they were competing against. I'm not really one of those HTML purists, and I actually think React and especially JSX is a huge improvement on the traditional DOM model. Although I grew up in the 90s, I would not willingly go back to that style of web dev... it's just not a good use of time when you're building more complex apps as opposed to documents, IMO. But if "web components" can also mean "reusable components" in general, then I use and really love UI kits like MUI: https://mui.com https://mui.com. It's very well thought out, implemented, and documented, and using it was what made me fall in love with modern frontend dev. To expand on this a little: A single reusable component on its own isn't very useful to me (unless it's for a specific use case, like a complex calendar or something). We already had those with drop-in ActiveX, Flash, or jQuery widgets back in the day, but they often created a disjointed, buggy mess of a site since you're just clobbering together different libs and widgets from different authors, each with their own idiosyncrasies, input shapes, etc. In contrast, having a cohesive framework (like React + Next/Astro/Vite/etc), UI kit (MUI, Chakra, Ant, or similar), and internal style guide (brand assets, colors, typography, flows, etc.), coupled with a well-defined state and routing model, makes modern web development so much more consistent and pleasurable to work with. I can compose a useful dashboard in 10% of the time it used to take me, with a state tree I can easily reason about, and I can cleanly separate client and server renders (on purpose). A Web Component on its own doesn't really do any of that except provide a reusable HTML snippet. It feels a bit like a serverside include to me (popular in the PHP days), but doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc. A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project, AND (via UI kits) still includes reusable components that work well with the rest of the system, from logic to styling. Visual Studio and the Winforms model, along with various Windows APIs, did all of that for desktop development long before the Web was popular. If you wanted to make a Windows app, you could just drag and drop UI widgets in a cohesive way inside a responsive layout (windows were resizable long before smartphones), share properties and styling across them programmatically, etc. Modern web frameworks and UI kits bring a similar integrated dev experience (minus the WYSIWYG part, sadly). I guess if you were a purist and wanted to eschew frameworks and had an app that doesn't have much complexity, maybe a Web Component would help you make it in a more reusable way? But honestly if a site were that simple, I'd just build it in Wix or Squarespace or Wordpress to begin with. I struggle to think of a scenario where a client or business would want to build up such a thing using HTML/DOM primitives instead of just reaching for either a low-code/no-code editor or a full-blown frontend with all the glorious framework bloat. Maybe there's room in the middle there for simple hobbyist websites, it's just not what people typically pay me for (as a frontend dev). -------- Zooming out a bit, my personal opinion (that's all this is) is that the Web and JS official specs move way too slowly to keep up with modern needs. WHATWG is an improvement over the W3C, but the ECMAscript standard lib is still pretty barebones compared to other high-level languages, and both move reaaaaaally slow. I think that's why we end up with things like jQuery and lodash and React and Next, a billion third parties trying to improve the developer ergonomics in a trillion different ways, none compatible with each other. It's resulted in some significant improvements, yes, but also a lot of obsolescence. It's exhausting to try to keep up and I wish we just had a FAANG Web UI standards group that could choose one path and rapidly iterate it instead. Hard to imagine the React, Angular, and .NET folks getting together to hash all that out cooperatively though... =/

mejutoco 2y ago
> A good framework does all of that and saves me weeks/months of having to reinvent the wheel for every project Managing updates for the framework is also something to evaluate. Going from a big angular update, or the recent nextjs changes can easily take up those saved weeks. > doesn't really holistically help me with routing, state management, schema sharing, composability, typing, etc. Style scoping comes for free with web components. That is much better than an html template, and makes them composable. Typing you can organize as you want by using typescript, also making them composable. In regards to state management I usually use component attributes (they are standardly defined in a web component, so they are easy to find in a codebase). That goes a long way. If tgat is not enough, an elm-like state management (one big switch with events and types for the payload) is easy to implement. I find it much easier than using redux. For routing, I feel like a component is not really the place to do routing. It feels like a bit of a hack, but convenient. Again, I find a single centralized definition of routes usually works. This is how routing components are used anyway IMO. For a long-running project, avoiding dependencies and updates is huge, compared to npm package problems and the constant wheel reinvention of React, for instance.