18 ms·
HTML Web Components
- yieldcrv 3y agowhen 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
- nathias 3y agoweb components are a failed standard, it was a good idea 10 years ago but now its a very bad idea
- meowtimemania 3y agoWhat makes them bad?
- nathias 3y agoThere are so many downsides of choosing web components you really need a very rare usecase to justify them. They are an artefact of a time we're all glad to be done with, they force you into OOP so you're doing inheritance acrobatics, add TS and now you're feeding two hierarchies of inheritance that don't quite match and bloat to a 80% of your codebase, making it unreadable, prone to hacks and bugs, impossible to maintain etc. The point of web components was to make components more shareable between frameworks, and code more reusable, but now code written in any of the major FE frameworks is more reusable (a component looks pretty much the same in React, Vue, Svelte, but not with web components).
- simonw 3y agoAlso read these articles for more on the idea of "HTML Web Components": https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the-light-dom/ 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 https://adactio.com/journal/20618 then suggests the catchy name.
- divbzero 3y agoCould we shorten the catchy name further? Call them “HTML components”.
- nightski 3y agoI 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 3y agoI 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 3y agoMost 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/ https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/ 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.
- madeofpalk 3y ago> 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 3y agoSo just run javascript before your components render so you don't have to run javascript before your components render.
- madeofpalk 3y agoIf you find a way to deliver a website without running any code, let me know!
- freeone3000 3y agoHave a HTML page that you just send. It’s really simples.
- 1-more 3y agoSend like in the mail on a USB stick?
- robertoandred 3y agoYou don't think code editors use code?
- Spivak 3y agoI 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 3y ago
- Spivak 3y agoDoesn'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 3y agoYeah 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 3y agoWe've abstracted away <DIV> soup
- mikebelanger 3y agoIf 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 3y ago> 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 3y agoHow 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 3y agoThat’s what JavaScript is supposed to be for: state change. Not rendering the page.
- goeiedaggoeie 3y agoThis is the main issue for me with webcomponents, they are not SSR friendly.
- kaba0 3y agoDo 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 3y ago> 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.
- superkuh 3y agoIt'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 3y agoI’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 3y agoYou'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.
- mock-possum 3y agoSorry, I’ve been working with web components since before they had wide browser support - so now, it’s ‘native’ in the sense that web component is a feature native to the browser, instead of being shimmed / polyfilled in. You can just write web components in an .html file, drag it into the browser, and it works, no build step or servers or external libraries required.
- troupo 3y ago> 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 3y agoReact 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 3y agoSo when react components were classes they were comparable, but now that react components are functions they are not?
- revskill 3y agoA class is a closure ?
- fkyoureadthedoc 3y agofunction Dog() {} var dog = new Dog(); Hey look classes are actually functions, now you can compare them, have at it.
- hu3 3y agoI think I've finally seen the light when it comes to Web Components: https://github.com/kennyfrc/cami.js 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 3y agoFor 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/src/supercomponent.ts https://github.com/codewithkyle/supercomponent/blob/master/s...
- gen220 3y agoHave 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 3y agoThe 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 3y agoReplace JSX with a custom non-standard DSL, call it a win.
- meowtimemania 3y agoIt's a win because it means no build step. You could also say that JSX is a custom, non-standard DSL.
- TheRealPomax 3y agoOne 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__ 3y agoI always saw web components as the missing leaves to the root that CSS frameworks embody.
- sam_lowry_ 3y agoFor those who read to the end... Angular still uses XMLHttpRequest and not fetch, IIRC. Funny, huh.
- LNSY 3y agohttps://lnsy.dev/blog/custom-html-components.html 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 3y agoIt 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 3y ago> 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 3y agoAm I misreading this or is it what https://htmx.org/ https://htmx.org/ provides?
- willsmith72 3y ago> 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 3y agoAt least you can server render web comppnents.
- robertoandred 3y agoYou've been able to server render React for like a decade.
- justsomehnguy 3y agoDefine 'server render'?
- troupo 3y agoOutput them on the server. Something you can't do with Web Components
- jakelazaroff 3y agoYou actually can't yet do that reliably. Declarative Shadow DOM is not yet supported by Firefox. https://caniuse.com/declarative-shadow-dom https://caniuse.com/declarative-shadow-dom
- Andrex 3y agoYou 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 3y agoSorta-- 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).
- sesm 3y ago> <user-avatar> > <img src="https://example.com/path/to/img.jpg 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 https://example.com/path/to/img.jpg" alt="..." />
- joestrouth1 3y agoThat 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_attributes/is https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- yuretz 3y agoThere is a polyfill for customiziing built-ins on Safari. https://github.com/ungap/custom-elements https://github.com/ungap/custom-elements
- earthboundkid 3y agohttps://caniuse.com/mdn-api_customelementregistry_builtin_element_support https://caniuse.com/mdn-api_customelementregistry_builtin_el...
- deleted 3y ago[deleted]
- jjcm 3y agoThey'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 3y agoThere’s almost no standard way to do anything when it comes to html style.
- account-5 3y agoWith 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 3y agoDoes HTML kinda look like XML? Yes.
- akshayka 3y agoWe 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 https://github.com/marimo-team/marimo
- joshstrange 3y agoI 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 3y ago> 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 3y agoThis is a purpose of a blog. This was not a tutorial or an article on how to use Web Components.
- continuational 3y agoI 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.
- rglover 3y ago*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 https://github.com/cheatcode/joystick
- yellow_lead 3y agoI 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-custom-elements/ https://www.abeautifulsite.net/posts/flash-of-undefined-cust...
- drawkbox 3y agoI 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 https://caniuse.com/template [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [5] https://caniuse.com/shadowdomv1 https://caniuse.com/shadowdomv1 [6] https://caniuse.com/custom-elementsv1 https://caniuse.com/custom-elementsv1 [7] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components [8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c... [9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition [10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [11] https://lit.dev/ https://lit.dev/
- CharlesW 3y agoBut 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 https://vuejs.org/guide/extras/web-components.html
- codingdave 3y agoI'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 3y agoIt 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 3y agoIn 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 3y agoYou can access the `nativeEvent` property on the event object[0] if you prefer [0]: https://react.dev/reference/react-dom/components/common#react-event-object-properties https://react.dev/reference/react-dom/components/common#reac...
- recursive 3y agoDoesn'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.
- zackmorris 3y agoI'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.
- butz 3y agoWhy 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.
- ivanjermakov 3y ago> 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 3y agoWeb 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.
- ivanjermakov 3y agoSSR is the traditional way to write frontends. PHP, Rails, JSP, most technologies that revolutionized the web were rendering HTML on the server. SSR, in one form or another, will exist for as long as HTML will. Additionally, SSR doesn't replace web components, it's a different technology with an intersecting feature. There is no problem to use them together.
- iteratethis 3y agoWhich 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 3y agoweb 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 3y agoI 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 3y ago>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 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 https://en.wikipedia.org/wiki/HTML_Components HTC Reference: https://learn.microsoft.com/en-us/previous-versions/ms531018(v=vs.85)?redirectedfrom=MSDN 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 https://youtu.be/R5k4gJK-aWw?t=177 Pie Menu ActiveX Behavior Control (htc file as text): https://donhopkins.com/home/PieMenu/piemenu.htc.txt 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 https://donhopkins.com/home/PieMenu/punkemon.xml.txt XSL Style Sheet (xsl file as text): https://donhopkins.com/home/PieMenu/punkemon.xsl.txt 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 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 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 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 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 3y agoI'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/proposals/html-modules-explainer.md#high-level-summary https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
- troupo 3y agoHTML 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 3y agoI 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.
- Nathanba 3y ago
- gryzzly 3y agoMy 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 3y agoA 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/ https://stenciljs.com/
- socketcluster 3y agoWeb 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-L115 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/ 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/ 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.
- yuretz 3y ago> ... with no custom code ... Except all the custom code in saasufy-components
- socketcluster 3y agoIt's generic code, not specific to the application as it can be reused for any application. There is code behind native HTML tags too but we don't say that writing HTML is writing code, the browser handles that.
- locallost 3y agoI 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 3y ago> 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://lpedrosa.github.io/blog/web-components-part-3/ https://github.com/lpedrosa/webcomponents-blog-examples 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
- oknoorap 3y agoThis is what I do with my web-component framework: https://realm.codes https://realm.codes The website itself also built with web component
- marcus_holmes 3y agoI recently used Web components to make a fairly complex form. It works well, but I am absolutely building the entire DOM tree inside the component in JS. The component relies on a bunch of tags being in the right place in the tree, with the right id. If the tags were specified by the HTML then there's too much opportunity to get it wrong. Templates might be do-able but there's no convenient way to add a template to a script file, or specify a template in JS (I guess this is why JSX came to be). I definitely feel like I'm doing it wrong, but all the guidance I see doesn't help - they're all very "hello world" examples that don't get into the difficult stuff.
- nsonha 3y agoI didn't have to read very far: > ...they can render before JavaScript what? Because web components are written in and run on magic? > a design of composability... composing core content with HTML and then wrapping it in a custom element that enhances its contents with additional functionality Put aside the self-reference, that's not what composability usually means, but I guess that sounds fancy to the uninitiated
- riquito 3y agoWhat's the preferred way to version web components since their name is global and you can't risk breaking old usages when you introduce a breaking change? user-avatar-v2? What's todays suggested practice?
- littlecranky67 3y agoMaybe it is just me but for me web-components were never able to deliver what they promised or a viable solution for a simple reason: i18n/translations. As a European freelance web dev, I've virtually never been in a project where we develop single-language UIs - its always at least the national language plus English. Those translations can't reside within a "component" itself for a simple reason: Translators push you to always share translations across components to achieve consistency throughout your UI. Now with react-intl or react-i18n-next those translation strings will live in a single or just a couple of files for the whole UI, and be provided through a react Context. It is also one of my pet peeves when people talk about "independent, self-sustained components". That is just not a thing in UI land, in most bigger projects each component has quite some external dependency from some form of enclosing context (translations beeing the most common one). In the article, user-avatar is probable one without any text at all, but thats the minority of components.
- kavaruka 3y ago@lit/localize (https://lit.dev/docs/localization/overview/ https://lit.dev/docs/localization/overview/) give you the same DX of react-intl, but for (lit-powered) web components
- floriankiem 3y agoI'm from inlang and we're building an ecosystem around globalization. Recently, we have released paraglideJS – a typesafe, super lightweight library that works with every framework. We've received a lot of good feedback in the last couple of days, feel free to try if it satisfies your purpose: https://inlang.com/m/gerre34r/library-inlang-paraglideJs https://inlang.com/m/gerre34r/library-inlang-paraglideJs
- ttfkam 3y agoApparently not widely know, but… > Svelte components can also be compiled to custom elements (aka web components) using the customElement: true compiler option. https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api This would negate the "vendor lock-in" arguments and allow Svelte for component development but web component for consumption and use. Best of both worlds. All the DX advantages of Svelte over web components without sacrificing interoperability.
- nathansherburn 3y agoAny examples of the web component code they spit out?
- pabc1 3y agoI believe some people generally avoid Svelte for custom elements since Rich (and other maintainers) have consistently shown criticism towards Web Components in general.
- shanghaikid 3y agoWeb components are encapsulated very well. It is different from template frameworks such as react. It is somewhat similar to frameworks such as angular. As we all know, angular fails because of its complexity. It uses javascript to look like java. Web components look like It is not that complicated, but it also introduces a lot of concepts. These concepts are rarely used by ordinary developers. It is generally difficult to change the developers' inherent concepts and development habits to adapt. If there is no react or vue, I feel that it may not be successful because there may be other simpler frameworks.
- Lennu 3y agoA problem I faced recently with web components using shadow dom is styling nested components within custom element: From <user-avatar> we can give styles to <img> <user-avatar> <img src="https://example.com/path/to/img.jpg https://example.com/path/to/img.jpg" alt="..." /> </user-avatar> but not anymore when its below <picture> <user-avatar> <picture> <img src="https://example.com/path/to/img.jpg https://example.com/path/to/img.jpg" alt="..." /> </picture> </user-avatar>
- j-bos 3y agoAs someone forced to use an in-house library of html web components at work,I will opine, run. Run at full speed away from the shadow DOM. It's cumbersome to work, poorly supported in testing tools, and web components themselves are a pain to deal with when your use case doesn't perfectly match the original build. I'd like to like them, but, no.
- morbicer 3y agoHugs to you brother. I am in exactly same boat. The encapsulation coming with shadow DOM can be done in other ways (CSS modules) so light DOM seems a like saner approach... but then you lose the slots and they are must have for any composability.
- phenomena23 3y ago[dead]