I Just Wanted to Deploy My Frontend
I used to love building frontends. Still do. But things have gotten complicated.
It used to be simple. You'd write your app, run npm run build, and deploy with a single command. Firebase. Now. Netlify. Whatever. It just worked. It was fast and quiet.
Then came the ✨ new new ✨
SSR. Edge functions. Full-stack frameworks. Everyone telling me I needed SSR. Or Server Components. Or ... well what do you mean you don't need SSR? Do you even server?
I just wanted to build a frontend. But now I had to set up backend tooling. Handle routing on the server. Learn yet another server framework to bust out of and do the deployment dances to get my html, js, and css up.
I didn’t ask for this. I didn’t want it. Still Don't.
So I went back. Circa 2018.
Back to the simple, yet powerful single page application. But yeah, I still needed to deploy it. So I dusted off an ole' nginx hash and cache strategy I wrote about years ago.
& turned it into a CLI called godeploy. It does what I needed:
- Generates Nginx configs
- Handles hashed assets for proper caching **
- Packs everything into a Docker container
** Hosting static sites is practically free using CDNs, so why do you have to pay for bandwidth on every SSR platform for your static site?
Then I made it open source. If you want to host your own frontend using an nginx server that will beat the pants off of any SSR runtime, it's yours to do so.
But I still missed the one-command deploy.
So I built that too.
godeploy deploy
Your app goes live at:
https://your-app.godeploy.app
No servers to manage. No DevOps. CDN-backed. HTTPS. It's a hosted service, not open source. But it feels like the old days. One command. Done.
I built this because I was done futzing around, ejecting out of SSR frameworks and server components.
Shipping is simpler when frontend tools stay focused on the frontend.
If you want to build frontends your way, this is for you.
No pressure. I'm just shipping what I needed.
Top comments (8)
100% I never do server side rendering.
I hit a hurdle with HighCharts, so I had to hack their vuejs library to get it to work, but that's the only issue I've had.
I hate that everyone (including vuejs themselves) writes their tutorials expecting you to do SSR.
react router bumming me out as they push client side router further and further into the corner... point is everyone is doing it!
Yeah I mean, preach...
This article is very much down the line of the modern classic:
XML IS THE FUTURE
Things like HTMX and stuff exist and persist because YAGNI has staying power and longevity... it's one of the core approaches for sustainable development methodology afaic.
The classic "old is new again". That is how React was built, on something that was considered a legacy practice.
Those aren't the good old days. G.o.d was when you deployed your site using FTP!
Everything ran server side. If you wanted interactivity it was an Ajax call to a PERL script via CGI.
Layout was done with tables and the only responsive consideration was VGA or SVGA.
Lol no doubt man, just might be a hard sell to try and make FTP cool again.
I'm propably too old. I remember times when SSR was the only way. And it worked great. Then SPA came. I still prefer SSR even when one of my open source projects is SPA.
Totally valid response! I bet the original SSR looked a lot different than what SSR means today in the JS ecosystem.