[HN Gopher] HTML Web Components
___________________________________________________________________
HTML Web Components
Author : goranmoomin
Score : 314 points
Date : 2023-11-13 15:31 UTC (7 hours ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| simonw wrote:
| Also read these articles for more on the idea of "HTML Web
| Components":
|
| https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... -
| "So there you have it: a few thousand words on my journey through
| coming to understand and work with these fully-Light-DOM web
| components, otherwise known as custom elements. Now all they need
| is a catchy name, so we can draw more people to the Light Side of
| the Web."
|
| https://adactio.com/journal/20618 then suggests the catchy name.
| nightski wrote:
| I just don't get the point. They are cumbersome to use, so now
| you need a lightweight framework on top of the built in
| framework such as Lit (which btw is larger than Preact). Then
| they solve none of the real problems like state management,
| routing, etc... so you'll likely need to pull in more.
|
| Sure you can get re-usable components. But are you going to
| pull in a re-usable web component that might use say Vue
| underneath when you use React? It just doesn't make any sense.
| ohwellhere wrote:
| I think there's a lot of value for classic server-side web
| applications rather than SPAs. That handles routing, state,
| etc. I'm personally a fan and hope that the server-based
| application renaissance happens as some predict.
| dmix wrote:
| Most people using react aren't building SPAs. Vue/React can
| be used the same way as jquery, which is to add enhanced UI
| functionality that server-side HTML views simply can't
| offer.
|
| The best example is a multi-select box, or a searchable
| select box with autocomplete (what W3 calls the combobox
| pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/)
| which in jquery was usually via https://select2.org/
|
| For example, on my company website there's a timezone
| select box with 151 options. Asking a user to scroll
| through 100+ options is a big ask vs typing a few
| characters and hitting enter. There really is no static
| server-side way to solve this problem (I tried hard to
| think of one)... without creating a multi-page Wizard for
| what should be a single field on a larger form.
|
| If you're building a SaaS product there are many UI
| requirements that demand high-interactivity and and there's
| really no better mainstream solution atm than static-first
| sites with small "islands" of React/Vue/etc components
| (ideally with hydration).
|
| People still abuse React/Vue of course and the trend is
| 100% moving back to "mostly static" rather than slow SPAs
| but IMO JS-powered components are not never going away
| unless browsers start offering a broad selection of built-
| in complex web components like comboboxes, datepickers,
| tooltips, etc.
| jtcasper wrote:
| The <datalist> element with a text input field is an HTML
| native typeahead, which works great with SSR or you could
| wire up the datalist client side with an XHR creating the
| datalist.
|
| You maybe don't get full control over the rendering style
| of it, but it's a still significantly more usable than
| the Angular Material autocompletes.
| xigoi wrote:
| <input> with <datalist> still doesen't work on Firefox
| Android.
| dmix wrote:
| That's an interesting one I wasn't familiar with.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/da...
|
| It's a shame clicking on it doesn't show the options like
| a select box though.
| couchand wrote:
| Click again I guess?
|
| > Recommended values in types text, search, url, tel,
| email and number, are displayed in a drop-down menu when
| user clicks or double-clicks on the control.
| cdcarter wrote:
| Clicking it shows the options for me (Chrome 119).
| boredtofears wrote:
| > Most people using react aren't building SPAs
|
| > People still abuse React/Vue of course and the trend is
| 100% moving back to "mostly static" rather than slow SPAs
|
| I'm not seeing this at all, in fact I can't remember the
| last React project I worked on that wasn't a full blown
| SPA. I don't see anyone starting or advocating for static
| sites with islands unless they're using a framework like
| Astro or something.
|
| Do you have any example sites or codebases using this
| approach?
| Zetobal wrote:
| Not elegant but we use a websocket for search in htmx.
| hu3 wrote:
| Preact requires a build step otherwise you don't get JSX and
| you have to build applications a la mithril.js mode:
|
| > const app = h('h1', null, 'Hello World!');
|
| With Web Components no build step is required and you're
| still able to intermix HTML with JS just like JSX. See the
| code below this section:
| https://github.com/kennyfrc/cami.js#key-concepts--api
| Joeri wrote:
| You can use the htm library as a pure client-side jsx:
| https://github.com/developit/htm
|
| It is not completely the same, but far better than that h
| function madness.
| naasking wrote:
| State management is only a problem if you have client-side
| state that isn't HTML state. Lots of web apps don't fit that
| mould.
| kansface wrote:
| Web components are only useful IMO in the case of a large
| enterprise which wants to systematically and consistently
| style a large number of applications written by different
| divisions in different frameworks in different languages
| targeting different clients.
| Fahata wrote:
| I'd add longevity. If your company works for a product
| where you'll have to maintain the code you write now for
| the next decades, you don't want to deal with then-ancient
| abstractions. The JavaScript of a well-written web
| component should be as valid now as it will be in 10 years,
| as you're just using the platform.
| troupo wrote:
| This year I pulled class-based React component into a
| greenfield React project. Worked without a hitch, even
| though its a 10-year difference between approaches.
|
| Meanwhile, "use the platform":
|
| - all form components written before form participation
| landed in browsers are broken
|
| - all web components written before cross-root ARIA (not
| even a spec yet) are potentially broken due to shadow DOM
|
| - ... you may continue this list at your own leisure ...
| divbzero wrote:
| Could we shorten the catchy name further? Call them "HTML
| components".
| jauntywundrkind wrote:
| I really appreciate there being some concerted advocacy for
| shadowless web components!
|
| So much of the beauty & elegance of the web was how declarative
| everything is, as that grants such observability &
| malleability. Shadow dom felt such an _enterprise_ desire, to
| build much higher _encapsulation_ walls, to layer in so much
| certainty, and that never felt like a goal I shared.
|
| This article shows how light dom work can compose. I want to
| see light dom advocacy go further. It always seemed clear to me
| a web component/custom element could and should just self-
| modify the dom inside of it, move children around, build new
| content. Another example in the comments talks about maybe the
| user avatar element adding a div with the users name... Maybe
| the page or framework adds the icon, and the custom element
| then inserts that name, or that name and some aesthetic
| embellishment.
|
| I guess my one concern with light dom / html web components is
| it seems like there have been - in some cases - some good
| performance wins from shadow dom. This wouldn't change what I
| go for unless I was desperate, but as a dev, in my head I see
| how shadow dom can scope down and reduce the number of elements
| that have to be traversed for a css specifier. and I want that
| win to be available somehow to me.
|
| Really elating to see a lighter take on custom elements / web
| components. Thanks for the great links Simon!
| madeofpalk wrote:
| > React components cannot do this -- full stop.
|
| Render your react components on the server and send them over the
| wire as plain html. no client side javascript required -- full
| stop.
| Spivak wrote:
| So just run javascript before your components render so you
| don't have to run javascript before your components render.
| madeofpalk wrote:
| If you find a way to deliver a website without running _any_
| code, let me know!
| Spivak wrote:
| I just think SSR is kind of missing it because web
| components allow a static frontend bundle to have a power
| that was previously reserved for SSR or HTML-only apps.
|
| Moving the render off the client is nice, but removing the
| prerender altogether is something much cooler.
| jkrems wrote:
| If you have a static frontend bundle, isn't that just SSG
| (static site generation)? And if you can generate the
| site at build time, what's the fundamental difference
| between any of the non-web component SSG solutions and a
| web component SSG solution? Sure, you can pretend like
| there will be "no build step". But only if you're fine
| with "no proper cache headers" (and a long tail of other
| things). So in practice - hopefully there _will_ be a
| build step anyhow.
| jzombie wrote:
| Websites with ads should take notice of this.
| freeone3000 wrote:
| Have a HTML page that you just send. It's really simples.
| 1-more wrote:
| Send like in the mail on a USB stick?
| robertoandred wrote:
| You don't think code editors use code?
| micromacrofoot wrote:
| Technically you're still running JS first, just on a different
| machine.
| Xeamek wrote:
| Or You could instead use this magic thing that has been around
| for decades, has massive tooling and most importantly, doesn't
| lock you into one specific ecosystem of language that was never
| supposed to be run server side to begin with;
|
| Html templating
| madeofpalk wrote:
| That's exactly what React is though?
|
| Rendering react on the server isn't some magical hip
| technology. It's just a different template framework. I'm not
| pretending this is anything special or fancy.
| Spivak wrote:
| Doesn't this create some nasty coupling since your web components
| look like a div but can actually require an arbitrarily complex
| HTML schema underneath? Can I write that down somewhere?
| animal_spirits wrote:
| Yeah that is my confusion too. The nice thing about react
| components is that I don't have to remember to write all the
| div elements inside them, but from this example I do.
| night-rider wrote:
| We've abstracted away <DIV> soup
| mikebelanger wrote:
| If things like slots are used, it isn't necessarily nasty
| coupling. But I agree this approach does make more a more
| complex tree structure than something you would see in a
| typical JSX/TSX file.
|
| That said, I think the author's bigger point was that
| augmenting, rather than replacing/abstracting away basic web
| elements will win out long-term. Some degree nastier-looking
| coupling is a worthwhile trade over more opaquely-operating
| render libraries. I suspect augmented web components fail more
| gracefully too.
| cantSpellSober wrote:
| > _they can render before JavaScript. React components cannot do
| this -- full stop_
|
| Not a _full_ stop; SSR means they _could_ render before _client-
| side_ JS.
|
| The example is a bit too simple to make the author's point IMO. A
| web component that handles changes to state would be a better
| comparison, and make for a better argument.
| algem wrote:
| How would an "Html Web Component" handle state change? I was a
| bit lost on the benefits given the example of wrapping an img
| tag. Sure you could group and reuse common elements but you
| would still need javascript to do anything interactive. Even in
| the example given the alt text of the image is typically
| dynamic now because of localization so even then content is
| missing with javascript.
| hyperhello wrote:
| That's what JavaScript is supposed to be for: state change.
| Not rendering the page.
| goeiedaggoeie wrote:
| This is the main issue for me with webcomponents, they are not
| SSR friendly.
| kaba0 wrote:
| Do you want SSR for SEO, or for fast first interaction?
| Because if the latter, then arguably some form of
| webcomponents might be theoretically better optimizable by
| browsers than DOM-element soups.
| nicoburns wrote:
| > then arguably some form of webcomponents might be
| theoretically better optimizable by browsers than DOM-
| element soups.
|
| Arguably they might be less optimisable than regular web
| frameworks, as they make it difficult to coordinate between
| different components on the page.
| goeiedaggoeie wrote:
| This is a good point, but I would counter, perceived speed
| of rendering from a user perspective is more important than
| time to interact with the app/site (a reasonable time to
| interact is however very important.
|
| Good load order and only loading in the content and JS
| above the fold initially helps a ton.
|
| JS frameworks are huge and I am still saddened that proper
| tree shaking and optimization got left by the way side in
| how the modern web has evolved. I worked with google
| closure in advanced modes and the closure components for a
| few years and the compiler was absolutely astounding (and
| the components designed with the compiler in mind) in code
| splitting, tree shaking and minimization.
| kaba0 wrote:
| Oh, google closure was absolutely ahead of its time!
| jmull wrote:
| Consider the approach this article suggests.
|
| You want to have the tags and content appear in the web
| component (not rendered by JS) which makes it easily and
| immediately available to crawlers.
| toasted-subs wrote:
| You can pre-generate them on the client though.
| inglor wrote:
| Good point, and conversely, web components can't since they
| must be registered in JavaScript before the side loads.
|
| Hydration solutions exist but are usually worse and come with
| surprising tradeoffs and harm composabilitiy.
| superkuh wrote:
| It's a nice idea and I'm glad we can expand the language to
| differentiate between html web components and javascript web
| components. That's important because the vast majority of use of
| web components are in the form of javascript web components. The
| only time I've ever seen HTML web components are on blog posts
| talking about how you can use web components. Never on an actual
| website about something besides web components.
|
| I want to believe... but reality is stacked against HTML web
| components. I'm just going to stick to HTML and leave the HTML
| with dashes to others.
| mock-possum wrote:
| I've made a couple of big SPAs that use Lit to manage views.
|
| I can't link you to them here without blowing my cover, but
| honestly I love working with web components, and being able to
| do it natively rather than propped up by a mound of JavaScript
| feels good.
| troupo wrote:
| You're not doing it natively. You're using a framework
| replete with its own custom DSL, multiple workarounds for
| issues like SVGs, its own data binding system etc.
|
| It's just as native as any other framework under the sun.
| troupo wrote:
| > but reality is stacked against HTML web components.
|
| Because they don't exist. "HTML web components" are just HTML,
| and you don't need components for them.
|
| Web Components are useless without Javascript.
| revskill wrote:
| React Component is a function.
|
| HTML web component is NOT a function.
|
| You don't just compare those things, they work and compose
| differently.
|
| I would rather combine them: A html web component renderer for
| React.
| fkyoureadthedoc wrote:
| So when react components were classes they were comparable, but
| now that react components are functions they are not?
| hu3 wrote:
| I think I've finally seen the light when it comes to Web
| Components:
|
| https://github.com/kennyfrc/cami.js
|
| > No Build Steps, No Client-Side Router, No JSX, No Shadow DOM.
| We want you to build an MPA, with mainly HTML/CSS, and return
| HTML responses instead of JSON. Then add interactivity as needed.
|
| > Declarative templates with lit-html. Supports event handling,
| attribute binding, composability, caching, and expressions.
| sibit wrote:
| For me, that's the beauty of Web Components. You can find (or
| build) a base class that works the way you need it. I like a
| React class component style class with an XState-inspired state
| machine built in.
|
| https://github.com/codewithkyle/supercomponent/blob/master/s...
| gen220 wrote:
| Have you tried HTMX before? Seems strongly aligned, with HTMX
| perhaps having a bigger community. Curious if you have, and
| found it lacking in some way.
| Sammi wrote:
| The Cami page already mentions htmx.
|
| ctrl+f htmx
|
| "For folks who have an existing server-rendered application,
| you can use Cami to add interactivactivity to your
| application, along with other MPA-oriented libraries like
| HTMX, Unpoly, Turbo, or TwinSpark."
| troupo wrote:
| Replace JSX with a custom non-standard DSL, call it a win.
| TheRealPomax wrote:
| One problem is that "web components" is not a thing, you don't
| make "a web component". "Web Components" is the name a stack of
| three things that, taken together, make up the Web Components
| API.
|
| You don't really make "a web component", what you make is a
| Custom Element, which might use a Shadow DOM, and might use an
| HTML template. Three things of which the most important one is
| the custom element.
|
| With the core concept being that you're just making "more HTML
| elements", everything you can do with those, including which
| attributes and JS API they support, is up to you, and the way you
| put them on a page, the way you interact with them, the way you
| listen for events on them, etc. etc. is the exact same as any
| other HTML element. If you known how to write web pages the "old
| school" way, then you already know how to use custom elements.
| You just need to learn how to declare them.
| k__ wrote:
| I always saw web components as the missing leaves to the root
| that CSS frameworks embody.
| sam_lowry_ wrote:
| For those who read to the end... Angular still uses
| XMLHttpRequest and not fetch, IIRC.
|
| Funny, huh.
| spyke112 wrote:
| No one is forcing you to use the Angular HttpClient though. You
| could just as well use fetch.
| meindnoch wrote:
| As of 2023, fetch() still doesn't support upload progress.
| LNSY wrote:
| https://lnsy.dev/blog/custom-html-components.html
|
| Here is my blog post about custom HTML Elements. It covers state
| changes, etc.
|
| P.S., I am looking for a Front End project, preferably writing
| vanilla JS. My email is on the page.
| singularity2001 wrote:
| It will be nice if/when these components can also be defined
| within HTML
|
| <template type=component name="user-avatar"
| parameters="[src,alt]"> <img src="{src}" alt="{alt}"/>
| </template>
| rsolva wrote:
| > My takeaway is: if you're looking for longevity, opt for a
| technical approach of augmentation and enhancement over
| replacement.
|
| This is my experience too, and this philosophy have made my web
| projects last a long time with minimal maintenance and
| dependencies.
| _joel wrote:
| Am I misreading this or is it what https://htmx.org/ provides?
| willsmith72 wrote:
| > But the unique power of web components (in the browser) is that
| they can render before JavaScript. React components cannot do
| this -- full stop.
|
| Unless you... server-side render them. Then your definition of
| "render" needs to change
| justsomehnguy wrote:
| At least you _can_ server render web comppnents.
| robertoandred wrote:
| You've been able to server render React for like a decade.
| justsomehnguy wrote:
| Define 'server render'?
| troupo wrote:
| Output them on the server. Something you _can 't_ do with
| Web Components
| jakelazaroff wrote:
| You actually can't yet do that reliably. Declarative Shadow
| DOM is not yet supported by Firefox.
| https://caniuse.com/declarative-shadow-dom
| Andrex wrote:
| You cannot, last I checked. JavaScript is required for Web
| Components and lack of SSR support is the only reason I moved
| away from them.
| mortallywounded wrote:
| Sorta-- that means you render it at least twice.
|
| 1. You convert the JavaScript/JSX into HTML on the server and
| send it down (along with multiple blobs of JSON/code to re-
| hydrate).
|
| 2. The browser parses all the HTML and added JSON/code.
|
| 3. The browser then re-hydrates the page via JavaScript loading
| all of the JSON/code and computing everything (rendering it
| again).
| Joeri wrote:
| Not if you use react server components, then markup is
| streamed in chunks as it gets rendered on the server and
| patched into the dom on the client. The JS for those
| components is never sent to the client.
| willsmith72 wrote:
| With progressive enhancement, the page is "rendered" for all
| intents and purposes before any js enters the scene
| notatoad wrote:
| >The browser then re-hydrates the page via JavaScript loading
| all of the JSON/code and computing everything (rendering it
| again).
|
| isn't this exactly what's going on under the hood with web
| components? if you send an html page including <user-
| avatar><img></user-avatar>, the browser is going to draw the
| <img> tag and treat the <user-avatar> tag as a no-op because
| it doesn't know what to do with that. then your javascript
| kicks in and transforms the <user-avatar> tag into whatever
| the javascript defines it as, at which point it will get re-
| rendered.
| mortallywounded wrote:
| Yeah-- but a single component is a much smaller degree of
| JS than an entire React application.
| troupo wrote:
| Depends on how many "small components" you need.
|
| Reddit's new redesign downloads over 100 js files:
| https://x.com/dmitriid/status/1708772121260732494 to
| render a menu.
| mortallywounded wrote:
| Of course there's a tradeoff--- if everything is a
| component then it may as well be an SPA (or at least
| bundle those files...).
|
| I don't think the core idea was to ever use "hundreds" of
| components. HTML should be able to do a majority of the
| work, and you sprinkle a component here or there as
| needed.
| sesm wrote:
| > <user-avatar>
|
| > <img src="https://example.com/path/to/img.jpg" alt="..." />
|
| > </user-avatar>
|
| I thought the standard way to do it is:
|
| <img is="user-avatar" src="https://example.com/path/to/img.jpg"
| alt="..." />
| joestrouth1 wrote:
| That is one way to do it, provided `user-avatar` extends
| HTMLImageElement and not the more generic HTMLElement.
| Extending built-ins and using the `is` attribute is not
| supported in Safari however and last I checked they were firmly
| opposed to it.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
| earthboundkid wrote:
| https://caniuse.com/mdn-api_customelementregistry_builtin_el...
| jjcm wrote:
| They're different things, though with an extremely simple
| component they might achieve a relatively similar goal. The
| downside of `is` is that you can only specify a single element
| to map to the component. An example of why you'd need to take
| the slotted approach is if you had something like this:
|
| <user-avatar>
|
| <img slot="image" src="...">
|
| <div slot="name">Bob Bobson</div>
|
| </user-avatar>
| randyrand wrote:
| There's almost no standard way to do anything when it comes to
| html style.
| account-5 wrote:
| With the massive caveat that I'm not a web developer or react
| developer, doesn't this stuff just look XML? I know html is a
| subset of XML but this stuff looks more and more like the XML
| that everyone complains about.
|
| Edit: I'm meaning the attributes being longer than what the tags
| are denoting.
| salzig wrote:
| Does HTML kinda look like XML? Yes.
| akshayka wrote:
| We use web components in our project (a reactive Python notebook
| that, among other things, lets users build simple web apps [1])
| to make it easy for the user to instantiate and compose our UI
| elements. Users can easily interpolate these elements into
| markdown, for example, since their representation is just HTML.
|
| [1] https://github.com/marimo-team/marimo
| joshstrange wrote:
| I was interested to see this article explain what `user-avatar`
| actually did/provided but it never did. Does it just have styles
| in it? If so why wouldn't I just use css classes?
|
| I also think having a `user-avatar` take a `src` prop makes way
| more sense than having to add an `img` tag inside it everywhere I
| use it. In that case what am I saving? What is reusable?
|
| Vue/React/Angular don't seem like they are trying to "replace"
| HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to
| augment it. HTML5 won.", in the "On The Web, Augmentation Wins in
| the Long Run" section), they are taking HTML/CSS/JS and building
| on top of them. If they all used canvas to render instead I might
| buy that argument but they don't. They absolutely push those
| technologies to their breaking point but it's nothing short of
| amazing in my book what you can accomplish with them compared to
| just HTML/CSS/JS and even "web components".
|
| I was excited when Web Components were first announced but they
| are incredibly lackluster with no "Batteries included" and feel
| like they don't really help you build web _apps_ like the
| frameworks do. Every alternative to the big frameworks (looking
| at you htmlx) feel like minor syntaxic sugar for jQuery and
| friends which feels like a massive step backwards and completely
| the wrong choice for building a web app.
| continuational wrote:
| > I was interested to see this article explain what `user-
| avatar` actually did/provided but it never did.
|
| Yeah, the lack of concrete examples makes this feel a bit too
| much like a shower thought to me.
| yohannparis wrote:
| This is a purpose of a blog.
|
| This was not a tutorial or an article on how to use Web
| Components.
| continuational wrote:
| I mean, anybody is free to write how they like on their
| blog. I just don't find arguments like these convincing
| without realistic non-trivial examples.
| reactordev wrote:
| >"with no "Batteries included" and feel like they don't really
| help you build web _apps_ like the frameworks do."
|
| Define _app_. React doesn't have batteries, it has
| composability. Web Components do too but you have to know how
| (it's a lot easier in React, just return (html)) but in Web
| Components, you can register your custom element and provide
| the functionality that you call "batteries". [1] So if you
| don't care about attributes and just want semantic composable
| things, just call it whatever you want to. <user-avatar></user-
| avatar>. Conceptually it's a web component that extends
| HTMLDivElement.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
| boredtofears wrote:
| I think the Eric Meyer post demonstrates the intention of that
| much better:
| https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the...
|
| The benefit boils down to progressive enhancement: because an
| img tag has built in behavior you simply rely on default
| rendering behavior and provide "augmentation" as needed via
| your web component.
| webstrand wrote:
| What's the advantage of this over just using divs for
| everything, though? If this used shadow dom, I could
| understand. But custom elements don't even behave like blocks
| by default. Namespace collisions with custom components are
| just as bad as class collisions, if not worse since you can't
| `.myns.button`. Is it just the `connectedCallback` versus
| some manual method of wiring up elements to their javascript
| behaviors?
| joshstrange wrote:
| That still doesn't click for me. Why wouldn't you make the
| label/slider part of the component itself. It feels like you
| have the worst of both worlds. You more or less need/expect
| it to always wrap those elements but nothing enforces that so
| this seems very brittle to me, not to mention verbose.
|
| They mention not wanting to pass though all those props:
| <super-slider type="range" min="0.5" max="4" step="0.1"
| value="2" unit="em" target=".preview h1">
|
| We will ignore the last 2 since those are required anyway.
| How is `type="range"` not the default that you would just
| set, no attribute/prop needed? Then min/max/step/value all
| feel like things you could have defaults for and then, yes,
| pass them through. In forms I'm always pushing towards
| consistency, I don't want to make it easy to just set random
| attributes on the underlying element, it needs to be
| deliberate.
|
| I can believe I'm just missing something but Web Components
| just seem like extra work with very little gain.
| tored wrote:
| The article argues between the difference of a JavaScript
| Web component and a HTML Web component, you describing the
| former, thus the need for JavaScript.
|
| Personally I think the main problem here is client side
| rendering to begin with, with a modern server side
| templating library you get a component based structure too
| and can abstract whatever HTML tags you want in your
| component _before_ client side JavaScript.
|
| Problem with React is that it is JavaScript first, you
| always begin with a JavaScript function, but in my opinion
| the web should be HTML first.
| joshstrange wrote:
| > The article argues between the difference of a
| JavaScript Web component and a HTML Web component, you
| describing the former, thus the need for JavaScript.
|
| The article goes on to add a good little bit of JS to
| make everything work they way they want. They still need
| JS to accomplish what they want. If you turn off JS
| things will break in that example.
|
| > Personally I think the main problem here is client side
| rendering to begin with
|
| I mean unless you want to roundtrip for new HTML segments
| (aka Liveview or whatever Laravel has) you either need to
| have client-side rendering or duplicate your rendering
| logic (in something like both PHP and JS for the fast
| update without refreshing on each click). I'll never
| duplicate rendering logic again if I can help it and that
| means client-side render (potentially with SSR for the
| first render). It avoids so many bugs/issues.
|
| > but in my opinion the web should be HTML first
|
| This just feels dated to me. I fundamentally do not
| understand this desire. What do you gain from the web
| being just HTML? What does that even mean? With a CSR
| framework you are still rendering out HTML, I don't
| understand why some people care that the HTML was
| generated server side or client side. The web has moved
| on from being just documents, it's interactive and that
| provides a much better UX.
| tored wrote:
| Sure, the article is incomplete in the sense that it
| doesn't fully commit to the idea of HTML Web component as
| opposed to JavaScript Web components, but it is the
| correct way of thinking about this.
|
| There will almost always be a roundtrip, either to fetch
| HTML segments or to ask for more JSON data, except for
| the rare cases you already have everything, because that
| is the nature of client-server paradigm.
|
| By putting all your templates in the backend you can
| render them as a whole document or in parts in one go and
| send them wherever, to the browser, over Ajax or in the
| email. No need for buggy asynchronous SQL JOINs over HTTP
| and infinite state handling.
|
| If you always start with a JavaScript function, and all
| that comes with that, you need a programmer to be able to
| create the web, but with HTML (and CSS) first you can
| have other categories of people do that, like designers.
| And combine that with a library like htmx you can then
| enhance that experience for interactive parts and still
| keep everything in the same backend template. And if it
| still a need for more complex interactive parts a
| programmer can can add that with JavaScript afterwards.
| That is a much better division of labour.
|
| And it is not outdated, browser actually excel in
| rendering HTML documents, that is what they are designed
| to do, thus it will always be faster to render the HTML
| document as it is rather than building it on the fly.
|
| And also the core idea of reaching for JavaScript before
| HTML will result in suboptimal solutions, I have seen so
| much unnecessary JavaScript code that could have been
| easily solved with a few lines of HTML. This change of
| perspective changes how we think and reason about a
| problem and therefore our solutions as well. That is why
| the bootstrapping of a "modern" web app has become more
| and more asinine.
|
| Another problem with frameworks like React, Vue, Angular
| and et al have is that they have their own lifecycle and
| that has made the web closed and not open how it once
| was, closed in the sense that you can't enhance the HTML
| document from the outside after it been rendered, thus
| this leads to the assumption that the person(s) who wrote
| the site is also the person(s) that manages or uses it,
| that is a bad assumption.
| troupo wrote:
| > Sure, the article is incomplete in the sense that it
| doesn't fully commit to the idea of HTML Web component
|
| What is that, exactly?
|
| > By putting all your templates in the backend you can
| render them as a whole document or in parts in one go and
| send them wherever,
|
| All frameworks can do that. Web Components cannot.
|
| > If you always start with a JavaScript function, and all
| that comes with that, you need a programmer to be able to
| create the web, but with HTML (and CSS) first you can
| have other categories of people do that, like designers.
|
| Web components quite literally don't work without
| Javascript. And they need Javascript to be able to do
| trivial things like form participation.
| tored wrote:
| > What is that, exactly?
|
| Component rendered before client side JavaScript.
|
| > Web components quite literally don't work without
| Javascript.
|
| That is why I'm not using them.
| sylware wrote:
| The core of the web only need basic HTML with closing tags (and
| properly shaped singleton element/tags) with the basic grammar
| (from the specs), utf8 encoded, no script.
|
| It is enough for a bazillion of online services, that without
| requiring a beyond insanely complex and massive web engine from
| Big Tech. basic HTML forms can do wonders.
|
| Of course, you can have a full blown Big Tech web app, but
| don't forget to have a interop portal with noscript/basic
| (x)html browsers to avoid, at least for critical online
| services, Big Tech lock-in and unreasonable exit cost.
|
| That said, it may be a good idea to be able to drive the
| display or not of <table> rules with the default styling (css
| or hardcoded) from the 2D semantic HTML document attributes (I
| should check the hardcoded style of links and lynx for <table>
| rules).
|
| (I am not talking about the abomination of the "semantic" web
| we had a decade ago)
| Ambolia wrote:
| If you are only doing web as documents with links. As soon as
| you use any Forms and error back-and-forth you have to either
| patch over the web stardards, or annoy your users with sub-
| par functionality.
| sylware wrote:
| I don't agree, what you call "back-and-forth" is not
| negative, actually it appears more like "consistency" to
| me... and in the end, more than enough for a bazillions of
| online services and that at a ridicule technical cost
| compared to the one from Big Tech (not to mention all the
| corollary issues).
|
| Of course, it is a trade-off, bells-and-whistles from rich
| GUIs are sexy, but the technical cost of such bells-and-
| whistles in a web context is grostesquely and absurdely
| unbalanced compared to what can be achieved with simple and
| consistent noscript/basic (x)html portals for any pertinent
| goal of a bazillions of online services.
| joshstrange wrote:
| If you don't care about UI/UX then I agree. I do and even if
| I didn't the companies I work for absolutely do and the
| customers expect a certain level of UI/UX that is absolutely
| not possible with no script. I also work primarily on web
| apps which cannot be done without JS.
| sylware wrote:
| Well, it all depends on what the "client" "wants".
|
| The problem often lies with the client tantrums.
|
| I was more talking about critical online services which
| have a duty of interop with Small Tech and must not force
| users into Big Tech engines only, that to keep the door
| open to alternatives of reasonable "size", and at the same
| time to lower significantly exit costs.
|
| But that's smashing open doors, most are aware of those
| issues here on HN. The real issue is implementation: it has
| to happen in a regulatory framework, laws dealing with
| discrimination, and my lawer has been looking into other
| legal leverages (yeah, I have an open conflict with my
| administration). The regulatory framework is here, but
| lobby-ied heavily by Big Tech, making it ineffective and
| pointless.
|
| A bit like what they have in the US with the "utilities"
| which then have much more regulatory duties than "non
| utilities". You also have anti-trust stuff: dominant corpos
| are much more tied to regulatory constraints, that to let
| alternatives to be viable (well, that does not seems to
| work very well in the US). In my country, anti-trust ultra-
| aggressive regulations did wonders in the telecom industry.
|
| You can still have a web app with a rich GUI, an anonymous
| simple and stable in time public HTTP-based middleware
| protocol (which allows to develop Big Tech independent rich
| GUIs), etc, until the core functions are provided to
| noscript/basic (x)html browsers (if one thing must work, it
| is this one).
| altairTF wrote:
| Problem is, i dont see a page that does more then a blank
| text with simple logos to be user frendlly to regular non
| tech users. People care much more to what they see and the UX
| at the end, imagine handling all the use cases of a credit
| card register form before some payment without all the fancy
| schmancy we have today.
| winter_blue wrote:
| A lot of web apps fetch data from the server prior to
| rendering; and the data that's fetched is often necessary for
| rendering. I suppose for things like a "control panel" that
| doesn't have much data on it, HTML Web Components might work
| fine; but a lot of use cases need non-stale server-supplied
| user data. I guess one other use case is caching stale data
| in local storage, and rendering that -- but even that
| requires JS.
| flanbiscuit wrote:
| React has `props.children`, Web Components have
| `this.innerHTML`. But also, anything inside the custom tag you
| can query using regular DOM querying. Here's an example I just
| created: https://jsfiddle.net/qc35an1s/2/
|
| I actually have zero Web Component experience so I'm not sure
| if I'm following best practices there, but I was able to get
| that working pretty quick
| Xeamek wrote:
| >Every alternative to the big frameworks (looking at you htmlx)
| feel like minor syntaxic sugar for jQuery and friends
|
| True
|
| >which feels like a massive step backwards and completely the
| wrong choice for building a web app.
|
| Why?
|
| I mean, I'd agree if by 'web-app' you mean something like
| google-sheets.
|
| But I believe this whole "anti-react" movement isn't talking
| about such usecases, but rather against defaulting frameworks
| and building using them 'from the ground up', where trully all
| the website actually need is the "sparkling of interactivity on
| top"
| joshstrange wrote:
| > But I believe this whole "anti-react" movement isn't
| talking about such usecases, but rather against defaulting
| frameworks and building using them 'from the ground up',
| where trully all the website actually need is the "sparkling
| of interactivity on top"
|
| We absolutely don't have shared language for these things and
| we aren't always talking about the same things. The thing is
| there are just vanishingly few places where you only need a
| "sparkling of interactivity on top". Yes your blog probably
| doesn't need a full framework, nor does your news site (which
| is just a blog++) or your marketing web page. But so many
| other things really do or things break down quickly. Also
| what your web site needs today might not cover what it needs
| tomorrow. I've seen a number of "web admin"/backend control
| panels (customer-facing for config) start simple then grow
| until they start to collapse under their own weight with just
| added jQuery as needed. Sure, at the start, htmlx/jQuery
| might cover all you need but soon you are building custom UI
| to represent business logic/ideas and managing with that gets
| very unwieldy. The people that say "all you need is the
| built-in HTML elements" are living in a fantasy land, try
| using the default date/time picker and get back to me.
|
| I'm sure there are things I'd agree with the anti-react crowd
| on (places you don't need a framework) but all their examples
| are incredibly contrived and feel like the "TODO app
| examples" you often see for frameworks or learning a
| language. They don't even scratch the surface of what's
| needed for complicated apps, they are great to show off the
| simple things but it seems like the anti-react/anti-framework
| crowd thinks those simple examples are all you need and
| that's just silly.
|
| At the end of the day I'll admit I reach for a framework
| earlier than I absolutely need it and that's because I've
| built 10's and 10's of sites (web apps) from the ground up
| and eventually you either use a framework or you end up
| creating a shitty version of one. So yeah, day 1 I might not
| need Vue but day 100 I'm sure glad I have all of Vue to build
| on.
| whatshisface wrote:
| I think the future of webdev is a framework-like system
| that can be added gradually to basic HTML, rather than one
| which requires that you totally replace it with JSX, etc.
| from the start. Webcomponents are a huge step towards a
| time when we can add state managers and things like that
| without bringing in a monolith all at once.
|
| Some projects require 1% of a framework, others require
| 98%, but the majority are in a range between 25% and 75%
| which currently need you to re-architect for a total
| perfusion of React or a competitor.
| joshstrange wrote:
| And I'll happily use such a system once it exists but
| Vue/React/Angular exist today and have allowed a level of
| productivity, DX, and UX unheard of with what browsers
| provide by default. If browsers want to compete then be
| by guest but FF seems to busy doing next to nothing,
| Chrome is eating everyone's lunch and giving the middle
| finger to standards, and Safari is derided for not being
| Chrome and slow to implement some things (while being
| fast on others).
|
| I think it's more likely to see some kind of WASM-based
| replacement take off rather than browsers get their act
| together. That's not to say browsers aren't improving,
| they absolutely are, but when it comes to competing with
| the existing frameworks the only answer so far has been
| Web Components and it was very lackluster IMHO.
| zztop44 wrote:
| Svelte is pretty close to this (at the expense of a build
| step). It gives you (in my opinion) better ergonomics
| that React, has no runtime and outputs sites that don't
| require JS unless they do.
|
| Sveltekit (its official fullstack framework) even
| encourages building apps that fall back gracefully for
| users with JS disabled.
|
| Of course, none of that is to say that you can't build
| bloated, badly performing apps in Svelte. Just that you
| *can* have the best of both worlds, even for
| simple/static sites.
| troupo wrote:
| All the things that "monoliths"[1] bring web components
| ate not bringing, and won't bring in any conceivable
| future.
|
| [1] There are very few monoliths among the frameworks
| these days, and apart from React and Angular [2] most aim
| for rather small bundle sizes
|
| [2] Out if the blue Angular just released version 17 with
| all the goodies you'd expect from a framework in 2023
| jiggawatts wrote:
| As a counterpoint: I consult for government agencies that
| have all separately decided to standardise on Angular.
|
| They mostly publish static content: alerts, updates,
| reports, etc...
|
| At most they might have a single page somewhere for
| submitting a payment or a simple form.
|
| But because of this JS framework by default policy all
| their apps end up with extra complexity, extra build steps,
| and an awful amount of dependency maintenance.
|
| Most of their sites could have been static HTML files on
| disk.
| toasted-subs wrote:
| Kind of obvious why, any of the react based frameworks
| all fail an audit.
|
| Doesn't even make sense to me why anybody uses them.
|
| You cant audit static sites (ones thing I don't like
| about having traditional linked libraries).
| tbossanova wrote:
| What kind of audit are you talking about?
| joshstrange wrote:
| That's understandable. Though I actually can see some
| logic in it. It's got to be way easier to hire Angular
| developers than it is to hire someone who wants to eek
| out the maximum performance with this lightest-weight
| approach (and do it in a maintainable/understandable
| way).
|
| I'll never say Vue/React/Angular are "light" and I'll
| fully admit we give up some performance for DX (and UX)
| but it's a tradeoff I think is worth it (I understand if
| you don't agree).
|
| In the same vein, I know cross-platform frameworks like
| Ionic/Quasar are nowhere near as good as native apps.
| That said the skill set you need (and dedication to
| actually embracing the platform idiosyncrasies) to make
| _good_ native apps is not cheap or easy. Cross-platform
| apps might not fit in as well and might be heavier but
| they allow fewer people to do more with less. Heck, I
| have a side-business that relies _heavily_ on apps and it
| would not exist if I couldn't write them in HTML/JS/CSS
| as much as that makes some people's stomachs turn.
| Xeamek wrote:
| Would this example be considered "trivial"?
| https://www.youtube.com/watch?v=3GObi93tjZI
|
| But also, you can mix things togheter. You can just use
| react based app 'embeded' into mpa for when you need that
| heavy lifting, and the same keep the content part of your
| app simple.
|
| "But why would i do that, if i'd already use react for some
| parts, why not every where".
|
| Becuase then it leads to abominations like reddit or
| facebook, where websites that are basically glorified text
| forums will use gigabytes of memory, have terrible UX, be
| slow and will crash your browser if you leave them open for
| too long.
| coffeecantcode wrote:
| > try using the default date/time picker and get back to
| me.
|
| Building my first web application in react currently and
| this resonated with me on such a deep level.
| sandreas wrote:
| Basically, HTML Web Components are classes extending
| HTMLElement registered manually via JavaScript / DOM API.
| class superSlider extends HTMLElement {
| connectedCallback() { let targetEl =
| document.querySelector(this.getAttribute('target'));
| let unit = this.getAttribute('unit'); let slider =
| this.querySelector('input[type="range"]'); } }
| customElements.define("super-slider",superSlider);
|
| For a more sophisticated example with scss, jsx/tsx and ES20..
| you could take a look at https://github.com/cyco/WebFun
|
| My personal problem with these "native" components is, that the
| shadow DOM is pretty restricted compared to component
| frameworks like React, Vue or Svelte.
| toasted-subs wrote:
| I don't understand why people use the shadow Dom. Why not
| edit the Dom directly?
| lpedrosa wrote:
| You are correct. You don't have to use the shadow DOM, when
| you create a new Custom Element.
|
| The shadow DOM provides two things:
|
| - style encapsulation (as well as `id` attributes)
|
| - ability to use `<slot>` for templating
|
| You should use it if you require one of the above or both.
| fuzzy2 wrote:
| My take is: As explained in the article, _user-avatar_ does
| absolutely nothing. If anything, it could only enhance the
| existing markup (with behavior), but never replace it. It's...
| semantic markup, if you will.
|
| Baloney if you ask me.
| andai wrote:
| > lackluster with no "Batteries included"
|
| I wish this weren't so, but it perfectly describes my
| experience with every single web technology. JavaScript, DOM,
| Canvas, Web Audio... they all remind me of this quote:
|
| "Beware of the Turing tar-pit in which everything is possible
| but nothing of interest is easy." -Alan Perlis
| rglover wrote:
| *Shameless self promotion warning*.
|
| If you're looking for a middle-ground between React and Web
| Components, check out Joystick [1]. I designed it to take a React
| v1 approach to ergonomics but you write your components with
| vanilla HTML, CSS, and JavaScript (no attribute hacks or new
| syntax to learn--if it's on MDN, it will work in Joystick).
|
| [1] https://github.com/cheatcode/joystick
| yellow_lead wrote:
| I don't like web components because of the flash of undefined
| elements[1]. Hiding it with css tricks is clunky and ugly too.
| The sad thing is that web components seem like a great idea
| otherwise.
|
| [1] https://www.abeautifulsite.net/posts/flash-of-undefined-
| cust...
| drawkbox wrote:
| I am more a fan of the augmented style because it doesn't entrap
| you in dev lock-in to platforms.
|
| The problem with frameworks, especially web frameworks, is they
| reimplement many items that are standard now (shadowdom,
| components, storage, templating, base libraries, class/async,
| network/realtime etc).
|
| DOM rendering speeds have been improved due to virtualdom but is
| no longer needed with shadowdom.
|
| The web standards of today are amazing and take away the need for
| frameworks today: from templating to html templates [1], vanilla
| javascript with classes [2] and async [3] and better api access
| like fetch [4] and browser support for vdom with shadow dom [5],
| components with WebComponents [6][7], css now with lots of
| additions like variables [8] transitions[9]/animations[10], flex
| and media queries, canvas/svg/etc for interactivity, and so much
| more. There is little need to use frameworks except to sell books
| and conferences and keep developers locked in.
|
| React for instance jumped ahead and front ran WebComponents and
| ShadowDOM, those are both part of the browser and standards now.
| The killer feature phase of React is over.
|
| If you like the component style of other frameworks but want to
| use Web Components, Google Lit is quite nice. [11]
|
| Google Lit is like a combination of HTML Web Components and
| React/Vue style components. The great part is it is build on Web
| Components underneath.
|
| [1] https://caniuse.com/template
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [3] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [4] https://developer.mozilla.org/en-
| US/docs/Web/API/Fetch_API/U...
|
| [5] https://caniuse.com/shadowdomv1
|
| [6] https://caniuse.com/custom-elementsv1
|
| [7] https://developer.mozilla.org/en-US/docs/Web/Web_Components
|
| [8] https://developer.mozilla.org/en-
| US/docs/Web/CSS/Using_CSS_c...
|
| [9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition
|
| [10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation
|
| [11] https://lit.dev/
| CharlesW wrote:
| But if you introduce an open-source dependency to make web
| components usable, why not use a popular, complementary
| ecosystem like Vue?
|
| https://vuejs.org/guide/extras/web-components.html
| drawkbox wrote:
| Staying closer to web standards is always best for
| maintainability and portability. I personally like custom
| direct standards but that doesn't always work in a team for
| some reason today. There will always be less dependencies in
| a straight standards solution, that makes for better
| maintainability and opsec. I also think it is better for web
| developers to know standards over just abstractions, it makes
| for better developers.
|
| Additionally, web standards like Web
| Components/templates/custom elements will always be faster at
| browser level.
|
| The article from OP mentions this:
|
| > _But the unique power of web components (in the browser) is
| that they can render before JavaScript. React components
| cannot do this -- full stop._
|
| There are other reasons as well but these are the best
| reasons.
|
| I think using a framework for a team isn't a bad idea, but
| for products and personal projects I like going custom or
| newer framework like Lit simply because of the web standards
| being less abstracted away and due to that, less need to
| constantly update on others schedules due to dev lock-in.
| There is less weight in straight standards.
|
| If you remember React/Vue originally won due to virtualdom
| and being small parts that work into an existing web, but
| recently they have been very monolithic in that they take
| over the entire project. The web is more about augmentation
| as the article mentions and I agree, those items will be
| easier to maintain.
| CharlesW wrote:
| > _Staying closer to web standards is always best for
| maintainability and portability._
|
| I understand that argument, but Lit isn't a web standard,
| and it's an esoteric choice compared to Vue, which works
| great with custom elements.
| troupo wrote:
| > Staying closer to web standards is always best for
| maintainability and portability.
|
| That's what you get if you chose literally anything _but_
| web components. Because web components are really bad at
| using and playing nice with web standards:
| https://threadreaderapp.com/thread/1717580502280867847
|
| They need dozens of new web standards to fix their self-
| inflicted wounds and to work with the browser in a way that
| everyone else is already working
|
| > Additionally, web standards like Web
| Components/templates/custom elements will always be faster
| at browser level.
|
| [citation needed]
|
| The 2010-era design choices that web components enshrined
| hinder a lot of optimizations that modern frameworks are
| doing.
|
| There are reasons why almost none of the modern frameworks
| use web components as the foundation. Including those who
| originally used their design or whose authors were bullish
| on them (Vue, Svelte, Solid).
|
| IIRC even Angular beats Lit in benchmarks now.
| codingdave wrote:
| I'm not sure I buy the "React is replacement, not augmentation"
| argument. At the end of the day/render, React still renders HTML
| elements... with javascript event handlers. Wrapping an '<img />'
| in a React component doesn't mean I've taken away any
| functionality of 'img'. I just add to it -- augmentation.
|
| Maybe the author has worked in different React codebases than I
| have, but in my experience, we use built-in browser functionality
| unless we have a reason not to. Maybe I've just been lucky?
| jakelazaroff wrote:
| It depends on the architecture of your app. If you're using
| React to return HTML from the server, then indeed wrapping an
| <img /> in a React component means you're augmenting an
| existing element. But if you're rendering the entire thing on
| the client side, then the <img /> is ultimately inseparable
| from the React component.
| recursive wrote:
| In some cases, react seems to go out of its way to make the
| built-in functionality harder to access. For instance, if you
| assign "onchange" to an <input>, react will give you the
| "input" event, not the "change" event. (Actually, it gives a
| neither. It gives you a "synthetic" event that's closer to
| input than change) What if you know what you're doing, and you
| actually wanted "change"? You have to use an element ref an
| attach the handler using an effect.
| no_wizard wrote:
| You can access the `nativeEvent` property on the event
| object[0] if you prefer
|
| [0]: https://react.dev/reference/react-
| dom/components/common#reac...
| recursive wrote:
| Doesn't solve this problem. "change" fires at different
| times from "input". `nativeEvent` is useful if you want the
| real event data object for the event that actually fired.
| In this case, it's a whole other event.
| 11235813213455 wrote:
| it's a well known thing in react (preact does it well
| https://preactjs.com/guide/v10/differences-to-react/#use-
| oni...), and probaly a design mistake on their side (now too
| late to change), I can't think of other cases like that
| recursive wrote:
| They could still expose a `nativeChange` event without
| breaking backward compatibility.
| afavour wrote:
| When I read that I thought about the reverse: putting React
| inside other HTML. In my experience React works wonderfully
| when you're using it from top to bottom (replacing your entire
| page structure) but it can be difficult to fit into an existing
| structure when you're trying to do things like server side
| rendering.
| TheCleric wrote:
| I could be wrong, but it seems like the article is saying that
| the core difference would be this:
|
| React (rendering in the browser, not server side): Page Load ->
| Component Load
|
| vs.
|
| Web Component Page Load -> Default Render -> Component Load
|
| So if someone has JS disabled they would still see SOMETHING
| for the web component vs. nothing in React. And with JS they
| could get to some further render state.
| iteratethis wrote:
| Surely every single web architecture ultimately renders HTML
| elements, that wasn't the point.
|
| The point is that the flavor "HTML Web Component" does not rely
| on JS to start rendering, unlike React.
| robinson7d wrote:
| You're right for the large majority of cases, but there are
| exceptions. These days some use canvas or WebGL, in the past
| some have used Flash or Java Applets/Swing.
|
| A popular app that some web developers here may use day-to-
| day recently is Figma, which uses WebGL for rendering.
| winter_blue wrote:
| Where does the data come from, if not JS? How then do HTML
| Web Components start rendering, without data?
| iteratethis wrote:
| The data would come as part of the server response in most
| cases.
|
| A variation could be the rendering of a partial UI whilst
| you then fetch data client-side. Even in this case the web
| component has the advantage as no JS is needed to render
| the initial UI.
| micromacrofoot wrote:
| As long as you're not shoving everything into the shadow
| dom, then you've got a fallback HTML element that can
| render before JS is read (and even if the JS is completely
| broken)...
|
| <special-image> <img src="/example.png" />
|
| </special-image>
|
| This image will render before the JS is executed, so you've
| got no blockers and a perfectly fine fallback, then with
| the web component you enhance your image with whatever JS
| you want.
| zackmorris wrote:
| I'm a backend php dev who is hopelessly behind on the frontend
| literature, so here's pseudocode for how I would like web
| components (dynamic tag definitions) to work:
| <html> <tag> <my_tag $message="Hello, world!">
| <script> alert($message);
| setTimeout(function () { alert("Boop!"); }, 10000);
| </script> <img src="my_image.png"/>
| <p>$message</p> </my_tag> </tag> <tag
| src="my_other_tag.html"/> <body> <!-- shows
| "Hello, world!" --> <my_tag/> <!-- shows
| "Hello, override!" --> <my_tag message="Hello,
| override!"/> </body> </html>
|
| By default, the browser would allow setTimeout(), so the user
| would see alerts showing after 10 seconds. But there should be a
| custom script.js that works like stylesheet.css that the user can
| set for the browser. It could have a line like quitTimeout()
| which would disable setTimeout() for all pages. And something
| like setScriptLifetime(5000) which would run Javascript for 5
| seconds in this case, preventing the alerts, then only allow new
| scripts to run upon user action. Or even have an option like
| setScriptLifetime(5000, 0) where the second argument sets a
| lifetime for new scripts, in this case preventing all future
| scripts from starting.
|
| That right there would make browsers run about 1000 times faster
| regardless of how many tabs are open, as well as stop most of the
| slowdown from ads.
|
| Maybe <tag> should be <tag tag="my_tag"> to make it inline. Or
| <$my_tag> so as to not confuse new tag definitions with existing
| tags. As they say, the devil is in the details. But I think it
| makes sense to nest the tag definition in case <head> or <script>
| tags are needed, which would maybe get installed in the parent
| page. And there are endless use cases for passing variables
| to/from tags which are beyond the scope of this comment. Probably
| that would happen through data tags, passing JSON or raw
| Javascript like for onclick="alert('Hello')" where myTag.data = 1
| + 1 would be like re-rendering with <my_tag data="2">.
|
| But if we had something like that, frontend code would end up
| several orders of magnitude smaller, because we'd get back to
| declarative interfaces with progressive enhancement, more like
| what Htmx is working towards.
|
| Keep in mind that I thought of this in 1995 when I very first saw
| NCSA Mosaic, and was flabbergasted that html tags weren't
| dynamically defined this way. When Netscape copied Mosaic but
| failed to fix even the slightest oversights like this, I knew
| that the future of the web was in perile and that we'd end up
| with the imperative stateful mess we live with today.
| nathias wrote:
| web components are a failed standard, it was a good idea 10 years
| ago but now its a very bad idea
| butz wrote:
| Why even build a component, when it is an image which could have
| styles applied using a class? I understand web components appeal
| when building complex elements, but this probably just slows down
| website, especially when element is repeated hundreds of times on
| page.
| yieldcrv wrote:
| when is 'composability' getting added to the dictionary?
|
| it is a pretty intuitive term - interoperable building blocks in
| areas that suffered from fragmentation - but isn't really part of
| the lexicon by the lexicon gods
| ivanjermakov wrote:
| > But the unique power of web components (in the browser) is that
| they can render before JavaScript. React components cannot do
| this -- full stop.
|
| Umm, that's why SSR was created?
| willio58 wrote:
| Web components are standardized by the web consortium. They are
| the way web browsers have agreed components should work. They
| have value inherently and don't necessarily mean you can't use
| react, in fact they can be used together very well especially
| for things like framework agnostic design systems. Basically,
| web components have more holding power inherently because they
| are browser native. React and SSR is just a great way to
| augment that.
|
| While I write react daily and love it, I think it's important
| to realize no methodology today will have any real importance
| or meaning 100 years from now. It's all a means to an end and
| frameworks and web components are just different means.
|
| In 2123, people will glance at a paragraph about react and move
| on to the next topic in programming history.
| iteratethis wrote:
| Which is React SSR. A few years down the line, React is gone.
| Legacy. Most on this forum don't care, they'll just move to
| another project.
| jdmg94 wrote:
| web components are the quantum realm of CSS. What you know as
| normal might not work when you're trying to write style
| customization. My org has multiple teams working with different
| stacks, so at one point someone decided to write our component
| library using web components. Everyone hated it and we're now
| moving away from it.
| Osmose wrote:
| I think this article is emphasizing custom tags / code reuse as
| the primary feature of React, which isn't really the case? The
| whole reason React was a game changer was because it eliminated
| (as much as possible, anyway) the invisible extra state stored in
| the DOM from your app and made its rendering declarative, which
| greatly reduces how much state you have to keep in your head when
| reading and reasoning about your app UI logic.
|
| Web components don't address this on their own, which is why a
| lot of libraries still exist that build on top of them.
| DonHopkins wrote:
| >With web components, you might even say React's component model
| is being ported to the browser. But it's being done in a way that
| works to enhance how the web already works, not replace it.
|
| I wouldn't say that React's component model is being ported to
| the browser, just that a component model is being implemented in
| the browser, independent of and different than React.
|
| Microsoft ActiveX Dynamic HTML Behavior Components (HTC files,
| introduced in IE5, after DHTML finally started working well)
| allowed you to augment HTML in the same way, and that's very old
| technology (circa 1999 or so) compared to React.
|
| https://news.ycombinator.com/item?id=27405137
|
| >[...] At the time that NSAPI came around, JavaScript wasn't
| really much of a thing, and DHTML didn't exist, so not many
| people would have seriously thought of actually writing practical
| browser extensions in it. JavaScript was first thought of more as
| a way to wire together plugins, not implement them. You were
| supposed to use Java for that. To that end, Netscape developed
| LiveConnect.
|
| >Microsoft eventually came out with "ActiveX Behavior Components"
| aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)"
| that enabled you to implement ActiveX controls with COM
| interfaces in all their glory and splendor, entirely in Visual
| Basic Script, JavsScript, or any other language supporting the
| "IScriptingEngine" plug-in interface, plus some XML. So you could
| plug in any scripting language engine, then write plug-ins in
| that language! (Easier said than done, though: it involved tons
| of OLE/COM plumbing and dynamic data type wrangling. But there
| were scripting engines for many popular scripting languages, like
| Python.) [...]
|
| HTML Components:
|
| https://en.wikipedia.org/wiki/HTML_Components
|
| HTC Reference:
|
| https://learn.microsoft.com/en-us/previous-versions/ms531018...
|
| I used them to implement nested piemenu components in a way that
| let you easily augment them with html in the browser (which was
| the wall I'd hit with OLE, not being able to easily use an
| animated gif or html table as a pie menu item, for example,
| having to draw everything myself with Win32), so you could embed
| snippets of HTML to define the menu background, center, items,
| and dynamic feedback.
|
| That worked nicely in conjunction with XSLT to transform XML
| models into HTML pages with embedded trees of HTML components.
|
| For example, the Punkemon Pie Menus used an XML database of
| Punkeland regions and Punkemon characters to make a tree of
| nested pie menus.
|
| JavaScript Pie Menus - Punkemon Pie Menus:
|
| https://youtu.be/R5k4gJK-aWw?t=177
|
| Pie Menu ActiveX Behavior Control (htc file as text):
|
| https://donhopkins.com/home/PieMenu/piemenu.htc.txt
|
| Punkemon Pie Menus XML Database (xml file as text):
|
| https://donhopkins.com/home/PieMenu/punkemon.xml.txt
|
| XSL Style Sheet (xsl file as text):
|
| https://donhopkins.com/home/PieMenu/punkemon.xsl.txt
|
| For example the XSLT transforms the XML Punkemon database into
| HTML with embedded nested <piemenu> <item> and arbitrary html,
| like a table inside one of the items to make a gigantic pie menu
| item at the bottom, whose purpose is more like an info panel than
| a menu item, just showing you some information about the
| magnified animated gif of the character in the top item.
|
| ActiveX Pie Menus that "hit the wall" (discussion near end of
| video):
|
| https://www.youtube.com/watch?v=nnC8x9x3Xag
|
| >Well, I ran into a wall of complexity with this ActiveX control,
| and I wanted to be able to have as the menu items animated gifs,
| mpeg movies, fonts with nice attributes, and things like that.
| The first thought was "well let's just put a web browser in every
| item!", but that was a little heavy-handed. So instead I put the
| pie menus into the web browser as dynamic HTML components, which
| I'll show next.
|
| All this stuff I explained in the video is incredibly obvious
| now, but it seemed really cool at the time in 2001, and it was a
| hell of a lot better and more web-centric than binary OLE/ActiveX
| controls. (Pardon my unabashed XML and Microsoft technology
| advocacy, but it really was a step up from what came before it,
| and you couldn't do anything remotely similar in Java!)
|
| But it illustrates that the idea of augmenting and embedding html
| in components like that goes way back, and that HTML Web
| Components were obviously influenced by Microsoft ActiveX
| Behavior Controls more than they were React.
|
| JavaScript Pie Menus: example of augmenting neste piemenu
| components with html:
|
| https://youtu.be/R5k4gJK-aWw?t=339
|
| Transcript:
|
| Now the really convenient thing for user interface designers is
| that the way these pie menus are specified in XML markup
| language.
|
| This test pie menu has eight items here, and North has a sub menu
| with four items. Now that map's very nicely into an XML tree. It
| has a piemenu element, and that has a name and ID.
|
| The neat things is that you can put arbitrary HTML inside of the
| XML, and that is just copied and just dumped right into the
| middle of the menu to make it look any way you want. And then the
| menu, this pie menu item, contains, besides this stuff to display
| in the middle an item, an item.
|
| It contains eight items, and this item's name is north, and
| that's its name to the program, which could be different, and
| that's what is displayed to the user here. Now it contains the
| sub piemenu, which is the North menu, and has even more.
|
| You can see how you can intersperse XML and HTML to specify all
| this that you need to describe for the pie menu.
|
| One of the really great advantages of using XML for the piemenu
| is that there are many ways to generate XML and many things that
| are represented by XML that you might want to make and then use
| for. In the case of the punkemon pie menus I really didn't want
| to make all those pie menus directly.
|
| So maybe I'm making a card game and I have this XML file that I
| use to print all the cards and maybe do the online game and
| everything. I've defined the markup language for punkemon cards.
| There's the punkeverse contains punkeland where they live, and
| that contains a bunch of punkemons.
|
| Now all these give information that is needed to make the menu
| for that. It's an application specific markup style, but it has
| information for menus in it. Basically all this gets translated
| into all this very automatically by an XSL stylesheet.
|
| That's a macro language for XML that takes the nice clean to the
| point punkemon xml file and then transforms it into a piemenu
| tree and a web page that pops that pie menu up.
|
| punkemon.xml:
|
| https://donhopkins.com/home/PieMenu/punkemon.xml.txt
| <?xml version='1.0'?> <?xml-stylesheet type="text/xsl"
| href="punkemon.xsl" ?> <punkeverse>
| <punkeland name="Rave Caves"
| itemradius="60" pieradius="100">
| <punkemon name="Candibi"
| foundin="Rave Caves" attacks="Disturbing Cuteness,
| Pacifier attack" likes="Candy, Stuffed Animals,
| Loops" dislikes="Ambient music, spankings, bed-
| time" creator=""
| url="http://www.gothic.net/~luvcraft/punkemon/rave/candibi.html"
| image="Punkemon/candibi.gif"> <description>
| The youngest and perkiest denizens of the Rave Caves, Candibis
| spend much of their time spinning around in circles with one
| hand high in the air and the other hand tightly clutching a
| large stuffed animal. Naturally shy, these cuddly creatures
| can often be enticed into a Punkeball with large amounts of
| candy, especially if the candy comes in perforated sheets."
| </description> </punkemon> [...]
|
| The header of the punkemon.xml file says "hey this is my
| stylesheet, if you want to display me, run me through this style
| sheet!" And what that style sheet does is expand to a web page
| with a title that says what it is.
|
| punkemon.xsl:
|
| https://donhopkins.com/home/PieMenu/punkemon.xsl.txt
| <?xml version="1.0"?> <xsl:stylesheet
| xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:template
| match="/"> <HTML> <HEAD>
| <TITLE>Punkemon Pie Menus</TITLE> </HEAD>
| <BODY> <DIV ID="Barf"></DIV>
| <DIV STYLE="width=100%;height=80%;behavior:url(piemenu.htc)"
| onchange="ChangePunkemon(event)"> <CENTER>
| <H1>Punkemon Pie Menus!</H1> <IMG
| SRC="Punkemon/island.jpg"/> </CENTER>
| <XML> <piemenu id="root"
| fixedradius="90" centermargin="50"
| centerbackground="white"
| itemnormalbackground="white"
| itemselectedbackground="gray"> <html>
| Punkemon<BR/> Pie Menus
| </html> <xsl:for-each
| select="*/punkeland"> [...]
|
| And then, the nice part is, this is how a web designer puts the
| pie menu on the page. You make a div, which is like just a
| section. And I'm giving it a width and height, and I give it a
| behavior.
|
| The behavior attaches this JavaScript code to it and allows it to
| receive input events and translate them to a higher level
| semantics and then send these output events like the pie menu
| changed, and it's going to call my JavaScript function that's on
| this web page to handle it.
|
| Now this div is the thing that's presented on the page that you
| click on, so it's got a little picture of the island there.
| Inside the div besides its presentation is an XML data island,
| which is just embedded XML that instead of being displayed on the
| page is just data that can be referred to.
|
| The pie menu looks in there, finds the XML, pulls out the pie
| menu definition in it, and uses it. You can pack these things
| nicely together. You can also point to another file that contains
| the pie menus externally. But in this case we're going to have
| them inline.
|
| The Punkemon piemenu contains the words "Punkemon Pie Menus". And
| then it uses the XSL macro language to loop over all of the
| punkelands, making items for each one of them. And that item is
| made by extracting fields from that punkeland, and just sticking
| them into HTML as either properties or content.
|
| You can get the value of the name of this guy and stick it into
| that guy, and put a bold marker around it, and make a div. This
| is just a bunch of nested loops that loops over the database and
| renders it out as dynamic HTML embedded in a piemenu tree
| embedded in a web page.
|
| And it works! That's what you're seeing over here.
|
| There's a lot of other really neat applications of automatically
| generating the piemenus or any other kind of user interface from
| an XML specification, that could also be used for a lot of other
| things. And you're just describing your data in one place, and
| then algorithmically rendering it out to all sorts of other
| things.
| jnellis wrote:
| I've recently just started playing with Web Components without a
| build environment. Meaning, no npm, no bun, no webpack, etc, and
| no dependencies; in typescript. Intellij can autocompile down to
| js and the browser view injects a small onchange handler for live
| updates when developing. So far no problems.
|
| The only thing holding web components back seems to be HTML
| Modules; being able to link to a .html file instead of a .js file
| to import a web component. Because of this if you want to use
| templates or anything more complicated you need to do the ugly
| inject of .innerHtml = `<tag soup>...`, which I thought would be
| a problem but the IDE parses the template string very nicely. It
| would be great to make a component in HTML and any javascript you
| would put in a <script> tag. It seems like there a lot of
| bureaucracy involved in getting HTML Modules out the door since
| its been eight years.
|
| https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
| troupo wrote:
| HTML Modules have been deprecated and removed in favor of JS-
| only imports.
|
| And no, it's not the only thing holding web components back
| tolmasky wrote:
| I can't tell if people who champion web components don't
| understand why the React model took off, or purposefully pretend
| to not know why since web components don't really solve most of
| the things people using React care about, and thus look bad in
| comparison.
|
| This article is a good example of this. For starters, the "one
| shell component" thing is kind of a red herring. There's plenty
| of React components that interact with children, and you can
| clearly make web components that also "hide all the details". So
| this seems to be more of a "general" good practice they want to
| encourage, than anything specifically tied to React or Web
| Components in particular.
|
| Critically however, the whole idea of "hey, web components still
| look good before JavaScript!" is either intentionally obtuse or
| really misses the point of React -- React can have a _better_
| non-JavaScript initial render, thanks to SSR, which is
| significantly harder to do with Web Components. I don 't really
| care if <user-avatar><img></user-avatar> "falls back" to some
| lame Web 1.0 rendering if my SSR-ed UserAvatar looks _identical_
| to the fully "active" component on first paint before any
| JavaScript runs. That is one of the main selling points of React
| and React-like systems _today_. You can 't just ignore that
| completely and expect to convince anyone who's currently using
| that sort of system. But I understand why they don't address it,
| since the only real answers involve using some sort of build
| system with Web Components, which they've _also_ decided to say
| are the worst thing ever. So their only choice is to compare non-
| SSR Web Components to non-SSR React Components. And, I dunno,
| maybe they 're better than the way we did things 8 years ago when
| that was the case? I'd have to think hard about that purely
| academic question.
|
| The funny thing is that these are often the same people that
| would push for as little JavaScript as possible, and yet Web
| Components are _fundamentally tied to JavaScript_. Whereas React-
| style components can actually generate fully static JavaScript-
| free pages if you want to. This sort of situation springs up a
| lot: Web Components go on and on about not being "shells single
| components", and yet React-style components make it _so much
| easier_ to deal with children. You aren 't forced into the ugly
| slot system which immediately removes the "illusion" of it being
| a "real" HTML component, and is easier to deal with in the catch-
| all case too. Not to get into another huge differentiation, but I
| also personally prefer a more "functional" approach of writing a
| single render function vs. dealing with a bunch of lifetime
| callbacks to track the changing states of attributes and
| children.
| gryzzly wrote:
| My first book on Javascript was "DOM Scripting" by Jeremy Keith.
| He is still at it, pushing progressive enhancement, making HTML
| more useful with JS. I love this.
| andirk wrote:
| A web component should do ONE thing whereas a JS framework is a
| whole ecosystem.
|
| I made a video player web component that could take in various
| inputs, with a torrent file being the most complex of them. I was
| then able to port it to Vue/React with StencilJS [0] (although it
| was good to go without). Just drop the `<awesome-player
| src="torrentOrVideoFile"... ></awesome-player>` along w/ its
| exported class from `awesomePlayer.js` and you have yourself a
| copy/paste HTML5 video player that plays torrents!
|
| I also strongly suggest your web component attempt to mimic
| existing HTML elements, when possible, such as how I used `src`
| because `<video>` does. That way the consumer doesn't have to
| RTFM to interact with it.
|
| [0] https://stenciljs.com/
| socketcluster wrote:
| Web Components are highly versatile. I built a chat app with
| GitHub OAuth login, blockchain-based authentication and access
| control using only 120 lines of HTML in a single .html file with
| no custom code, no framework, no custom server-side code. It can
| run anywhere:
|
| https://github.com/Saasufy/chat-app/blob/main/index.html#L23...
|
| You can try the app here (if you have a GitHub account):
| https://saasufy.github.io/chat-app/
|
| The backend is serverless built using Saasufy.com - The
| platform/startup I'm working on currently: https://saasufy.com/
|
| An effective approach I've found is to create components which
| consume slotted <template> elements to produce HTML that can be
| fully customized and injected with data they loaded from a back
| end. This allows you to create components which are declaratively
| bound to specific back end resources.
| locallost wrote:
| I don't really agree that frontend framework components are meant
| to be replaced completely and are not composable. Maybe from the
| outside, but I use slots quite a lot in my components because
| they are very easy to do and they trivially work. Web Components
| on the other hand are usually demonstrated as insert <img-
| editor></img-editor> which basically inserts a ton of code to
| create some kind of an editor. Using slots in Web Components is a
| pain, a lot of appending nodes manually, templates as strings,
| for some more complicated things when I tried them I had to
| listen to the slotchange event etc. It's essentially the DOM api,
| which if it wasn't terrible, we wouldn't have switched to
| frontend frameworks like react etc.
|
| Also disagree with the side note that XHTML failed because it
| didn't augment HTML. IMHO it failed because if forced the
| applications to be completely valid and it put the validation on
| the client/browser. If you'd really used real XHTML a small error
| in the markup would've crashed your page. So we all validated our
| XHTML to be future ready, but it was always utopia that a
| business would risk crashing their, well, business because a p
| tag was not properly closed.
| lpedrosa wrote:
| > This feature of web components encourages a design of
| composability.
|
| I am not a React, Vue (and friends dev) at all. Heck, I haven't
| done front-end or full stack for a long time now.
|
| However, taking React as an example, where does it not encourage
| composability?
|
| I like Web Components. I even spent the last couple of weeks
| playing only with the vanilla APIs (no Lit, etc.) just to see
| what is like:
|
| https://lpedrosa.github.io/blog/web-components-part-3/
|
| https://github.com/lpedrosa/webcomponents-blog-examples
|
| Like many other people have pointed out in this post, it is great
| that you can leverage the platform. All the things you will learn
| e.g. DOM APIs, native elements and events, etc., are things you
| can carry over to React and Vue.
|
| However, I believe articles like this fail to acknowledge the
| contribution React and friends brought to developer experience.
|
| Building complex desktop like UIs was no longer impossible to
| maintain. You can easily make components and compose them,
| customise them, etc.
|
| The general complaint is more around "you don't need Next.js" to
| build a news/marketing/blog website. The pendulum is swinging,
| especially with things like HTMX gaining traction.
|
| IMO, people do it because:
|
| - It's easier to hire developers that know the framework du jour
|
| - Custom Elements are very flexible, so it's hard to enforce a
| particular style
|
| - There aren't enough examples of people using vanilla Web
| Components (and I mean vanilla, not Lit and friends), so why use
| a web component framework when I can use a react based one?
|
| Write more about how we can combine things like Custom Elements
| and "traditional" server side templating.
|
| Write more about how a native element reacts to changes to its
| attributes or how it communicates user interaction and how that
| helps building a good custom element.
|
| Or how building a good custom element is similar to building a
| good React component, and where it differs.
|
| Antagonising existing knowledge or even the status quo is not
| constructive, and leads to poor discussions e.g. "Web Components
| is a failed technology" or articles like OP
___________________________________________________________________
(page generated 2023-11-13 23:00 UTC)