Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

211–220 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#211

Post by breadwinner »

stickfigure wrote: post #207
breadwinner wrote: post #189

Earlier quoted context omitted.

MVC is a proven and popular technology. It works very well, otherwise it wouldn't be so popular. I notice you allude to "problems we all experienced with MVC" without mentioning any . Surely if there are so many problems, you would be able to mention one?

As parent pointed out, the MVC in server-side development only shares a name with the MVC in GUI development. Yes, MVC is a proven and popular name. But it means different things to different people.

Why would it be different? The concept of Models is the same whether it is client-side or server-side. These are objects that encapsulate business logic. The concept of Views is also the same. These are responsible for rendering the screen. The concept of controllers? That too is the same. Controllers determine application flow from one screen to the next.

Re: Web Components Eliminate JavaScript Framework Lock-In

#212

Post by api »

WorldMaker wrote: post #138
menssen wrote: post #39

Earlier quoted context omitted.

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

> 4. Observables (Ember, maybe Angular 2+?) Don't forget Knockout which was the OG. You can also make the case that Svelte, Vue, and Qwik all are different takes on Observables (at least as much as Angular 2+ is) all with more or less magic and more or fewer escape hatches from Observable best practices to imperative(-looking) code. I got a "What if we did Knockout but with with the compile-time benefits of TSX and P…

I used Knockout to implement the very very very first ZeroTier network control dialog. Nice paradigm, but I think React beat it when things got really complex.

Re: Web Components Eliminate JavaScript Framework Lock-In

#213

Post by jitl »

breadwinner wrote: post #189
jitl wrote: post #64

Earlier quoted context omitted.

The server side style of MVC you describe is a far stretch from how MVC is practiced in retained-mode UI frameworks like UIKit, Cocoa, or Backbone. It’s possible to make this style work fine with careful design and planning; Apple built web versions of Pages and Keynote using SproutCore (which evolved into Ember?) in 2013-era. In fact back then, everyone’s big app was MVC - usually Backbone. I worked on Airbnb’s host…

MVC is a proven and popular technology. It works very well, otherwise it wouldn't be so popular. I notice you allude to "problems we all experienced with MVC" without mentioning any . Surely if there are so many problems, you would be able to mention one?

I mentioned the main problem in the second paragraph:

> There were many bugs in this scale of app around making sure the DOM reflected the latest change to some model. The engineering team regarded the more complicated screens as a nightmare to maintain in our fast paced environment with many teams touching the code.

I've seen this same issue in Cocoa/UIKit/Android views. Older Cocoa in particular has a lot of hairy wiring up of signals and first responders and delegates. I think it's less of an issue there because the rate of change is typically lower; in web land we expect to deploy continuously and with a very high number of engineers, anything targetting the app store will usually deploy at most weekly (2 orders of magnitude fewer deploys) and with many less engineers (usually an order of magnitude at least. My hypothesis is the difference in change rate is why this kind of bug was more of an issue for web developers.

Re: Web Components Eliminate JavaScript Framework Lock-In

#214

Post by iteratethis »

I don't think there's a need to cause a stir and generate hate for either Web Components or React.

We should hate both equally.

Either approach is frankly an embarrassing way to build complex interactive applications. Web tech is just way too low level, batteries not included. We've added mountain of complexity to deal with it but it doesn't hide that the fundamentals are broken and that productivity is low.

Re: Web Components Eliminate JavaScript Framework Lock-In

#215

Post by jitl »

breadwinner wrote: post #211
stickfigure wrote: post #207

Earlier quoted context omitted.

As parent pointed out, the MVC in server-side development only shares a name with the MVC in GUI development. Yes, MVC is a proven and popular name. But it means different things to different people.

Why would it be different? The concept of Models is the same whether it is client-side or server-side. These are objects that encapsulate business logic. The concept of Views is also the same. These are responsible for rendering the screen. The concept of controllers? That too is the same. Controllers determine application flow from one screen to the next.

The server is typically not a retained-mode kind of abstraction. Incremental view maintenance in retained-mode MVC systems is the main source of bugs. If you render the view from scratch on every request, it's more similar to React style immediate-mode UI than something like UIKit where you end up handling many UI events and keeping little bits of the UI up-to-date with model changes incrementally.

Re: Web Components Eliminate JavaScript Framework Lock-In

#216

Post by EnergyAmy »

jakelazaroff wrote: post #155
mmis1000 wrote: post #136

Earlier quoted context omitted.

I also wonder about this. The webcomponent make the style completely immutable unless you add part selector specifically… how on the earth this is even useful? Imagine using an ui library that you can't change the style at all. That sounds like a total joke to me. That isn't even a sane default that is useful to most web folks that make page base on layout that designers gave.

I find it very useful for embedding interactive demos on my blog that are mostly independent of the styles for the rest of the site (for example, the article here). But for what it’s worth, there is discussion of an “open-stylable” shadow DOM mode that addresses those concerns: https://github.com/WICG/webcomponents/issues/909

Shadow DOM was a mistake. It's a 0.1 version that was unfortunately pushed out as a completed standard. Basic stuff is missing like your link. The entire thing should be deprecated and we should start from scratch.

If you want to embed something that doesn't use your page's styles, we already have iframes. Shadow DOM is just a half-assed recreation of that.

Re: Web Components Eliminate JavaScript Framework Lock-In

#217

Post by techpression »

menssen wrote: post #39
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

I would say SolidJS does everything better than React while keeping with the same general mindset. React spent way too much time worrying about DX to the point that now DX is really bad. Fine grained granularity is such a breath of fresh air to work with after the very large and very heavy brush that is the React “render the world every time anything changes” method (yes they try to be smart about it, but so far haven’t succeeded, the next compiler might solve it, but then we’re back to a black box of incomprehensible code soup to debug).

Re: Web Components Eliminate JavaScript Framework Lock-In

#218

Post by jongjong »

djrenren wrote: post #20

I've found webcomponents to be really good at encapsulating anything that doesn't directly query application state. Specifically there are two type of components that really thrive as web components (as opposed to react): 1. Highly interactive components - Components that implement complex interaction management (but sort of agnostic to application state) are ideal web components. You don't need to mess around with `…

I find that they can work very well with state but since state is typically passed via attributes (downstream), it means that components can only share state with each other via strings. I found this to be an advantage, not a drawback because simple interfaces are at the core of my coding philosophy and strings make it infeasible to pass complex instances or functions to other components.

Re: Web Components Eliminate JavaScript Framework Lock-In

#219

Post by WickyNilliams »

auggierose wrote: post #92

As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.

Strings as _attributes_, yes. But that's par for the course when it comes to html (boolean attributes aside).

However, anything can be passed as a _property_. React operates on properties by default (hence `htmlFor` and `className`, not `for` and `class`). In fact, react's upcoming improved WC support will first do an `in` check on a property name before falling back to attribute. This is similar in vue etc.

So yes if you're only authoring plain html you're confined to primitives, but if you're using a framework or WC lib, they almost certainly support properties

Re: Web Components Eliminate JavaScript Framework Lock-In

#220

Post by socketcluster »

The main problem with the Shadow DOM which makes people avoid it is the inability to use CSS externally to style the elements which are generated internally by the component...

This is unfortunate because the Shadow DOM is essential if you want to work with child components slotted into it from the outside. This opens up many use cases.

There is one alternative which is not being considered; it's possible for components with a shadow DOM to inject their elements into the Light DOM (where they can be styled/skinned externally with CSS), you just have to make the user slot a div (or other element) from the outside to act as a 'viewport' so that the component can inject its children into it (instead of injecting them into its Shadow DOM).

With this approach, you can still access slotted elements. It's an ideal pattern for situations where you want the component to generate child elements from a slotted template.

I wrote an article about this approach here: https://dev.to/jondubois/web-components-the-template-viewpor...

Post reply on HN