I think there’s a difference between what’s expected/acceptable for library code vs application code. Types like this might be hard to understand, but they create very pleasant APIs for library consumers. I’ve generally found it very rare that I’ve felt the need to reach for more complex types like this in application code, however.
RXJS’s pipe function has a pretty complex type for its signature, but as a user of the library it ‘just works’ in exactly the type-safe way I’d expect, without me having to understand the complexity of the type.
A vibe-coded double pendulum sim should produce a much better result than the physics on this page. Claude Code made this just now off one prompt, the physics are much better: https://keir.is/swinging
In an ideal world you'd have one source of truth for what the shape of a User could be (which may well be a discriminated union of User and AnonymousUser or similar).
Without fullstack TS this could look something like: (for a Python backend) Pydantic models+union for the various shapes of `User`, and then OpenAPI/GraphQL schema generation+codegen for the TS client.
The problem with this is that your One True User shape tends to have a bunch of optional properties on it. e.g., in the user profile you fetch Post[], but in the user directory you don't, and so on with other joined properties. If every endpoint returns the One True User, then you end up needing to write conditional logic to guard against (say) `.posts` when you fetch users in the profile, even though you know that `.posts` exists.
In Typescript at least, if the discriminated union is set up correctly, you just need a single check of the type field. That lets TS narrow the type so it knows whether e.g. `.posts` is present or not.
I think I can do this, yes, but it becomes a very large amount of repetitive work.
Let's say I have api/profile (which has `.posts`) and api/user-directory (which does not). I define User as a discriminated union - one has type `user-with-posts` and one has type `user-no-posts`. OK, good so far. But now say I have a photo gallery, which returns photos on user. Now I have to add that into my discriminated union type, e.g. `user-with-posts-and-photos`, `user-with-posts-but-not-photos`, `user-with-no-posts-but-yes-photos`... and it gets worse if I also have another page with DMs...
You can use a string union to discriminate when it makes sense, but that's not the only way to discriminate and in this case you'd instead use the presence of the items themselves (essentially duck-typing with strong type guarantees)
Change the design of the API so that the posts and the photos and so on are not returned inside the user object but on the same level as it.
So {user: {...}, photos: [...]}, not {user: {..., photos: [...]}}.
Alternatively define separate schemas for each endpoint that extend the base User schema. But I'd prefer having the same structure everywhere as much as possible.
Not sure how other stacks solve this, but with GraphQL the backend defines a `User` type with a full set of fields, and the client specifies only the fields it wants to query. And with codegen you get type safety.
So on the /posts page the client asks for `{ user: { id, posts: { id, content }[] } }`, and gets a generated properly-typed function for making the query.
Whether this was done on-camera or in post, there's color grading happening here. The moody, almost film-like quality present in these pictures is also really popular in high production TV shows right now. Also a good eye for fun compositions, like the shot with the wall/barrier present in the left to offer the feeling of being closed or restricted.
Notice how the shadows are somewhat teal-tinged and the contrast is toned down. There may or may not be some grain or vignetting added in post as well. There are Lightroom color profiles that can get this sort of color feel on application. But the compositions and natural lighting are pure photographer skill to chase.
Good camera + good lens + good photographer + good processing.
Photography is a deeper, more subtle art than a lot of people realize. Two people can take a picture in the exact same location and time and get wildly different results.
I think with good presence (being able to see what other users are doing) and an app that isn't used offline, conflicts are essentially not a problem. As long as whatever is resolving the conflicts resolves them in a way that doesn't break the app, e.g. making sure there aren't cycles in some multiplayer app with a tree datastructure. Sounds like Zero has the right idea here, I'll build something on it imminently to try it out.
I've used PixiJS and react-pixi-fiber to write a declarative 2D WebGL renderer in React with excellent results. PixiJS also has a Canvas2D fallback when WebGL isn't available. I wonder how this compares.
Konva is much easier to use for simpler apps, especially combined with React. You basically define some shapes similarly to how you would declare any component, pass props and event handlers to it, and it just magically works.
Pixi is lower level. It takes more scaffolding to get to the same level of functionality. But it can be more performant for some draw intensive operations. Not that Konva is particularly slow though.
I think "tons of code and maintenance" is an exaggeration for this effect, once it's done you'll rarely have to come back to it.
Many people value creating and using products with these kinds of details, I disagree with "don't use this in projects you intend to maintain" as across-the-board advice.
I disagree. Check the changes required to the spacing/sizing. Soon you will need to adjust those values and that.is.maintenance. Multiply this by each detail and soon you have more work than you signed up for. This is usually when someone comes along and wants a rewrite because the codebase is fragile.
If you're using a CSS preprocessor like SCSS or LESS you can just define the height for the toolbar as a variable and then use the mask area for the blur as a multiplier (eg. 1.88) of that variable. In general for making things easy.to.maintain it's better to not build project-wide stylesheets with raw CSS.
It's not universally safe to use CSS nesting yet. Without nesting support, writing raw CSS is like raw-dogging a sex-trafficked Vietnamese prostitute from Malaysia. Sure, it will probably work, but if your goal is zero maintenance then you're ignoring the post-exposure prophylaxsis and antibiotic regimens necessary for typical usage patterns.
> I disagree with "don't use this in projects you intend to maintain" as across-the-board advice
Backdrop-filter is... fine. Using masks, animations, and backdrop filter, and gradients, especially for fine details like edges, are just asking for trouble.
Browsers are incredibly complicated, and rendering engines have lots of edge cases, broken features, slight incompatibility issues some of which vary by hardware/os/enabled-flags.
I’m at the point in my career where if it’s an internal project, zero shame for Bootstrap and JQuery. If that’s what floats your boat, do it. It’s simple, well understood, functional.
RXJS’s pipe function has a pretty complex type for its signature, but as a user of the library it ‘just works’ in exactly the type-safe way I’d expect, without me having to understand the complexity of the type.