I like Hotwire/Turbo more than HTMX because of its core philosophy: start by building a fully functional page without any JavaScript, and then layer in enhancements only as needed. That approach has stayed consistent for years and feels really straightforward to work with.
Readit NewsDeleted Comment
Justwatch | golang | Berlin | https://www.justwatch.com/talent/jobs/tech/streamingguide-ju...
Backend development at justwatch. Looking for all levels, not only junior.
Go, postgress, kubernetes.
No remote.
Feel free to contact: guillermo.alvarez at justwatch.com
> it will probably expand your knowledge
It really just fragments my knowledge to be honest.
Say "I gotta get things done".
Get me to a terminal. You've got Mac OS command line flags, GNU, BSD. Great.
Then it's some kind of asinine config to interact with some piece of software, all to achieve "generally the same thing", just a different way/flavor.
I really don't see the benefits.
It’s like driving a car. Most people can drive without needing to understand the internals, and it’ll still get them from point A to B. But just like some people enjoy diving deep into car mechanics, others enjoy understanding the intricacies of software.
For me, that deeper knowledge is an advantage. It helps me quickly evaluate tradeoffs between databases, debug at the OS level, or dismiss a library still relying on select if I expect heavy load. This insight saves time and increases efficiency.
I use Linux, FreeBSD, NetBSD, and OpenBSD all for fun, learning, and profit(the first two).
At the very least it is nice to make acquaintance with at least one BSD because it will probably expand your knowledge on Linux in ways you wont be able to anticipate.
For example, FreeBSD got me into kernel development, full system debugging, network stack development, driver development, and understanding how the whole kit fits together. Those skills transferred back and forth with reasonable fidelity to Linux, and for me jumping into Linux development cold would have been too big a leap.. especially in confidence and developing a mental model.
For my personal infrastructure, I tend to use FreeBSD because in many ways it is simpler and less surprising, especially when accounting for the passage of time. ifconfig is still ifconfig, and it works great. rc.d is all I need for my own stuff. I like the systematic effects of things like tunables and sysctl for managing hardware and kernel configuration. The man pages are forever useful to new and old users. The kernel APIs and userland APIs are extremely stable akin to commercial operating systems and unlike Linux.
There are warts. There are community frictions. The desktop story and some developer experiences will be perpetually behind Linux due to the size of the contributor base and user base. The job market for BSD is very limited compared to Linux. But I don't think it's an all or nothing affair, and ideally in a high stakes operation you would dual stack for availability and zero-day mitigation (Verisign once gave a great talk on this).
I completely agree! If you're looking to deeply understand how Linux works under the hood, I highly recommend trying out Linux From Scratch. It gave me invaluable insight into the system, especially when I first explored it 20 years ago. Building everything from the ground up—without relying on prepackaged distros or libc—was a game changer.
Check it out: https://www.linuxfromscratch.org/
If an intruder gets into my local account, I'm far more worried about them stealing my cookies or accessing company IP than my browser history.
With cookies and browser access, they could get into my emails, family photos, bank accounts, and even read desktop notifications from my phone's SMSs.
For developers, the real risk lies in the variety of dependencies our apps have, which could get compromised.
So, this isn't really news. There are also tools to access all your iMessage history from a Mac, for example.
I believe the feature is really useful, and for sure you can turn it off.
Justwatch | Golang eng (Junior/Senior) and Senior ML engineer | Berlin (min 2days in office) | full time
Hi. I am Guillermo, backend developer of StreamingGuide. We try to make justwatch.com the best streaming guide worldwide.
We predominantly utilize Golang and Kubernetes, interfacing with GRPC APIs from teams such as Content (housing "the" database) and Martech (for ad display). Additionally, we work with databases like Scylla and Elasticsearch, ensuring seamless operation even under high loads exceeding 5k requests per second.
We're tackling challenges like integrating video ads, fortifying against scraping, enhancing response times, and optimizing the click-through rate for our recommender engine.
My colleagues from the content team, are also looking for a ML expert that help us finding the right recommendations.
If you in, write me (guillermo.alvarez@justwatch.com) or visit: https://www.justwatch.com/talent/jobs/tech/streamingguide-se... (Junior offer to be open soon).
What makes this less of a rabbit hole than the alternatives you mention?
If you have discipline, probably none.
The difference is developer behavior that each framework encourages.
While htmx/turbo focus in just couple of helpers and then leave you with the full HTML/JS, in a react ecosystem you end having with 3 party components, and a state management system and build system that will change in 10 months. I don't say it isn't justify and that it have its pros, but it's a rabbit hole in my experience, where you easily end fighting with the framework than focusing on business.
Maybe if one’s mobile apps are just a WebView. Otherwise you’re maintaining a REST API for the mobile apps and the Hotwire/Livewire request handlers that deliver html fragments.
IMO PWA is a client issue and should be handled client side without introducing server dependencies.
For sure, there are cases in which a PWA focus is to add offline support, and you are totally right there.
However, I will argue that 80% of PWA exist to have proper push notifications, or faster development than native.
https://go.dev/blog/wirehttps://github.com/google/wire