After so much hype,
After so much excitement,
After so many buzzwords,
After months and years of waiting for the next React major...
It landed...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Currently working on a thing that creates React wrappers around my custom elements, based on a Custom Elements Manifest, and I just cant help but think how absolutely ass backwards and ridiculous this all is.
The next time I see someone say web components require so much code and boilerplate, I'm gonna point them to some of the hacks/hoops I had to jump through just to get HTML support in React.
I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
I dunno, are they really bigger or do they just have a louder bark? 🤔
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
It's not either-or. There are many web component libraries with an FP flavour:
Just off the top of my head.
Web Components !== OOP
You don't have to give up your functional programming style to use web components!
More importantly:
React isn't the only functional UI framework
Preact works just fine with the DOM and has for years.
OP is about web compat, not flaming FP or OOP styles.
Stencil already supports the WC <> React wrapper out of the box. Check it out here:
github.com/ionic-team/stencil-ds-o...
It‘s quite simple to set it up & thanks to the engrained usage of TS it can be fully autogenerated
Its nice that Stencil supports this, and that with Custom Elements Manifest we can create this for other libraries, too, but its ridiculous we need to resort to this kind of thing in the first place. If React would just support HTML, we wouldnt need to use these workarounds.
It's definitely pathetic, especially considering the mountains of money moving through Menlo Park
Did you end up publishing this?
Yeah, bit experimental still, but here it is: npmjs.com/package/cem-plugin-reactify
I'm all for it as a React dev I hate that they don't respect standards all I want is write HTML elements, same way I hate that Apple don't respect browser standards and openly hates the web and is trying to make the web experience as bad as possible so users download apps.
Use your voice, @ivanjeremic
Does React have a future?
The very interesting truth is Facebook has no Browser,
and is not a core member of the WHATWG.
And since 2019, the WHATWG;
read: Google, Apple, Microsoft , Mozilla are in control of what runs in the Browser;
when the W3C handed them the keys: techxplore.com/news/2019-06-w3c-wh...
The WHATWG is by-invitation-only;
will Google, Apple, Microsoft and Mozilla invite Facebook?
Is React the new Flash?
Just to note that Facebook started contributing to the Web API:
Whether or not that means that the fundamental tension between Facebook and the web is shifting - I don't know … but I somehow doubt it. It's more likely a feature that has a particularly high value from React's perspective to make it worth the effort to contribute.
A Different Kind of War
Modern Web Development
The Web of Native Apps II: Google and Facebook
Great blogs, but... techies only look at technology.
Sure, I am a techie too, and bashed React in my latest Dev.to post.
But foremost, in the WHATWG, and effectivly on Web Components,
I see 4 companies working together. And getting better at it, every feature...
Something the like I have never seen in my 31 Internet years.
If you follow the WICG discussions, do not only read the what,
read between the lines, how engineers from those 4 companies, communicate.
You can't but wonder... would this cooperation have been possible with Jobs at the helm...
Now it is up to Google to stop pushing their developments, and focus on joint efforts only.
AMP should have been a good learning Lit (in its current its-a-Google-party form) has no future.
We want a good BaseClass in the Browser, not one we have to load.
🛎🛎🛎🛎🛎🛎
A better question is whether Facebook even wants to be on the WHATWG
and an even better question is whether anyone outside of Facebook wants them on the WHATWG
Facebook engineer's are not top class BTW. From an engineer friend working there I heard they mostly copy-paste CSS snippets, which for me is the hallmark of not taking the frontend seriously.
reduxis overly complicated (redux-sagais even worse with thefunction generatormachismo) while it was forcing a pretend-functional paradigm with a ton of boilerplate.overmindjscame and I felt that was how top class engineers design APIs.FYI, the React team just announced that after much debate about the exact semantics, a PR is in progress to update React 18 to properly support Web Components:
github.com/facebook/react/pull/22184
FWIW, if you read through the "React and Custom Elements" issue at github.com/facebook/react/pull/22184 , it's very clear that there were a lot of nuances of behavior that were blocking this from being worked on, because even Web Component advocates couldn't agree on what the proper handling should be.
And yet somehow every other framework including preact pulled it off without much fuss 🤷♂️
You are right it would be better if
reactwould be able to deal with webcomponents out of the boxBut there are different solution which build a bridge and allow to use webcomponents directly in react app e.g.: github.com/BBKolton/reactify-wc
Facebook would also need to reactify webcomponents so the only difference is that this code would then be written by Facebook itself.. I am not sure why using another OOS package is such a big issue..
Unpopular opinion: as much as I don’t use or need React, and everything for the Web is covered by one or more libraries of mine, React goes beyond the Web.
Hermes doesn’t support classes, and Custom Elements V1 are classes based and Custom Elements, cross platform, won't "just work", likely not even with my hermes-class module, as the DOM is a foreign environment in terms of React targets.
This is something none of the libraries/frameworks you mentioned care about, but maybe the reason React is not investing much on it.
After all, ube, and its SSR counter part, are there to showcase that Custom Elements, specially without built-in extend ability, are really overrated, or not as needed as many think.
Please bear in mind, I've written more than one Custom Elements polyfill to date, and while I find their place on the Web platform a must have, also being the best primitive, in certain cases, I don't think a library targeting native platforms too should care as much as Web developers do, about Custom Elements.
Low quality comment. You are well aware of the many high-quality FP web components libraries available, and the ones you've written yourself. Read the post.
I did read the post, and maybe my arguments (already flagged as unpopular) were not mentioned?
It's easy to compare React with every other Web-only based framework (none of them work across Web and native, AFAIK), but React does something more, or something different, with different requirements (see Hermes), no other library or framework needs to care about.
If you knew me, or followed me, you'd know I've never been a React fanboy, quite the opposite, but I do admire the fact their architecture somehow scales beyond the Web, and unless we have alternatives that would work seamlessly with Custom Elements too, which are not even needed most of the case on the Web (like ube demonstrates), the comparison sounds slightly unfair to me.
TL;DR let's compare Apples to Apples, without frameworks/libraries that target only the Web platform, shall we?
what is the purpose of this article?
edit: I would hope, as well, that most developers would be concerned about whether or not such a widely-used framework supported HTML