If you think the Virtual DOM makes no sense since “you have to update the DOM anyways”, you are going to hate the fact that modern web engines like WebKit themselves keep not 1, but *2 further levels* of tree abstractions [1], because they (foolishly ...
-
Francisco Tolmaskyreplied to Alex Russell last edited by
@slightlyoff But templating isn’t what many asking for (some maybe, web’s a big place, lots of uses). But if presented to React or Elm devs as a “native solution” for templating, or even “custom components”, they won’t even think it is *attempting* to be an alternative for their tools. I empathize, because I’m Ironically in your position with UIKit vs. SwiftUI. SwiftUI *sucks*, but it’s a mistake to think templating would fix UIKit. You need an answer to what it’s good at, not what it’s bad at.
-
Alex Russellreplied to Francisco Tolmasky last edited by
@tolmasky Then we have failed to educate. The substitutability of these systems is self-evident with enough context.
-
Francisco Tolmaskyreplied to Alex Russell last edited by
@slightlyoff I mean, not without a wrapper framework. Web Components are nothing like React or Elm of SwiftUI or anything in that family. Honestly I think hyping up Web Components hurts React alternatives. It’s too complicated to be used alone, convinces people the DOM still “isn’t ready”, but sucks up all the oxygen, stealing the spotlight from next-gen “pure DOM” frameworks like lit/enhance/etc, which are probably a better starting point. I’d stop presenting it as an end-user tool full stop.
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
@slightlyoff These next-gen frameworks also potentially miss the mark (I don’t blame them, it’s hard!). But using enhance as an example:
1. You still need tooling, whether IDE to syntax color magic HTML template strings, or a compiler even just polyfilling standard JS features. Those may very well be more valid uses of tooling but criticisms of JSX and compilers can sound disingenuous if you also end up requiring tooling, especially if you’re coming from JSX. It sucks! But it’s true. (cont.)
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
2. Focusing on compilers at all is a lost cause, IMO, thanks to Typescript. *Lots* of people use Typescript, so not needing a build step may change nothing for them.
3. You should probably support TS! I don’t like it, but It’s very popular, and it’s hard to find any mention on enhance.dev. TS and React now bokster each other since TS seems “built for it” (JSX support), and gives it more “functional vibes” by adding types. Don’t cede this ground to React.
(cont.)
-
Alex Russellreplied to Francisco Tolmasky last edited by
@tolmasky You're really going hard into this strawman, huh?
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
4. After all that talk of VDOM, it turns out, enhance.dev supports VDOM… optionally. So now it just seems like a more complicated version of VDOM, that I need to figure out. This is confusing. When do I need it? When my app is big enough? Am I doing all this just for it to end up being little more than an API change? I don’t know the details behind this, but it seems so egregious that I’d even just name it something else like “aggressive cache mode” or something.
(cont.)
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
5. It’s really unclear how to do child components, one of the most popular things about React and one of the harder aspects of Web Components.
This is a subset of the issues, but enough to probably make you check the next one if you’re coming from React. You can repeat this for all the pure DOM frameworks I’ve seen. (cont.)
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
It’s goonly a straw man insomuch as it’s an attempt to give an accurate portrayal of what it looks like on the other side, from someone that agrees with your first principles, but has seen the web repeatedly fail at this. We agree people seem to keep using React, right? I’m sure their reasons seem like straw men too, just like these, but you have to address *their* reasons. It sucks but it’s worth it if your goal is to help the user.
Alex Russell (@[email protected])
@[email protected] You're really going hard into this strawman, huh?
Toot Café (toot.cafe)
-
Francisco Tolmaskyreplied to Francisco Tolmasky last edited by
It’s not impossible to beat React, many (non-pure) frameworks have managed to make progress. But the “use-the-platform” frameworks start from a disadvantage (Use the platform? Then why do I need you? No compiler? I like my TS compiler, etc.). There also isn’t, AFAIK, a pure-DOM framework as invested as React/Svelte/etc. This is a meta-reason, but you may need someone (or company) as committed to a framework as Svelte/etc. It’s not like Apple is going to push Web Components.
-
Alex Russellreplied to Francisco Tolmasky last edited by
@tolmasky This is like 80% invented problems that seem like a lot of react cargo culting and active discounting of the legion of issues React adds. I dig teams out of these problems for a living, and it's not going well once the app isn't a toy. All the alternatives with the warts you outline are better in practice, which is what matters.
-
Francisco Tolmaskyreplied to Alex Russell last edited by
@slightlyoff I feel like I've gone out of my way to make clear that I am not necessarily sympathetic to these arguments, but that they are compelling to a lot of devs, regardless of my opinion of them. I, for example, mentioned that while I don't like Typescript (and trust me it was very painful to devote this much of the argument to TS), I do recognize the importance of highlighting it. I don't think dismissing these arguments is working. I don't think this gets us to a web without React.
-
This is what is so frustrating in the web components discourse.
Devs and web framework authors: here's a laundry list of reasons why we use what we use. This list contains a multitude of things: from convenience to purely technical considerations.
Web components: straw man, skill issue, invented problems...
...
Web components: BTW have you tried this alternative that ships with a compiler and custom syntax more ad-hoc than JSX and rules more weird than hooks?
-
On top of that this report exists for a reason, and has nothing to do with React or VDOM
Web Components Community Group: 2022 Spec/API status
This is required.
(w3c.github.io)
-
@dmitriid @tolmasky You've missed the point (sadly, per usual). I'm not saying "use web components", I'm saying "the assumption that React is a good answer to any modern problem is just wrong, both in theory and on the experienced merits". That covers the same ground, and allows for all the warts you hyper-focus on.
This is engineering. Here we do tradeoffs, not purity.