The Case for React-Like Web Components
andrewrabon.com
andrewrabon.com
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.
I definitely agree with pretty much all your points. I think it's a pretty exciting time for web dev right now.
Awesome that you're here responding, though. Great post, overall! (Sorry if my points were mostly critical...I glossed over the parts I liked.)
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.
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.
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.
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.
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.
The major thing still missing is upload/download progress.
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.
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.
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.
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.
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?
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.
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".
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.
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.
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.
For example, I am glad I did not spend more than a few minutes looking at Coffescript.
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!
And it's not like "Vanilla JS" isn't a moving target itself.
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.
Those who master the platform win, regardless of flavour of the month Framework that one puts on top of it.
(The lib is 200 lines, so it is almost the same as VanillaJS)
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.