Live data from Hacker News

Web Components Aren't Framework Components

kgscialdone.substack.com

11–20 of 42 posts

Re: Web Components Aren't Framework Components

#11

Earlier quoted context omitted.

Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems. A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very li…

> A framework component is effectively a reusable block of code. I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element. As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can…

> than simply writing 3 custom elements that monitor and propagate values for any child element.

I feel like you're underestimating how easy this is to skrew up.

Re: Web Components Aren't Framework Components

#12

Earlier quoted context omitted.

> A framework component is effectively a reusable block of code. I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element. As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can…

> than simply writing 3 custom elements that monitor and propagate values for any child element. I feel like you're underestimating how easy this is to skrew up.

You're probably correct in your assessment of my estimation.

However, it's far far easier for a newcomer to screw up when approaching react or cue than when approaching a custom html element.

Time will tell as I use my experiment in more domains, more often and in larger apps.

Re: Web Components Aren't Framework Components

#13
post #9

I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a ` ` element. simply retrieves the specified file and adds it to the DOM where the `remote-fragment` is declared. No need for server-side scripting to include common parts of the HTML page. There's a bunch of similar use-cases currently satisfied by fat client frameworks or server-side languages that simply go away when yo…

Cool. But is it readable from a search engine?

Not a priority for webapps.

In websites, search engines ignoring the common elements that you would use this for, such as navbars, isn't a deal-breaker.

When I search Google for keyword FOO, results that have FOO only in the elements common to all web pages are useless results.

I'm typically looking for FOO in the content, not in the navigational elements or other common elements.

Re: Web Components Aren't Framework Components

#14

Earlier quoted context omitted.

Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems. A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very li…

> A framework component is effectively a reusable block of code. So is a web component…

Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"?

To me there is a larg distinction but I do concede that to others there may be no difference.

Re: Web Components Aren't Framework Components

#15

Earlier quoted context omitted.

It seems like you reinvented Edge Site Includes ( https://en.m.wikipedia.org/wiki/Edge_Side_Includes ).

I like to think that I didn't reinvent it (just like react, et al didn't reinvent it), I only refined the concept into the simplest form that works :-) After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec. Look at the options for including HTML fragments in web pages: 1. Comple…

Refined the concept into the simplest form that works… as long as you have JavaScript enabled.

Re: Web Components Aren't Framework Components

#16

Earlier quoted context omitted.

I like to think that I didn't reinvent it (just like react, et al didn't reinvent it), I only refined the concept into the simplest form that works :-) After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec. Look at the options for including HTML fragments in web pages: 1. Comple…

Refined the concept into the simplest form that works… as long as you have JavaScript enabled.

What's the alternative other than simply doing without this feature?

Re: Web Components Aren't Framework Components

#17

Earlier quoted context omitted.

> A framework component is effectively a reusable block of code. So is a web component…

Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"? To me there is a larg distinction but I do concede that to others there may be no difference.

Both Web Components and Framework Components utilize JS and HTML.

Re: Web Components Aren't Framework Components

#18

Earlier quoted context omitted.

Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems. A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very li…

> A framework component is effectively a reusable block of code. I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element. As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can…

> a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element.

Web components/custom elements are reusable behaviours/functions - which can contain custom js, all bundled as a reusable HTML element.

Think of it a bit like an object in an object orientated programming language - the object has both data/state (DOM) and code/functions to manipulate that state.

Re: Web Components Aren't Framework Components

#19

Earlier quoted context omitted.

Refined the concept into the simplest form that works… as long as you have JavaScript enabled.

What's the alternative other than simply doing without this feature?

E.g. Apache's Server Side Includes[0] allows for

    
Tbf, you did specify 'server language' in a post further up the comment chain, but the the thing is that it doesn't have to be much more complicated that SSI -- assuming it's available for your deployment target, of course.

(SSI obviously does not require JavaScript.)

[0] https://httpd.apache.org/docs/current/howto/ssi.html

Re: Web Components Aren't Framework Components

#20

Earlier quoted context omitted.

Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"? To me there is a larg distinction but I do concede that to others there may be no difference.

Both Web Components and Framework Components utilize JS and HTML.

> Both Web Components and Framework Components utilize JS and HTML.

If you're writing them, certainly.

For web designers, using Web Components means not having to know JS, not having to know React, not having to know hooks, not having to know usememo, etc.

That's, to my mind, a large enough distinction: the requisite knowlege to reuse a framwork's components needs a full time developer. The knowledge required to reuse a web component is ... HTML (and maybe CSS?)

Post reply on HN