I worked on a project a couple years back that would have benefited greatly from this approach. I look forward to giving it a spin when I have an opportunity.
I’m curious how much is React-specific, or rendering-specific for that matter. Context: the use case I had previously was “headless”, in the sense that state lifecycle was completely decoupled from rendering (with a thin library-agnostic bridge for presentation layer integration). Obviously that’s not a typical use case, I’m mainly curious because that design was partly driven by the kinds of inherent complexity that would nudge me to look for something like this in the first place.
I generally agree. But FWIW it does feel fairly idiomatic in terms of code written with Effect/API design in the Effect ecosystem. (Disclaimer: my Effect usage so far has been mostly casual, this
observation is based on following the project and ecosystem pretty closely.)
Thanks! From what you say here and what I see in the docs, it looks like everything is much simpler and more robust than when I was exploring the space. I’m happy to see that, and thrilled it’s mature enough now to support use cases like nub.
I’m surprised to see this using a `--require` hook (rather than `--import`). Maybe something’s changed significantly since I was looking into building some similar functionality… but it makes me wonder about nuances in nub’s ESM support.
(When I was investigating this it was very early in Node’s `--import` story, but there were several edge cases with the more common ESM-to-CJS approaches that I wanted to address. Most were probably exceedingly niche concerns, but I’d expect top-level await to affect a meaningful subset of users.)
A trivial counter example to the intuition one might have that compilers likely produce deterministic output. It’s directly responsive to the exchange between Aoi and Numa above, wherein Aoi expresses exactly that intuition. Of course, those are characters playing out a question less familiar readers might ask. Presumably the intent is to make this content accessible to a wider audience, using an obvious example to introduce the concept without requiring much background knowledge.
I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake.
It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context.
Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.
Well before the LLM explosion I would often preface my answers with some form of praise for the question. It depends a lot on audience of course, but it’s amazing how many people tend to perceive direct answers to their questions as negative… and just as amazing how far a little strategic sycophancy goes to temper that. Even though everyone knows it’s half-sincere dead weight.
I agree. And I think this also distills down to Rob Pike’s rule 5, or something quite like it. If your design prioritizes modeling the domain’s data, shaping algorithms around that model, it’s usually trivial to determine how likely some “duplication” is operating on shared concepts, versus merely following a similar pattern. It may even help you refine the data model itself when confronted with the question.
It’s a muscle you can exercise, and doing so helps you learn what to focus on so it’ll be successful. IME a very successful approach is to focus on interfaces, especially at critical boundaries (critical for your use case first, then critical for your existing design/architecture).
Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations.
Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.
The point of a type system isn’t ever that you don’t have to check the things that make a value represent the type you intend to assign it. The point is to encode precisely the things that you need to be true for that assignment to succeed correctly. If everything is in fact modeled as an Option, then yes you have to check each thing for Some before accessing its value.
The type is a way to communicate (to the compiler, to other devs, to future you) that those are the expected invariants.
The check for invariants is trivial as you say. The value of types is in expressing what those invariants are in the first place.
> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).
It’s not a hack, but you may find more documentation for the equivalent preload values expressed as a <link> tag. There is (near) parity between that and the HTTP Link header. The values used in the article should work in HTML as well.
Disclaimer: I’m a strong advocate for static typing.
I absolutely see the connection. One of the advantages of static typing is that it makes a lot of refactoring trivial (or much more than it would be otherwise). One of the side effects of making anything more trivial is that people will be more inclined to do it, without thinking as much about the consequences. It shouldn’t be a surprise that, absent other safeguards to discourage it, people will translate trivial refactoring into unexpected breaking changes.
Moreover, they may do this consciously, on the basis that “it was trivial for me to refactor, it should be trivial to adapt downstream.” I’ll even admit to making exactly that judgment call, in exactly those terms. Granted I’m much less cavalier about it when the breaking changes affect people I don’t interface with on a regular basis. But I’m much less cavalier about that sort of impact across the board than I’ve observed in many of my peers.
You might want that, I might too. But it’s outside the constraints set by the post/author. They want to establish immutable semantics with unmodified TypeScript, which doesn’t have any effect on the semantics of assignment or built in prototypes.
Marko’s compiler is designed for partial hydration (by default, without any special developer effort), which performs quite well. IIRC they were also looking at implementing “resumability” (term coined by Qwik, for an approach that sidesteps hydration as a concept entirely). I’m not sure where they’re at on that now, but I think it’s generally safe to say that Marko prioritizes load time performance more than nearly all other frameworks.
I don’t agree with your characterization that anyone is “pretending”. The whole point of abstraction is convenience of reasoning. No one is fooling themselves or anyone else, nor trying to. It’s a conscious choice, for clear purposes. That’s precisely as hilarious as using another abstraction you might favor more, such as an effect system.
It’s a clear-minded and deliberate approach to reconciling principle with pragmatic utility. We can debate whether it’s the best approach, but it isn’t like… logically inconsistent, surprising, or lacking in self awareness.
I’m curious how much is React-specific, or rendering-specific for that matter. Context: the use case I had previously was “headless”, in the sense that state lifecycle was completely decoupled from rendering (with a thin library-agnostic bridge for presentation layer integration). Obviously that’s not a typical use case, I’m mainly curious because that design was partly driven by the kinds of inherent complexity that would nudge me to look for something like this in the first place.