A very simple idea: when you eat more than your maintenance calories, you gain weight; when you eat less than your maintenance calories, you lose weight.
By using an algorithm, we can accurately figure out your maintenance calories more accurately than traditional regression based formulas like katch mc ardle.
It's way more accurate than calorie burn tracking devices like fitness bands and watches. (garmin/apple watch etc...)
MacroCodex helps you spot dips in maintenance calories from metabolic adaptation, then auto adjusts your calorie target and macros so your plan stays aligned with your real maintenance calories (TDEE).
It's very useful to those who find it hard to gain or lose weight.
it's a completely free app, no paywall, no unnecessary data collection.
i am not using any tool like pgbouncer and have not run into any issues so far. Is it even required these days? Have you guys tested your setup without these connection poolers/multiplexers?
Most of my apps are now simply HTMX + Go + SQLite.
I've found it's enough for most projects.
One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:
1. S3 (I wanted reliable data storage)
2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning.
3. BunnyCDN in front
Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.
And if you run only S3, the bills will be huge.
But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in the app without sign up or involving a backend.
What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.
I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.
If 2009 is too far back you can try your luck in 2012 with Firefox OS.
Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.
The amount of effort that goes into keeping Termux barely functional, has a lot to do with Android and the platform making it harder and harder, to access a dev environment on a phone.
Running `npm install` on Android isn't so easy.
(Caveat: The new Android Terminal that only works on a handful of models.)
No that's not correct, they both support PWAs with a large feature set. I built and have been maintaining a client's PWA (an internal tool for their employees) for over 10 years now.
Not my site, but someone on HN (can't remember who) built it: https://pwascore.com
Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).
It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps. It feels like it's specialized for that and not trying to be a jack of all trades.
>One of my sites is image heavy and serves 10 TB of traffic per month
I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?
Lots of legitimate businesses that deal in maintenance have ridiculous amounts of image data.
I have a civil engineering firm as a client, they take video & photo’s of roads they help project manage the maintenance on.
Small towns of 10000 can have ridiculously big road networks in Australia. And you take a photo every 10m, likely more but you only care about every 10m. It adds up, quick.
I’m only now investigating a web version of the app I wrote them because I think origin file system will work for them but I would never consider serving their 200TB+ of their imagery as a website.
10TB is nothing these days. All Hetzner virtual servers in Europe have 20TB/month traffic included (excess less than $2/TB) and all their dedicated servers have unlimited fair use (which is probably about 200TB/month averaged over many months).
Are you me? I've been on a tear building stuff with HTMX + Go + SQLite. It's like the trifecta of boring technology that jives with me. Stuff gets deployed to a colo server using a generic bash script.
I created a couple libraries to abstract the SQL and HTMX/web/OAuth bits; my apps are now very similar and easy to copy features between.
> Cloudflare will not let you run an image heavy site on its own
Cloudflare R2 object storage is S3-compatible, offers free egress, and does not share their CDN product's fair use policy against image-heavy use. Storage is 65% the per-GB cost of S3.
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
Because there isn't a 30% walled garden you can create with that.
Since you're using HTMX, I have to ask: do you have any tips or idioms for composing complex forms and UI without things getting out of hand? I love the approach, but I'm having a bad time figuring out where the ideal balance is between too few or too many HTMX-replaced areas in a page. Thanks.
My #1 advice is not creating separate server endpoints for every HTMX fragment, unless you are 1000% sure that endpoint will be used in multiple different pages.
Working on a "simple html page" that is actually 5 different independent "subpages" (routes, views, templates) in the backend is awful. The UX was improved, but the DX was sacrificed.
I recommend having a single view function for each page/SPA and do sub-routing within that function to handle page fragments. In other words, use a GET/path/Header parameter that indicates which fragment is currently needed, defaulting to the full document as normal. Just make sure you are considering request logging and client-side caching in your solution.
This makes it very easy to add/remove async content from the page, since you are just editing the one view function/template and you can easily reason about the entire page as one logical unit.
It also means you don't need to duplicate security logic or other middlewares for the page, since it can be implemented once at the start of your multi-faceted view function.
Generally you don't even need to do the sub-routing in the handler. You can just render the entire page and have `hx-select` attributes pluck out the part that you want.
That is a good solution for reusing content across pages, but most of my HTMX usage is for fetching data that would otherwise delay first page load significantly, or for seamless interactivity. Very different use cases.
> Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.
Pages has a 20k-100k limit on static files, but if they just guide you to R2 to offload it, which is still Cloudflare.
Did you mean the CDN? In which case, I'm not seeing that in the terms. [0] Though, I would have expected they'd have a similar thing. R2 resources don't generally count towards your cache limits.
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
There WAS. Firefox OS phone! HTML+CS+JS apps! But Mozilla kicked it to the graveyard even though it was very popular in third world nations. I guess it was not $$$$$ enough for the Mozilla CEO of that era.
I've learned about several frameworks that are system language + web frontend. The general approach is, ship a small binary compiled for the specific platform, and use the platform's native browser (and whatever html frontend tech you like) for frontend. The whole binary can be 1mb or less.
There's a couple of Rust libraries like this; right now I'm building an app in Tauri+Svelte.
It looks like Wails might be a similar framework in Golang.
Your Go server can have endpoints that render XML instead of HTML and basically get the same server-driven experience of your HTMX site. Fully skips the need for the app review process since you're not updating the actual client app code to make UI changes.
Can't vouch for it's effectiveness, but Hotwire Native might meet the needs for mobile paired with plain HTML. Despite the name, it doesn't seem that using Hotwire for the web UI is necessary to use Hotwire Native. I could be wrong about that though.
That's pretty much true of HTMX too (which is what GP mentions using). I mention Hotwire Native (different from plain Hotwire) because it makes it easy to wrap a web app as a mobile app. Then you can replace performance critical parts with native views, but keep everything else working through the web app portion. This is easier to maintain, albeit with the downside that everything requires network round trips. Depending on you use case, that may be an acceptable tradeoff.
Then that approach will work. If you need to scale beyond that, you need some way to route the request to the server with the right data. And what if a request needs data that was stored on two different servers?
Dont worry the vibecoders will tire out, they're the same people who were making NFTs and mining bitcoin, they'll move onto the next hot thing soon enough. Its more an archetype, not necessarily the same exact people. They dont commit long term.
The hilarious part is that spam actually makes money, while slop does not. There's no reason to tire out if it's profitable, right?
Meanwhile.. have you ever paid for a vibe-coded anything? Why would you, when you (along with everyone else) can slop the same thing together in a weekend with a $20 CC subscription?
Back in the day, Playstore app updates used to get quickly published often only taking less than a few hours, but now with vibe coding and lots of people pushing app updates on each minor edit, Google has started throttling updates to three days recently (based on discussions on the web).
It means if your app accidentally breaks in production, it may take three days to restore normal operation.
This is forcing developers to look for faster update methods. React native already has a solution for this but flutter solution is paid (shorebird)
My question is why will Python programmer, use Rust when they can use Go?
As someone who went from C++ to java to Ruby to Javascript to Python, to Go.
I find Go enviornment much superior. Not only your code can keep working for decade and compile fine with new compilers, you get more than enough speed you need.
And also, you don't use random libraries, you precisely use to part you need which imho makes you software more reliable, cleaner and smaller.
Using libraries and other people's module will always bite you just like llm bites you because you believe you understand it but you don't know how it's actually implemented and those who actually go through library and check all that, can implement parts they need from scratch without adding 100s of things u don't need.
A very simple idea: when you eat more than your maintenance calories, you gain weight; when you eat less than your maintenance calories, you lose weight.
By using an algorithm, we can accurately figure out your maintenance calories more accurately than traditional regression based formulas like katch mc ardle.
It's way more accurate than calorie burn tracking devices like fitness bands and watches. (garmin/apple watch etc...)
MacroCodex helps you spot dips in maintenance calories from metabolic adaptation, then auto adjusts your calorie target and macros so your plan stays aligned with your real maintenance calories (TDEE).
It's very useful to those who find it hard to gain or lose weight.
it's a completely free app, no paywall, no unnecessary data collection.
Already reached 13,000+ users
reply