Twitter, still.

Despite several attempts to move off, the center of gravity is still there.

I recently rewrote my frontend's API from GraphQL to REST (I had a public API that was always behind on functionality - this approach forces me to keep it up to date), using Hono + Zod has been brilliant for creating types that my frontend can consume AND generate into OpenAPI specs/clients.

I get several folks per week claiming an ai/llm recommended them my product, while I personally wouldn't run a procurement process that way, some certainly do.

> Claude is never on the web reading documentation - as far as I can tell that's not even in its toolkit.

Add the Context7 and grep MCP servers to your installation, it'll change your life (well it'll make claude less dumb).

I always saw it as bimodal (even before LLMs) - you have folks working in regular shops making average comp, and you have the big tech elites earning high base + equity comp.

The Pragmatic Engineer argues it's actually trimodal (at least in Europe): https://blog.pragmaticengineer.com/software-engineering-sala...

Are you doing a year in review for the past year?

"5 times faster" reminds me of Cap'n Proto's claim: in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers: https://capnproto.org/

I mean, cap'n'proto is written by the same person who created protobuf, so they are legit (and that somewhat jokish claim is simply that it requires no parsing).

> I mean, cap'n'proto is written by the same person who created protobuf

Notably, Protobuf 2, a rewrite of Protobuf 1. Protobuf 1 was created by Sanjay Ghemawat, I believe.

Really dismissive and ignorant take from a bystander. Back it up with your delivery that does better instead of shouting with a pitchfork for no reason.

This bystander has been using protobufs for more than ten years. I'm not sure what I need to deliver since ASN.1, Cap'n Proto and Flatbuffers are all more efficient and exist already. ASN.1 was on the scene in 1984 and was already more efficient than protobufs.

Protobuf has far better ergonomics than ASN.1. ASN.1 is an overcomplicated design-by-committee mess. Backwards compatibility in particular is much harder.

I don't doubt your experience, but with X.509 having evolved substantially, and ASN.1 on billions (if not tens of billions) of devices, in practice it seems OK. And it was formally verified early.

ASN.1 on billions of devices doesn’t make it less of an anti-ergonomic, design-by-committee piece of crap. Unless your goal is to be binary-compatible with these devices, one should be free to explore alternatives.

By all means, keep using it, but it might be worth figuring out why other people don’t. Hint: it’s not because they’re more stupid than you or are looking to get promoted by big G.

(Personally, I like the ideas and binary encoding behind Capn Proto more than all the alternatives)

One of the advantages of of protobuf I never see anyone highlight is how neat and well-designed the wireformat is, in terms of backward/forward compatibility and lowlevel stuff you can do with it. Very useful when building big and demanding systems over time.

For high performance and critical stuff, SBE is much more suitable, but it doesn't have as good of a schema evolution story as protobuf.

lol are you accusing Sanjay of creating Protobuf to get promoted?

In my experience capn proto is much less ergonomic.

More info here: https://www.eu-inc.org/

Builtwith reports this website is built with Framer, is this an official EU asset? If that's the case it's also a declaration of intentions.

the FAQ clearly states that it isn't an official EU website, it was used for petitioning the EU to consider this proposal.

Thanks for poiting this out

I write about my experiences running an Internet business here: https://maxrozen.com/articles?q=diaries

Sure Bootstrap is better, for you.

Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.

For the rest of us, we throw that "bg-sky-500 hover:bg-sky-600 active:bg-sky-700 text-white px-4 py-2 rounded-lg" (or whatever color and shape matches our brand) into a component with a variant=primary property and call it a day. What developers actually see on a day-to-day basis is <Button variant="primary" />.

> Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.

You know that bootstrap is trivial to customise right?

It turns out identifying primary and secondary buttons is a pretty standard thing in any kind of UI that has... buttons.

Cant you just customize the css of btn-primary?

oof, that looks like absolute trash. i don't get why you want to use something less readable than css but to each their own i guess

TailwindCSS is useful for applying styles to isolated components, in paper-shredder scenarios. Devs using it get to ignore the cascade, don't have to name things, and can use the predefined spacing and colors.

It is of course quite unmaintainable (good luck with updating the class soup for a bunch of components across a project).

I personally just ... cannot. CSS in 2026 is incredibly powerful and beautiful. Embracing the cascade allows for minimal CSS (see ITCSS methodology). Standardizing spacing and type with https://utopia.fyi is brilliant. Standardizing colors with custom props is trivial.

But, it seems that a lot of people are not paid to think about CSS. Tailwind embraces that. LLMs love it, because it reduces the complexity of pure CSS.

LLMs are quite capable of rewrites these days - there are few tasks where I'd actually want 10 parallel agents, but rewriting off Next.js would've been faster with that setup.

(I ended up just using the claude web interface and making it use a checklist, took 8 hours)