Comment by spankalee | Hacker News Reader

Comment by spankalee | Hacker News Reader

Parent Full thread

> 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.

Aren’t form validation and http also separate libraries for React?

Only if you need form validation or http options the browser doesn't provide...

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.

Reply on news.ycombinator.com