DEV Community

Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Posted on • Edited on • Originally published at bennypowers.dev

What's NOT new in React 18

After so much hype,

After so much excitement,

After so many buzzwords,

After months and years of waiting for the next React major...

It landed

Cupid's foot landing (from Monty Python)

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.

Skip code sample comparison

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

Preact: Just Works

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>
  );
};
Enter fullscreen mode Exit fullscreen mode

React: y, tho?

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)

Collapse
 
thepassle profile image
Pascal Schilp

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.

Collapse
 
jorenbroekema profile image
Joren Broekema

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

I dunno, are they really bigger or do they just have a louder bark? ๐Ÿค”

Collapse
 
rejhgadellaa profile image
Roderick Gadellaa

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)?

Thread Thread
 
jorenbroekema profile image
Joren Broekema

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)

Thread Thread
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ • Edited

It's not either-or. There are many web component libraries with an FP flavour:

  • hybrids
  • haunted
  • FAST
  • atomico

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.

Collapse
 
brunnerlivio profile image
Livio Brunner

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

Collapse
 
thepassle profile image
Pascal Schilp

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

It's definitely pathetic, especially considering the mountains of money moving through Menlo Park

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Did you end up publishing this?

Collapse
 
thepassle profile image
Pascal Schilp

Yeah, bit experimental still, but here it is: npmjs.com/package/cem-plugin-reactify

Collapse
 
ivan_jrmc profile image
Ivan Jeremic • Edited

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Use your voice, @ivanjeremic

Collapse
 
dannyengelman profile image
Danny Engelman • Edited

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?

Collapse
 
peerreynders profile image
peerreynders • Edited

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.

He inferred that Google's deep ties to the web (and standards bodies) make the web, as a platform, a risk that Facebook does not want to be exposed to. He says that React is a step toward abstracting away the browser.

A Different Kind of War

So the engineers at Facebook in a stroke of maniacal genius said โ€œto hell with the W3C and to hell with best practices!โ€ and decided to completely abstract away the browser

Modern Web Development
The Web of Native Apps II: Google and Facebook

Collapse
 
dannyengelman profile image
Danny Engelman • Edited

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

It's more likely a feature that has a particularly high value from React's perspective to make it worth the effort to contribute.

๐Ÿ›Ž๐Ÿ›Ž๐Ÿ›Ž๐Ÿ›Ž๐Ÿ›Ž๐Ÿ›Ž

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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

Collapse
 
latobibor profile image
Andrรกs Tรณth

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.

redux is overly complicated (redux-saga is even worse with the function generator machismo) while it was forcing a pretend-functional paradigm with a ton of boilerplate. overmindjs came and I felt that was how top class engineers design APIs.

Collapse
 
markerikson profile image
Mark Erikson

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

And yet somehow every other framework including preact pulled it off without much fuss ๐Ÿคทโ€โ™‚๏ธ

Collapse
 
jantimon profile image
Jan Nicklas

You are right it would be better if react would be able to deal with webcomponents out of the box

But there are different solution which build a bridge and allow to use webcomponents directly in react app e.g.: github.com/BBKolton/reactify-wc

const VaadinButton = reactifyWc("vaadin-button");
Enter fullscreen mode Exit fullscreen mode

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..

Collapse
 
webreflection profile image
Info Comment hidden by post author - thread only accessible via permalink

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.

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

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.

Collapse
 
webreflection profile image
Andrea Giammarchi • Edited

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?

Collapse
 
siarhei_siniak_marketing profile image
Siarhei Siniak

what is the purpose of this article?

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ • Edited
  1. inform React users who maybe weren't aware that React is way behind the competition
  2. spur action from the React team

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