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

151–160 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#151

Post by matt7340 »

spankalee wrote: post #53
veeti wrote: post #30

Earlier quoted context omitted.

How do we know this won't be killed off by Google in six months?

Honestly, you don't. It's used for many Google projects like Chrome, parts of YouTube, Maps APIs, Collab, the Google Store, and a ton of internal things, so I think it's unlikely, but I understand Google's reputation. This is one reason why we care so much about low coupling and lock-in, and a small, easy-to-understand codebase. You should be able to migrate away from Lit very easily, and fork or maintain it if neces…

I've read that Angular is also extensively used for Google internal projects. How do the teams choose between Angular and Lit?

Re: Web Components Eliminate JavaScript Framework Lock-In

#152

Post by chiefalchemist »

> To prove it, we’re going to do something kinda crazy: build an app where every single component is written with a different framework.

Interesting exercise. But now I wish she/he would one-by-one replace each framework with web components, so that in the end, there are no frameworks, only web components. As in, "Oh shit! We're going to abandon Vue (or React, etc.) and replace it with web components" or "We've been taked to only use web componentst, and no frameworks." What does that migration / transformation look like? Isn't that a likely scenario?

Re: Web Components Eliminate JavaScript Framework Lock-In

#153

Post by myaccountonhn »

metadaemon wrote: post #76
switchbak wrote: post #69

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

It's a very complex problem to solve and I think a lot of people need to accept that. There will never be a simple solution with a low learning curve that's actually performant for non-trivial applications without a fundamental shift in browser technology.

I think elm showed that it is possible to build a solution with a low learning curve.

Sadly elm hasn't really taken off but as far as frontend goes... it is just so simple together with elm-ui.

Re: Web Components Eliminate JavaScript Framework Lock-In

#155

Post by jakelazaroff »

mmis1000 wrote: post #136
jdmg94 wrote: post #108

Earlier quoted context omitted.

except you can't use it as a normal component, you can't adjust its CSS normally, you have to `&::part()` your way around and hope for the best. Accessing through refs is a complete blackbox. I work with web components daily and it is a hindrance to my daily work, it is very common for people at my org to just re-write a component instead of using its web component version.

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

Re: Web Components Eliminate JavaScript Framework Lock-In

#156

Post by breadwinner »

DougBTX wrote: post #120
dexwiz wrote: post #66

Earlier quoted context omitted.

If one of the most popular APIs is a violation, then maybe the pattern is broken.

It’s a misremembering of history. The point of all the “pure functional” discussion was that rendering the UI now shouldn’t depend on how the UI was rendered earlier. The idea was to move away from the “create then update” paradigm to just “render”. React would be responsible for which elements need to be created and which can be updated in place. To achieve that, it doesn’t matter whether the state is local to a com…

> React would be responsible for which elements need to be created and which can be updated in place.

That works for simple, read-only components. The moment the component starts managing its own interactivity you end up needing state, and at that point things break down. If you need to change props, you have to essentially recreate the component by changing key [1], and at that point, what is the benefit of React?

[1] https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont...

Re: Web Components Eliminate JavaScript Framework Lock-In

#157

Post by mattgreenrocks »

switchbak wrote: post #69

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

The problem with many front and backend web frameworks is they love the medium of the web too much. This might sound absurd, but they leak all sorts of web gunk through and then pile their own concepts on top.

A simple example of this is most backend frameworks let you signal an error by throwing an exception. Good choice! Except when you go to throw one, you often have to choose from a bunch of HTTP status codes to bundle with your exception. I want to tell the user that validation failed, that's all. I should throw a ValidationError, not a HttpResponseError. They're not really abstracting anything, just adding a layer of structure, usually via libraries that are glued together.

Similarly, I've started to be of the opinion that the ideal HTTP request handler has very few HTTP-specific details in it, as the framework can introspect the types and annotations to determine how to pass data in and out. This is very different from typical frameworks which are happy to hand you raw requests and responses and tell you to do it all. Nothing wrong with that for special cases, BTW, except for people's tendency to mix HTTP, infrastructure (DB/messaging/APIs), and business logic in the same handler.

There will always be cases where you need direct control, but I've been moving towards stacks that automate most of this to cut down on the gunky makework feeling I get when doing webdev, and it has been integral to me actually enjoying the tooling rather than feeling like I'm filling out TPS reports. Currently that's Spring Boot + Kotlin, despite the enterprise stigma the JVM and Spring have.

Re: Web Components Eliminate JavaScript Framework Lock-In

#158

Post by [deleted] »

btbuildem wrote: post #115
switchbak wrote: post #69

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

I don't really do FE anymore, but I've worked in that realm long enough to see several frameworks come and go - as well as see the JS ecosystem scale far beyond the limits of its organizing principles. In my opinion, the community is lacking foundations, structure, and principles - something that would otherwise be instilled by formal education. JS is fantastic for exploring how programming works, it makes it easy to…

[deleted]

Re: Web Components Eliminate JavaScript Framework Lock-In

#159

Post by djrenren »

paulddraper wrote: post #139
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 `…

> React conflates two concepts that I think are better when separated: templates, and components. Whether a React code base conflates them depends on the code base, but the more familiar terminology is container vs presentation . [1] [1] https://www.patterns.dev/react/presentational-container-patt...

You can absolutely follow a discipline like this which recreates this separation in a framework that lacks it

Re: Web Components Eliminate JavaScript Framework Lock-In

#160

Post by mattgreenrocks »

mattlondon wrote: post #85
switchbak wrote: post #69

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

I think you are talking about web components. Even in the old desktop world someone had to build the button widget (and all the others) that let you just throw stuff together in MFC or Swing or whatever. Same today - someone has to build the web components in order for us to declaratively use them as high-level Lego. Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML…

> Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML elements

This is why I hate making web UIs.

> then the probably reason for their not being a general high-level library is that everyone wants something special for their websites

This is why I hate using web UIs.

At this point it's hard not see this as a fully self-inflicted wound by the platform. I know there are component libraries, but the work always remains fragmented because someone decided that their buttons needed purple highlights while someone else's needed drop shadows.

And the devs seem to love staying at this low level of abstraction. Feels like they had to be dragged into the component model espoused by React et al over many years.

Post reply on HN