Replies: 8 comments 6 replies
-
Accessibility
Selectors
Stylesheets
Style customization
Defining/Upgrading
Description
Templating
Module graph
|
Beta Was this translation helpful? Give feedback.
-
Defining/Upgrading (addendum)
|
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this is totally what you're looking for, but two related areas I'd like to see explored more which haven't been mentioned yet: Server side renderingPersonally, I would love to see some improvements in the SSR'd web components space. The web ecosystem has been moving more and more towards SSR infrastructure again, and a framework-independent specification for an SSR-capable component could be just as valuable on the server as it is on the client. I have no idea what this would look like, especially given that it's not really a browser problem, but I would really like to see more experimentation and standardization in this area. Some specific items (most of which inspired by this thread):
My end goal here is to be able to take existing web components in a standardized format and render them on the server, providing a common format for components to be used across any server framework / infrastructure. This would enable a number of performance and usability improvements as well as unlock a whole new environment for web component authors to leverage without relying on frameworks or special support in applications. Imagine a full design system which is completely framework-agnostic but also supports SSR, with most components having zero-JS runtime since all the work is done on the server! "Webcomponents-over-the-wire"A recent idea I've been exploring is a more standards-driven HTML-over-the-wire approach, powered by web components. The TL;DR is that I would love to have a supported way for an SSR'd web component to be an API response type. Instead of returning a JSON response that gets CSR'd into the DOM, let's just return an SSR'd component which just gets attached to the DOM. This pulls on many of the above SSR issues but also brings up some other challenges. (Full disclosure, I'm not totally convinced all of these are good ideas, but as a long shot "North Star" vision of what web development could look like I think it's worth at least mentioning them in this context.)
My vision for this is being able to write an HTML-over-the-wire application entirely based on web components and existing standards without any special tooling, infrastructure, or heavy coupling to a server framework. This would give developers the flexibility to easily choose where rendering happens (client or server) as well as mix and match these approaches with different components and use cases in the same application. This would also all be possible without overly committing their application's architecture to SSR or CSR, letting them choose the best tool for the job at any given time. Again, I'm not totally sure this is what you're looking for in this thread, but hopefully these are at least interesting ideas to consider in a "North Star" vision. 😁 |
Beta Was this translation helpful? Give feedback.
-
|
Great start! Thanks. 🚀 Already some productive overlap 😅. Sussing out those "a part of all the visions" parts seems like a good direction to outline? Couple of things I'd love to hear more about:
|
Beta Was this translation helpful? Give feedback.
-
They are server-centric and I agree that's awkward from a standardization perspective. HTTP does cover servers and Node folks are involved in the standards process from my understanding, so this isn't unprecedented even if it's a bit weird. I'm not familiar enough with the different standards groups to know exactly where this would fit. It's possible this makes more sense as a community protocol or some other mechanism, which is why I'm framing this more as "I want a way to author and use components in a standardized fashion which can use SSR but aren't dependent on any particular framework". Maybe that's more of a problem space than a vision of a desired solution.
SSR can be useful outside of initial page load contexts. If a lot of work is done to compute the rendered DOM or you need to make a server round trip anyways, why bother implementing and supporting a CSR implementation of a component if all your use cases can actually be met via SSR. It also means less JS is required at runtime if all it does is incrementally update an already rendered element instead of rerendering the whole thing from scratch. This is explained more in the blog post I linked about SSR-ing specific pieces of DOM on-demand and using custom elements to hydrate it with functionality in an "islands-style" architecture. I'm imagining an "SSR-ed web component" as a custom element with pre-rendered children. Something like: <my-tweet>
<template shadowroot="open">
<style>...</style>
<span>Hello from an SSR tweet!</span>
<button>Like</button>
</template>
<script src="my-tweet.js” type="module"></script>
</my-tweet>You can do this in a typical web page today, but with HTML modules this could be a complete response to
To clarify what I mean by "same HTML module with different content", I mean a single component definition with different SSR'd content. For example if I request <my-tweet>Hello world from tweet 1234!</my-tweet>
<!-- vs. -->
<my-tweet>Hello again from tweet 4321!</my-tweet>The definition of This gets extra confusing if you consider that a tweet could be edited, so requesting See https://blog.dwac.dev/posts/html-fragments/#code-vs-content for more details here.
I haven't been very involved with the standards process, so I've only really brought this up in the blog post and some Twitter threads. I agree it's not really a custom element, so this might not be the right venue for it, but it's usage is heavily dependent on the "webcomponents-over-the-wire" approach I'm suggesting here, so I think it definitely fits with this North Star vision, even if this working group might not be the one whoch actually lands the proposal. |
Beta Was this translation helpful? Give feedback.
-
Unified resource reference and importmapsWhether it is a URL gives ability to refer the page DOM element, external resource and partially location within external resource. Unfortunately it is not coupled with importmaps to make externally served libs viable. In addition to generic ability, the attributes like This concept is covered by several web component libs and a must feature for Web Components driven web app MVP. |
Beta Was this translation helpful? Give feedback.
-
|
If I could sum it up it one phrase it would be "HTML Apps". In five years' time, web components and associated technologies should be sufficiently mature to allow simple web apps to be developed little or no userland javascript, and complex apps with far less than is the norm today. To get there we'll need at least
And preferably something like declarative ElementInternals (aka |
Beta Was this translation helpful? Give feedback.
-
|
For "HTML Apps" in addition to list ^^ the data access layer (DAL) is needed as well. Which includes
Concept is quite popular in existing libs, just declarative syntax is not polished enough. |
Beta Was this translation helpful? Give feedback.
-
Full Stack Web ComponentsWith the advent of ESM on the server, supplemented by the rapid rise of web first serverless and edge runtimes backed by the WINTER CG, what I am most excited for is the potential of a web standards based development paradigm from server to browser for Web Components. Through a combination of ESM, TemplatingPage and layout templating using components, common in full stack JS frameworks like Next and SvelteKit can be achieved with just a little bit of work / community alignment, and can make the server DX seamless. Not that I have anything wrong with templating languages, but between this and template literals, I am totally ready to never have to use some bespoke DSL again. import './components/footer.js';
import './components/header.js';
export default Layout extends HTMLElement {
connectedCallback() {
this.innerHTML = `
<app-header></app-header>
<h1>Welcome To My Website!</h1>
<app-footer></app-footer>
`
}
}
Over The WireWas chatting about this one recently with @dgp1130 and have some thoughts about how current and future horizon specs could leverage the constituent parts of a component definition (HTML / CSS / JS) independently. This would support being able to optimize the workload for the given environment the component is running in (e.g. web vs server). Thinking a combination of DOM Parts and / or HTML Includes and / or even Import Assertions could shake something like this loose? For example, on the server where you may just care about returning static HTML, the below is a bike shed at what something like DOM Parts with HTML templates could look like. Template <product-details>
<h1>${name}</h1>
<h2>${description}</h2>
<p>Price: ${price}</p>
<img src="${image}" alt="${name}"/>
<button data-product-id="${id}">Buy Now</button>
</product-details>Handler Function import detailsTemplate from './components/product-details/product-details.html';
export default async function handler (req, res) {
const data = await fetch(`http://example.com/api/products/id=${req.id}`).then(resp => resp.json());
const template = new Template(detailsTemplate, data);
res.send(template.getContents());
}But on the client, where say that product details can be interactive and you want to attach behavior (event handling), you'll want the JS there too, and of course still want to use that same HTML template for hydration (Declarative Shadow DOM). // or maybe globally loaded via an HTML Include <link rel="html" href="/components/product-details/product-details.html"> ???
import detailsTemplate from 'http://cdn.example.com/components/product-details/product-details.html';
const template = document.createElement('template');
template.innerHTML = detailsTemplate;
class ProductDetails extends HTMLElement {
connectedCallback() {
if (!this.shadowRoot) {
this.attachShadow({ mode: 'open' });
this.shadowRoot.appendChild(template.content.cloneNode(true));
} else {
this.shadowRoot.querySelector('button').addEventListener(this.buyProduct);
}
}
buyProduct() {
const id = this.shadowRoot.querySelector('button').getAttribute('data-product-id');
prompt(`Do you want to buy ${id}?`);
}
}
customElements.define('product-details', ProductDetails);One advantage of this system here is no need for a DOM shim on the server side, but still have a single source of truth for your component definition across frontend and backend. StylingPer @Westbrook, a good story around CSS would be vital as well. I think import assertions would work really well here too, and / or in the interim, custom loader hooks like with NodeJS's import detailsTemplate from './product-details/product-details.html';
import detailsStyles from './product-details/product-details.css' assert { type: 'css' }; // import assertion example
import detailsStyles from './product-details/product-details.css'; // or custom loader example
const template = document.createElement('template');
template.innerHTML = `
<style>
${detailsStyles}
</style>
${detailsTemplate}
`;
class ProductDetails extends HTMLElement {
...
}
customElements.define('product-details', ProductDetails);
I think being able to facilitate these kind of developer workflows natively all through the runtime(s) is pretty compelling IMO. Just install NodeJS and / or opening your browser and wherever you find yourself, you can use that Web Component! 💚 All in all, it's never been a better to time to bet on the web and I would love to see (and help) Web Components lead the charge into this future! ✌️ |
Beta Was this translation helpful? Give feedback.
-
|
missed connection between With DCE <define tag="product-details" template="./product/templates.html#details" /> <!-- css loaded from within -->or JS with extended HTMLElement class ProductDetails extends HTMLElement {
// import returns Promise<TemplateHTMLElement>, css loaded from within HTML with relative URL,
// hydration driven module loading
static get template(){ return import('./product-details/product-details.html', {as:TemplateHTMLElement} ); }
...
} |
Beta Was this translation helpful? Give feedback.
-
templating
Externally defined templates source document have to be reused without the need to be injected directly into current document. When the page changes, templates DOM remain in memory and ready to be reused or offloaded. |
Beta Was this translation helpful? Give feedback.
-
|
5 years is not nearly a long-term planning. They turn 11 years this year (starting with the original poposal by Alex Russel). What we see in the list is "how can we patch the hundreds of holes in web components that no one stopped to think about, and instead just barrelled through with implementations". What the web really needs in the next 5 years is:
All the proposals seem to be just a continuation of "hell yeah, we know what to do" without ever, ever asking "why do we do this"? All of the issues are the issues web components themselves created. It's a self-perpetuating source of constant work and churn. |
Beta Was this translation helpful? Give feedback.
-
Isomorphic Template Syntax That's Compatible with DSD(First of all, great ideas and thoughts shared thus far!) The biggest issue for me by far right now is the lack of any sort of template specification that is server-language agnostic (aka doesn't require the use of JavaScript) and is compatible with DSD. Let me explain. We can use the ubiquitous "counter" component example because it so easily describes the issue. Let's say I want the counter to start at 1. So I can start to write a component like this: <my-counter count="1"></my-counter>OK, so far so good. Now I want to add a button in the shadow DOM to increment the counter as well as display the counter: <output></output>
<button>Increment</button>Now I have two questions. (1) How does the counter value get injected into Maybe we can punt on the event listener problem. Do it imperatively with a JS statement in Still, we definitely have the issue of output. OK no problem, we use some sort of simple Handlebars-like syntax. <output>{{ count }}</output>
<button>Increment</button>We can render that into a DSD: <template shadowroot="open">
<output>1</output>
<button>Increment</button>
</template>OK, but now once my component has been upgraded on the client and a button click or an attribute or prop changes Well we'd likely have a copy of the template stored client-side with the JS. But now we have to start doing DOM diffing between the template and the DSDed output. It has to "figure out" that In my view, the answer is clear. We shouldn't use something like Handlebars. We should use something like Vue, Knockout, and other frameworks which can bind things via attributes. And then let those template bindings flow unchanged through the DSD rendering process. Let's revisit. In pseudocode: <output bind="count"></output>
<button>Increment</button>That renders out as: <template shadowroot="open">
<output bind="count">1</output>
<button>Increment</button>
</template>Aha! Right there in the DSD, the template syntax has flowed from server to client! Now if the value of OK, but what about the other direction? Can't we do something similar with event handlers? Again, looking to syntax like Vue's (or Lit's for that matter) for inspiration here. Not sure if it's actually valid HTML, but browsers don't seem to mind. <template shadowroot="open">
<output bind="count">1</output>
<button @click="increment">Increment</button>
</template>It turns out that's actually the easiest problem to solve because we likely don't care about event handling on the server. We just want to pass some indication along to the client that it should connect with client-side component code. What about something more ambitious though? What about repeating lists? Well, another thing that's nice about Vue is that you can supply a template tag which defines a for loop. <template v-for="item in items">
<li>{{ item.msg }}</li>
</template>We could write this out something like: <template bindfor="item in items">
<li bind="item.msg"></li>
</template>Then the question becomes, how do you actually render out the list of items from the server, yet provide a mechanism to mutate that list on the client? I don't have a super great answer to that, but the thing I've prototyped in user land is basically this: <template bindfor="item in items">
<li bind="item.msg"></li>
</template>
<li bindif="!hydrated">Message 1</li>
<li bindif="!hydrated">Message 2</li>
<li bindif="!hydrated">Message 3</li>And once the client first processes these nodes, it essentially deletes the unhydrated nodes and replaces them with hydrated nodes…presumably with the exact same starting state so it's a relatively seamless process. Does this cover all use cases? Not by any means. Yet it has the potential to solve quite a significant number of use-cases. There's also outstanding possibilities like binding attributes (e.g., toggling a class on/off depending on a boolean) and all that, but I feel like that gets into the weeds of a spec. We first need to agree (a) do we need any spec at all, and (b) what basic problem would this new spec solve. As I wrote online:
I really and truly love web components, but increasingly I find it's a very hard pill to swallow that in order to write any sort of "isomorphic" web component, I am unequivocally forced to drop all server architecture that isn't squarely based in JavaScript via Node/Deno/Bun/etc. That seems, as I also wrote recently, to break a fundamental promise of web architecture: that the precise OS/language/runtime of the server is agnostic, and only protocols need to be agreed upon for client & server. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
@jaredcwhite , this thread is wrong for proposal kind discussion. I would expect it on https://github.com/WICG/webcomponents/issues Syntax of Parts with curly brackets is already in heavy discussion, kind of stock as of now. PS. I count the Declarative Web Application stack definitely worth of pursue. |
Beta Was this translation helpful? Give feedback.
-
It's always good to have a plan, a vision, a North Star (if you will), and that includes Web Components. In association with our API/Specs Status Report for 2022, we're looking to include a rough visions for Web Component Specs in the next five years and how browser implementers can support getting there along a path that is successful for all involved in the process. To do so, we want to know where you think Web Components APIs and Specs should be in the next five years.
There's no guarantee any of this comes to life, there's not even a reasonable way to include that all of your ideas get included in the report, but I can guarantee that we'll all be excited to hear your thoughts. From these ideas we'll formulate a general five year vision of Web Components and work back from there to outline APIs and specs that need to solidify and land to make these futures, or a future like them, a reality.
Thanks in advance for sharing your thoughts!
Beta Was this translation helpful? Give feedback.
All reactions