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

Ways to make a web component

webcomponents.dev

Post reply on HN
Print view View original

71–80 of 200 posts

Re: Ways to make a web component

#71

Post by rishav_sharan »

staticvar wrote: post #64
staticvar wrote: post #61

Earlier quoted context omitted.

I appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.

There are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...

Is there no Shadow DOM involved? love your way btw. Here is my no-class implementation from the vanillajs spa that I am working on

https://github.com/rishavs/Verdin/blob/master/src/views/comp...

I just wish that one of these days I will get off my ass and actually finish something that I start :D

Re: Ways to make a web component

#72

Post by dpweb »

Been working on this off and on for the last 15 years. Pretty much ended up where I started. Except the newer JS syntax is nicer than in 2005.

Control:

  controls.hello = e =>
    e.innerHTML = `Hello ${e.getAtttribute('x-who')}`
"Framework" just cycles thru the dom and calls control def with the element as the param.

To handle data, there's a window.data object, which is global data for the app. Its a proxy object. So when window.data is changed, for instance from the results of a fetch, any controls that specify that key - their set() function is called.

  Click me
  

  data.count = 0
  controls.counter = e =>
    e.set = () => e.innerHTML = data.count

Re: Ways to make a web component

#73

Post by georges_gomes »

mshenfield wrote: post #21

First contentful paint (FCP) is basically the same (+-10ms) from React down to a raw HTMLElement. I guess at some point appending elements to the DOM is the bottleneck, rather than the overhead of parsing JS and the efficiency of said JS. To get a faster FCP, statically rendering the component to HTML and re-hydrating it in the client (using Gatsby, for example) seems like it will have a bigger impact than the WebCom…

Co-author of the blog post here.

My mistake is to call it FCP. This local benchmark only shows the performance of: - parsing the javascript code - creating the DOM node

That was the only goal.

We should have network simulation for the next update of the blog post to show some additional color. Good idea :thumbsup:

Static + re-hydrating is actually built in Web Components (technically). "Only" tooling like Gatsby or Next.js is missing to make it more developer friendly.

Re: Ways to make a web component

#74

Post by rishav_sharan »

clairity wrote: post #31

is there any reason you can't write a web component with a block, a block, and a bunch of html? the wedging everything into js is messy, to say the least. it seems the main benefit is being reusable and tightly scoped, but with randomized class names, you could tightly scope the aforementioned bundle as well. even better would be if html added 'for' attributes to and tags, like labels have, so you could target nodes…

I tried that using blocks, a few years ago.

my biggest problem was simply that I still had to add all my templates to a single long html file. And that really feels suboptimal. I had a scaffolded page structure at top. and then dozens of template sections following it. and then as some templates are supposed to call other templates (form inside page section) there was a clear hierarchy but my html file was flat and it was getting harder to reason about the structure of my app the more templates I added. I finally threw it all away and just did a vanillajs spa.

I really wanted to be able to breakup my html file into smaller composable ones without having to do that in JS. but there is no current solution for html importing other html files, and the spec discussion around html import are pretty much dead in the water (and have been since 2013)

Re: Ways to make a web component

#75

Post by georges_gomes »

co-author of the blog post here. Thank you @kjhughes for sharing our work here :pray: I don't know you but I love you already :heart: :)

I'm trying to comment where I have something to bring. If you have questions or maybe a list of things that you would like to see in the next update, please shoot at me!

Many thanks

Re: Ways to make a web component

#76

Post by ohmaigad »

eeJah9to wrote: post #23

I've rewrote the frontend of one of my personal apps from react to webcomponents lately. For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it. For the same reason, only the first example in this page would do for me (the one based on standard without using any library). But I suppose that for actuall…

> For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it.

Doesn't really make sense because for JS frameworks and for the "pure" component the dependency is the same - browser. If i don't have to maintain a project i can just pick whatever is the current version of React/Vue/Other and have the project running as long as the browser doesn't break/change something.

Re: Ways to make a web component

#77

Post by georges_gomes »

CivBase wrote: post #4

This is neat, but I wish there were more examples than just a counter. I would never use something like Angular, React, or Vue to implement something so trivial.

Yes, the counter is simple.

One reason is obviously that writing something in 30+ different framework that you need to "learn" is quite some work :) (10x more that I initially thought :D)

The other reason is that a simple component actually amplify the cost of the framework. And if you think about it, with a more complex component, what you have is more HTML, more CSS and more JS but they are essentially always the same. Only the binding are different from one framework to another. So in the end, the counter is actually a good representation of the cost related to the technology.

This been said, to be correct, the benchmark component should use more capabilities like slots and events to really cover the wide range of capabilities.

This is something we have in mind for a future update of the blog post...

Re: Ways to make a web component

#78

Post by georges_gomes »

staycoolboy wrote: post #43

It would be great to include metrics on: 1. size of framework javascript required to load first 2. tooling to compile. For example, the Vue.js works without tooling, but the React w/Class requires command line tools to build before the site is ready. That's a HUGE difference, IMHO.

co-author here.

1. The bundle size barcharts shows the component size (in light blue) and the framwwork size (darrk blue)

2. The Bundle Analysis chapter contains a description of the build tooling use for each component.

Vue can be used without build tooling if you choose to use the Vue lib with the compiler included but we use the pre-compiled way for max performance and smaller Vue runtime (without compiler).

Re: Ways to make a web component

#80

Post by Joeri »

georges_gomes wrote: post #75

co-author of the blog post here. Thank you @kjhughes for sharing our work here :pray: I don't know you but I love you already :heart: :) I'm trying to comment where I have something to bring. If you have questions or maybe a list of things that you would like to see in the next update, please shoot at me! Many thanks

Many thanks for this, it's an excellent resource.

A suggestion for a next iteration: it would be nice to see which approaches work in IE11 / legacy edge. From looking into web components it seems those browsers are the major stumbling blocks, and I know stencil has an ability to polyfill things on those browsers, but I don't know about the other solutions.

Post reply on HN