This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
@donita starts thing off in the What’s the most frustrating thing about the process of looking for work or interviewing? thread, capturing five frustrating aspects of many interview processes:
- The plethora of recruiters who lead you on.
- Junior Dev Roles that requires 5 years of experience
- The lack of Junior Dev Roles
- Recruiters lying about certain aspects and perks of the job
- The interview process with no feedback
A browser, made in a browser. Welcome to 2018.
The modern frontend toolchain is where I'm tapping out on the "full-stack" idea. I can do everything I need to do with server-rendered templating languages; if I'm working on something that requires getting serious about understanding React or Vue or Webpack, I'm going to be working with someone who knows React or Vue or Webpack. I can work out what's going on in there well enough to fix problems and add minor features, but I'm profoundly disinterested in digging deeper.
In an awesome, 100+ comment thread discussing Which trend or advancement is being overlooked by most developers?, @bennypowers drops some serious analysis. And this was a reply to a reply!
In my humble opinion, the react community is too heavily invested in their library. I can understand that, given the runaway success of their library, but I do think the bubble will eventually burst. The wise developer will begin to sharpen their custom-elements-fu and should consider them for their next project.
React vs. Web Components is a False Dichotomy.
Since web components are browser standards, they are as usable within react components as
divs are. There are some minor caveats surrounding custom events, due to the odd way that react works with the DOM, but there's a well-trodden cowpath for working around react's eccentricities on that front. Preact, by the way, largely mitigates those caveats.
Although it's my opinion that web components are technically superior to React components because they are natively supported by the web browser instead of requiring developers to fight the browser, there is actually no contradiction between the two.
React is Tomorrow's MooTools
React is quite popular today, it's true, but that might not always be the case.
<span> isn't going anywhere, neither is
querySelector, but we've seen plenty of library frameworks fall to the wayside. In the mean time, web components have gained traction in the enterprise world due to their obvious future-proofing benefits, and interoperability between browsers and libraries.
Today, Web Components are Widely Supported
Now that Firefox supports Shadow DOM and Custom Elements, and the Edge team has announced their intent to ship, the web component standards have truly arrived, and are a compelling feature of the platform. I don't think it's a coincidence that we've seen a lot of shade thrown on WC's on social media this past month. Now that the standards have landed it's a much more looming threat to all-js component models.
The FUD Around WC's is Unjustified
A lot of the react-world arguments against web components boil down to some variation on
- The standards aren't accepted
- They are hard to work with
- They can't do what react does
But this is simply not true. The now-deprecated v0 standards are no longer supported, they've been replaced with the v1 standard, which as we've seen is widely supported.
While it's true that the low-level APIs described by the standards can be cumbersome, libraries and base classes like hybridsjs or lit-element smooth over those bumps with only a tiny addition to js page load sizes.
As far as features, web component libraries can do everything react can do and more without the VDOM overhead or the cognitive and tooling complexity added by that abstraction - Web component dev tools are browser/dom dev tools.
I have a friend at a browser vendor. A few years back, his team was busy building browser UIs and features using react.js. Even as he praised the elegance of the one-way-data-flow-with-central-store architecture (now easily implemented with custom element base classes like GluonElement or LitElement and state containers like redux etc), he complained about the performance limits of the React JS library (his words). I suggested he check out web components, since with them the performance limits would be the browser itself, rather than a JS library. He shot off an IM to a coworker. It's a few years later and lo and behold, that same browser vendor is currently in the process of re-writing their UI components with their own web-component-based library.
React brought a lot of wonderful things to the web development community.
- A Functional approach to UI
- One-way-data-flow patterns
- Popularizing the component model
But it also brought a lot of baggage with it.
- FUD around working directly with the DOM
- Cumbersome and unnecessary tooling
- The popular misconception that react is the only way to do component-based UIs on the web
Today, you can factor a modular, component-based front-end app without any browser flags, build steps, bundling, or tooling other than the browser and a text editor. And it will run on all the major browsers.
It's clear to me that the future will be built on open standards rather than bespoke implementations. However much good React has done for the web community (and I hope I clearly recognized that good), it won't be able to compete with that.
See you next week for more great comments ✌