
The Case for React-Like Web Components - Andrex
https://andrewrabon.com/the-case-for-react-like-web-components-63887335fe41
======
wakamoleguy
This is OK. It compares some of the features of Web Components and React
components as they stand today. Having recently used Web Components in a side
project, I will say that I wish it touched more on how to give Web Components
reactivity. The author touches on data binding, but doesn't really go too
deeply into what will be one of the most customized (ergo hard to maintain)
pieces of the VanillaJS code.

Polyfills also add an interesting twist. You can use them to enable Web
Components in Firefox, but they mimic shadowdom behavior imperfectly. You need
to be very careful of how you use CSS in that case.

Lastly, there seemed to be some gotchas in ES6 module loading a few months
back. Perhaps those have been fixed. At the time, I found it hard to debug
modules that failed to load.

In any case, I'm always happy to see Web Components and more powerful/useful
features being added to JavaScript in the browser. Frameworks like React serve
useful purposes, and it's great that we have a platform that allows us to move
quickly and bring new patterns to life without waiting for browsers. In the
long term, though, I will always be an advocate for standards and making
vanilla implementations feasible.

~~~
Andrex
Believe me, _I_ want to touch more on Web Component reactivity, but I don't
have the depth of knowledge yet to really expound on it in a blog post. Happy
for others to fill the gap in the meantime though. :)

I definitely agree with pretty much all your points. I think it's a pretty
exciting time for web dev right now.

~~~
wakamoleguy
Yeah, I wish I could call myself an expert there, too, but I've still some
exploration to do before I'm really happy with how I have it set up, let alone
recommending it to others.

Awesome that you're here responding, though. Great post, overall! (Sorry if my
points were mostly critical...I glossed over the parts I liked.)

~~~
Andrex
Haha, I always expect far worse when sending a blog post like this out there.
It's the nature of the medium and I try to take it in stride. Your comment was
good-natured, so no worries.

------
bastawhiz
Serious question: does anyone still care about Web Components? They still
don't work cross platform, they have substantial limitations, and they lack
many of the important features that React and others come with by default
(event handling, anyone?).

For real, try to build a form with React, then try to build the same form with
Web Components. It's a nightmare going from controlled inputs to manual DOM
fiddling. Even just telling the parent component about the form submission
means creating and dispatching your own event!

Is the point of Web Components to service frameworks? I really don't see who
the intended audience is, because any half decent framework is infinitely
simpler to work with.

~~~
DougWebb
That used to be the same argument for using jQuery instead of native JS and
DOM, but now much of jQuery's goodness is native. I predict the same thing
will happen with React. Like jQuery it will still be useful and will probably
be somewhat cleaner, but most of its value will have gone native.

~~~
dmitriid
> now much of jQuery's goodness is native

Frankly, not that much. Most of the APIs are still the same imperative you-
can-only-do-one-thing-at-a-time hell, often with very limited capabilities
compared to jQuery.

And yes, whoever made the decision to return NodeLists instead of arrays
everywhere should at least re-evaluate whether they should really be doing
programming.

~~~
sametmax
Yep. Fetch is very low level. Chaining is a godsend. Adding elements is way
shorter with jquery. All the vanilla js project i've seen end up writting a
poormy tested a'd documeted half backed jquery little brother. It's not a win.

~~~
sebringj
I like fetch except its missing xhr basic stuff like cancel and abort, etc. I
don't know who makes these standards.

~~~
realityking
Abort/cancel has recently been added to the spec as AbortSigal
([https://developer.mozilla.org/en-
US/docs/Web/API/AbortSignal](https://developer.mozilla.org/en-
US/docs/Web/API/AbortSignal)). Currently only supported in Firefox 57 and Edge
16.

The major thing still missing is upload/download progress.

------
pjmlp
Quite true, I also prefer Vanilla JS and look forward to Web Components
becoming more mainstream.

The pure Web stack skills stay, while framework specific skills are only good
until the next JS Framework hype cycle.

Where are Dojo, MooTools, YUI, Promise.js now?

In a couple of years React, Angular, Vue, Polymer might join them, but
VanilaJS, HTML, CSS skills will stay relevant.

~~~
chatmasta
You can learn React in a day. The API is composed of less than ten functions.

To answer part of your question, Promise.js has become formalized in the
ECMAScript standard, so maybe not the best example.

These frameworks emerge to make it convenient to solve problems that JS does
not offer an easy way to solve. I don’t see anything philosophically wrong
with that; in fact, I would argue it’s a big driver of JS adoption.
Prototypical inheritance makes it very easy to bend javascript to your will.

If you don’t like the frameworks you don’t need to use them, but it’s going to
harm your career if you actively avoid learning how to use frameworks that are
deployed with increasing frequency on new projects.

The other advantage of frameworks is that they provide common idioms and
enforce procedural standards, both of which make working on a team more
productive as everyone has the same base of understanding. They also make it
easier to hire for that team.

Try implementing any sufficiently complex app in vanilla JS and you’ll likely
end up recreating many of the aspects of popular frameworks, except your
“internal framework” will be messy, undocumented, and unique to your project,
severely reducing maintainability and increasing onboarding time of new
developers.

~~~
meesterdude
> You can learn React in a day.

Maybe React itself, but everything else that goes into doing react
development; design patterns, gotchas, testing, webpack, native and so on?
That takes far longer than a day, and is what most would expect when being
able to really say they "know react".

~~~
dictum
I don't want to turn this into another misguided "JS sucks" thread[0], but
here's an example from create-react-app, the official point of entry for
people learning React:

[https://github.com/facebook/create-react-
app/blob/master/pac...](https://github.com/facebook/create-react-
app/blob/master/packages/react-scripts/template/README.md)

The README included on a project generated through CRA is 116KB. A screenshot
of that page rendered in GitHub is 60054px tall.

Honestly, I don't know if this could be made simpler or easier. React and its
ecosystem deal with complex problems that can't always be reduced to simple
explanations. In the case of this README, of course a lot of it is about
specific setups that most beginners don't need to care about, but that CRA,
being the blessed point of entry, still should support, or it would lock
everyone into a Facebook workflow.

I think many developers would be better served by entering frontend
development not through React, but through the basics (HTML, CSS, JS) and
other ecosystems.

[0]: Unrequested opinion: frontend developers reach for bigCo solutions —
whatever Facebook/Google/some billion-dollar startup uses — when smaller,
lesser known, "boring" or exploratory solutions could be better, trying to
solve problems they don't have.

~~~
symlinkk
That's not the official point of entry, the main React site is:
[https://reactjs.org/docs/hello-world.html](https://reactjs.org/docs/hello-
world.html)

~~~
dictum
Good point. What I meant by "point of entry" wasn't the way to learn React as
an absolute beginner, but the official tool to use after you've learned the
basics of React itself. A beginner can (and should) go far without a build
system.

------
yesimahuman
If you want even more react-like web components, we built Stencil to use JSX
and output plain web components as we move to WC's for Ionic Framework:
[http://stenciljs.com](http://stenciljs.com)

------
petilon
You can build Web Components using JSX using this library:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

(The lib is 200 lines, so it is almost the same as VanillaJS)

------
sebringj
Don't you kind of wish they just said screw it, let's just use React for the
standard and move forward. Is that wrong to say?

~~~
colordrops
No, but it's also not taking into account a lot of reasons web component
features exist as they do, and the flaws with react.

~~~
sebringj
Right but "flaws" is relative.

~~~
colordrops
What I'm getting at is that the reason web standards are slow is because they
go through a long vetting and trade-off discussion between various
stakeholders to flush out flaws and make conscious compromises. React has not
gone through this process, and was created for Facebook's needs. It would need
to go through the same process before becoming a standard.

------
dmitriid
There's no case.

Web Components are an overly-verbose under _and_ overspecified near-
monstrosity that cannot even function on its own without throwing in
Polymer/Skate/whatever.

"React-like" components in the article are to React what rocks are to a CNC
machine. I also encourage you to count the number of problems the author
mentions vs. the number of advantages.

