I'm not into web development at all so this sounds very new to me, but aren't components in general meant to be self-contained so that they can be reused as "building blocks" for larger applications (or pages, i guess)?
Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some of them use the same framework but different versions? What about the same version, does that get duplicated for each component or they get shared?
Also are these components meant to be "bundled" with your code or you are supposed to source them from their "home" server? In the latter case does that mean that a site using 10 components will open connections to 10 different servers (one for each component, assuming all components are from different developers)?
Or am i missing the point completely? TBH i think of "components" as in Lazarus, Delphi, .NET, etc (where you have reusable components like buttons, labels, input boxes, etc but also nonvisual stuff like timers, imagelists, etc).
> though for some reason webdevs try not to admit this
This is mostly because if you can keep development paradigms consistent within your job, that is one less thing to whack-a-mole in the fun game of "with permutation X of the endless combination of browser (and version), OS (and version), etc. why isn't the thing working?"
I don't know why the sibling reply comment to this by
golemiprague was killed.
My understanding is that he is correct - in terms of requiring a framework to be bundled with your code. Svelte is not a framework that needs to be bundled with your code, instead it injects helper code during the transpilation step and the result has no dependencies.
If I'm incorrect I'd appreciate the trigger happy person to explain why rather than killing this comment.
While they use a JS framework it doesn't mean the framework is used also in run time, in pre compiled frameworks like svelte the generated components are just vanilla JS and can be used later in any webpage.
The entire ecosystem got a bit too crazy for me as well, but there are a few sane places if you go looking. I settled on the Elm ecosystem after a long period of consideration. Probably the only good thing to come out of having too many options is the higher probability of finding one that suits your perspective.
I've just heard about it, but Shoelace [1] is a component library designed to work with any and all frameworks. To quote from their website, web components address these problems:
Unfortunately, framework-specific components fail us in a number of ways:
- You can only use them in the framework they're designed for
- Their lifespan is limited to that of the framework's ⏳
- New framework versions can lead to breaking changes, requiring substantial effort to update components
There's another discussion on the frontpage [2] about Shoelace that addresses some of your questions.
So for the angular implementation, the compiler will only include the necessary parts of the framework with the web component. So you’re only including the bits you need for the component to be usable.
There are ways you can coordinate the components and their dependencies to rely on the same versions, but this will probably assume they are your components.
Svelte does something kind of similar where it doesn’t share the same bits between components, but according to the creator it the theoretical point at where it would be more beneficial to have share is so far off to be pointless. So presumably if you have something that efficient you won’t have to worry so much, I think we are a ways away
> Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component?
yes something like react would be the main framework on the page. i guess this is showing how much overhead there is in each of the different of frontend frameworks and also what the code to do a relatively simple but not trivial example looks like.
Right on the money. In fact, unless this changed recently, you also can't use two components that both depend on different, incompatible versions of the same third component.
> Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component?
You should depend on any dependencies (including frameworks), but you shouldn't bundle them, exactly so that when an app is bundled it can do the efficient thing and share dependencies.
> What happens if you want 10 components that each use a different framework?
One reason to now use frameworks, but use smaller modern rendering libraries, or none at all. In a large application it's probably not a big deal to use a couple of 3KB libraries - you'd still be far under a typical framework in weight.
> Or some of them use the same framework but different versions?
That should be fine and is a huge reason to use web components. When you have a stable component boundary you can upgrade libraries a component at a time, rather than needing to upgrade the whole application at once. Yes, you might have some overhead during the transition, but at least you aren't stuck. You might not even deploy during the transition, but at least you could. Framework transitions are super tough in monolithic frameworks and I've worked with teams that use web components specially to get around that.
> What about the same version, does that get duplicated for each component or they get shared?
Again, components should be distributed unbundled so that bundlers do the right thing. It's similar to not bundling React with every React component, or jQuery, etc.
I downvoted this because these are (in my opinion) entirely theoretical and not practical answers. This reminds me of the "React is better than Angular(js) because look how compact and clean the API is compared to Angular!" type arguments. This implies that "React apps" are going to be less complex than Angularjs apps but the reality is anything but: large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do.
Likewise "When you have a stable component boundary you can upgrade libraries a component at a time, rather than needing to upgrade the whole application at once. Yes, you might have some overhead during the transition" I'll believe this when I see it, but I suspect you're making this sound way less painful than it actually would be. More likely each dev adds a new framework, they all move on to other teams/companies, no one is interested in painstakingly updating everything, and you have perpetual lock-in until you do the "JavaScript Shuffle" i.e. scrap it and rewrite in a new framework.
I'd love what you're saying to be true but my experiences tell me it probably is not.
> large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do.
I largely disagree with the comment you're replying to in its oversimplification of things, however, this simply isn't true. 'Create React App' plus 'React-Router' is literally all you need for the vast majority of applications.
And you don't need "20 or 30 other compact libraries", unless what you're doing is specialised and requires them.
The idea you need "a state manager" is an unfortunate fallacy, due to React/Facebook's history by accidentally implying a Flux-like solution should be added to augment React, when in fact so much more could be achieved by simply following React's component model, and React's built-in mechanisms for managing state.
I've worked with a ton of apps migration frameworks in my career. From GWT, jQuery, Angular 1, and several non-OSS ones. The only successful incremental migrations I've ever seen have been via web components.
I'm working with one now that rather than convert from Angular 1 to Angular 9 in one shot is converting component-by-component to web components and working on features as they go. They'd have to stop features for at least 6 months otherwise.
Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some of them use the same framework but different versions? What about the same version, does that get duplicated for each component or they get shared?
Also are these components meant to be "bundled" with your code or you are supposed to source them from their "home" server? In the latter case does that mean that a site using 10 components will open connections to 10 different servers (one for each component, assuming all components are from different developers)?
Or am i missing the point completely? TBH i think of "components" as in Lazarus, Delphi, .NET, etc (where you have reusable components like buttons, labels, input boxes, etc but also nonvisual stuff like timers, imagelists, etc).