Convopage
See the entire conversation
350 replies and sub-replies as of Jan 20 2021
I listened to a podcast about web components just a few weeks ago and it basically amounted to the interviewers giving a list of things web components can’t do very well and the guest saying “well I don’t need to do any of those things, so I don’t see the issue.”
People? How many people are you talking about? I reckon it's a minority but that doesn't have the same impact 🔔🔚
That's what @Ionicframework has been doing all the time if I'm not wrong.
Not sure I understand the context here...but when we discuss semantics, we talk about how our components utilize semantic markup under the hood. An auto-opt-in to best practices. We for sure don't talk down to anyone ☕️
I was pointing out Ionic as positive example here, I love the way you implemented multi-framework support using WC
Ah, wonderful! Must have misread due to lack of coffee 😬
So you're saying there aren't enough web components tutorials? I agree. But that's because there aren't as many web component devs as react devs. What makes the issue worse, is the space is very fragmented, there are dozens of wc frameworks:
WebComponents.dev
The Component IDE for Web Platform Developers
webcomponents.dev
Well yes... because you almost can't do a thing with WC alone :(
You can do a whole lot. Of course, it depends on what you mean by "the thing", but Web components are just vanilla js, the sky is the limit here.
Well yeah that is correct in theory. No one has the time to make webcomponents nicely talk to each other in a big app though.
Like, are you kidding me. Except if you don't know how to write js.
I think this issue is with devs in general and not just WC. WCs don't force you to write semantic HTML, and are just JS like any front end library anyway.
haha yeah I definitely agree with that.
Yeah unfortunately it is also easier to create more bs to combat the original bs than to address it head-on.
No comment to this specific scenario.. just generally.
Just heard the "div-itis" thing on a podcast complaining about React... Maybe React is different, but I think a lot of my Vue components are pretty well covering the semantic spectrum. Maybe I got lucky and picked up a good habit early? I don't feel like it takes that much effort
Not to mention that WCs have a11y drawbacks that aren't shared by built-in elements that *can't* just be solved with education twitter.com/Rich_Harris/st…
There will always be people who deride the popular frameworks because of the fact that beginners use them and then point at missteps beginners make and blame the FW. But the anger is misplaced on the enabling FW, rather than on the lack of cohesive education on underlying topics.
It's more than that. It's "use the platform that's provided so you have time to learn about semantic html instead of which tech to use". And then the finger is never pointed inward to ask "why doesn't the platform make all of this stuff easier?"
In general, I think the industry *is* too focused on new and shiny tech over fundamentals, but that's human nature. We tend to prefer improvements to problems we're aware of and already partially solved over discovering new problems to fix!
Don't forget that there are a lot of people invested, in the old school web, who came up touting (rightly then), web standards etc. They've made careers lecturing on HTML and the evils of JS.
Which is why it's all the more ironic to see them advocate something that literally doesn't work without JS
Well, I mean, custom elements have to be JS. But the fact that there's no renderToString or equivalent has been a blocker for me.
This is because they're designed for progressive enhancement. Once you treat them this way objections around accessibility and server render go away. It's not what they're good at.
I dunno, I think I understand what you're saying but I don't think progressive enhancement means you chuck a11y.
I am not suggesting that. 😑
Ok, my misinterpretation. I thought you were saying that since they're progressive enhancement, the a11y issues matter less.
I'm saying you need JS to activate custom elements because that is how they work.
So we use them to enhance the page with interactivity. PE.
The default should be accessible and assume two things: the context could be mobile and might NOT have JS enabled.
Ok. But I think the original question had to do with whether using plain JS/HTML without the baggage (or advantages) of shadow Dom was better for a11y and shared css etc. I can see encapsulation being useful sometimes, but not all the time.
Oh btw, I'll take this opportunity to ask what's the opinion here of Alpine JS? I see it as a pretty solid middle ground. More in the "sprinkles of JS" category than, er, the whole 🍩 (sorry, had to stretch the metaphor!) , but it works very well with existing markup.
Looks fun!
Sure, they're designed to be *only* PE with no thought of isomorphism. That doesn't mean the design is correct. Its philosophy over pragmatism.
Ya I'm interested in shipping not philosophy. Correctness is pragmatism IMO and trying to pretend these things are something they aren't isn't pragmatic.
I'm not pretending they're something they are not. I'm saying the very thing WC advocates rail against is inhibited by this philosophical insistence that backends don't exist.
Ya I don't think anyone is doing that ?
I think we collectively need to clarify our definition of progressive enhancement. For me, it means things like <form> works without JS, but progressively enhances to an AJAX-enabled form with JS. That's straight-up impossible with <fancy-form>.
For me the conclusion is inescapable — if we care about building robust, resilient applications that meet a11y requirements, we should avoid using web components. The energy currently devoted to them should be spent on standardising CSS scoping and adding new built-in elements
The assertion in your previous twete is not correct. We can emit a custom element from the backend and indeed it can contain a vanilla html form. If JS is available we can activate the custom element to do what you describe.
you mean my <fancy-form> has to contain a regular <form> inside it? i mean... c'mon
We do this. It works great. You could call it fancy.server.js and it requires fancy.client.js ... Which is the conclusion react arrived at.
Also! This can be almost entirely declarative with slots. Maybe y'all aren't ready for this. But browsers are.
brian this is absurd
because it isn't... doing anything. the ~whole point~ of WCs is that they're supposed to encapsulate implementation details
It's progressive enhancement so the form doesn't need to reload the page but works even if the client doesn't have JS. This is the use case AFAICT. It is doing that. The mismatch here is assuming the purpose is running identical code client and server.
By way of analogy: This bicycle is a terrible boat! Why is it sinking?!
But you marketed the bike as a boat, and every time we say “hey this doesn’t work on roads” people come out of the woodwork telling everyone to build a canal system so that we don’t *need* a bike 😂
cc @AdamRackis who will appreciate this analogy I think.
I'm not marketing web components. I am explaining how we use them successfully.
It's not complex. Tho burden of that proof is on me to provide aside these trivial button examples. All I can do is point at begin.com which is a pretty amazing user experience imo. Anyhow. I'll keep sharing and eventually folks can verify for themselves.
Of course that’ll work, but what even is the wc doing at that point, if it needs to wrap non-wc content to be resilient to non-JS environments?
Yeah sometimes called accessibility.
Html forms are accessible already, though. Surely something went wrong with wc if, to not break things, users of <fancy-form> need to include a vanilla form when they reach to use it?
I'm not breaking anything. I'm giving them a form that always works and sometimes won't reload the page.
Right but wouldn’t it have been better if the wc solution didn’t require devs to stuff an old school form inside of the wc form? That strikes most devs as kinda silly - per Rich’s original reply to this
What do you think happens when you have an accessible form in React/framework land ? You have a form. With a bunch of other stuff. It's how that would work regardless of your personal fav implementation.
But you don't write 2 versions of the form with React, you write one implementation which runs on both client and server, there are additions for the client version, but it's still not 2 separate versions of the same form
I'm only writing one version also. Yes, there's a <form> tag being rendered. Same with React.
Ah I think I see what you were saying originally now. So the <form> tag is *auto-generated* by some sort of backend build step?
yes. our backend uses string template literals for this. it will send <my-form><form ...></my-form> which will activate my-form if JS is enabled. same difference as any framework.
It's also perfectly possible for your fancy-element to surface a hidden regular input field in its light-dom to participate in any regular form container. I agree this is a hack while we wait for AOM and form participation to land but it is possible to solve a11y and form issues.
this is frustratingly ridiculous. so much energy being wasted solving the problems introduced by WC, when it's been perfectly easy to build accessible forms with vanilla HTML or frameworks forever
I am building vanilla forms and then enhancing them. It's way less work. It's not 'frustrating' or 'ridiculous' it's way less code and works everywhere without a build step or upstream deps. What is the argument against this ?
reread the tweet brian, i'm saying that the energy being spent on e.g. fixing the a11y problems WCs introduce is frustrating and ridiculous
I don't have a11y problems and I've now explained how/why for the given use case multiple times.
*you* don't have a11y problems because you've come up with a frankly somewhat convoluted-sounding bespoke workaround that involves doubling up on elements and writing separate client/server versions of stuff
Is using the browser primitives bespoke ? A workaround? Client and server are different runtimes.
i'm happy for you that you've found something that works well for you. i'm just saying that i don't expect 'write two versions of everything and expose implementation details in light DOM' to persuade, say, React users that they should start Using The Platform™
you mean like myform.server.js and myform.client.js ?
Neither are we.
Think some of our source is available at arc.codes but nothing walking through this pattern specifically yet. It's just progressively enhancing a form using custom elements to initiate the enhancement.
OpenJS Architect documentation
Architect is the quickest way to build serverless web apps on AWS
arc.codes
yep! we use slots to perform the markup upgrading should it be necessary (isn't always)
right, that's the solution you appear to advocate. in react, even with RSC, you write myform.server.js (but not in this scenario, because that precludes AJAX) OR myform.client.js, or just myform.js. you'd never write both
You can compose client components with 'server' ones in react. But we don't have hard limits so much as we are embracing the runtime. There are ways to run client DOM centric code in Node (and Deno). It's just not a good use of our time.
Yes, you can compose server components with client components, but the unit of composition is either/or, not both. There is no isomorphism in WC, the way there is in modern FWs.
Obviously I'm aware. This is swimming upstream for little benefit as the server doesn't support client interactivity. But you do you! I'm just explaining our approach which works for us. If latency doesn't matter toString is fine.
The benefit is I only write my component in one file, one source of truth. You're conflating the benefits/detriments of server with single source of truth. Anyway, you're not *just* explaining what works for you, you're actively declaring what has "little benefit".
Clearly most agree given how few server render and opt for SPA instead. Pre-rendering seems ok if you don't mind a build step. Anyhow these are all just trade-offs I personally prefer to avoid and rather prioritize authortime and runtime performance. 1/2
You still have a single responsibility principle. Better really! Interaction is decoupled from initial presentation logic.
I don't know that people agree those should be separated as much as in the past tho. Server or pre-render is becoming very common with Gatsby, Next, Svelte, etc no? Imo the best distinction you're making here is build or no build step. But I'd argue few stacks have no build now.
Eg rise of utility CSS like Tailwind requires build step for CSS alone and before that, Sass. Obviously Sass compile < Gatbsy build*300 doc site but fewer tools have no build step now for better or worse.
I'm using Alpine JS a lot recently which requires no build, but I'd bet it loses the Pepsi vs Coke performance challenge against say Svelte and I'm sure litElement isn't as fast.
The rise of Tailwind requires this. Utility CSS that doesn't require tooling is entirely doable -- Tailwind decided on doing things a particular way.
Yes for sure, but as with a lot of this discussion in general, whats popular and practical is at variance with what some consider best practise. TW is very practical, very popular. It'd be great if it didn't have a build step, but since it does builds aren't strange territory.
What I mean is the pratical benefits of TW and its build (IMO) outweigh the theoretical disadvantage of having a build step. And for what its worth, the authors are investigating a middle ground, no-build option as well.
The key revolution from React and modern FWs is that presentation logic *shouldnt* be decoupled from interaction logic. You can say what works for you, but again, this is the bit that WC advocates keep paper plugging their ears about. Devs have rejected "separation of concerns".
Ya my Lambda functions don't have touch events etc. But cool story.
Both authortime and runtime are faster for us. Iteration and especially debugging which happens far more often than initial code. Trade-off is we have deep browser knowledge. That investment is compounding however as browsers are backwards compatible unlike userland tools.
Whats frustrating to me is there's really no one on the standards side listening to this. Devs have made it abundantly clear that they need to write once for server/client. The only way to make that really possible is to drastically approve HTML.
But HTML is essentially in maintenance mode. With CSS there's dozens of people actively improving it (look at Miriam's post for yesterday), but with HTML there's only devs asking for stuff and a handful of brave browser engineers making small incremental changes.
Compare this to what happens on the CSS side, or the highly active JS standards process. HTML is a ghost town. Yet it's probably the most important part of the web. I'm continually amazed by how few people notice this and recognize how dire it is.
I don't think this is fair to either CSS or HTML.
CSS moves at a sclerotic pace too, and HTML improvements have focused on DOM and WC, with a great deal of vendors-playing-catch-up on many fronts until very recently. Both can move faster to do more, and both should.
Simply not true, go compare github.com/w3c/csswg-draf… (oldest issue on first page is 10 years) to github.com/WICG/webcompon… or HTML or DOM.
WICG/webcomponents
Web Components specifications. Contribute to WICG/webcomponents development by creating an account on GitHub.
github.com
CSS's previous biggest issue was already fixed (grid) and the current one has actual draft specs (see layers and scoping). The HTML issue discussed here probably gets a couple dozen github comments per year.
Ack! 10 days, not 10 years :)
CSS's biggest issue, full stop, has been extensibility. The way the transpiler ecosystem has evolved is a direct parallel to what's broken w/ HTML/JS, and CSS WG has been too slow (in parallel ways to HTML) at addressing.
Alex, extensibility doesn't mean shit unless you have a good stable language to extend upon. CSS prior to Grid was not-good-enough. The idea that we should have continued using floats for layout so CSS engs could focus on a thousand types of worklets is insanity.
I think it speaks to where CSS is today that they prioritized (and continue to prioritize) the right things and punted on "making it easier to create your own masonry layout" and where HTML is today, with most of the big issues of the last 20 years no where close to being solved.
If you want to ascribe positions to me that I'm not taking (did I say layout pre-grid was good?), rather than engage on how to make the progress you want happen faster, that's fine, but I was hoping to help you be more effective in getting what you want.
Can you clarify what you mean by "CSS's biggest issue, full stop, has been extensibility. " then? I took that to mean it's a bigger issue, in your mind, than grid. If not what do you think it's more important than?
Are you familiar with the concept of pace layers?
Thanks, bookmarked for later. I doubt it tells me whether you think extensibility is more important than grid though so I think you'll have to tell me that yourself.
LMK when you've read and we can discuss! Happy to meet if you can make time.
Do you ever wonder why people are put off participating in conversations about the platform, when this is the kind of interaction they can expect?
I'm not sure what I'm missing but from where I sit all I'm seeing is Alex trying to help you have a productive conversation and guide towards a better interaction with the standards bodies and platform, while you both continue to rail on the mistakes of the past.
'to understand my thoughts on the relative importance of CSS Grid and Houdini, purchase and read this book and schedule a meeting with me' doesn't come across as particularly helpful
Come on. He's spent significant time here engaging with you on multiple points. Suggestions on reading material to help make the conversations more productive and align on how we theorize about the platform in order to have better discussions is constructive feedback.
Not helpful. All platforms have to take a stance on how they will survive the long haul. One of the major problems with user land frameworks is most don't do this. The topic of pace layers is a good concept to understand when trying to evolve a platform designed to last decades.
I can't tell you how frustrating it is for people like me to be told, every time we point out ways to improve the platform, 'so go and do the work' — as if its shortcomings are our fault. We're giving you the solutions, and you're not listening.
*sigh*...
I guess we have the mute button for a reason.
Checking out of this, there were some interesting points in this thread but I've spent enough time on this. Good luck getting the changes you want to see with this approach to collaboration and discussion.
What we've been trying to demonstrate is that the fast layer is doing just fine (and would be even without WCs; I would certainly argue that the most interesting innovation has been happening elsewhere), but that the slower layers *aren't* doing the essential consolidation work
(Specific to HTML, I mean. Fugu has been going guns blazing and it's wonderful to see, if frustrating to note that the future is unevenly distributed due to differing priorities from other vendors)
It's definitely been slow going, but then again the slower layers will be slow to change by definition?
I feel WC are actually helping in that regard though. With WC we can begin to move towards defining new elements that could be agreed upon & tested & moved into the built-ins
Hopefully this can help accelerate open-ui and other efforts.
Yes they're not perfect, but they let us play a built closer to the built-ins than pure user land approaches.
We largely agree; I want HTML to integrate (& explain) more. The open-ui approach is effective because, IMO, Greg has such deep background in how browsers see change. My goal here is to highlight how to formulate proposals that are more legible for integration in this same style.
What's frustrating is watching talks like this: youtube.com/watch?v=y-8Lmg… where @slightlylate says: "Moving common stuff from user space into the platform itself let us reduce dev time, complexity, and let us radically improve user experience" (at 7:20)
And then nothing happens.
Web Components: Just in the Nick of Time (Polymer Summit 2017)
When Google started the project that developed Web Components back in 2011, the full impact of the mobile revolution hadn't yet been felt. Many tools and fra...
youtube.com
Fun fact: the frontend community already successfully consolidated around their frameworks.
The WCs have hopelessly lagged behind and developers are not looking at them – because switching to WCs is a step back in many aspects
The main step back is lack of isomorphism, but that got dismissed by @brianleroux because his backend lacks touch events, lol
so weird! no touch events. no click events. no onsubmit events. its like the backend isn't user facing interactivity ? idk, seems suspicious. whats that guy hiding ?!
That guy is hiding the fact that html elements, which are represented as a string on the backend, are the things events get attached to.
by the browser runtime. not the node runtime. to say nothing of the somewhat important cases of ruby/python/java/rust/c#/etc. (which could also participate in the initial render…if you separate these concerns.) anyhow! I'm not claiming its the ONLY way. just a way that works.
We can't all have Parler-level HW budgets, can we?
but you do appreciate that isomorphism _is_ important for some of us?
no shit. actively trying to point out that universal rendering isn't the only way and in fact may not be desirable for certain use cases esp when performance is crucial.
Sure but ... you do realize isomorphism is a pretty common use case, and wc’s failure here is pretty bad.
When perf is crucial, we have caching and static site generation. But even still, recognizing that not everything is perf crucial, isomorphism seems like an important ergonomic.
right. was just checking we were in agreement on that point, because brian entered this thread to combat mike's point that the lack of isomorphism prevents many of us from adopting WCs — seemed to think he was just confused
No he's not confused. We're aligned
ah yes, I'm just confused. super good faith discussion rich.
sorry, 280. i meant you seemed to think mike was just confused about the importance of isomorphism
isomorphism *and* rejection of "separation of concerns"
Although I guess they're highly related here.
Interested in where perf breaks down from universal rendering??? (Also on the topic of PE the banner dropdown on begin.com doesn't work without JS. Not a WC issue, could probably be a anchor tag rather than a button on initial render)
two places: authortime and runtime. authortime is slower because build steps slow down iteration speed. (no build is faster than 'no build'.) at runtime …idk… mostly a swipe at React renderToString which is shockingly slow for a toString. you can bench that.
Yeah, conflating React specifics with the general strategy of isomorphism.
well, they're not unique in this. all the SPA frameworks pretending to not be are slower than template strings thats for sure.
Yes, but not by any meaningful measure
what about the SPA frameworks that compile to template strings? also worth acknowledging that the authortime claim is deeply subjective — I don't doubt that it's true for you, but it certainly isn't true for me
hey there's a reason I don't mute you completely ! ;) you are obviously on the right track…
Why I think this is a trap:
extra work for CSP: github.com/ionic-team/ste…
ShadowDOM breaks accessibility: github.com/whatwg/html/is…
you are required to re-implement built-in HTML functionality: github.com/ionic-team/ion…
compatibility issues with frameworks:
Event names are incompatible with Angular templates · Issue #4221 · material-components/material-components-web
I have run across a conflict with the event binding syntax in Angular. It appears to be an issue with the colon in the event names. I know this is more of a concern of Angular, but aside from liste...
github.com
For the context, I spent this summer building a wc-based components library, but could not make it to prod because of the issues mentioned above.
Now, this is wasted work.
More generally, it's not as if we're short on cowpaths to pave. Just cracking open web dev projects provides plenty. Like, how many declarative routing implementations do we need before we get a standard? Complex forms?
I mean — has anyone looked at the innards of a rich text editor recently?
For CSS, I've seen a whole lot of cases that could use support for simpler code management and reuse, that's a lot of what preprocessors solve. Extensibility? Meh.
I'm not sure we can have productive discussions on the future if we don't have some alignment on what the mistakes of the past were.
But I think I'm done with this thread. Today's a good day. A non-psychopath is now president. *hugs* to all.
"HTML improvements have focused on DOM and WC" sounds a lot like saying that other important work (such as adding new built-ins) has been deprioritised to make space, which is exactly what WC-sceptical devs have been concerned about
It's true new elements haven't been arriving as fast as plumbing to explain the old ones, but given what a disaster the HTML5 batch were, this was prudent. Pendulum now swinging the other way (rightly, as anticipated).
What was disastrous about them? Wouldn't a better response have been 'improve the process for introducing new elements' rather than 'abdicating the responsibility to userland'?
A good critique of the process in both cases has been that the WGs have been dysfunctional. Now, nobody involved wants to hear that, but it's true. Houdini is doing for CSS what WC are doing for HTML, and that's good.
Consolidation of good userland ideas into the platform on the back of reasonable extensibility also helps everyone. The EWM was meant as a waypoint, not an end destination. Getting the process fixed means also fixing the input pipeline.
We should all want a big pile of semantically "close" options in a space that explore variants, so that when the WGs sit down to write something into the runtimes, it's a process of consolidation, not invention.
CSS has a lot of unresolved surface syntax consolidation to do; hierarchies, reusable chunks, etc. The backlog from transpilers is still huge.
Anyway, the point is that if you are looking to the chartered WGs to invent the future, rather than to dot i's and cross t's, you will be continually disappointed.
The action is, and should be, mostly in userland, then in Incubations.
Sure — and let's pretend that WCs are the only form of userland implementation going, as though jQuery UI and everything since had never existed. Means nothing if the consolidation doesn't actually happen! By your own account, WCs are sucking up all the oxygen. It's a problem.
Nobody's pretending they're the only form of userland extension going. You know me, you know my history. I might not be the sharpest tool in the box, but I come by these scars honestly.
It *is* a problem that the design input language to the eventual spec is so semantically disjoint, tho.
HTML5 made this mistake: it looked for surface syntax similarities, not deep semantic correspondence. We can do better now, and extensibility helps show how, at the limit.
So, now we have a better design language for proposed extensions.
So propose some! Make custom elements that do exactly what you want and say "it should work like this" to us.
Don't you have enough material already, between the many existing design systems and open-ui.org (not to mention WAI ARIA authoring practices and non-WC component libraries)?
Home
Open UI
open-ui.org
I can't tell you how frustrating it is for people like me to be told, every time we point out ways to improve the platform, 'so go and do the work' — as if its shortcomings are our fault. We're giving you the solutions, and you're not listening.
Sorry, this wasn't meant to discount existing efforts; the work at open-ui is very similar to work we begin in Parkour to explain how some of the built-ins work, and I'm excited to see it. I'm just trying to point out how one can now better phrase these potential additions.
That's an improvement -- as open-ui shows -- and we should all be pushing for HTML to expand on the back of them.
That said, there's a lot of process assumption and antagonism from you that's just not helpful. Happy to advise/discuss in another forum.
Also, if you're looking for moral arc villians (don't recommend it in this space, but to each their own) to explain "why didn't HTML move faster?", let me tell you a little story about two standards houses, the W3C and WHATWG, alike in dignity...
Not looking for villains, and not making assumptions. Just describing the outcomes I see.
Maps should work like this: geogratis.gc.ca/mapml/en/osmti…
1/ I'll use this as a place to rant xd: This may be the view of a young, naive programmer (me) but here I go. I don't enjoy the state of the web right now. I really think the web standard shouldn't be aimed at consumers (front-end devs). The web standard should treated as a
2/ compile target. In my ideal world we would have 3 binary formats. One that describes structure (replacing html), one that describest styling (replacing css) and one that describes logic (replacing js). The last one would be fulfilled by web assembly already. To me, it doesn't
3/ make sense to enforce a standard an all programmers that want to write for the web. That said, html should not be getting consumer facing features like web components. It just doesn't make sense. By trying to make html more complete we're making it harder for frameworks to
4/ compile to html+js (svelte, solidjs) or to wrap js (react, vue, etc). In my perfect world the web standard would be analogous to llvm, for native environments. Right now compiling to the web standard is like compiling rust to java, instead of compiling it to llvm.
You're advocating for wasm.
I guess I am
They don't control Node/Deno. Tho thx to wasm running a DOM isn't that bad now...but you should ask what for. If it's just for toString perhaps that initial state isn't entirely appropriate colocated with client interactivity. (If you care about single responsibility..)
You are correct,
trying to convince people of anything is a fools errand
writing two versions would be annoying if that is what was required
A slot can be filled many ways
Svelte is really slick and I am very happy it exists, but let's be fair here.
What is more energy, using platform primitives as they were intended instead of trying to make them work like React?
Or
writing a compiler with new conventions that abstract web primitives?
the wasted energy i'm talking about is that spent on creating ever more convoluted primitives that never quite catch up to (let alone surpass) what userland has been doing for years, while neglecting things that devs are crying out for (more built-ins)
That is fair.
The new primitives have gotten stranger and stranger, but it made sense when I realized the actual use cases they were satisfying.
Web Components are perfect for authoring 3rd party content ( *cough* Ads )
With that said they are very low friction way to ad interactivity to existing DOM.
Meaning no framework required, no compiler configuration needed, already loaded in browser etc.
I also really appreciate how uncoupled they are from the presentation by default with slots.
As a whole solution they can't touch Svelte.
The DOM manipulation and incremental update abstractions in Svelte are masterful.
But it is possible to make something comparable with Web Components.
The frictionlessness is wonderful, I agree. If they'd been designed just a little bit differently I would probably be a huge advocate for them. Which makes their shortcomings that much harder to bear
I still argue that they design isn't the issue, they work really well.
It's the way they have been marketed.
They are terrible at copying react style components with an embedded "whole hog" template.
They are amazing at progressive enhancement.
100% this. WCs are amazing for progressive enhancement and encapsulation & distribution of components across teams / apps.
They do not even try to replace the complete application framework & shouldn't. But... I believe they are enough for many small use cases standalone though!
WC for me lack the isomorphism I want. That's my only blocker
you can run them on the backend with a lot of hackery but imo react got this right with component.server.js and component.client.js … these runtimes are different and have different constraints. toString is too course.
This was my complaint as well until I rethought my approach.
Web components should never be run on the server.
They should just add interactivity via the slot interface.
My custom elements are free to look however I want and as long as I adhere to the interface they just work.
I understand how that works. I want colocation and write once.
template strings are the backend colo you're looking for. clientside interaction on the backend isn't ever going to make sense. (trivial inert static render use cases aside)
I thought I understood as well.
Put plainly HTMLElement doesn't exist on the server, and imho never should.
You can write one function that always returns a styled HTML string.
yup. the most frequent claims are 'it's good for design systems' and 'you don't need to keep rewriting <Tabs> in new FWs!', but the reality is you have to keep writing <x-tabs> for every new design system instead. Imagine if we had <tabs> and a 'design system' was a .css file
You feel my pain.
There are always going to be designers that create new and interesting takes on tabs though.
We might always need the ability to swap mark-up.
There's also a wide array of other types of components that will never be 'standard' that applications need. I agree we need better customization capability in the existing primitives also but there's always going to be a need for deeper customization and new controls.
If we'd had WCs when HTML5 was being thrashed out, we'd probably never have had useful things like <input type="range">. Totally agree that we will always need to build beyond the platform, but there's so much low hanging fruit in e.g. the WAI ARIA authoring practices
ARIA is a mess.
I am 1000% behind making everything a11y,
but the current solutions are so frustrating to author and require JS in more cases than they should.
Whatever component authoring choice we make ARIA has to continue to improve.
Lol - yeah, this really blew up.
As someone who's been a little on the periphery of the WC/FW discussion, are there some resources that succinctly explain both perspectives? It's hard to offer anything constructive when there are years of hard work and frustration by those intimate with the issues.
this thread 😂
There isn't an alternative other than just do nothing, which is not a real option if you want to improve the web. Most websites suck (including the ones I build). HTML5 has failed. Web components have failed. You either spend energy improving what you have or start from scratch.
I'm totally cool with any of those, just not stopping HTML improvements and wait for frameworks to magically make websites good which they haven't been able to do for the last 15 years.
I'm advocating for standardising CSS scoping and adding built-ins. Where did you get 'stopping HTML improvements and wait for frameworks' from? WCs are the opposite of improving HTML; they're just 'oh they'll solve it in userland'. It's the platform abdicating its responsibility
I feel like the extensible web manifesto gives direction that always makes the platform leave users to solve problems themselves
EWM has the wrong motivation. It seeks to avoid mistakes. If you only work on low-level things you are less likely to make a mistake. It's a miscalculation on their part to place the emphasis here, when what the web really needs is massive usability improvements.
From our many previous discussions on the topic this was my feeling but if I got it wrong that's good! I would love to see those things happen but also wouldn't hold my breath since so many similar solutions have fallen through.
On the other hand CSS scoping is coming from the CSS wg which tends to get things done so I have some hope
Crossing my fingers. It would be a big step forward
They working on nesting too? Damn it'd be nice to not need Sass anymore ...
yeaahhhhhhh
Mixins. Still need mixins (or functions).
We really need to. It's just web development. Not great for marketing or drama but you write code, it works in all browsers and there's no third party code shipping breaking changes and unplanned work. It's great compounding for your investment of time.
Rich. You literally just argued for more spec work on CSS scoping and new platform vendored build-in elements. This is a equally a huge amont of energy to invest, especially when WC are a perfectly valid way of solving this problem as the AOM and Form Participation specs land.
Ping me when we've solved no-JS and WCs inside SVG. If we'd prioritised CSS scoping and widely-used elements we'd likely have never bothered with WCs at all, and the missing pieces I've talked about wouldn't be missing
for everyone <3 this twete I would like to point out that <Form> wrapping <form> *is the same thing*
you don't write <Form><form>...</form></Form>
Is it though? I think the fact WC are DOM elements makes them a completely different thing. `<Form>` is a virtual construct and never needs show in the output. It could be a function call. It has no necessity of being part of how they mechanical function.
no, they're not remotely the same thing — (<Form> wrapping <form>) === (<my-form> wrapping <form>) only if the latter is contained in shadow DOM (i.e. you don't write <form> at the point of usage), which it isn't in brian's case, because that would break progressive enhancement
We completely disagree but the main difference is I'm using this technique in production and have migrated from multiple other paradigms. That's an appeal to authority tho so I reccommend building something for yourself before drawing conclusions.
i understand you are using it in production brian, everyone is very impressed. but you have yet to explain how your <my-form><form>...</form></my-form> is the same as everyone else's <Form>...</Form>, and not akin to clamp(num, min, max, { Math })
i mean, it's so obvious that it barely requires articulating — the ergonomics are just atrocious. it's as if you created a clamp(num, min, max) function and had to pass in the Math builtin as an argument
and believe it or not, i have also built web apps, even including web components! so please drop the condescension and try to engage reasonably. it's exhausting.
sorry but I am not condescending you. you're using your own authority as evidence with frankly totally incorrect conclusions and words like 'frustrating' and 'absurd' with no substantial argument.
I've explained multiple times! Don't think you are listening which is why I'm suggesting you try it out for yourself. Can view source on arc.codes or begin.com (we don't minify or transpile).
And I am not shaming anyone. You aren't your code.
OpenJS Architect documentation
Architect is the quickest way to build serverless web apps on AWS
arc.codes
you've explained what you're _doing_, which is doubling up on elements. that's an interesting and very unusual workaround for the PE drawbacks of WCs, and i would love to hear more! but you haven't explained why this isn't a false equivalency
for everyone <3 this twete I would like to point out that <Form> wrapping <form> *is the same thing*
Similarly, <my-button> would (and should) use a <button>. The benefit is in adding features such as icons, loaders, and other features that _don't_ come with <button>. Nothing leaks in, nothing leaks out, and users get a simple API without boilerplate, e.g.
<my-button loading>
The button example is a bit contrived, but the idea is you can build on top of what HTML provides in a safe, reusable way. Not sure why that's such a controversial thing. 🤷🏻♂️
First off, I'd ideally want <my-button> to _extend_ <button>, but that can't happen because Safari (justifiably) killed is="button". But even without that, I want the <button> to exist in shadow DOM, not light DOM — that's what I mean by encapsulating implementation details.
But that results in something that doesn't work without JS! (Unfortunately, this applies to <sl-button>.) Instead, if you want PE you have to write (or generate) this HTML:
<my-button>
<button>...</button>
</my-button>
yes, you're close! so! what's wrong with wrapping an element for PE ?
ask cory, who maintains a WC library that doesn't expect you to do that. or the maintainers of literally every WC library that has its own styled button.
or, like, every single web developer that isn't you. i guarantee you are in a very small minority here!
ah, neat, so I must be wrong! ;)
i should have expected the 'everyone disagrees with me therefore i'm right' response 🤷♂️
I 'm waiting for an argument that isn't a logical fallacy and not hearing it.
i mean, it's so obvious that it barely requires articulating — the ergonomics are just atrocious. it's as if you created a clamp(num, min, max) function and had to pass in the Math builtin as an argument
just shy of an ad hominem attack (clearly I am able to understand things so please do articulate)
sorry not following! (I am in this convo in good faith)
these things are not equivalent:
<my-form>
<form>
<!-- contents -->
</form>
</my-form>
<Form>
<!-- contents -->
</Form>
that earlier tweet made me think perhaps you *weren't* manually adding <form>, but the more recent ones suggest otherwise
the latter <Form> does not work in any browsers I'm aware of; but it would desugars to the former once it renders/etc
it would more likely desugar to <form>
right that's what I'm sayin
Right. This.
So if <Form> is a third party lib you grab on npm, built for Svelte, React, Vue, etc.
You can just ... *use it*
If it's
<fancy-form>
then you can't just use it. You need some bespoke build step to ram an old-school <form> inside of it.
we do not have a build step; thx for playing
So you put the old-school <form> tag inside of <fancy-form> ... manually? That's honestly worse.
So this PE takes advantage of the fact that since JS is disabled the browser will just "ignore" the WC tag and render what's inside?
What if I want to use the default slot in my WC? I now have a problem if JS is enabled. This feels super hacky.
I guess you have to name the slots then and leave the default open? - but yeah, fallback content is already as you say, hacky. Eventually of course you might formalize this practice and now you have a "framework", albeit an inferior one. 🤷♂️
why can't we just change the semantic meaning of a web-component? Could it be possible in the future?
I personally don't agree with wrapping buttons/inputs, and I'll accept that point in terms of PE/no JavaScript. But I don't think we should throw our hands up in the air and walk out of the room over it. There's something useful here...let's figure out how to make it _better_.
Point taken. I agree that it should extend, but I was never a fan of `is` either. Still, we have to start somewhere and I think it's worth continuing to explore.
i hear that a lot from WC advocates! often begins with 'your criticisms are unfounded', then when dialog reveals them to be perfectly well-founded, it moves to 'ok you're right, but it'll be fixed when X happens, let's keep iterating'. we're iterating on the wrong things!
I'm genuinely curious as to what we _should_ be iterating on. Maybe a declarative way to extend HTML? How else can we achieve what WCs give us without JavaScript?
FWIW I don't think web components are perfect by any means. There ARE shortcomings that I'd love to see improved and fixed. But to me, it's still an exciting idea that's absolutely worth exploring.
this tweet probably sums up my position best — we need CSS scoping (that works without JS), and more built-in elements
yup. the most frequent claims are 'it's good for design systems' and 'you don't need to keep rewriting <Tabs> in new FWs!', but the reality is you have to keep writing <x-tabs> for every new design system instead. Imagine if we had <tabs> and a 'design system' was a .css file
I'd support this, except I don't have confidence in browsers to let me style complex elements like that. I still have to use vendor prefixes for <input type="range">. I doubt they'll be able to agree on something as complex as tabs, nor provide the features/variations I'd expect.
That's true, browsers don't have a good track record. I think they're painfully aware of that, and styleability would be top of mind were we to try and invent new elements. That said, some level of consistency (i.e. a radio button always looks like a radio button) does help users
This is a good step in the right direction: open-ui.org
Part of WCIG:
WICG/open-ui
Maintain an open standard for UI and promote its adherence and adoption. - WICG/open-ui
github.com
Regardless of the WC discussion, I very much would like to see css scoping and better built-in elements (in terms of ux, styling and a11y).
I'm very invested in the old school web. Same arguments were being made back then too, against jQuery (of all things).
Yes I am too and you're right about that. I just mean there's some high profile neo-luddites who made a lot of progress 15-20 years ago but who refuse to see the validity in anything other than "HTML is a document!"
Beginners should get gentle feedback & tons of encouragement because woohoo, they are doing great just to be here, hello beginners 👋. For pros, a11y knowledge (or lack of it) controls who is able to use the site. That’s a bigger responsibility than people seem to think.
100%. And a11y knowledge has nothing to do with which FW you use
You’re right, I think I got sidetracked by @swyx’s comment about “closet gatekeeping”. Like, the core HTML knowledge to not exclude disabled people from content is a gate worth keeping imo, at the professional level. Totally agree that FWs don’t inherently impede accessibility.
- shadow dom of which purpose is encapsulation
- some folk tries shadow dom
- puts a label into
- label is being encapsulated
- folk cries about label that is encapsulated
Fail.
- If you want your label to be accessible, why put it in shadow dom, put it outside?
- want framework like behaviour? well, one can use custom element without shadow dom and your <fancy-element> will be accessible inside
- there are still a few options, like aria tags and roles
It's kinda weird when people talk about standards and mention web components, a term which is not even mentioned in the specs.
maybe it would to make use of the actual specs:
- custom elements
- templates
- shadow dom
- etc.
they can be used separately, but hey 🤫
i wrote a web component compiler, but thanks for this useful information
I'm aware of this, and actually I often refer to your talk about reactivity, which I really love.
So you have a huge impact on the community and people listen and follow you (as I do).
Said that, I think it's kinda wrong to just say
"WC breaks a11y" without actual context :/
the context is literally in the quoted tweet!
yes, but still, if a dev <encapsulate> an input and build a custom wrapper around it, then its the dev's responsibility to provide semantics for screen reader.
If the goal was just a <custom-input>, then why shadow dom?
There's a faulty reasoning
we can blame devs, or we can provide them with fewer footguns
suuuurrrreeeee, so now everyone has to learn these incredibly nuanced details on top of the existing teetering pile of stuff in order to achieve basic a11y, something at which the vast majority of devs are already struggling. great plan
If you're using a component driven framework, you will sooner or later have to deal with aria tags / roles.
It starts by creating a simple <my-checkbox> which consists of a div with some background.
You will have to do some preparation, so screen reader can understand the markup
Also, if people would talk more often about "custom elements" (which is almost always the intent) and not web components, I think they wouldn't directly try everything with shadow dom, which is not necessary every time
Just ONE example, how component driven frameworks deal with accessibility.
Anyway. If you would have read the complete conversation, you would realize that I'm asking exactly the same questions.
yes, but still, if a dev <encapsulate> an input and build a custom wrapper around it, then its the dev's responsibility to provide semantics for screen reader.
If the goal was just a <custom-input>, then why shadow dom?
There's a faulty reasoning
we can blame devs, or we can provide them with fewer footguns
If you don't want to play around with shadow-dom, then just don't do it.
If want you to compare framework components like react and angular, then do it with custom-elements and don't involve shadow-dom. These are two separate features.
Talk about "disingenuous arguments".
WC != ShadowDOM
In fact, the only time I've ever coded a WC to use the ShadowDOM, the product never used that part of the library.
And, personally, I've never run across an a11y issue with WCs (inherent to WCs/vanilla js, at least).
oh good, the deliberate misunderstanders have logged on
Depending on the take here, you're either 11 hours, or 2 years late on that accusation. But I suppose a solid callout is better late than never.
So when you're done misunderstanding (or misrepresenting) WCs, feel free to speak on the value your lib provides that WCs don't.
(Personally, I'd go with "DX". That's all the rage these days. And Svelte surely does provide a great DX! Not as good as some smaller, more performant libs, but a great, and industry leading DX nonetheless!)
sorry I have better things to do than feed trolls
Sure seems like it.
Regardless, I'm a dev. An FE dev with plenty of industry experience. You're misrepresenting WCs because you think that helps make your point that frameworks are the better way to do FE dev. No matter how much I agree with the point, your complaint is obtuse.
oh, you think WCs and FWs are in opposition somehow? you must have missed the WC advocacy memo
I have no idea how you could understand what I wrote as "WCs and FW are in opposition".
But anything to avoid admitting an overreach, I guess!
You know he always has this kind of replies when his straw mans are attacked, right? I've been following his work for a couple years now and it's always the same.
Oh but don't you dare to point out issues with svelte.
Pre- React.Fragment I think it was a valid complaint. It's still _sometimes_ a valid complaint with the ugly APIs required to add an aspect to an element (e.g. add an onFocus handler without clobbering others), such that libraries use a wrapper div instead. But that's edge case.
Yeah but Vue 3 for example isn't that old yet. And in Vue 2 normal components (non-functional) require a single root node as well.
(Angular "solves" it by rendering the component name itself as root, e.g. <data-table>, which can break CSS and is annoying as hell...)
That said, replacing a div with a Fragment does not in any way make it *more* accessible or anything. It's just removing an extra layer you see in DevTools, but it's not actually any more "semantic".
What is divitis?
I think it's when a dev uses too many divs for markups
<dothey/>
Where I work there seems to be an issue with button web components having issues submitting forms. I want to like/use them, but it seems like a bit of a dealbreaker at this point for me
I think there's been some work on making web components work with forms.
Ah this is really nice, thanks, I'll pass it on to some colleagues who may be interested
The trigger word in your post was 'seems' .. used twice.. So you imply you don't know the answer. What issue do you experience? Post a question on StackOverflow and you are bound to get a definite answer if the 'seemingly issue' really is an issue
We have 12k devs here and it's really on the advocates of WCs within the org to resolve the issues that they've described.
Here's a shocking fact for you — did you know that just like React components, Vue components, or Twig template partials, web components are also made of *gasp* divs and spans and other normal HTML elements? 😱
Such a weird argument 🙄
WebComponents are always adding _more_ to the DOM, as they also include the host component and a shadowDOM instead of the div they "saved". Some libs such as lit-html / lit-element also add a ton of comment nodes as placeholders.
everything is a div, cough* box
But if you look long enough, you see the truth: there is no div, the div is your mind diving
I understand (and mostly agree on) all the points in this thread, but, I can't help but think of all the people of @w3c and browser vendors, years spent to design/implement this technology. Is it really that bad and useless?
I am hoping our work on @ChromeDevTools can give an interesting perspective of the unique value of web components. Migrating away from a large legacy component framework that was not testable makes WCs shine.
FWIW that doesn't mean other solutions aren't valuable on their own.
Sorry if I'm misunderstanding—web components seemingly aim to solve many problems, but semantics feels orthogonal 🤷♂️ in other words, isn't div-itis as much a concern with web components as it is with JS frameworks?
Hey! I assume there were one or more Tweets or other triggers for this. Would you mind pointing them out? By DM is fine if you'd prefer.
People tend to get their pride wrapped up in methods/utilities they use and double down.. even if they're wrong. 🤷♂️
More importantly, people should understand.. Better tools do not mean better results. You can still paint a shitty picture with a good brush.
I assume this is reference to the recent Tailwind article where the author is extremely nasty and unfair...
this is one of the only arguments against @tailwindcss I’ve accepted simply because I have yet to learn WC, but it sounds like even this argument is built on shaky ground