I've been evaluating schema libraries for a better-than-Zod source of truth, and ArkType is where I've been focused. Zod v4 just entered beta[1], and it improves many of my problems with it. For such a mature library to improve like this, v4 is treat and speaks volumes to the quality of engineering. But ArkType has a much larger scope, and feels to me more like a data modeling language than a library. Something I definitely want as a dev!

The main downside I see is that its runtime code size footprint is much larger than Zod. For some frontends this may be acceptable, but it's a real cost that isn't wise to pay in many cases. The good news is with precompilation[2] I think ArkType will come into its own and look more like a language with a compiler, and be suitable for lightweight frontends too.

[1] https://v4.zod.dev/v4

[2] https://github.com/arktypeio/arktype/issues/810

- 3 new email chains from different sources in a couple weeks, all similar inquiries to see if I was interested in work (I wasn't at the time, and I receive these very rarely)

- escalating specificity, all referencing my online presence, the third of which I was thinking about a month later because it hit my interests squarely

- only the third acknowledged my polite declining

- for the third, a month after, the email and website were offline

- the inquiries were quite restrained, having no links, and only asking if I was interested, and followed up tersely with an open door to my declining

I have no idea what's authentic online anymore, and I think it's dangerous to operate your online life with the belief that you can discern malicious written communications with any certainty, without very strong signals like known domains. Even realtime video content is going to be a problem eventually.

I suppose we'll continue to see VPN sponsorships prop up a disproportionate share of the creator economy.

In other news Google routed my mom to a misleading passport renewal service. She didn't know to look for .gov. Oh well.

Remote: in-office/hybrid preferred, open to remote

Willing to relocate: yes

Technologies: TypeScript, Svelte, HTML/CSS/JS, Postgres, SQL/NoSQL, Node/Deno/Bun, AI prompt engineering

Résumé/CV: https://docs.google.com/document/d/1Fti-__uwjazBllAqR73wrQ1l...

Email: mail@ryanatkn.com

I’m a design-minded software engineer with 13 years of experience as a fullstack web developer. My specialty is frontends with novel UX, heavy interactivity, real-time updates, and high performance. I enjoy prototyping, architecting high quality maintainable systems, creating custom dev tools, and technical writing. I like the workhorse role and I’m open to being a lead.

I have a lot of experience with open source, and I recently dipped a toe into technical video creation and blogging. I’ve also been integrating AI more in my workflows - in 2024, I experienced LLMs reaching the threshold needed to increase my coding productivity without losing quality for many kinds of problems.

I'm not actively searching for work, so for example I’m not looking for non-Svelte frontend roles, but I would jump at the right opportunity. Please reach out if you think I could be a good fit!

You won't get a Svelte to look past the flaws of web components by saying "React is bad".

This cost will compound over time where new frameworks emerge, and components get stuck on older versions of their frameworks.

I can't see this as anything but significant, and not to be minimized. Having multiple redundant libraries on a page is not the direction I would advise anyone to take, particularly not when baked into the accepted best practices. This bodes poorly in the long term.

I've listened to the arguments from web component advocates in blog posts, social media, and videos for years now, and I should be in the target market. But on top of the interop tax, they're full of negatives that aren't present in the mainstream frameworks.

Interop works great within each framework's ecosystem. The same dynamics that cause developers to seek interop cause them to huddle around a small number of mainstream frameworks. So we get a few vibrant ecosystems that push the state of the art together. Web components cannot keep up on the tech side of things, and introduce a ton of complexity to the web platform - ignorable to me as a dev, but not for browser implementers - in service of their early 2010s designs.

[1] https://x.com/Rich_Harris/status/1840116730716119356

In the docs[1]:

> Instant uses a declarative syntax for querying. It's like GraphQL without the configuration.

Would you be interested in elaborating more about this decision/design?

[1] https://www.instantdb.com/docs/instaql

For undo-able actions, toasts disappearing too fast or colliding with other toasts badly is a real problem. An affordance to see the toast history with non-disappearing undo buttons may be more to implement but for a lot of apps, a viewable and editable history combined with toasts is a much better UX than either system on its own.