MongoDB is fascinating in how it defies the conventional wisdom that technology is all about trade-offs. They seem to have really figured out how to make a project that is the worst at absolutely everything, with no benefits to show for it anywhere. It gives you hope that if it is possible to make a no-compromises bad-at-everything tool, it might just be the case that a good-at-everything tool is also possible.
Posts
-
MongoDB is fascinating in how it defies the conventional wisdom that technology is all about trade-offs. -
Complexity isn't a syntax problem.@brianleroux Not sure if you’ve seen where it’s headed: https://gist.github.com/lucacasonato/7db690976cb527a1918f9712fab32dec
-
Complexity isn't a syntax problem.@brianleroux Agreed, one of the many problems with ES modules vs. require.
-
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 ...@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.
-
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 ...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.
-
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 ...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.
-
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 ...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.)
-
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 ...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.)
-
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 ...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.)
-
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 ...@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.)
-
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 ...@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.
-
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 ...@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.
-
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 ...@slightlyoff Criticizing the VDOM in some ways becomes a (convenient? accidental?) way to *actually* criticize immediate mode rendering patterns, which only incidentally require them. I don’t *really* care about VDOM, but it’s kind of inescapable for Elm-style rendering. I don’t even know what it means to “use the DOM” in that environment. The whole point is a rejection of appendChild mutation, anything-throws UI functions, and unrewindable code. Implement that w/o VDOM and no one will complain.
-
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 ...@slightlyoff I think this oversimplifies the many reasons VDOM is popular, and is partially why Web Components keep missing the mark. VDOM can be expensive, or not, depending on the use case. There’s indirect reasons too: it is a good way to power immutable immediate-mode rendering patterns (whether in JS like with React or e.g. in Elm). VDOM becomes harder to beat the more your “conceptual render model” deviates from DOM. Ironically, this is *also* why “Alt DOMs” are used under the hood.
-
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 ...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 I’m sure!) see performance and correctness opportunities in intermediate representations, including for the silly reason of guaranteeing immutability. They could save thousands of lines of C++ by just sticking to the DOM
1. https://trac.webkit.org/wiki/NextGenerationLayoutAndRendering