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.

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.

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

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.

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.

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

Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>.

Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well.

Still, for components I think Web Components will be a great addition, and should combine nicely with React.

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.

Most modern front end frameworks are younger than Web Components. They've rebooted the spec at least once. Even after half a decade, there's still no good way of even managing state with Web Components.

Really I'm not sure what we're waiting for at this point. The only thing Web Components have really solved is component isolation, but that's not something folks really struggle with these days.

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

I agree, and I prefer jQuery over native. It's still better, and does more. My point was that people say we don't need it anymore because the features it introduced are native now, and I think that's going to be said about React and Web Components too at some point. The same counter-argumemt will also be said: people will defend continued use of React because it will still be better, and will still do more. Just like jQuery.

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.

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

Abort/cancel has recently been added to the spec as AbortSigal (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.

In remembering this issue I had, I made a frankenstein promise return object mimicking fetch's interface called "retch" but didn't publish it. It allowed progress and cancelling. It made me think would be nice to have a promise interface standard class you could inherit from where you could add sugar to it so the chain would remain consistent with your additional functionality. Anyhoo.

I have a open job application with a company whose code challenge has me using vanilla Javascript. I'm not enthused about finishing it.

>but now much of jQuery's goodness is native

Since I never really learned jQuery, I can't attest to how much of modern JavaScript is based off of it. But looking an a quick reference for jQuery, it's pretty obvious that a huge part of it did not become standard. So all of the time invested in learning those features is wasted. Any application using those features is permanently locked in to a nearly obsolete framework. And the owners of those applications is now forced to find developers who both know and admit to knowing jQuery knowing they'll be dooming themselves to supporting old legacy code.

The point of Web Components is namespacing (variable and styling scope), composability (one component inside the other) and cacheing (fewer network calls). Now, frameworks can work with the browser to provide those features instead of working against the browser to emulate them.

Any framework that's integrated into browsers with no extra runtime to parse is worth caring about. Not disagreeing that the current state of Web Components is pretty bad, but the more recent versions of React are still a 100KB runtime - that's not great either!

People definitely still care about Web Components. They have evolved quite a lot over the last couple years, and there are some very nice helper libraries that have come out for them (skate.js, stencil.js)

I agree that state management/binding is hard, in general, but I'm sure that these Web Components helper libraries will be more and more sophisticated as time goes by. Also, isn't it pretty much standard to use redux/mobx for state management with React? Why not use these kinds of tools with Web Components? In the past I've used slots and symbols to communicate between parents and children without exposing all the guts of my components.

Aside from that, there's not really any good reason I can see that React itself couldn't/shouldn't support Web Components at some point soon.

If Web Components are only usable with a library on top of them, what is the point of using them in the first place?

Different libraries would then be compatible and interchangeable. You could mix and match web components using different or no frameworks on a page.

The guy I replied to is saying that he needs to use third party libraries just for state management and data binding. Pretty much every non-trivial component is going to need these features, and if they're using a library to get them, we're back to the same situation we were in before Web Components.

Nope.

The whole point of Web Components is that all of the innards of components are completely encapsulated in a component, the 'client' of a component only cares about setting its attributes and responding to the events that it emits. (And perhaps supplying external styles.)

I also think your claim of having to use 3rd party libraries for anything non-trivial is false, but let's ignore that for now.

What about processors? You need entire operating systems for them to become usable.

I don't think web components were intended to be used directly by average users; even a basic abstraction layer makes the tedious bits easier. Take this to its logical end and you have something like [skatejs](https://github.com/skatejs/skatejs), an abstraction layer over web components that you'd probably find very familiar and easy to use.

In that sense, web components aren't meant to compete with react and other frameworks, but to serve as an alternate, native foundational layer for frameworks.

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.

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.

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

Agreed, but as I mentioned in my edits of the comment, you’ll likely end up needing to solve all these problems in vanilla JS as well. So it’s really a question of picking your poison.

Also, many of the concepts you need to learn for proficient react development are auxiliary to react and could be applied to vanilla JS or really any UI framework. Any UI is fundamentally a state machine, and solutions to implementing it all require state management and clean separation of the presentation and data layers.

Yeah, and how WebComponents are gonna help with that? Considering that you need all of that just to make them marginally useful.

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

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.

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

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.

> They also make it easier to hire for that team.

At my last company, we found the opposite to be true. Switching to React made hiring all but impossible. Our Ruby devs mostly refused to learn the new stack and left, and most of the people we did hire to replace them were Java developers. I only met one hire who was immediately productive on our stack and she said it's because she had spent the past few months learning programming for 70 hours a week (!). She left 3 weeks later for a better paying job. Front-end development is absolutely bonkers right now.

I have been developing software for about 30 years, following the latest hype is not always the best to one's career.

For example, I am glad I did not spend more than a few minutes looking at Coffescript.

>> You can learn React in a day.

You can't build an application using React alone. You also need to learn ReactRouter and Redux, which add lots of complexity. Not to mention, if you spent only one day learning React you're probably going to do it wrong: you have to learn things like where to put state, when you have a hierarchy of components. Learning the "ten functions" of the API isn't enough!

How and where can you learn react in a day? Thats the problem in the real world, you can learn about react within a day, you need more and lots more time to master react and all that comes with it.

Yes. The right answer is to fix JavaScript so it doesn't need 5000 frameworks that have their own spin on how to organize code.

fix javascript.. lol.. what makes js one of the most used languages is it's crazyness.

>what makes js one of the most used languages is it's crazyness

No.. it's ubiquity in the browser alone made it one of the most used languages. Obviously, when there is only one game in town, that game is going to be popular.

People hate javascript and its "crazyness" so much that the entire universe of modern web development was designed around using other languages which "compile" to it so that developers could avoid direct contact with it as much as possible. What other language gets treated like a contagion by its own users?

Assembly?

If Brainfuck was included in browsers it would be 'one of the most used languages'.

These "React is just this month's JS Framework Hype" comments are really starting to look silly, considering React is coming up on 5 years.

And it's not like "Vanilla JS" isn't a moving target itself.

I think its easier to say that because of the past history of moving targets with JS. The "aha" moment you get with React is it abstracts things in a very easy to understand way with JSX at its heart. You then find it quite easy to move from React Web to React Native to React VR or whatever other thing they cook up because its just simple to look at abstraction without the hairy object boilerplate that you are normally subjected to.

Maybe React itself is just another flavor but the JSX paradigm is really the goodness I think more frameworks could use which cough cough was done by Microsoft a long time ago.

Vanila JS is part of the browser stack, a bit like UNIX and C, Java and JVM, CLR and C#, iOS and Objective-C/Swift, Android and Java,....

Those who master the platform win, regardless of flavour of the month Framework that one puts on top of it.

Very silly. If you are keeping up with the latest and greatest in JS, you have the 20 minutes to sit down and learn the basics of a framework that will make your life a bit easier. This argument will never end, code hipsters need their voices heard.

Afaict vanilla js these days is much less relevant than any of the current frameworks. Is it really that big of a deal to learn a new framework/library every now and then? They're really not that hard to learn and the productivity boost is definitely worth the investment. Hype is not at all the reason they're popular.

The problem isn't learning the frameworks; the problem is creating code that relies on them and has to be supported for years, which may or may not be longer than the active lifespan of the framework.

Regardless of whether web components would actually be a stand-in for things like React: what makes you think that integrating something in the language results in it being there to stay? If Angular 1's two-way data binding had been added to HTML proper, I'd still have moved on to a virtual DOM-based approach.

VanillaJS and CSS have changed far more than React in the last few years. ES6 and CSS grids alone brought massive changes.

They aren't going anywhere, they are part of the browser stack. Now React, well lets seen in 5 years time.

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

You can build Web Components using JSX using this library: https://github.com/wisercoder/uibuilder

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

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?

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.

Right but "flaws" is relative.

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.

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.