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

111–120 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#111

Post by jdmg94 »

oblak wrote: post #16

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve…

Stencil does it, but the resulting web components are still not great to work with because of shadow dom and the missing standards you can't expect from custom elements. You want inline styles? hope your dev remember to drill those down.

Re: Web Components Eliminate JavaScript Framework Lock-In

#112

Post by itslennysfault »

paulddraper wrote: post #102
itslennysfault wrote: post #98

I like the idea of web components, but really dislike html and js being intermingled (the reason I don't like React/JSX). In web components its even worse because its HTML as a string which means it has no validation and isn't syntax aware. I much prefer the angular approach where you have separate css,html,ts files, and would love a web component framework that could work similarly. Searching for this I found some k…

> its HTML as a string Can you explain what you mean by that?

This is the example from the article, and pretty common practice for web components. As far as an IDE is concerned this is just a string of text (it doesn't know/care that it is html). This makes it more error prone as the IDE can't catch syntax errors in the html.

  connectedCallback() {
    this.shadow.innerHTML = `
      
Hello from a web component!

      
        p {
          color: pink;
          font-weight: bold;
          padding: 1rem;
          border: 4px solid pink;
        }
      
    `;
  }

Re: Web Components Eliminate JavaScript Framework Lock-In

#113

Post by paulddraper »

Devasta wrote: post #101
ecmascript wrote: post #86

Earlier quoted context omitted.

I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly. Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any…

Devs use web frontend tech because it is installed on every machine, will never have anything less than the full backing of the browser devs for the next hundred years, and gets around corporate filters. No need to deal with IT security losers to get your app installed, no need to get ports opened, just everything down port 443 until the end of time. INTERCAL could win with that feature set.

I think you missed the point.

> why people use front end tech to make native apps today

Even when you have to deal with IT security losers to get apps installed, implementing it w/ web tech is extremely popular.

E.g. the #1 IDE by popularity [1] is a desktop app developed with web tech. (And yes, it was later ported to browsers, but it didn't start there.)

[1] https://survey.stackoverflow.co/2022#section-most-popular-te...

Re: Web Components Eliminate JavaScript Framework Lock-In

#114

Post by claytongulick »

I've been using Web Components in production for years with great success.

My guiding principles:

- Avoid shadow dom unless it's a library. Stick with the light DOM and css system of your choice.

- Use lit-html or similar for rendering

- Use class properties for reactivity (add a render() call to setters, as needed)

- Ignore attributes entirely. Just use properties.

- Don't bother with composable components and slots. You generally don't need them

- Use a nice router like vaadin or ionic or similar to hoist components and support deep linking

- Let components maintain their own state. Structure the dom so that it's easy to grab state from a component with querySelector. If this doesn't work, I have a little state lib called ApplicationState[1] that works great.

- Really think about what needs to be a component vs normal html. Don't overdo it with components.

- Structure the app with high level "scene" components that map to URL deep links, and app components that you use to build the scenes. Scenes are targets of the router.

[1] https://claytongulick.github.io/applicationstate/

Re: Web Components Eliminate JavaScript Framework Lock-In

#115

Post by btbuildem »

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 stitch things together, and the barrier to entry is basically zero; all you need is a text editor and a browser.

The flipside is that people regularly reinvent things, same sets of ideas get formed and re-formed, fall into and out of vogue over and over again. It is true that there is great complexity to be dealt with in this domain, but it feels like whenever the current set of tools and practices matures enough to face some of the hard problems, the instinct in the community is to "start from scratch" and before long some new shiny exciting thing appears. It shows a lot of potential, it's nowhere near facing the hard problems, people jump on the bandwagon, time passes, and the new set of tools and practices arrives at precisely the same place.

Web components have been in the works for a long, long time. The inherent competition between the major frameworks divides people into camps, which doesn't help. But, seeing the slow but steady progress in the web components realm indicates to me that they're apart from the patterns I was ragging on in the previous paragraph. They increasingly seem to deliver on the promise of creating advanced building blocks - perhaps one day a developer won't have to choose between a React Table, a Vue Table, a Gobagool Table, etc, but use a plain vanilla standard issue web component table to display their CSVs.

Re: Web Components Eliminate JavaScript Framework Lock-In

#116

Post by jdmg94 »

adam_arthur wrote: post #103

People discussing writing Web Components by hand are missing the point. Web Components, once adequately specced, will become a compile target for higher level frameworks like React and Vue. That way you still get the benefits of higher level frameworks but the components can interoperate with each other. Vue CLI already supports compiling down to a WebComponent, though not sure how first class it is. There are far to…

I work at a big org and we use Stencil to produce UI kits using web components. In my experience and the anecdotal experience of the people in adjacent orgs that work with web components too: Its still a shit show.

Re: Web Components Eliminate JavaScript Framework Lock-In

#117

Post by mmis1000 »

jakelazaroff wrote: post #37
earthboundkid wrote: post #17

No, they just lock you into one framework per component. I don't know why people say obviously false stuff like this about web components besides they just really, really want it to be true. Yeah, if you're willing to have the same framework on the page ten times, you can just chuck them all in separate script tags using the custom element API. But if you care about making a performant page with progressive enhanceme…

Author here — I'm not sure what you mean by "lock you into one framework per component". The point is that you can encapsulate framework code within web components, not that every component you write should be a web component. Let's say you're writing a Vue app and you really want to use a library that's only available as a React component. You can wrap that library in a web component and use it in your Vue app just…

The biggest problem of web component is that it don't support most state injection(for things that rely on contexts, for example: tabs) and template instantiation(render function of react or scoped slot in vue for example), which literally every current popular web framework does. You may pass string or number as string to it. But anything more complicate that can't be easily serialized? Good luck.

You may add another layer of abstraction on the top of it. But that only make you another framework (like polymer) instead of actually using web components.

In other word. Web component is useful to encapsulate an 'app' (for example: a interactive map viewer that accept an address) inside another app. But is mostly useless to encapsulate anything other than a simple ui/input component. There is basically 0 functionality to inter-blend between parent and child components of different frameworks.

Re: Web Components Eliminate JavaScript Framework Lock-In

#118

Post by itslennysfault »

claytongulick wrote: post #106
itslennysfault wrote: post #98

I like the idea of web components, but really dislike html and js being intermingled (the reason I don't like React/JSX). In web components its even worse because its HTML as a string which means it has no validation and isn't syntax aware. I much prefer the angular approach where you have separate css,html,ts files, and would love a web component framework that could work similarly. Searching for this I found some k…

If you use a good rendering library, like lit-html then (at least in vscode) you get very nice syntax highlighting, completion and validation: html` `

I was actually just looking at that after posting this (lit is new to me). That's a pretty cool solution. I'd still prefer an option to have the html in its own file, but that is just my taste. I know a lot of people feel exactly the opposite.

Re: Web Components Eliminate JavaScript Framework Lock-In

#119

Post by usea »

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

Do elaborate on what UI paradigm web browsers ought to use from mid-90s GUI development.

They said things should be better than they are, not that we should go back to the 90s or even use it as inspiration.

Re: Web Components Eliminate JavaScript Framework Lock-In

#120

Post by DougBTX »

dexwiz wrote: post #66
menssen wrote: post #52

Earlier quoted context omitted.

It is possible with React to write an application where components have no internal state, every component is "read only," and all UI changes are state transitions in (something like) a redux store. This is rarely done, because there are pragmatic reasons (e.g., animations) not to, but it is possible. The other mistake alternatives make is to try to make components having internal state "easier." It should not be eas…

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 component or global across the application.

Post reply on HN