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

121–130 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#121

Post by fuzzy2 »

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…

Then… use Angular Elements?

Using innerHTML isn’t specific to Web Components in any way. It was and is a quick & dirty way to dynamically insert HTML.

Re: Web Components Eliminate JavaScript Framework Lock-In

#122

Post by yohannparis »

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…

You can use `` for that purpose and keep your separation of concerns okay.

Re: Web Components Eliminate JavaScript Framework Lock-In

#123

Post by paulddraper »

itslennysfault wrote: post #112
paulddraper wrote: post #102

Earlier quoted context omitted.

> 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; } `…

Well, you can use `innerHTML` and a string, but you don't have to.

But there several alternatives:

1. Use DOM APIs (createElement).

2. Fetch the HTML as a separate resource.

3. Have the HTML in a separate file and bundle it with a bundler.

4. Use React/JSX.

5. Use a preferred templating library of your choice.

You can do whichever of these you like the most

Re: Web Components Eliminate JavaScript Framework Lock-In

#124

Post by adam_arthur »

jdmg94 wrote: post #116
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.

Yes, the Web Components spec is incomplete and not adequate for real-world use currently.

But the end state will be as a compilation target, not as a development platform.

Re: Web Components Eliminate JavaScript Framework Lock-In

#125

Post by paulddraper »

usea wrote: post #119
paulddraper wrote: post #105

Earlier quoted context omitted.

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.

Oh well, yes, it would be nice for things to be better than they are.

(^ feel free to copy-paste that to any HN thread)

Re: Web Components Eliminate JavaScript Framework Lock-In

#126

Post by gherkinnn »

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.

I agree.

useEffect should have been named useDangerousSideEffectAndThisIsNotALifecycleHook and the js influencers should have never compared useEffect to component lifecycles and the React team should have updated their docs and not wait 4.5 years to do so and the dependency array should absolutely not be optional.

Re: Web Components Eliminate JavaScript Framework Lock-In

#127

Post by runarberg »

svieira wrote: post #83
runarberg wrote: post #59

Earlier quoted context omitted.

For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. Some Input Or I can simply ask…

Or you can do a little more work in your lib for your users and offer: import lib from "the-lib.co.uk"; lib({ target: ".target" }); If your users might not want you to watch the _whole_ DOM for performance reasons: import lib from "the-lib.co.uk"; lib({ target: ".target", root: ".all-the-targets-show-up-here" }); And if your users might already have a mutation observer in their apps: import lib from "the-lib.co.uk";…

It may just be me, but all of these seem a lot inferior API design then a simple web component. Particularly if I’m asking my users to setup a mutation observer.

Aside: Don’t you need to pass the library function into the callback while constructing the mutation observer?

    import lib, { mutationObserverCallback } from "https://my-lib.example";

    lib({
      target: ".target",
      observer: new MutationObserver(mutationObserverCallback),
    });
Honestly, this feels like so much magic compared to a simple:

    Some Input
where I handle update in my library by listening to the slotchange event.

Re: Web Components Eliminate JavaScript Framework Lock-In

#128

Post by djrenren »

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…

Web Components are really just the minimal APIs required to allow the implementation of new HTML elements. This includes things like:

- Responding to being attached to the DOM

- Encapsulating DOM nodes (the Shadow DOM)

- Scoped styling (Shadow DOM + User defined stylesheets + CSS parts)

It is definitively not a templating engine. It doesn't provide any new APIs for creating DOM nodes, or mutating them a la React or handlebars or lit-html. Templating is basically the "next step up the stack". Using shadowDom.innerHTML = `...`; is basically a stand-in for having an actual templating engine.

There is work going on, developing a native templating system in the browser which may interest you. It's called the DOM Parts proposal and you can find info on it here: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Re: Web Components Eliminate JavaScript Framework Lock-In

#130

Post by MrDresden »

yohannparis wrote: post #122
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…

You can use ` ` for that purpose and keep your separation of concerns okay.

As a non web dev I had to look this up and yeah, this looks like a very sane and clean way to separate concerns and get proper handling from IDEs:

https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Post reply on HN