Katja Lutz ๐Ÿฆ‹๐Ÿ‡จ๐Ÿ‡ญ

Katja Lutz ๐Ÿฆ‹๐Ÿ‡จ๐Ÿ‡ญ

@katywings.bsky.social

Anarchist altruist, down-to-earth, independent hobby astronaut ๐Ÿง‘โ€๐Ÿš€ and amazingly lively, passionate web developer, in the stand against the technocrats. Creator of @nitropage.bsky.social, the FOSS visual website editor. nitropage.org / lufrai.org

386 followers406 following595 posts

The cause of it is a complete lack of ethical persistence and estimation of human craft. Most individuals totally ignore the fact that LLMs are disrespectfully trained on OSS code without consent. As if that weren't enough LLMs amplify narcissistic mindsets.

Ryan@rschristian.dev

I've found the OSS scene to be super depressing lately. Quite a few individuals that I've respected for years due to the care, quality, and thoughtfulness put into their work have done this strange flip where they've entirely abandoned that, switching to a model of just throwing shit out the door.

Figured out a workaround: Instead of enjoying Drizzle's "with" relational queries, just use multiple separate queries. This atleast brings the performance back to Prisma levels ๐Ÿซ ๐Ÿฅณ.

So Drizzle is faster than Prisma - until it isn't ๐Ÿซ . I am currently benchmarking @drizzle.team with Nitropage and the relational queries are 2-3 times slower compared to Prisma 6.19 ๐Ÿ™ˆ. github.com/drizzle-team...

What the F are we even doing? First corpo disrespectfully trains LLMs on oss code without consent. Next we sell our successful, yet for some reason unsustainable projects to corpo. Then we disable external PRs. Whats next? Make everything closed source again?

Vitest@vitest.dev

We are updating our AI Policy to reduce maintenance stress. All pull requests are now automatically closed, unless they are created by maintainers or users from an approved list of contributors. The PR is not lost. If the team decides the change is worth pursuing, we will reopen it.

Katja Lutz ๐Ÿฆ‹๐Ÿ‡จ๐Ÿ‡ญ reposted

this approach is a bad trend ๐Ÿ™๐Ÿ‘Ž how are contributors supposed to know whether you even looked at a PR when every PR gets closed without comment there is no signal just close the PR with no comment - it signals you looked and you closed it it's how GitHub works and it works! this doesn't.

Vitest@vitest.dev

We are updating our AI Policy to reduce maintenance stress. All pull requests are now automatically closed, unless they are created by maintainers or users from an approved list of contributors. The PR is not lost. If the team decides the change is worth pursuing, we will reopen it.

Hate to say it, but it seems like Prisma v6.19 is the last good js orm. Conclusion after trying to migrate from Prisma v6.19 to Prisma 7 / Drizzle v1 RC4. Both promise performance improvements, but end up 2-5 times worse than v6.19. I hope Drizzle v1 RC5 (coming in 2037) will change things ๐Ÿ˜….

So Drizzle is faster than Prisma - until it isn't ๐Ÿซ . I am currently benchmarking @drizzle.team with Nitropage and the relational queries are 2-3 times slower compared to Prisma 6.19 ๐Ÿ™ˆ. github.com/drizzle-team...

github.com[BUG]: RQB-V2 creates low performing queries in MySQL and Postgres ยท Issue #5245 ยท drizzle-team/drizzle-ormReport hasn't been filed before. I have verified that the bug I'm about to report hasn't been filed before. What version of drizzle-orm are you using? v1:beta8 What version of drizzle-kit are you u...

Any @drizzle.team pros willing to quickly review this little prisma->drizzle migration PR ๐Ÿ˜‚? codeberg.org/nitropage/ni...

Stop using LLMs is the answer. You stop purchasing products from disrespectful companies. You stop supporting them to steal art, texts and code from other human beings. You have to learn again, you have to care again and you have to take your time again. But you will feel excited again.

Thilo Maier@maier.tech

I used to be so excited about the SvelteKit v1 and v2 releases. v3 is probably another topper. But with agentic coding, I feel no release excitement. The thing that keeps me busy (not excited) is how to not sink with my team in an ocean of technical debt in which little details don't matter. ๐Ÿ˜ข

Katja Lutz ๐Ÿฆ‹๐Ÿ‡จ๐Ÿ‡ญ reposted

๐Ÿš€ Nitro v3.0.260903 is here! ๐Ÿงญ Smarter, Safer and Faster Route Rules ๐Ÿ’พ Powerful Caching Utils ๐Ÿ—„๏ธ New DB Connectors and ORM Integrations ๐Ÿ”ญ Native Vercel & Cloudflare Tracing โ–ฒ Vercel Deploys with Immutable Assets ๐Ÿ“ฆ Smart prompt to install deps ๐Ÿ”’ Strong Security

Localization for German and English is deployed ๐Ÿš€. I used this as a little case study on how localization will work with Nitropage Core.

Today we had the going live of llum-spectacles.com powered by my OSS CMS Nitropage ๐Ÿฅณ! It's the landing page for high performance glasses designed by a friend of mine ๐Ÿ˜Š.

In the localization abstraction I am designing for my CMS, you will be able to change most of the settings on localization level. E.g. you will be able to show different images depending on language :). But this opens up a tough question:

Should a localization abstraction allow the switch of the default language by design? E.g. you have an english/german website, english being the default, now you wanna switch to german as the default - must this always be possible, even if it means more work for the user?

Or is it reasonable to have an abstraction that allows the user to choose between: - A: Default language integrated into non-localization related default settings (easier to work on a new page) - B: Default language separated from other default settings (easier to later switch default language)

Katja Lutz ๐Ÿฆ‹๐Ÿ‡จ๐Ÿ‡ญ reposted

Formisch v1 is here. ๐ŸŽ A schema-first form library for 8 frameworks: React, Vue, Svelte, Solid, Angular, Qwik, Preact & React Native. โœ… One Valibot schema = types + validation โœ… Native performance across all 8 frameworks โœ… Headless โ€” works with your existing UI โœ… Bundle size starts at just 2.5 kB