Fragility of progress
This article concerns Web Components, Mozilla, Google and something GitHub created called Catalyst touching on ideas and that sometimes pride can get in the way of good things.
Catalyst is something released by GitHub that is their vanilla JavaScript library of good patterns to make web components more easily. They themselves use it to make the UI of GitHub. This got me thinking on Web Components again and recently I took the journey to whatever happened to the rel=import in HTML <link> tag.
Web Components
This idea started a while back already, maybe around six years ago or so. The idea that you would be able to create custom elements (tags) in HTML with their own scoped CSS and JavaScript in so called Shadow DOM so you could better create reusable components and complex UIs with modern paradigms. Also making HTML carry more of the load and since it should be responsible for structure this is a good move to make.
This all sounds great, we currently have a bunch of them; Shadow DOM, Custom Elements and templates and slots. I won't go into too much detail concerning these but one thing is missing from this and Google thought of it.
Imports
Being able to import HTML files into your current web page that holds all those custom elements code would be amazing. Google thought of this, and implemented it. It even made a framework around it, Polymer. It moved too fast though. Other vendors, at the time Microsoft and Mozilla did not want to implement it. Seemingly it was because Microsoft could not implement it for Internet Explorer and Edge was quite a long ways away. Mozilla just did not want to because it found that imports were already solved by ES modules that you could import. You can read about that here. Note that Google abandoned it in version 73 that is from 2019-03-12. So not that long ago.
Modules
These days you can make so called modules and they can relatively import each other. The caveat is that is done with JavaScript only. It is true that part of making it work with custom elements is JavaScript but the main part are the <template> and <slot> tags that make them work. So this would mean you can currently put the code in modules and still have to have the HTML strewn about.
Broken ideas
So currently we have a broken idea, that will never be implemented because Mozilla is too egotistical. The idea is a good idea, even though it came from your competitor does not make the idea any less viable. I am with Mozilla, I do not like Google on the whole either and I am very happy Mozilla stays in the browser war fight. I use Firefox to type this article currently, and it is my preferred browser by far for a long time already. Still this idea looked so cool and still looks like such a boon to Web development on the whole. The source of an idea does not affect the idea. It does affect how it will be received, conveyed and communicated though.
New Framework
I also followed this CommitStrip comic, I have a cool idea for a framework though.
First let me say this problem can be fixed server side for sure. Just like HTML templates exist there for MVC frameworks you can include and load and do things there that will substitute the need for the rel=import, however that implies you need an application server again to support this. I think it is stronger to have the browser be able to do this. Therefore, I propose the following.
Have an entrypoint in a normal <script> tag that sets some data. Or load it in an index.mjs, just one entrypoint. The entrypoint will use a single method of the framework feeding a config object that will download the html files and inject them into the page. Setting up all the Custom Elements for you, bringing the rel=import back into the browser.
In all seriousness, I wish Mozilla and Google would reconcile and implement this.