> The backend: from simple to absurdly complex...
> Here's where the real inversion happened...
> 2011 stack: PHP...
> 2026 stack: Next.js...
Welp, it's your choice to complicate the stuff. You could easily keep the PHP and just add ReactJs or even better - VueJs.
Have you ever checked out Laravel at all, considering your Rest API endpoint even?
And why use Docker in Production of personal projects that are supposed to be used for high load? Why not deploy on a finite VPS/VDS environment existing explicitly for this single workflow? Why add a separate layer in already isolated environment?
Totally fair points. Back in 2011 everything was built in plain PHP, and honestly, it worked perfectly for years. The shift to Next.js came much later, mainly because we needed proper SSR to handle SEO at slace. We're talking about 4 languages and around 13M pages. in that context, Next.js really shines, especially with file based routing and ISR making things much easier to manage.
Regarding Docker, we have quite a bit running on a single EC2 instance: PostgreSQL with PostGIS (about 13 million rows), Redis, Nginx, theAPI and web app. Using Docker Compose lets us keep everything versioned and spin up or redeploy the whole stack in seconds. Without it,we'd dealing with dependencies manually, and that's where things tend to get messy fast.
You're right, PHP is SSR by nature. What I meant is that Next.js gives us SSR plus built-in routing for 4 languages, ISR for cache invalidation on ~900K pages, and a React frontend — all in one framework. With PHP we'd need to wire that up separately.
That said, honestly, the ecosystem momentum probably influenced the decision more than a strict technical comparison. Looking back, we probably weren't critical enough about whether we actually needed to move away from PHP. It works and we're happy with it, but I wouldn't claim it was the only valid choice.
It was still likely possible to have retained the originality and novelty of the first site without succumbing to the plague of our contemporary blandness.
You're not wrong. The 2011 version had character. Google+ icons, chat per city, a people search engine. It felt like a place, not a tool.
The tradeoff was deliberate though. Serving 261 countries in 4 languages with an API and MCP Server pushes you toward structure over personality. But I do miss some of that original energy.
Thank you. Te 2011 version wasgenuinely fun to build. Chat by city, airport databases, a people search engine, things that made no business sense but felt right.
We're trying to keep some of that. You can browse countries, compare them, explore cities, look up universities. It's not just an API docs page. But I hear you. :)
If you don't mind, I would like to link to your article and site in a small blog post I am writing on the subject of deliberately ugly webdesign (you are not the ugly website ).
Of course, go ahead! Would love to read it when it's published, feel free to share the link here or drop me an email (manuel.longo@bamwor.com)
And hey, in my experience the best blogs I've ever read were the "ugly" ones, turns out what make a blog beautiful is usually the writing, not the CSS. Looking forward to it.
Stop using AI to “write” slop. It’s immediately obvious from the kicker of the article. Save us all some time and just post the bullet points you gave to an LLM.
16 comments
Have you ever checked out Laravel at all, considering your Rest API endpoint even?
And why use Docker in Production of personal projects that are supposed to be used for high load? Why not deploy on a finite VPS/VDS environment existing explicitly for this single workflow? Why add a separate layer in already isolated environment?
Regarding Docker, we have quite a bit running on a single EC2 instance: PostgreSQL with PostGIS (about 13 million rows), Redis, Nginx, theAPI and web app. Using Docker Compose lets us keep everything versioned and spin up or redeploy the whole stack in seconds. Without it,we'd dealing with dependencies manually, and that's where things tend to get messy fast.
That said, honestly, the ecosystem momentum probably influenced the decision more than a strict technical comparison. Looking back, we probably weren't critical enough about whether we actually needed to move away from PHP. It works and we're happy with it, but I wouldn't claim it was the only valid choice.
The tradeoff was deliberate though. Serving 261 countries in 4 languages with an API and MCP Server pushes you toward structure over personality. But I do miss some of that original energy.
The posts rationalization of getting out of the way of the content makes sense and if there is the primary motivation it is perfectly rational.
But as a human user: I would like to explore the web again.
We're trying to keep some of that. You can browse countries, compare them, explore cities, look up universities. It's not just an API docs page. But I hear you. :)
And hey, in my experience the best blogs I've ever read were the "ugly" ones, turns out what make a blog beautiful is usually the writing, not the CSS. Looking forward to it.