Stoids · HackerTrans

As someone who created those horrifying RxJS monstrosities, I agree with most of this, which is why I caveated my concerns. Tanstack Query simplified a lot of these issues—separating server state and caching from client side state was a huge boost. I’m mostly coming from the perspective of someone who just inherited a Jotai code base with 200+ atoms and trying to wrap my head around it. Any library poorly used can lead to a mess though, so not going to claim it’s a problem inherent to all atom based approaches.

Stoids

昨年議論

Most UIs I've written in my career benefit from being modeled as FSMs. While I see the value proposition of the atom-based approaches, especially for basic applications, I can't help but become a bit hesitant about their scalability long-term on large teams. Part of the reason the very dogmatic Redux approach of a event dispatching + single store of truth caught on so quickly was because a lot of us had felt the pain of two-way data binding / global state with event listeners in Angular 1. I distinctly remember the horror of debugging digest loops (scope.$$phase memories) and being completely lost in the unstructured data flow. What made for a great demo became a nightmare at scale.

There's nothing stopping people from using these atom-based libraries to build more robust abstractions, but from my professional experience I tend to just see global getters and setters with useEffects / lifecycle method of your frameworks choice as a side effect sync.

Maybe my instincts are off here though and I am overly cautious. I love XState but the learning curve is rather massive and getting buy in from other team members is hard when the DX of the atom approach is so nice.

I feel like state "management" and reactivity performance are talked about a lot, when ultimately state orchestration is where I see things fall over the most.

Stoids

2 年前議論

We aren’t good at creating software systems from reliable and knowable components. A bit skeptical that the future of software is making a Rube Goldberg machine of black box inter-LLM communication.

Stoids

2 年前議論

That's right, Effect lifts all types to a lazily-evaluated common type and provides combinators to work with that type, similar to RxJS with Observables and its operators.

Retrying[0], observability[1], and error handling[2] are first-class concerns and have built-in combinators to make dealing with those problems quite ergonomic. Having these features is a non-starter for any serious application, but unfortunately, the story around them in the TypeScript ecosystem is not great—at least as far as coherence goes. You often end up creating abstractions on top of unrelated libraries and trying to smash them together.

I'm a big fan of ReasonML / OCaml, and I think the future of TypeScript will involve imitating many of its code patterns.

[0] https://effect.website/docs/guides/error-management/retrying

[1] https://effect.website/docs/guides/observability/telemetry/t...

[2] https://effect.website/docs/guides/error-management/expected...

Stoids

2 年前議論

I think going all-in on Effect in its current state is not something I'd do. However there's a subset of its functionality that I'm currently replicating with a bunch of different libraries: ts-pattern, zod, some lightweight result / option wrapper like ts-belt, etc. Pretty much trying to pretend I'm writing ML / OCaml. Having those all in one package is quite convenient. Add in TypeScript's the much needed story around retry / observability / error handling—I see why people lean into it.

Having experience with ZIO / FP in Scala, I'm a bit biased in seeing the value of Effect systems as a whole, but taking on the burden of explaining that mental model to team members and future maintainers is a big cost for most teams.

Stoids

2 年前議論

The fragmentation around runtime validation libraries is pretty crazy. The fact that half these comments mention some alternative library that mimics almost the exact API of Zod illustrates that.

It is filling a necessary shortcoming in the gradual typing of TypeScript, and using validator schema types to power other APIs generic inference is powerful. I am optimistic about an obvious leader emerging, or at least a better story about swapping between them more easily, but a bit annoying when trying to pick one to settle on for work that I have confidence in. That being said, Zod seems like the community favorite at the moment.

Stoids

2 年前議論

I do consulting for a few restaurants, and despite my experience building full-stack web applications, I find myself reaching for Excel for most of my deliverables. These are "applications" that "non-technical" restaurant operators need to be comfortable in. Having a sheet where they paste in some data and get their needed output has required the least amount of continued maintenance and training. They can drag the file around in Dropbox / Google Drive and that works for them.

I still try to "engineer" to the best of my ability—separating raw input from derived data from configuration, data normalization, etc. With Lambda functions in Excel now, I kinda just pretend I'm writing Lisp in an FRP editor / runtime environment. The ETL tools with PowerQuery are quite good for the scale that these restaurants operate at.

Hard for me to turn off my brain in my full-time job when I am tasked with poorly recreating a feature that Excel nailed years ago.

Stoids

2 年前議論

Do you have any favorite resources (can be books, courses, blog posts) that teach with this approach from? I have been diving more into 3D and the shortcomings in my mathematical background are starting to show.

Stoids

2 年前議論

I have not used it in production yet, but it's been great for one-off scripts and side projects. Setting up a TypeScript Node environment with ts-node, ts-jest, ESM support, top level await, etc. is more annoying than it should be. More recent Node releases have alleviated some of this pain, but not as trivial as running bun init.

I've enjoyed using the bun shell [1] API.

[1] https://bun.sh/blog/the-bun-shell

Stoids

2 年前議論

I like the idea, especially the TS-like syntax around enums and union types. I've always preferred the SDL for GraphQL vs writing OpenAPI for similar reasons. Most APIs I've run into in my career would benefit from modeling their API responses as ADTs versus the usual approach of overloading 4 different union members into a giant spare object.

I echo the sentiment others have brought up, which is the trade-offs of a code-driven schema vs schema-driven code.

At work we use Pydantic and FastAPI to generate the OpenAPI contract, but there's some cruft and care needed around exposing those underlying Pydantic models through the API documentation. It's been easy to create schemas that have compatibility problems when run through other code generators. I know there are projects such as connexction[1] which attempt to inverse this, but I don't have much experience with it. In the GraphQL space it seems that code-first approaches are becoming more favored, though there's a different level of complexity needed to create a "typesafe" GraphQL server (eg. model mismatches between root query resolvers and field resolvers).

[1] https://github.com/spec-first/connexion

Stoids

2 年前議論

ts-pattern has been a decent band-aid for the lack of native pattern matching, but obviously has downsides that could be avoided if it was built into the language.

https://github.com/gvergnaud/ts-pattern

Stoids

7 年前議論

Jonathan Blow and no one else clearly.

Stoids

7 年前議論

Yes, almost any routing library will expose a Link component wrapper that properly sets those attributes.

コメント