Hacker News Reader

Nope, your thoughts are all essentially correct. The answer is “yes” to all of them; even the ones where it seems that “yes” would be contradictory.

Bundle everything? Yep. Self contained? Yep. 10 components that open connections to 10 different severs? Yep.

The web is so massive that there is a way for pretty much everything (though for some reason webdevs try not to admit this).

> 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?"

Except for the pure HTML5 solutions, everything else uses a JS framework.

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.

Sums up "state of the art" web we're using right now = absolute mess, bail out if you can, save yourself, stay sane

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.

Ignore what people say and just write everything yourself.

https://jsfiddle.net/4qkpLw3c/

ghee, that was hard????

i like the keyboard support :) +1

> Or am i missing the point completely

Sort of. These are ways you can built web components today with modern conveniences that some of these _libraries_ (not frameworks), might lend you.

The site isn't claiming these different approaches can all be used together on one page in a practical way.

Technically you could, but it would have the obvious downsides you mention. This is just the reality of the limitations in the standards today.

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.

[1] https://shoelace.style/

[2] https://news.ycombinator.com/item?id=23866894

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.

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.