They can, but it will not mean anything until someone references them. The important part is incoming vouches, not outgoing ones

I really like this concept but the lack of signatures means someone can just copy and paste your human.json, no?

Interesting concept, but I have to assume it's gonna get corrupted by LLM bros eventually.

I have a website, but I honestly wouldn't know who else to trust, so that is also a problem.

idk. I just write scripts for myself. I keep meaning to get trained on git though

I've just started reading "Working Effectively with Legacy Code", and so far it has been great.

While I'm having troubles with it mostly because I work in gamedev, and a lot of the TDD approaches are difficult to apply (or actually merge into the codebase, since it's simply not an industry practice and I'm nowhere senior enough to be able to push as big change in workflow), I've still learned a lot, especially cool tricks about how to add/fix features or refactor.

It should be recommended reading for anyone who deals with codebases.

Isn't that exactly what the commit message is for?

I at least preserve the old code in a comment, and write a dated not about what I was fixing

that's exactly what happened with recent project I worked with it's https://spaidyslabs.com/ if you are interested. we just shove whatever worked at the time of developing it and now it just a mess!

no policies protecting the supabase, all the supabase calls are coming from client instead of the backend which makes it so difficult to make it secure. 😭

at this point I think we need a entire rewrite of the database and the nextjs code which takes time and effort 😭😭😭

So "modern" design that has too much wasted space and "mobile"-fied fields? That's actually my original discontent with Facebook and Reddit, so glad I never made a home out of Stackoverflow.

Reminds me there are a few used bookstores in nearby big cities. Maybe I should travel to some on a development books hunt at some point...

Then I ask if they'd want something like that.

"Well... but it looks a bit simple, doesn't it?"

Simple is the word that keeps coming up. And I've learned that when a client says simple, they don't mean easy to use. They mean not impressive enough. They mean what will people think. A lean, fast website doesn't look like it cost anything. It doesn't signal effort. It doesn't say: we take this seriously.

The real irony is that building something genuinely simple, something that loads instantly and says exactly what it needs to say and nothing more, is often harder than bolting on a chatbot. But that's invisible work. Nobody sees the restraint.

—

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

-Antoine de Saint-Exupéry

The pressure isn't really coming from clients anyway. It's coming from the web itself, from a decade of bloated pages, dark patterns, and feature arms races that quietly redefined what a "real" website looks like. Clients are just reading the room. The room is wrong, but they're not imagining it.

The shift might come from users, not decision-makers. It might come when enough people notice that the fast, calm site was easier to use. That they actually found what they came for. That they didn't have to close three things before reading a single line.

Everyone is to blame here:

clients want flashy websites, not considering user experience

managers don't translate wants to real needs and pass the problem to devs

devs like to have less work, so they will gladly insert random external dependency to fulfill the growing number of wants

users just accept shitty websites without complaining, even letting themselves take the blame - if X is slow, then it is time to buy a new PC

MEGA MENUS was the thing I hated most. I’m strongly opposed to any hidden content.

Yeah that's why I couldn't stay in design work. Too many times the client wants you to take your balanced, appealing attempt to express their vision and turn it into clipart.

The quote made me optimistic. It's a shame that clients followed their own observation about straight-to-the-point websites loading fast and being easy to read, with a degrading remark about the simplicity of such websites. I realize that the point of a web developer job has always been something different than making good websites (as a whole, it's closer to first making something nice and then trashing it with your own hands), but that's a dreadful realization.

The library in the post itself is pretty new, so I don't think there are any real examples out there aside from the website advertising it.

That said, its idea of sending HTML from the backend and showing it in the frontend isn't new - HTMX has been pretty popular the past few years and is basically the same thing. It's great for any type of website that doesn't update often, so anything that isn't a webapp or does a lot of things from the client side. There's a popular article of a company switching from React to HTMX which simplified the code heavily.

Btw: I wish there was some showcase of example (ideally open source) websites using this framework. Might be helpful in making decision of actually using it

Nice, but feels like it has really narrow use case. Probably excellent for blogs, landing pages, maybe news sites. But I'm afraid anything more interactive would be a nightmare... although I wish to be proven wrong.

The alternative isn't to download random executables, it's to use your system's package manager

yet another web tool...

I like HTMX (:

I’ve seen people complaining about this for years. I still don’t fully understand how it’s so different from downloading random executables and running them separately. Maybe you could get in trouble if you get a network issue mid way? You can still MITM a file download. Feels like a weird hill to die on.

I look at the docs, see another tool yet again asks to curl | bash to install it, and sob.

Yes!! That's exactly what I though! 😅😖

Maybe AI is useful after all!! 🤣

inb4 --zz-top