Live data from Hacker News

Ways to make a web component

webcomponents.dev

61–70 of 200 posts

Re: Ways to make a web component

#61

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…

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

Re: Ways to make a web component

#62

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…

SVG has the concept of re-usable components.

Maybe in 10 years we can replace HTML with SVG.

hides

I'm sure that would make it much, much harder for people with accessible needs.

Re: Ways to make a web component

#63

I'm not into web development at all so this sounds very new to me, but aren't components in general meant to be self-contained so that they can be reused as "building blocks" for larger applications (or pages, i guess)? Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some…

I've just heard about it, but Shoelace [1] is a component library designed to work with any and all frameworks. To quote from their website, web components address these problems:

  Unfortunately, framework-specific components fail us in a number of ways:
    - You can only use them in the framework they're designed for 
    - Their lifespan is limited to that of the framework's ⏳
    - New framework versions can lead to breaking changes, requiring substantial effort to update components 
There's another discussion on the frontpage [2] about Shoelace that addresses some of your questions.

[1] https://shoelace.style/

[2] https://news.ycombinator.com/item?id=23866894

Re: Ways to make a web component

#64

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…

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...

Re: Ways to make a web component

#65
post #3

Alternate title: The fractured state of web UI design explained using a simple counter. I say that only slightly in jest, as it is a neat way to show all (or most) of your options. Although it doesn't have my at-the-moment favorite way to make web components, blazor/web assembly. For me, it's made front-end development fun again, which I haven't enjoyed in a long time.

Hi nend, co-author of the blog post here. I had blazor/webassembly in mind for quite some time, we will try to have it in on the next update :thumbsup:

IMHO Web Component is the opposite of fractured because whatever "helper" you use to make a Web Components, they sit on the same Custom Element standard. Somehow it's more convergence then having components in Vue and components in React that can't (without massive cost) be used together.

Re: Ways to make a web component

#66
post #3

Alternate title: The fractured state of web UI design explained using a simple counter. I say that only slightly in jest, as it is a neat way to show all (or most) of your options. Although it doesn't have my at-the-moment favorite way to make web components, blazor/web assembly. For me, it's made front-end development fun again, which I haven't enjoyed in a long time.

I've been working on project with Blazor for a few months. I still find myself feeling a little dread when I need to start work on a new big component and then I remember, not only will it not be painful, it will be pleasantly supersizing how easy it was compared to the 5 other time I built something similar in various JS frameworks over the years.

Only Clojure(Script) with Reagent gives me a similar good feeling, better actually, but I've never had a chance to use it at work. If Razor markup could somehow also be C# instead of HTML, like how Reagent markup is just Clojure, that would be neat, but I'm not sure that could be done in a pleasant way.

Re: Ways to make a web component

#67

I'm not into web development at all so this sounds very new to me, but aren't components in general meant to be self-contained so that they can be reused as "building blocks" for larger applications (or pages, i guess)? Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some…

> Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? You should depend on any dependencies (including frameworks), but you shouldn't bundle them, exactly so that when an app is bundled it can do the efficient thing and share dependencies. > What happens if you want 10 components that each use a different framework? One reason to now use frameworks, but…

I downvoted this because these are (in my opinion) entirely theoretical and not practical answers. This reminds me of the "React is better than Angular(js) because look how compact and clean the API is compared to Angular!" type arguments. This implies that "React apps" are going to be less complex than Angularjs apps but the reality is anything but: large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do.

Likewise "When you have a stable component boundary you can upgrade libraries a component at a time, rather than needing to upgrade the whole application at once. Yes, you might have some overhead during the transition" I'll believe this when I see it, but I suspect you're making this sound way less painful than it actually would be. More likely each dev adds a new framework, they all move on to other teams/companies, no one is interested in painstakingly updating everything, and you have perpetual lock-in until you do the "JavaScript Shuffle" i.e. scrap it and rewrite in a new framework.

I'd love what you're saying to be true but my experiences tell me it probably is not.

Re: Ways to make a web component

#68
post #62

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…

SVG has the concept of re-usable components. Maybe in 10 years we can replace HTML with SVG. hides I'm sure that would make it much, much harder for people with accessible needs.

Accessibility is key IMO. And why it's sad the standard components don't get more love. Like why in 2020 can't select dropdowns do basic matching on any part of optiond instead of only leading characters? Or show filtered results as one types?

Re: Ways to make a web component

#69

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...

Wow, that's so much cleaner - why don't they just do it like this in the example? I'd be much happier learning standard web components if they were all a breath of fresh air like this.

Personally I'd miss the JSX syntax, but this more than makes up for it by removing the entire whacky state vs. props thing. Although- how do you represent custom props here - arguments to the constructor? That'd be really elegant.

Do those styles and query selectors leak out of the component? I'm assuming they don't since that's the entire point of the idea of a component, but just want to be sure.

Re: Ways to make a web component

#70
Web components to me represent the architecture I’d like to have. I think a good arch could be:

1. Build a rails/django type site, make everything work vanilla http+html etc.

2. Create standalone web components for the places you need some more interactivity, like type-ahead search box, “click to add” type thing, or a datatable

So most of your performance stuff could be handled/improved on the server, focus on aggressive caching etc. and most of the complexity would be on the server with small stand-alone parts on the client (ideally without a lot of interconnection, i.e. without a big client side state manager). This would not allow full-spa but I am not convinced SPA is the answer in many/most of the cases it’s used.

Post reply on HN