Hacker News Reader

Comment by M4v3R | Hacker News Reader

No sane person would kick off a brand new application that expects huge traffic on Django + PHP, right?

This goes to show that technology stack is not as important as devs (myself included) sometimes made it out to be. And that old, boring, battle-tested framework and technologies can actually deliver.

View on HN

I worked in a Bay area co-working incubator type place a few years ago. Everyone lol'd that I was self taught and went with a namecheap shared hosting, PHP, and jquery. What about AWS or Google cloud at least? What about node? What about some fancy front end framework (I forget their names as theres like 5 and they're all the same yet all different).

I saw several people drawn in their own tech stack drama, almost never creating a product.

I put some PHP together and have 34 companies paying.

It's a mess but I'd say that's more because it was my first real project, not because of php and jquery itself.

It's not a mess because it's your first real project, it's a mess because that's what happens when software meets the real world, and moving requirements. Software engineers like to use the term 'technical debt' which is a fancy way of saying a mess :)

That sounds nice but I have to assume that a self taught first timer that learned off YouTube videos is going to have 10x the technically debt of someone who's been doing this for several years and several iterations, and learned some lessons.

AWS and GCP aren't that expensive. The smaller instancss are ~$10 a month which is comparable to hared hosting.

The good thing is you can spin up/down quickly, which is not always possible with some of those SHPs who want month-to-month commitments.

IMHO all 3 major cloud providers are overpriced if you have just a simple service. Go with something simpler like Hetzner or DigitalOcean, Vultr, or better yet fly.io or similar if you can.

AWS especially will just suck you in with all the complexity. If you barely have an MVP you’re doing it wrong if you’ve ever thought about IAM lol.

It's all too complicated. One of the people at the co-working place was an AWS expert with tons of certifications blah blah. He spent months and thousands of dollars spinning up some insane micro services architecture for a product in the end he never got built as the real owner grew disillusioned with how it was all going. Price isn't the only thing to keep in mind.

But you only need to spin up/down quickly when you have huge variations in traffic which most small scale apps/service do not have.

Django + DRF is still fine, and is still a good choice. Especially for smaller projects that are expected to have a long lifetime with few resources available for maintenance.

Django is stable, well-known, and offers very long LTS. It's easy to find people who have experience on it, it is well documented and performs well enough for 95% of exiting websites.

You can quite easily convert DRF serializers to TS types/models, that you can then use in your preferred flavor of frontend framework.

I work with Django and while it’s true there is an unshakeable old-school vibe to it (Is it the docs? The SO posts from 2009? The source code with plenty of Python 2 era code?), other than proper async support, I don’t feel anything about it prevents me from making modern apps. I like my clients separate, so I do. And if I had to build a system with different services (without a specific async requirement), then I might as well patch a few Django services together…

I don’t have a dog in the fight, but it seems silly to use “what FAANG companies are able to make their tools do” to inform decisions for smaller companies.

I'm actually writing an argument against myself, because I'm usually closer to the "let's use the new shiny thing" camp. But that article is a nice reminder that the new shiny thing is not the only way to go and the "old, boring thing" is as capable if used right.

but Meta's versions are significantly different than the old, boring thing that you and I have access to. At my company, we are slowly rewriting our python services in golang because off the shelf golang incurs significantly less costs than off the shelf python on a per request basis.

Meta is actually contributing directly to upstream cpython. If you really wanted to, the internal fork is also open source: https://github.com/facebookincubator/cinder

>it seems silly to use “what FAANG companies are able to make their tools do” to inform decisions for smaller companies

Yes, and yet for many years now that's exactly the perpetual mistake that so many companies - both small ones and ones not in technology - would make because they assumed that if Google did it that way, it must automatically be the best.

> This goes to show that technology stack is not as important as devs

Facebook PHP isn't the same as the standard PHP engine though - they've spent 20 years optimizing their own compiler and PHP engine/infrastructure:

> Overall, our experiments demonstrate that HipHop is about 5.5x faster than standard, interpreted PHP engines. As a result, HipHop has reduced the number of servers needed to run Facebook and other web sites by a factor between 4 and 6, thus drastically cutting operating costs.

https://research.facebook.com/publications/the-hiphop-compil...

NB: that's from 12 years ago. HipHop didn't last long; a JITted PHP runtime (HHVM) replaced it at Facebook a few years later. Vanilla PHP also got a lot faster around versions 7 and 8.

The comparison was made in 2012 with PHP 5. PHP 8 is out now and likely includes most of Facebook's improvements. PHP 8 should be fast enough for any web app or backend.

A lot of Facebook those days is Node.js, Rust or Python.

Its no longer PHP heavy like it used to be.

There is absolutely no truth to that

FB is not using Python or Node? What’s the build pipeline for their frontend in then? Is GraphQL in PHP? Are AI services in PHP too?

Python is used all over the place but there is no node that I’ve ever seen. GraphQL is indeed in php, but the AI services are in python (I think)

What's the build pipeline for the React.js client in if its not in the Node.js?

I had a quick look and.. I have no idea. Frontend development at meta works differently than you probably imagine: things aren’t built locally but on dev servers or on-demand instances that all run services that take care of any build jobs in the background. I don’t know if there’s any nodejs involved at any point there or later in CI, but I suppose it’s possible. I still think it’s unlikely because my search turned up barely any mentions of nodejs, so I still think that my main point holds true: there’s very little node in use at meta, and nearly all the facebook frontend services are php (or python for Instagram/threads)

Is Haste still in use? Is it in PHP?

Looks like it, and yes, all PHP. Why did you think Meta was all nodejs and no more PHP anyways?

I've didn't think "no more PHP". I am just seeing how much non-PHP Meta open sources and talk with Meta guys at events who are building stuff for JS, talking about new client and varied tech stack and then you've told me "actually its still mostly PHP".

That’ll be because Facebook doesn’t use PHP as such, but Hack, which isn’t compatible with vanilla PHP. Hack isn’t really used much outside of Meta, so what’s the point of going through the extra work of open sourcing our stuff if nobody else will ever use it?

When you have buckets of money to throw at cloud spend, then yeah the tech stack might not matter quite as much. "Just throw more hardware at the problem" can sometimes work.

But OTOH you can't really compare the fangs to other circumstances, they can boil the ocean with a new or old tech stack.

Haha, indeed. I found myself surprised when I learned Instagram is still using Python.

Nobody uses Threads, that's why they're fine /s.

But yeah, I used to get anxious reading HN and hearing about some new web tech stack. I thought my knowledge and expertise was falling behind.

99 times out of 100 the new stuff is nice, but not game changing, and the stuff I know is good enough.

Even stuff that's been around for a bit; I can't speak for web, but on iOS I'm still seeing a lot of cases of people merely experimenting with SwiftUI and not actually switching to it, because UIKit is still more useful.

Reply on news.ycombinator.com