Yet another thread of React vs the rest of the world. Each has its use case, and most of the time, React/Vue are largely overkill. Personally, I would never, ever, ever start another React project again. The nightmare of the horrible JS ecosystem, build steps and tooling is behind me. All my projects now use either HTMX or Alpine Ajax - and for web apps that are actually pretty large. It works perfectly fine. Add Turbo to the mix and you almost have the feeling of using a real SPA, without the headache and large bundled JS files. Feels refreshingly simple. Still have to figure out the no-build step so I can completely drop Bun/Yarn/Npm, and life will be a wonderful thing.

Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.

I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems.

Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style and not realizing some injected fragment of HTML somewhere relies on it being a certain way. I hope you’re using a monorepo because unlike typescript APIs, those HTML fragments and CSS styles are not type checked.

This is easy to solve. Just configure htmx to automatically add an `Accept-Version` header to its requests:

    document.addEventListener('htmx:configRequest', evt => {
      evt.detail.headers['Accept-Version'] = APP_VERSION;
    });

And have a middleware that checks for this header. If it finds a version mismatch, have it respond with an HTTP 400 and a message to update the app to get the latest version. This is pretty similar to what many SPAs are already doing nowadays so it shouldn't come as a big surprise.

Well yeah, HTMX wouldn't be a good fit for micro-frontends, but I didn't think many people were actually using those. You have to write all your html in accordance with a single stylesheet, but that strikes me as the least of HTMX's impositions.

That's because jquery takes a very global approach to the DOM, which will naturally lead to spaghetti code.

Every backend framework, be it dotnet or Symphony or Rails, has a concept of components. It's a non-issue.

Thanks. It's exactly what I thought, but written in a funny way. I'm so sick of this way of writing, which is actually tuned to appeal to the broadest audience possible and follow every guide on "how to write efficiently".

No. Kagi uses Google results behind the scenes. Partner with Duckduckgo, yes. Or others. But please stop fueling Google, even indirectly.

DDG uses Bing instead, that's not really any better. Ideally a Browser should not partner with any websites. It's always been a deal with the devil even when Google was not as evil.

To me, Firefox has way better dev tools than Chrome. I don't even mention Safari here - who can stand their horrible dev tools? Firefox has a fantastic add on marketplace which competes with Chrome's. Firefox without too many addons actually do not drain battery life on MacOS. Firefox has "native" profile management with real separation of cookies. JS benchmarks provide no value to me, since I try to avoid heavy-JS web apps anyway.

I don't know. As a dev and user, Firefox wins on every single aspect for me. I understand that every user is different. But I'm glad it exists.

I had the same thoughts a few months ago, and then someone told me Atuin Desktop is made for DevOps and the likes, in order to scale manual and repetitive operations accross many teams. This made sense to me.

We have CI actions we use to configure and deploy dev namespaces. We document a bunch of steps for these actions in a doc, including situational tweaks. I could see this being a great replacement for that, given the right integrations.

Tried it few days ago, and came to same conclusion myself. In a way, it's like Ansible but simpler for some use cases.

Manual repetitive processes are already a smell. Shared across teams?

One of the main things we’re aiming to do here is make these manual processes much less manual! I’m a big believer in automating things gradually, which runbooks enable

You are downvoted but I actually agree with you. This blog post could have been a LinkedIn post from any "influencer", considering how generic it is.

Technically really impressive. In practice, completely unpractical in any medium to large organization. And although I adore Zed's speed and reliability, I still don't understand why we need these features at all.

Because Zed is not somebody's side project, it's a business looking for ways to pay everybody's salary

> Collaboration as it stands today is considered alpha, and for the time being, is free for all to use! Peruse the source code.

Based purely on this blog post it looks like they are trying to compete against notion but with an IDE extension

Because "maximum editor" was achieved with Visual Studio Code (which is why all these new editors look and feel like VSC), the same way "maximum toothbrush" was achieved with the electric toothbrush. But the toothbrush industry had to keep going, so now we have a $400 bluetooth connected toothbrush-as-a-service that monitors your brushing habits to optimize teeth cleanliness, with brush heads that cost more than 5 regular toothbrushes.

Zed and the current crop of AI editors (including VSC itself) are that toothbrush.

Beets is amazing. The fact that it exists is a blessing for those like us who maintain our own music library.

I've been wanting to build my own Plex alternative for a while now. I've tried all the other tools out there, but Plex is definitely the least bad tool that let me enjoy my music without subscribing to Spotify and others.

I've already spent hours trying to figure out all the things that are required to make this new system. And it's unbelievably complicated. From parsing metadata to converting music, to understanding how deep and complex tagging work for music (yeah, it doesn't sound like it at first, but it truly is infinitely complex), I'm overwhelmed by how hard it would be to build a tool that compete with a combination of beets/iTunes.

There are a lot of alternatives for music servers in the world. Can I ask if you've explored Plex alternatives (Jellyfin, Emby, Lyrion, Navidrome, various Subsonic/OpenSubsonic-compatible servers, etc.), and if so, what you need that they don't do?

I ask because I'm working on a new music app for iOS which has pluggable sources, and so my bias is that most of the issues preventing me from easily enjoying my music library are actually on the client side.

Frictionless use is the biggest one.

I can install Plex, all my movies, tv-shows, anime and music is there.

Then I can drop Plexamp on my phone, log in with my Plex account and all my music is right there and if I rate a song on my phone, it's updated on Plex and vice versa.

Plexamp is what I settled on too, before deciding that I was only going to be happy if I built something better.

Plexamp is quite good as a standalone app, but as close to greatness as it is, it's a React Native app (better than a Flutter app, but still) that doesn't play well with the iOS ecosystem — no widgets, virtually no Siri/App Intents support, no Apple Music integration, etc.

I also decided that it shouldn't matter where my music "lives", and so it supports any local, self-hosted, or cloud-based source. (These are working today: https://imgur.com/szrkeIJ)

Hard to talk about "everyone" since I'm not aware of any large polls around this point. On a personal note, yes, considering that I'm 44, I tend to always increase font size everywhere: the code editor, the terminal, the browser, the OS itself and mobile phone.

It's unavoidable for me. I was making fun of those people with huge font sizes on phones 10 years ago. I'm almost one of them now.