What is the most underrated movement that could have a real affect on software?
What are the majority not thinking enough about?
For further actions, you may consider blocking this person and/or reporting abuse
What is the most underrated movement that could have a real affect on software?
What are the majority not thinking enough about?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (97)
Web components are a huge advancement in the web platform, but most devs hadn't heard of them.
How would you respond to push back? (Mostly from the React community from what I've seen)
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 isquerySelector, 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
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.
An Anecdote
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.
Summary
React brought a lot of wonderful things to the web development community.
But it also brought a lot of baggage with it.
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.
Thanks for a really thoughtful reply!
Figured I'd provide some response from the React side of things. :-)
dev.to/dan_abramov/comment/6kdc
I'd say there's really no reason for the bad blood, and frankly, to me it feels immature at times and ill-informed. You can still use WCs in your framework. Take a look at this: custom-elements-everywhere.com for example.
Another point: Say I'm developing something with Vue, and I want to use a React component that I remembered because I used it in a different project, you'd have to hope there's a Vue version of that component, or roll your own. A web component you'd just plug and play, no matter the framework.
If you want to use your framework because of whatever reason, you can still leverage web components. Or not. Whichever is fine. You do you.
Additionally; Standards tend to outlive frameworks.
Do you have any recommended reading and tools to dive into this over the weekend? Thanks!
Scathing!
WELL...
There is this blog series everyone's talking about 😅
Lets Build Web Components! Part 1: The Standards
Benny Powers
MDN is also amazing
developer.mozilla.org/en-US/docs/W...
Lol, I was going to write "jQuery" but i thought that wouldn't write capture the essence of the problem 😉
CSS Houdini! So so so cool!
Elaborate?
It will allow you to write JavaScript in order to make CSS more powerful -- it should also make it so that browser compatibility isn't an issue anymore. Here's more -- some features have started rolling out especially in Chrome's Canary and FireFox's Nightly
I'm so jazzed for this to land
I've heard about it on fun fun function. Haven't yet looked into it.
Ali it would be great to see a post from you about this technology.
Polyglotism. Systems thinking. Art of simplicity. Post capitalism. User empathy.
GraphQL, but I'm not in the industry so not sure
GraphQL is pretty hot right now. I'd say the issue is the opposite - people choosing GraphQL for simple projects where REST would be better.
Live programming. Devs are stuck in a code-run-debug-code cycle, but it doesn't have to be this way. What if you could see the values of your variables while you program? Once you try it you realize just how slow normal programming is.
There's some very exciting work going on in this area - look at lighttable / quokka / wolf / algojammer / FoxDot.
I'm the creator of AREPL, a vscode extension for live programming in python. I'm convinced that live programming will be a big thing. It may not be my extension, or any of the things I listed, but eventually live programming will become popular, not just a niche theoretical concept.
Programming with pure functions, sometimes known as Functional Programming. All that mathy stuff associated with FP is pretty cool for expressibility and reuse, but it pales in comparison to the value of just using pure functions for as much of the code as is reasonable. With pure functions testing is easy and refactoring becomes very low risk. (Thinking typed FP... not as familiar with untyped.)
This extends to the front-end as well. The Elm Architecture has really taught me a lot in this regard. We have done epic refactors of our code base, fixing early mistakes. And because Elm code is pure, it was a bit of work, but it wasn't risky.
Writing pure functions is an investment in the code base, but it returns big over time.
Is it possible that the average dev shop is just too short sighted to really buy into FP?
I don’t think it is short-sightedness as much as inertia. Even if you have felt the benefits first hand, writing pure functions can be really difficult with the tools/languages devs generally use. Most languages expect mutation as a foundational principle. Every line of code is expected to be a side effect. It is going against the grain to do otherwise. And the reason most of our tools are like this is just the happenstance of history’s unfolding.
So then once you resolve to use tools which normalize and expect pure functions, you then immediately have another crisis. You have no idea how to solve problems with pure functions. It’s just different at times.
So I think it is only natural that these difficulties prevent people from giving it a try. I only started to discover the benefits myself pretty recently in my career (6 years ago?). And it wasn’t until even more recently that I began to be able to articulate specifically how it helps.
Fortunately a lot of languages have incorporated functional features. So that helps toward the familiarity of solving problems functionally. For example C# LINQ is a significantly liked feature that is basically lifted straight from FP.
Anyway, i just think it’s hard to do in most of our tools. And changing tools plus learning different ways to solve common problems is too much change at once for most of our teams. It took me multiple tries. Maybe as our tools start to incorporate more FP ideas, as they seem to be doing, the barrier will get smaller.
That CPUs have reached a limit to how much speed they can reach.
Now it's all about core count and parallelism. Languages that excel in that front will give tech companies an implicit edge.
For example, elixir.
I can tell you that I'm most overlooking blockchain, mostly due to it's applications in cryptocurrency and my level of disinterest in cryptocurrencies.
there's a reason blockchain is overlooked. and it seems you've found it already.
Not sure it’s a current trend, but... server side rendering.
People have come to expect client side functionality. If every little steps requires a full page reload you add friction to their usage and once it adds up enough they will get fed up and leave.
Not when server rendering is done in such a way as to be nearly indisguishable from SPA... providing a high fidelity experience that delights users. It can be done.
This is a common misconception! Technologies like PJAX mean that you don’t need full page reloads to do server-side rendering.
PWA and WebAssembly are two killer techs... but, people still prefer frontpage-like solutions 😄
iOS needs to stop intentionally lagging in support of PWAs
I hope so... but Apple is so greedy for their apple-store subscription 🤬
It feels pretty intentional, doesn't it? I get that they want to keep people in the app store, but at this point it seems pretty hostile to their customers...and the web in general.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.