webdevladder

Higher friction and fragmentation are Fediverse features (not bugs) that give it a different grain. ATProto has different tradeoffs that lead to a different form of social media. I'm glad both exist, and bridging efforts are worth paying attention to for anyone frustrated with the distinctions.

You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees.

Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great.

ArkType is a really interesting library that has a difficult time marketing itself. More than being a schema validator, it brings TS types into the runtime, so you can programmatically work with types as data with (near?) full fidelity.

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

I believe I was the target of employment-flavored spear phishing a few months ago. Could have been a researcher like the OP.

- 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.

Location: United States

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!

Reminder that malicious impersonation is common and easily automated with LLMs.

Counterfactual invisibility is a real bummer.

Also the heuristic used to collapse file diffs makes it so that the most important change in a PR often can't be seen or ctrl-f'd without clicking first.

A more broad observation, I'm being pointed in the parent comment - web components need to win over framework authors. The signs are not trending well here from what I've seen consistently. That community is on X and web components are not addressing their problems and they're not used in optimal scenarios. I hope web components can win them over but they're mostly saying they've been a failure, arguably on balance bad for the web.

The point being made is that web components can pay this cost per-component, and this problem will compound over time. This is an unprecendented cost to frontend framworks and it's the expected usage pattern.

Look at the thread you've created here - I'm arguing that the article minimizes the antipattern cost they impose, and your response brings up React as if it somehow changes that.

You're ignoring page bloat as a performance cost. That's hugely impactful for UX on the web.

React is irrelevant for me and my users. This is not an argument in favor of web components over Svelte. Adopting web components would mean an objectively worse UX for my users - for example requiring them to enable JS.

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

You can judge React, but like I said, not frontend. You're responding to an argument I didn't make.

As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.

I think this minimizes the fact that interop - the main selling point to me as a user - comes at a performance cost where every component you use could have its own unnecessary runtime attached.[1] Using a framework like Lit with web components is the recommended way to use them.

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

This looks incredibly well-designed and documented, can't wait to watch some speed runs!

My experience tells me the opposite, it's an incredibly thoughtful and useful evolution IMO.

As a potential dev user this looks really intriguing, hitting all of the main points I was looking for. I build apps in this space, and the open source alternatives I've evaluated are lacking specifically in "live queries" or don't use Postgres. The docs look great too.

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

I tend to agree but I think toasts can still be useful and good UX. Putting useful and actionable feedback in context instead of toasts is a rule of thumb that I try to follow but it's not always appropriate.

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.

I wrote this blog post about how Svelte 5 (currently a release candidate) uses signals to fix two problems with its former reactivity system that was introduced 5 years ago.

If you were unaware, signals are being adopted by almost every major frontend framework except React. From the TC39 proposal[1] to add them to the JS language - "Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz". Adding signals to JS would enable standardized developer tooling around them among other benefits, the proposal describes more.

Signals also enable Svelte 5's fine-grained reactivity, which again puts it among the performance benchmark leaders, and the signals DX with runes[2] is simply fantastic in my experience.

[1] https://github.com/tc39/proposal-signals

[2] https://svelte.dev/blog/runes

There's also a video if you'd prefer to watch - https://www.youtube.com/watch?v=lcnimZTNOCA