> 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.
You're right, I do use AI to help with the writing. English isn't my first language (I'm native Spanish speaker) and I use it to translate and polish my text. I wouldn't be able to participate here otherwise.
The site runs in 4 languages (English, Spanish, Portuguese, Italian) and covers 261 countries. Back in 2011 we relied on the machine translators available at the time, you probably remember how rough those were for the end user. AI finally lets us produce content that people can actually read in their language without those painful translation artifacts.
I apologize if that's off-putting, but the alternative would be less content for fewer people, or content full of bad translations.
The screenshots are from 2011 and the redesign took months of engineering, PostgreSQL + PostGIS with 13M features, Redis caching, MCP Server for AI agents. Happy to discuss technical details.
//
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.
How is PHP not SSR?
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.
Personally really liked your maximalist design form 2011: it was original, it looked fun.
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.
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.
Thanks ^^
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.
You're right, I do use AI to help with the writing. English isn't my first language (I'm native Spanish speaker) and I use it to translate and polish my text. I wouldn't be able to participate here otherwise.
The site runs in 4 languages (English, Spanish, Portuguese, Italian) and covers 261 countries. Back in 2011 we relied on the machine translators available at the time, you probably remember how rough those were for the end user. AI finally lets us produce content that people can actually read in their language without those painful translation artifacts.
I apologize if that's off-putting, but the alternative would be less content for fewer people, or content full of bad translations.
Slop article about a slop redesign.
The screenshots are from 2011 and the redesign took months of engineering, PostgreSQL + PostGIS with 13M features, Redis caching, MCP Server for AI agents. Happy to discuss technical details.