Static Frontends and Rented Backends
Lenny Bogdonoff, co-founder and CTO of Milk Video, on the past, present and future of Javascript
This shift turned backend work from a custom engineering job into a menu of rented services. Once JavaScript frameworks got good enough to run most product logic in the browser, teams could ship an index.html file and a JS bundle, then plug into Firebase, Parse, auth, storage, and search APIs instead of standing up their own servers. That especially changed what a one to five person team could build, because frontend developers no longer needed a full backend specialist to get a real product live.
-
The technical progression was concrete. Teams moved from PHP or Java apps rendering full pages, to those backends sending data into JavaScript pages, to static frontends calling remote APIs directly. The backend did not disappear so much as get chopped into smaller hosted pieces.
-
That change created a new product layer for platforms like Netlify and Vercel. If the app is mostly static assets plus API calls, the valuable product becomes build, deploy, preview, rollback, env vars, and CDN delivery, not managing long running application servers.
-
The trade off is economic, not magical. Backend as a service tools remove setup work early, but as usage grows they can become much more expensive than running MySQL, Postgres, or cloud infra directly. Teams buy speed first, then often unbundle later.
The longer arc is toward backends becoming more invisible at the start of a company and more specialized later. New waves from Supabase to PlanetScale are rebuilding the same promise with better primitives, which means more apps will begin with outsourced backend pieces, while the biggest products will keep pulling critical infrastructure back in house once scale makes the math worth it.