Used Windows since forever because "it just worked for me". Last year switched to Fedora + Plasma, as I started to consider staying on windows was risky.
The feedback/forum tool, has been a thing for years. Submited many bugs that I wanted fixed, and always been ignored.
> The feedback/forum tool, has been a thing for years. Submited many bugs that I wanted fixed, and always been ignored.
Just like the dialog that searched for a solution to why my program just crashed. Of all the times I saw that (maybe every other day), it found something precisely 0 times, but wasted my time every time.
What they are doing is backing in the browser, via specifications and proposals to the platform, their ideas of a framework. They are using their influence in browser makers to get away in implementing all of this experiments.
Web Components are presented as a solution, when a solution for glitch-free-UI is a collaboration of the mechanics of state and presentation.
Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.
Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.
On the other hand, you have the Web Component Group, and they wont listen, they claim you are free to participate only to be shushed away by they agreeing to disagree with you and basically dictating their view on how things should be by implementing it in the browser. Its a conflict of interest.
This has the downside that affects everyone, even their non-users. Because articles like this sell it as a panacea, when in reality it so complex and makes so many assumptions that WC barely work with libraries and frameworks.
> Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.
You could say the same about the DOM itself. That’s why frameworks were created in the first place. The Custom Element API is complex. The DOM is complex. It’s just that we’re used to the latter and not the former.
I love web components, but the fact that there's plenty of shadow-dom piercing properties defeats their purpose of "author them once, reuse them in different applications".
One very common pitfall I encounter is the html's own base font size, since it impacts all the calculations in your webcomponents. Use a webcomponent with a font size of 12/14/16 and you get completely different behavior.
If they were truly isolated they would really scale, but they don't.
Not to nag, but this seems like a design error? WC font settings should be inherited and relative, rather than any specific pixel size. Designs should be robust enough to support overflowing text, should the user increase scale/zoom/etc.
Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.
I agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing and perhaps the most valuable ideas ( custom elements and ES modules ), were those which did have the biggest precedence.
> Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.
This feels a bit deflective from the very real issue of in page framework interoperability - which is different from dev's taking to each other and sharing ideas.
When people say battle tested what they are really doing is looking for bias confirmation. Its no different than when they say software becomes more durable due to community validation.
The only way to be sure is to actually measure things, with numbers, and then compare those numbers to some established baseline. Otherwise its just a guess. The more confident the guess becomes the less probable from the average it becomes. This is how rats out perform humans in weighted accuracy tests in clinical trials.
Not sure what you mean - are you asking number of users, length of time etc?
All I'm saying with this is that ideas which have actually been implemented, used and evolved, are much less likely to have rough edges than something that's never left a whiteboard or spec document. I wasn't expecting that to be controversial.
This stuff is difficult - if I remember correctly the original web components vision was a completely self-contained package of everything - that didn't survive contact with reality - however the things like custom-elements, templating and ES modules are, in my view at least, very useful - and I'd argue they are also the things that had the most precedents - because they were solving real world problems.
That is an irrational comparison. There is no comparison between components and something imaginary or theoretical. The comparison is between components and not imposing components into the standards, which are both well known conditions.
People don't need components. They want components because that is the convention familiar to them. This is how JavaScript got classes. Everybody knew it is a really bad idea to put that into the standards and that classes blow out complexity, but the noise was loud enough that they made it in for no utility reason.
The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.
We can argue about whether components as proposed was the right solution, but are you arguing that templates, custom elements and modules have no utility?
Templating, for example, has been implemented in one form or another countless times - the idea that people don't need that seems odd.
Same goes for a js module system, same goes for hiding markup soup behind a custom element.
There was an initial proposal called web components that comprised a whole slew of enabling technologies - like custom elements, like modules, templates etc. Some of the proposals never got implemented.
The closest single thing to web components is custom-elements ( with optional shadow dom and optional slots ).
That completely misses the point. You are mistaking your preference for some objective, though unmeasured, benefit.
I could understand an argument from ignorance fallacy wherein your preference is superior to every other alternative because any alternative is unknown to you. But instead, you are saying there is only way one of doing things, components/modularity/templates, and this is the best of that one way's variations, which is just a straw man.
You really aren't limited to doing this work the React way, or any framework way. If you want to continue doing it the React way then just continue to use React, which continues to evolve its own flavor.
> But instead, you are saying there is only way one of doing things,
Nope. I did not say there is only one way of doing things. I asked you whether you really thought people didn't want improved modularity, encapsulation, reusability, interop.
For example without standardised modules you either had to choose one of several community module systems or live with poor modularity and encapsulation. And by standardising modules interop improves.
> If you want to continue doing it the React way then just continue to use React,
Only one of us is appearing to want to stop the way the other only likes to develop. If I want to use custom elements why all the anger?
> agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing
What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.
Read my comment again. I literally said that various parts had various levels of precedents - and that the more successful parts were those with stronger precedents.
> Literally nothing in Web Components was ever battle-tested before release.
So you don't thing the ideas of modules or templates had had multiple precedents?
Totally agree that some aspects had much less precedent - and that's why, in the end, they either didn't get implemented or haven't got much traction.
Web components are just a way for developers to build their own HTML elements. They're only a "framework" in as much as the browser is already a framework that wires together the built-in HTML elements.
I don't see any reason to lock away the ability to make nodes that participate in the DOM tree to built-in components only. Every other GUI framework in the world allows developers to make their own nodes, why shouldn't the web?
> too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Do you have any concrete examples there? What "mechanics" are you referring to. Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
With your other specific complaints about the community, I think I can guess you are. That person come into our discord server, was so mean and rude to everyone that they had to be told by multiple people to chill out. Had one very specific proposal that when multiple people thought it was a bad idea, threw a fit and said we never listen. You can't just come into a place and behave badly and then blame the community for rejecting you.
> Do you have any concrete examples there? What "mechanics" are you referring to
Try the 2022 Web Components Group Report. Including things like "most these issues come from Shadow DOM".
> Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
Trillion dollar corporations also build sites in Angular, or React, or Blazor, or...
So you're deflecting from the original point raised.
Anyway, yes. Web Component "community" was fully and willfully ignoring most issues that people (especially framework authors) were talking about for years.
At one point they managed to produce a single report (very suspiciously close to what people like Rich Harris had been talking about since at least three years prior for which he got nothing but vile and bile from main people in the "community"), and then it went nowhere.
> I still don't know what "mechanics and assumptions" are baked according to the OP.
Again: you do, people who wrote the report do, but you all keep pretending that all is sunshine and unicorns in the web component land.
While the report very explicitly calls out a very major behaviour baked in, for example. And calls out a bunch of other issues with behaviours and mechanics. While web components need 20+ specs to barely fix just some of the assumptions and baked in mechanics (that literally nothing else needs, and most of which exist only due to web components themselves).
Anyway, I know you will keep pretending and deflecting, so I stop my participation in this thread.
We have been using the isolation stuff in Web Components to make React applications that our partners can embed in web pages regardless of what other CSS and JS they use. I don’t know if I’d want to make an application with 100 tiny web components at the level of individual buttons and such that work together but self-contained widgets that pop into a web page look great to me.
We basically tried wrapping an entire registration app into the Shadow DOM just for a hopeful kick but it came with weird accessibility quirks, arrow keys not always working to go through selections, and some overlays acting strangely. We were using Shadcn which is powered by Radix Primitives, however, and a setup they probably weren't expecting or testing their code to be in.
But for smaller things like chat widgets or players I think it's a great solution.
We had overlay problems with a fancy <Select> control, also systems like Emotion can have trouble, or anything that is portalized or computes coordinates for absolute positioning. We were able to fix all the ones that affected us.
Funny we have been using the HTML <dialog> because you can't really pass accessibility reviews if you use the modal dialogs that come with MUI, Reactstrap, etc. Only <dialog> really inerts the whole page but you run into very similar problems getting components to work properly inside them which we were able to solve for all the components we use inside dialogs, but I think it's an absolute shame that this has not been adopted by MUI or anything I can find in npm -- what I hate about accessibility is that I feel like I'm held accountable and my organization is held accountable but not the people who write trash specs, make trash screen readers that crash my computer, vendors of React components, etc.
Wow, this is a weird a comment. Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks. Is the Illuminati behind this? I kid, but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable. It's quite a bit different than the fluidness of a JS framework.
This discussion comes up all the time and I always have the same response: not everyone needs a full-on framework for what they're doing. They also may need to share that code with other teams using other frameworks or even third parties. The post even mentions that web components may not be a good fit for you.
> Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks.
Yes. There is. The main developers and proselityzers were completely insanely biased against web frameworks (especially React).
It wasn't even a conspiracy. All you had to do was to follow Alex Russel (the person who introduced the idea of web components in the first place) and see his interactions with framework authors and his views towards web frameworks.
The new people in the space driving the specs are hardly any better. E.g. their reactions to Ryan Carniato's rather mild criticism of Web Components is just filled with vile, bile, and hate.
They literally refuse to even admit they have a problem, or want to look at any other solutions than the ones they cook up.
> but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable.
Strange, browsers push dozens of specs for web components without ever taking any time to see if the yet another half-baked "solution" is actually workable.
Some links to examples of the sort of behaviour you're describing would be really helpful here (I say this as someone who is sympathetic - I work with on a web component/Lit codebase in my 9-5 and I'm not a fan, compared to the React workflow I had in a past life).
Unfortunately, as most of them left Twitter they also temoved all their accounts, so you can only see responses from framework authors like Rich Harris.
Web components are a trend? I've been using them for close to 10 years and they're still not anywhere close to mainstream. Loudly as possible? They've quietly just kind of been there for years.
I think we have a generation of developers that only know React and they're so engrained with it they simply cannot imagine a world without it. If you really can't find a use case for web components then you're living in a bubble.
We have been through all this before with jQuery. The generation of JavaScript developers at the beginning on React only knew jQuery and they really wanted to shoehorn all the jQuery nonsense into the standards. From their perspective it makes complete sense because that is the only one way to do things. They got querySelectors into the DOM.
Now we are seeing the exact same thing again. People only know React, so they want the standards to look like the only one thing they know. That doesn't make it a good idea. Every time this comes up we exchange simplicity and performance for easiness and temporary emotional comfort. Its only a temporary win until the next generational trend comes along.
> If you really can't find a use case for web components then you're living in a bubble.
There's a very tiny use-case for web components. And even there it's riddled with a huge amount of potential (and actual) footguns that "in the bubble" devs have been talking about for a decade at this point, and some which were finally acknowledged: https://w3c.github.io/webcomponents-cg/2022.html (no updates since)
> There's a very tiny use-case for web components.
That's weird, we've been using them at my company for a number of years and there's plenty of other examples of them being adopted elsewhere too. This continues to read as, "it's not React, so it's bad."
There are companies that still use jQuery, or Angular, or Ember, or vanilla JS, or Blazor, or...
Just because tech exists and is usable doesn't mean it doesn't have a list of issues and footguns a mile long, some of which are explicitly recognized by the Web Components Working Group. And which still need 20+ various specs to paper over.
> Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Does not line up with my experience (the past 8 years or so of working with native web components, Polymr and the Lit library) at all. You can build staggeringly complex views using nothing but web components, I’ve done it, I am doing it, and inshallah I will keep doing it.
What in particular do you believe web components are unusable for? What do you count as crossing the line into ‘slight complexity?’
Yes Microsoft DHTML and behaviors were this and represented tremendous lock-in. Plus, they were terrible. Those who don’t know their history are truly doomed to repeat it.
Yep, `lit` is contaminating the browser API with their ideas just because their group of people writes the code for the browsers. They should be competing from the outside. Instead of pushing this kind of apis that only fit their mental models.
SolidJS and dom-expressions are the best things that have happened in the front-end since React, it is influencing the whole ecosystem, from templating to Signals. It will be very, very hard to come up with better ideas, it may not be that popular, but it's leading the way.
Made this table listing the typings used by SolidJS, Voby, Vue, Preact, React, Pota, VSCode-LSP and Chrome, for easily comparing type definitions between frameworks and the browser.
Note: There are a few inaccuracies, like the `<audio>` tag not including typings, that's because extended interfaces aren't resolved, but _most_ of the stuff is there.
In an all honest reply, is that the people that writes these specifications, live disconnected from the reality, they don't use the stuff they specify. That stuff works for very simple things, but then when your forms evolve you realise you will be better off just writing the whole thing yourself.
This. Doing relatively common things like cross-referencing from other fields ("did the user specify a country? If so, we can validate the postcode/zip code they just entered, but if not we'll have to wait until they pick a country") almost immediately require JS to handle, and as soon as you're using JS then it's all just easier to do in code than trying to mess around with validation properties.
Yep. This is great until you need a cross-browser date picker, at which point you need to implement a bunch of stuff yourself. It’s frustrating how primitive HTML forms are, after so many years.
What's hilarious is they do have UI for it in about:config "dom.forms.datetime.timepicker". It makes me so angry that it's not on by default. It works fine!
That you’re correctly using html forms won’t quickly lead to browser improvements.. so the result is that users will hate your forms.
Users/your customer might possibly even think that you’re to blame, and not $browserVendor.
I’ll go one further and say that the customers are absolutely justified to blame the developer instead of the browser. If a developer knowingly chooses a built-in form control whose common implementations are bad for their users, how are they not at fault for the resulting experience?
“This site only uses functionality provided by the HTML spec” is not a useful goal in and of itself. Using the right tool for the job, which might be JavaScript, is always more important.
The `required` attribute, which this article is about, is an HTML5 thing and first appeared in browsers in 2010-2011. So sure, not brand spanking new, but the web was already used to write modern apps. There's no good reason for the validation features to be so shabby.
Even 'required' doesn't work properly. Browsers do very odd and inconsistent things when your required field is hidden when submitting. Like in a basic tabbed or multi-step form.
It tries to fetch a sitemap for in case there's some missing link. But it starts from the root and crawls internal links. There's a new mode added this morning for spa with the option `--spa` that will write the original HTML instead of the generated/rendered one. That way some apps _will_ work better.
It saves the generated/rendered html, but I have just added a `spa` mode, that will save the original HTML without modifications. This makes most simple web app work.
I have also updated the local server for fetching from origin missing resources. For example, a webapp may load some JS modules only when you click buttons or links, when that happens and the requested file is not on the zip, it will fetch it from origin and update the zip. So mostly you can back up an SPA by crawling it first and then using it for a bit for fetching the missing resources/modules.
My main use case is that the docs site https://pota.quack.uy/ , Google cannot index it properly. On here https://www.google.com/search?q=site%3Apota.quack.uy you will see some tiles/descriptions won't match what the content of the page is about. As the full site is rendered client side, via JavaScript, I can just crawl myself and save the html output to actual files. Then, I can serve that content with nginx or any other web server without having to do the expensive thing of SSR via nodejs. Not to mention, that being able to do SSR with modern JavaScript frameworks is not trivial, and requires engineering time.
I’m not quite understanding: you’re saying you deploy your site one way, then crawl it, then redeploy it via the zipfile you created? And why is SSR relevant to the discussion?
Modern websites execute JavaScript that render DOM nodes that are displayed on the browser.
For example if you look at this site on the browser https://pota.quack.uy/ and do `curl https://pota.quack.uy/` do you see any of the text that is rendered in the browser as output of the curl command?
You don't, because curl doesn't execute JavaScript, and that text comes from JavaScript. One way to fix this problem, is by having a Node.js instance running that does SSR, so when your curl command connects to the server, a node instance executes JavaScript that is streamed/served to curl. (node is running a web server)
Another way, without having to execute JavaScript in the server is to crawl yourself, let's say in localhost, (you do not even need to deploy) then upload the result to a web server that could serve the files.
The feedback/forum tool, has been a thing for years. Submited many bugs that I wanted fixed, and always been ignored.
Thanks, but Im not looking back.
reply