After so much hype,
After so much excitement,
After so many buzzwords,
After months and years of waiting for the next React major...
And congrats to React for delivering some much ballyhoo'd features...
...But what they did not deliver was HTML support.
For five years now, there's been a concerted, multilateral push to bring React into line with every other major framework on custom elements, enshrined in the HTML and DOM specs for years now. Much effort was spent both in public and behind the scenes to encourage the React core team to implement real support for the standards.
But then the PRs were closed, or ignored without public comment. And the issues languished. And the hopeful indications of a willingness to play ball with the rest of the web community grew stale and limp.
We, developers that want to write components that work in any frontend stack, were really hopeful that React 17 would deliver, but React is still the Safari iOS of front-end frameworks.
What's not new in React 18? What will probably not be new in React 19? A serious commitment to first-class support for the full range of the HTML and DOM specifications. It's not like the React engineers don't know how to do this. Preact's had it for years, and at smaller bundle sizes with better runtime performance, yet. No one wants to take away your functional API or your fantastic ecosystem, we can have it all while still playing nice with the broader industry.
import { Fragment } from 'preact';
import { useState } from 'preact/hooks';
import '@apollo-elements/components/apollo-client';
import '@apollo-elements-demos/spacex-launches';
export const LaunchesDemo = ({ limit = 10 }) => {
const [{ missionName, id }, setSelectedLaunch] = useState({});
const [launches, setLaunches] = useState([]);
return (
<Fragment>
<apollo-client uri="https://api.spacex.land/graphql">
<spacex-launches
limit={limit}
onselected-launch-changed={({ detail }) => setSelectedLaunch(detail)}
onlaunches-changed={({ detail }) => setLaunches(detail)}
></spacex-launches>
<p>From {launches.length} launches, you selected {missionName || 'nothing'}.</p>
</apollo-client>
</Fragment>
);
};
import React, { createRef, useState, useEffect } from "react";
import '@apollo-elements/components/apollo-client';
import "@apollo-elements-demos/spacex-launches";
export const LaunchesDemo = ({ limit }) => {
const launchesRef = createRef(null);
const launchRef = createRef(null);
const [{ missionName, id }, setSelectedLaunch] = useState({});
const [launches, setLaunches] = useState([]);
useEffect(() => {
launchesRef.current.addEventListener("launches-changed", ({ detail }) => setLaunches(detail));
launchesRef.current.addEventListener("selected-launch-changed", ({ detail }) => setSelectedLaunch(detail));
}, [launchesRef.current]);
useEffect(() => {
launchesRef.current.limit = limit;
}, [limit]);
return (
<React.Fragment>
<apollo-client uri="https://api.spacex.land/graphql">
<spacex-launches ref={launchesRef}></spacex-launches>
<p>From {launches.length} launches, you selected {missionName || "nothing"}.</p>
</apollo-client>
</React.Fragment>
);
};
Facebook can do this
Facebook's engineers are world-class; surely they have the skills to support the DOM standard. Enough of the excuses, come and join us at the table. Facebook can do this. But do they want to do it?
The broader open web community has, for their part, bent over backwards to pick up the React team's slack; writing workaround, after hack, after bodge. The rest of the web has cut their losses, it seems. A shame for all of us, but especially for React users.
The Future of the Web
For the seemingly overwhelming crush of developers and recruiters who have convinced themselves that React and VDOM is The One True Component Model™️, I'm deeply concerned that the cruft crisis will hit your shores sooner than you think. I can still point to startups struggling with their legacy angularjs codebases, unable to move forward, and lacking the resources or will for The Big Rewrite.
Compare that to web standards: HTML is 28 years old and still hasn't ever broken backwards. At the risk of invoking a meme, go load up the Space Jam homepage from 1996 in your evergreen browser and bask in the glory of <table> layouts and image maps, still happily running three decades hence.
HTML and the DOM are the bedrock foundations of the web. They're critical, non-negotiable, and even if not perfect (they aren't), they're not going anywhere. We, as web developers of all stripes, committed to any framework or none, should rally together to fight the real struggle: protecting and nurturing the open web that gave us our livelihoods, to keep it relevant and vibrant into the next decades.
Meanwhile, on the actual web, web components adoption is spreading like wildfire. Developers, don't get left behind! Build that design system using a web component base class or a functional web component library, and export React components automatically with one of the reactify-ing workarounds. Your users across all frameworks will thank you, and you'll be glad you did when it comes time to handle the next big hype cycle.
We can't wait to welcome React back into the fold, but increasingly we've been asking ourselves if they even want to be there with us. My biggest hope in writing this is to be proven wrong by a meaningful commitment from Facebook.
Top comments (27)
Currently working on a thing that creates React wrappers around my custom elements, based on a Custom Elements Manifest, and I just cant help but think how absolutely ass backwards and ridiculous this all is.
The next time I see someone say web components require so much code and boilerplate, I'm gonna point them to some of the hacks/hoops I had to jump through just to get HTML support in React.
I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
I dunno, are they really bigger or do they just have a louder bark? 🤔
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
It's not either-or. There are many web component libraries with an FP flavour:
Just off the top of my head.
Web Components !== OOP
You don't have to give up your functional programming style to use web components!
More importantly:
React isn't the only functional UI framework
Preact works just fine with the DOM and has for years.
OP is about web compat, not flaming FP or OOP styles.
Stencil already supports the WC <> React wrapper out of the box. Check it out here:
github.com/ionic-team/stencil-ds-o...
It‘s quite simple to set it up & thanks to the engrained usage of TS it can be fully autogenerated
Its nice that Stencil supports this, and that with Custom Elements Manifest we can create this for other libraries, too, but its ridiculous we need to resort to this kind of thing in the first place. If React would just support HTML, we wouldnt need to use these workarounds.
It's definitely pathetic, especially considering the mountains of money moving through Menlo Park
Did you end up publishing this?
Yeah, bit experimental still, but here it is: npmjs.com/package/cem-plugin-reactify
I'm all for it as a React dev I hate that they don't respect standards all I want is write HTML elements, same way I hate that Apple don't respect browser standards and openly hates the web and is trying to make the web experience as bad as possible so users download apps.
Use your voice, @ivanjeremic
Does React have a future?
The very interesting truth is Facebook has no Browser,
and is not a core member of the WHATWG.
And since 2019, the WHATWG;
read: Google, Apple, Microsoft , Mozilla are in control of what runs in the Browser;
when the W3C handed them the keys: techxplore.com/news/2019-06-w3c-wh...
The WHATWG is by-invitation-only;
will Google, Apple, Microsoft and Mozilla invite Facebook?
Is React the new Flash?
Just to note that Facebook started contributing to the Web API:
Whether or not that means that the fundamental tension between Facebook and the web is shifting - I don't know … but I somehow doubt it. It's more likely a feature that has a particularly high value from React's perspective to make it worth the effort to contribute.
A Different Kind of War
Modern Web Development
The Web of Native Apps II: Google and Facebook
Great blogs, but... techies only look at technology.
Sure, I am a techie too, and bashed React in my latest Dev.to post.
But foremost, in the WHATWG, and effectivly on Web Components,
I see 4 companies working together. And getting better at it, every feature...
Something the like I have never seen in my 31 Internet years.
If you follow the WICG discussions, do not only read the what,
read between the lines, how engineers from those 4 companies, communicate.
You can't but wonder... would this cooperation have been possible with Jobs at the helm...
Now it is up to Google to stop pushing their developments, and focus on joint efforts only.
AMP should have been a good learning Lit (in its current its-a-Google-party form) has no future.
We want a good BaseClass in the Browser, not one we have to load.
🛎🛎🛎🛎🛎🛎
A better question is whether Facebook even wants to be on the WHATWG
and an even better question is whether anyone outside of Facebook wants them on the WHATWG
Facebook engineer's are not top class BTW. From an engineer friend working there I heard they mostly copy-paste CSS snippets, which for me is the hallmark of not taking the frontend seriously.
reduxis overly complicated (redux-sagais even worse with thefunction generatormachismo) while it was forcing a pretend-functional paradigm with a ton of boilerplate.overmindjscame and I felt that was how top class engineers design APIs.FYI, the React team just announced that after much debate about the exact semantics, a PR is in progress to update React 18 to properly support Web Components:
github.com/facebook/react/pull/22184
FWIW, if you read through the "React and Custom Elements" issue at github.com/facebook/react/pull/22184 , it's very clear that there were a lot of nuances of behavior that were blocking this from being worked on, because even Web Component advocates couldn't agree on what the proper handling should be.
And yet somehow every other framework including preact pulled it off without much fuss 🤷♂️
You are right it would be better if
reactwould be able to deal with webcomponents out of the boxBut there are different solution which build a bridge and allow to use webcomponents directly in react app e.g.: github.com/BBKolton/reactify-wc
Facebook would also need to reactify webcomponents so the only difference is that this code would then be written by Facebook itself.. I am not sure why using another OOS package is such a big issue..
Unpopular opinion: as much as I don’t use or need React, and everything for the Web is covered by one or more libraries of mine, React goes beyond the Web.
Hermes doesn’t support classes, and Custom Elements V1 are classes based and Custom Elements, cross platform, won't "just work", likely not even with my hermes-class module, as the DOM is a foreign environment in terms of React targets.
This is something none of the libraries/frameworks you mentioned care about, but maybe the reason React is not investing much on it.
After all, ube, and its SSR counter part, are there to showcase that Custom Elements, specially without built-in extend ability, are really overrated, or not as needed as many think.
Please bear in mind, I've written more than one Custom Elements polyfill to date, and while I find their place on the Web platform a must have, also being the best primitive, in certain cases, I don't think a library targeting native platforms too should care as much as Web developers do, about Custom Elements.
Low quality comment. You are well aware of the many high-quality FP web components libraries available, and the ones you've written yourself. Read the post.
I did read the post, and maybe my arguments (already flagged as unpopular) were not mentioned?
It's easy to compare React with every other Web-only based framework (none of them work across Web and native, AFAIK), but React does something more, or something different, with different requirements (see Hermes), no other library or framework needs to care about.
If you knew me, or followed me, you'd know I've never been a React fanboy, quite the opposite, but I do admire the fact their architecture somehow scales beyond the Web, and unless we have alternatives that would work seamlessly with Custom Elements too, which are not even needed most of the case on the Web (like ube demonstrates), the comparison sounds slightly unfair to me.
TL;DR let's compare Apples to Apples, without frameworks/libraries that target only the Web platform, shall we?
what is the purpose of this article?
edit: I would hope, as well, that most developers would be concerned about whether or not such a widely-used framework supported HTML
Some comments have been hidden by the post's author - find out more