> And Search is just completely unusable now. They built an entire empire off our content. Bloggers, old forums, niche sites. We made the web worth searching in the first place. Now their AI Overviews just scrape our exact answers, strip out the hyperlinks, and repackage it in a blue box without linking back.
I don't like that they throw AI overview on your face when you search, rather they should show AI overview on the right column and search results on the left.
I'm working on Daestro[0] - a job orchestrator that can directly integrate with cloud providers like AWS, Vultr, DigitalOcean and Linode to create instances for jobs to run on and destroy when done.
Currently I'm working on following features:
- Multi user support (Team) on project level
- Then I'll look into whether to add support for OIDC/SSO now or not
- Alert on slack
- Webhook support
I am working on Daestro[0], which is a cloud agnostic job orchestrator with built-in support for AWS, Vultr, DigitalOcean and Linode to run jobs on. Daestro can spawn and terminate compute instances based on requirement. It is suitable for running batch jobs or data engineering related jobs.
Self-hosted compute can also be linked to Daestro to run jobs on.
In general I love the PaaS experience and I can see the value Flightcontrol can potentially provide to the companies that work mostly with AWS. The free starter plan for individual is tempting to try out Flightcontrol, BTW what is the service limit for free plan? I could not find it.
I am also working on similar tool[1] but it's bit more niche to batch jobs type functionality but not just limited to AWS rather it's cloud agnostic.
I've been building something with HTMX since the last week, I have not done whole lot of complex things with it but I don't think it will pose any problem when time comes.
I get the premise of HTMX and when and why to use it, it's not solution to everything however it is a blessing for backend developers' who wants to work on frontend.
-> A bit of backstory
For my project Daestro[0], which is bit complex (and big) I chose Rust as backend and Svelte (with Sveltekit) as frontend SPA app. This was my first time working on both. After years of working on Django, I wanted to try statically typed language, after some research and trial, I chose Rust. Sveltekit was obvious because it made sense to me compared to other frameworks and it was super easy to pick up.
After working on Sveltekit for a year, I realised I've been spending a lot of time doing these same thing:
1. You create the api on the backend
2. then you create Zod schema on the frontend for form validation
3. the create +page.ts to initialize the form
4. in +page.svelte you create the actual form and validate it there itself with zod before sending it to the server
Hopping over two code bases just for a simple form, and Daestro has a lot of forms. I was just exhausted with this. Then HTMX started to get a lot of traction, I was watching it from a distant but having worked with Django and it's template, I was dismissive of it and thought having separate frontend is best approach.
-> Why I'm leaning towards HTMX now?
- Askama (rust crate) is a template engine which is compile time checked
- Askama supports block fragments[1], which is you can render certain part (block) of template, plus for HTMX usage
- Askama's macro almost don't make me miss Svelte's components
- Rust has amazing type system, now you can just use it, no need to replicate those on Typescript
- same codebase, no more hopping
- only one binary to deploy (currently for Daestro I've 3 separate deployments)
-> My rules for using HTMX
You must self-impose a set of rules on how you want to use HTMX, otherwise things can get out of you hand and instead of solving a problem you'll create bigger ones. These are my rules:
- Keep your site Multi-page Application and sprinkle some HTMX to make it SPA like on per page basis
- make use of hx-target header to only send the block fragments that is required by HTMX (very easy with Askama)
- do not create routes with partial page rendering instead a route must render complete page, and then use block framents to render only what is being asked in hx-target
- Do not compromise on security[2]
I don't like that they throw AI overview on your face when you search, rather they should show AI overview on the right column and search results on the left.