I wish an alternative to JS for the front end would catch on and be something more than obscure... I'd love to use something like clojurescript, but I struggle to imagine doing so for anything but a personal side project :/ Maybe this is easier to adopt if you're already a clojure shop for the backend?
Are you worried because it’s not a mainstream language and coworkers may not know it, or are you worried about the language itself getting abandoned or being bad or such?
I’ve not used it in production, but I’ve shipped a few side projects and stuff for family members in it. ClojureScripts React wrapper, Reagent, honestly makes more sense to me than React does. I used Hiccup to generate HTML, and your components are just functions within Hiccups DSL (which is really just lists) and it ends up looking incredibly clean. Static things look static, dynamic things are obviously so, and it felt much less magic than regular React.
The only things I found that felt bad were trying to use non-functional components I found on NPM. It’s not a deal breaker, but the code was ugly. Nothing I couldn’t fix with a wrapper, but some JS libraries are heinously ugly in cljs by default.
A big reason why react in clojure can make more sense than react itself is because clojure is much more declarative than JavaScript. There's been a lot of work done on the react end to fix that but the mismatch will always be there.
The type of code you're writing isn't special, it's the way people have written lots of clojure programs for over a decade.
Totally agree. I also think Clojures relative lack of support for custom types leads to elegant APIs.
It’s a breath of fresh air that practically every DSL takes either lists or maps so I can use very similar patterns to build their input rather than “every API wants me to method chain their custom types so every API needs its own special helpers library for common patterns”.
I never realized how much I hate classes until Clojure.
Have you tried typed Clojure? Curious about opinions on that vs having Malli do runtime validation. I tried it when I was a total noob and got overwhelmed. I feel like I have just enough context now to try again, and not sure if it’s nice or the overhead is so high it’s a boondoggle
> Static things look static, dynamic things are obviously so, and it felt much less magic than regular React.
Yes! The moment for me was when React introduced their notorious useEffect/useState hooks API. It immediately jumped out to me as the wrong API, by making static things dynamic. Reagent was really a breath of fresh air. Reagent was a really nice API, though it somewhat encouraged inefficient code.
Don't be afraid, it's great! I certainly wouldn't call it "obscure", I've been using it for 10 years now to compile a complex app into highly-optimized client-side code. And the community is very welcoming and mature.
> I struggle to imagine doing so for anything but a personal side project
Don't imagine. You have any bash scripts your team uses? Rewrite them in Babashka. Start with your own personal scripts first, get a knack for it, feel the benefits (it's not going to be universally better for every case). You have to be very confident about it personally, because people will come for your guidance later.
This is a good strategy for introducing unfamiliar things - pick something less important, rewrite it, let it sit there. If it becomes problematic - easy to revert. If people start liking it, you can add more, and so on.
That's how I sneaked F# in my .net shop years ago - I started writing less important tests in it.
I agree! I have kept an eye on Elm for many years, I think the simplicity and architecture is great, but the language itself never clicked for me.
Then I was made aware of Lustre[1], an Elm inspired web framework in Gleam. I have done two small projects in it now and I really enjoy working with both Lustre and Gleam.
Building UI in HTMX is such a breath of fresh air. I hope it kills the "React" style big complicated SPAs. Its so easy to develop in, its so fast to run, so fast to load.
Ten years ago we were writing ClojureScript for the frontend at work. We weren’t a Clojure shop at all. As my then manager said, picking ClojureScript was part of the hiring bar: people who weren’t interested in functional programming tended not to be good programmers and so we avoided hiring these people.
Check out Mint (https://mint-lang.com), it's s language where everything is built in: small to mid size projects can be built without any third party dependencies and JS interop is easy.
I've had some incredible product ideas while asleep, down to very intricate technical detail. The problem has been that when I wake up, reality kicks in, and I realise that, say, even if I built that incredible messenger app for dogs, they still wouldn't be able to communicate with us.
If you’re interested in prototyping something, the buttons Christina Hunger sells are able to send webhooks. I made a Telegram bot for receiving messages “typed” by my golden. (She’s less than one year old, so the sentences she makes are really basic.)
Really sad to see this. I had only recently learnt about this project, and was really impressed by it. I was planning to set it up this weekend (via autobase). I've also been under the impression that it's likely to be what powers the backups in RDS, Cloud SQL, etc., but I may have misunderstood.
I wondered the same! FWIW I'm currently migrating from managed postgres to self-managed on hetzner with [autobase](https://autobase.tech/). Though of course for high availability it requires more than one server.
Beware of Hetzner Cloud volumes, they're unusable for a database, they're too slow. I'm not sure what workloads people run on Hetzner but the low-performance volumes and unreliable load balancers don't seem like a good fit for real production stuff with traffic.
I've run some benchmarks a couple years ago, I don't have them at hand unfortunately but off the top of my mind, seqread 4k produced around 1500 IOPS while seqwrite was like a third of that. The practical performance was abysmal, I moved PostgreSQL storage to a volume and it was very noticeably slower just by browsing the web app (compared to NVMe SSD storage).
For comparison, I'm now using UpCloud which uses network-attached storage for all volumes and easily hits 10k IOPS (up to 100k with some tuning).
I certainly may have missed something while testing this so I'm happy if someone else wants to contribute and correct me if I'm wrong.
I'm not the OP but I came here to voice the same concern. I would love to use something like this. I also signed up for rewind.ai and Limitless and pre-ordered the pendant. But ultimately I cancelled it out of privacy concerns.
I wonder if it could be local storage and you could provide your own Open Router endpoint? That way it could be a local model or your own deployment of GPT/Claude in Azure/Bedrock/Vertex etc where you can control retention policies etc.
Basically, I want to know that you guys don't have access to view my stuff. I get that that limits your ability to improve the product and support issues, but when I'm sending everything it really starts to matter. Just thought I'd share what held me back from immediately signing up despite really wanting to use a product like this!
Maybe you could try AirJelly, a context-aware proactive AI companion we are building recently. Data are all stored locally, on your MAC. Local LLM models would be difficult, as we also use Claude/Gemini to serve as the model provider. But as the software builder, we don't collect any user information, anything for improving our product would be sent by our users voluntarily (just send feedback in the app). If you would like to try, you could visit our website airjelly.ai.
Just what I'm looking for, but I'm reluctant to trust a third party with full time screen recording of my device... Any chance of local processing (or even custom LLM endpoints) in the future?
I'm having a hard time understanding how this is different from a bastion server, where you're tunneling through an intermediary server that you've deployed in the target network.
I guess the difference is the fact that the intermediary server doesn't need a port open (as standard nat punching will work)? Or are there other big differences?
We've setup and used peer-relays since it was first announced and they've been great, but they do solve a somewhat specific problem.
Some of our users experienced fairly limited throughput from time to time. Under certain circumstances (eg. always ipv4 NAT/double-NAT, never for ipv6) their Tailscale client couldn't establish a direct connection to the Tailscale node in the datacenter, so data was relayed through Tailscales public relay nodes. Which at times was rate limited/bottleneck - in all fairness, that is to be expected according to their docs.
The first mitigation was to "ban" the specific public relay they were using in the policy. Which helped, but still not a great solution and we might just end up in a weird whack-a-mole-ish ban game with the public peer relays in the long run.
So we setup a peer relay, which networking-wise is in a DMZ sort of network (more open), but location wise still in the datacenter and allowed it to easily reach the internal (more restricted networking) Tailscale nodes. Which solved all throughput problems, since we no longer have users connecting through the public relays.
Also, the peer relays feels a little bit magic, once you allow the use of them in the Tailscale policy, it just works(tm) - there is basically zero fiddling with them.
EDIT: I'll happily provide more details if interested - we did a fair amount of testing and debugging along the way :)
I think that biggest difference is that your client applications don't need to be explicitly configured to use the bastion server. For example ssh, web browsers, rdp, samba and so on can just pretend that you are inside the target network. Doubly useful if this is a "customer" network and you are working with multiple customers.
Not the OP, but I've got a "Names to remember" evergreen note in my Reference folder. Within it, I have a few headings (e.g. neighbours, or locations), and a bullet point for each person, with context that will trigger the memory. That might sound like there's a lot of structure, but it's really the act of writing it down in the first place that helps me remember.
reply