8 ms·

I haven't done any php development in maybe 10 years but this landing page almost got me to spin up a hello world. I like the elephant frankenstein character -

I haven't done any php development in maybe 10 years but this landing page almost got me to spin up a hello world. I like the elephant frankenstein character - goofy and ugly/cute. Design, color scheme, copy, and animations are clean :chefkiss: The value prop is well highlighted - at least for someone that's been out of php dev for a while. This seems like a nice way to bootstrap something small. Getting started code snippet makes it seem quick and easy.

zer00eyz 2y ago
I moved from PHP to Golang a bit over a decade ago... Because binary deploys are the bees knees. I dont want 8 containers isolating a bunch of bad software or worse messed up dependency's (looking at you python, maybe some ruby and node code as well). Because rather than releasing installable software you packaged up "works for me" and shipped it to the world. I might play with this out of nostalgia but not so sure that I want these sorts of things in my production environment any more.
- francislavoie 2y ago
  This is PHP running inside a Go server, btw. Compiled with CGO. One binary, one process.
  - zer00eyz 2y ago
    Wow the PHP is going to magically get into the binary? /s Yes I could build this with c-go + the PHP and statically link everything (and there might need to be a bit of prayer involved...) ... or I could just write GO and accomplish all the same things with fewer steps. That knotted up mess is why containers are popular.
    - francislavoie 2y ago
      Well, FrankenPHP avoids that prayer, cause it's already done for you lmao But obviously the point of using PHP is for its ecosystem, frameworks etc. Go is still missing a lot of that, the Go community has a weird aversion to frameworks.
      - zer00eyz 2y ago
        I wrote PHP from version 3 to version 6... I remember PHP before it had "frameworks"... PHP ate perl because the battery's were included, you didn't need CPAN, and it had an amazing manual... Python (pip), Ruby (gems) and Node (NPM) all looked much more attractive because they had rich library's at their core and symphony wasnt really useful yet. Yet Go eschews a lot of the same package management issues those other languages have. And a lot of go devs look at the standard library the same way early PHP devs looked at it "I dont need a lot more than this". It's not that go devs are framework adverse we only want what we need and nothing more. In a language that favors composition frameworks quickly become "baggage". It's kind of interesting to watch someone come from a language with a strong package ecosystem and watch them build their first go project. They tend to cruise GitHub and throw EVERYTHING in the cart. It takes them 3-4 days of working with all that before they are complaining up a storm! You hand that same dev SQLC, Validator, and point them at middle ware and the standard lib and ask them for API's and they come back 2 days later grinning ear to ear. Go, done well, is brutalism. Blocky, functional concrete buildings have an amazing charm to them... Go is blocky, its utilitarian, its expressive... You dont write cute code in go, you dont try to make go magical, you want clear easy to read and understand code... Your more likely to come back and add features long before you have to address the performance of go.
        seszett 2y ago
        > version 6 PHP6? That was long ago because I don't even remember it! I don't have much to say otherwise, except you could very well say the same "Go is great" without having to shit on PHP and the project that is being discussed here. Especially since you don't really come off as very knowledgeable on what you're talking about.
        zer00eyz 2y ago
        It might shock you that I wrote perl before PHP... I have been in the game a LONG time. I was around for php being the language that EVERYONE shit on. I was around when PHP got somewhat huge and respectable. PHP buttered my bread for a number of years and I was one of its bigger advocates. My lament here isnt about PHP at all.. It's about the instructions here: https://frankenphp.dev/docs/embed/ https://frankenphp.dev/docs/embed/ to generate a monolithic binary... It's about the execution of this script https://github.com/dunglas/frankenphp/blob/main/build-static.sh https://github.com/dunglas/frankenphp/blob/main/build-static... None of that is very go like at all. Having spent a lot of time with PHP I recognize a good portion of what turns up in that shell script. That having been said there are parts of it (the curl of the diff) with NO context that I would pause and go figure out what the hell that was. It really needs a note as to WHY it's there so I dont have to go hunting. It looks like the shell script is meant to work in the docker container... A real build system might be in order here (make, basel, mage).
    - withinboredom 2y ago
      There are things Go excels at and there are things PHP excels at. They don’t always overlap. For example, you can write a simple web app in 100 lines of php code, and a process manager in 100 lines of Go code. If you flip the languages around, the number of lines explodes.
      - zer00eyz 2y ago
        I started writing PHP back in the 3 and 4 days... I have been writing go for over a decade. If I had to add a few dynamic elements to a static HTML site, php is still king. If we're building an API, go will win hands down. Not only in LOC but performance, and reporting. When you get into whole pages (think blogs or shopping or... ) a lot of that is going to depend on what framework you're grabbing on the PHP side. There arent a lot of "batteries included" solutions on the golang side... You might end up writing fewer lines of code in the first week but by the end of the month were going to be at feature parity and your quickly going to fall behind. The moment I need a SPA, on page interactive GUI you're going to end up with a JS framework and an API back end... here again, go will shine.
        withinboredom 2y ago
        > If we're building an API, go will win hands down. I'm not so sure of that. Writing business logic in PHP is usually more concise than in Go, and more flexible. Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP.
        zer00eyz 2y ago
        >> Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP. Not at all. There are some that would be painful to write "by hand". An expansive and nested set of null fields would suck if I had to spell it all out... https://sqlc.dev https://sqlc.dev << changes everything. If you add in the YAML (and I hate yaml) you can get your JSON to DB mapping in there, as well as your validations (all output as struct tags). Everything else that you're going to want (transforming inputs to/from json, logging, auth) is some pretty simple middleware.
    - eru 2y ago
      > Wow the PHP is going to magically get into the binary? It's fairly simple to pack assets into a binary. (Not sure, if they are doing that. But it wouldn't involve any magic.) Compare also https://doc.rust-lang.org/beta/core/macro.include_bytes.html https://doc.rust-lang.org/beta/core/macro.include_bytes.html Btw, making a tarball or a zipfile is also a way to put multiple files into one binary file. You might have even heard of self-extracting zip files? They were very popular, before Windows got a build-in unzipper, I think.
      - kdunglas 2y ago
        Optionally, you can embed the PHP scripts in the final binary using a Go feature similar to `include_bytes`: https://frankenphp.dev/docs/embed/ https://frankenphp.dev/docs/embed/ But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both).
        eru 2y ago
        > But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both). Yes, but that's completely independent from whether / how you embed the scripts? (Which you do via the the procedure described in your first link?) Btw, how does your version of PHP compare to Facebook's Hack? I had opportunity to use Hack a few years ago, and I think it's the best language they could have made (from PHP as the fixed starting point).
- conradfr 2y ago
  This is the one good thing non-Go web developers are jealous about Go.
  - BartjeD 2y ago
    .Net and rust and many other languages also support binary deploy. You raise the impression this is a unique property of 'go', how come? You guys have go tunnel vision because you work with it?
    - conradfr 2y ago
      That was not my experience when I worked with .Net, IIS and the whole thing but it was a long time ago so good to know :)
      - lomase 2y ago
        How long ago? Nowdays most people dont use ISS for docker builds, it usually runs on Linux containers.
      - tracker1 2y ago
        .Net is a lot more sane now... since Core releases (mostly). Linux deploys with docker are pretty typical these days.
    - withinboredom 2y ago
      Go started it. Or at least, popularized the static build, single binary docker files. Naturally, you’ve been able to do this since forever with many languages like C/C++ etc.
      - pjmlp 2y ago
        Among people that have used nothing besides scripting languages.
        jchw 2y ago
- hipadev23 2y ago
  why would it be 8 (or any N>1) containers for a php/node/python/ruby app?
  - gertop 2y ago
    Python is pretty messy to deploy without a container. Sure you can (and should!) use a virtual env, but by that point using docker isn't much more efforts. Rails and Node and PHP have at least the decency to have the project's dependencies contained inside the project's own directory by default.
    - hipadev23 2y ago
      nah not questioning containers. questioning why he wrote 8 (obviously exaggerated) and why it’s not 1.
      - deergomoo 2y ago
        Nginx/Apache/Caddy + php-fpm + something like MySQL if your database lives on the same server as your application. PHP in its default form isn’t a persistent process[0], so you will typically have a web server accepting the requests and forwarding them onto PHP to generate a response. 0: it actually usually is these days for performance reasons, with a pool of processes that are reused. But the mental model is one short-lived process per request
        hipadev23 2y ago
        and if the Go dev needs a database, or a cache, or an actual fully-featured HTTP daemon processing the requests? I’m just confused about their focus on “single binary” when applications in those languages tend to be a single-container plus the same supporting services their single binary is going to need too.
    - gnz11 2y ago
      That’s the default of the package managers (i.e. composer, npm, etc) not the language. Setting up a virtual env for Python is a one liner. Hardly messy. I’d argue that deploying a Python web app with mod_wsgi or gunicorn isn’t any more difficult than deploying a PHP web app with PHP-FPM. If anything I’ve seen far more misconfigured PHP-FPM setups than gunicorn setups.
- pjerem 2y ago
  I’m a total noob in Go but is there something that approaches completeness of the good old monolithic frameworks ? I’m in a pause in my career and I’m having a great time working on a "side" project in Django currently. Everything just works and makes sense, I just have to write business code and it gives me a nice app. I’d be happy to try Go for fun and because deploying Python/Diango is a mess (at least without docker) but my project isn’t API first, it’s deliberately a traditional server side rendered app. Every Go frameworks I stumbled upon looked like they were made to serve APIs and In the case of a 1 man team, it defeats the purpose of easy deployment since you will anyway need to code and deploy a full blown frontend (and front end fatigue is a big reason why my career is currently in pause).
  - zer00eyz 2y ago
    GO + HTMX + standard templates... or some folks swear by templ On the API side (not what you wanted, but good looking) is sqlc + validator Between all of those you have everything you want for a website. Week 1 go is going to be a lot slower than Django or Rails. You're going to have a bit of bootstrapping to do for your project. By the end of the first month you will be a week or two behind but performance parity will be the same (you should have roughly the same feature cadence). A good framework brings a lot to the table. With go you have to "solve" for that yourself. "How do I log a request" would be one of those first questions... the answer is "the standard logger is pretty good" and "Middleware is awesome". It's a question that has a simple, short, very common answer. One that works for web apps or CLI apps or ... It takes a bit but you end up embracing the idea that less is better
    - tracker1 2y ago
      Was going to say the same... Similarly .Net (razor views) + HTMX is pretty nice as well. There's YouTube content for both, on the .Net side, there's some JetBrains extensions to make the HTMX experience relatively seamless.
  - JodieBenitez 2y ago
    > I’m a total noob in Go but is there something that approaches completeness of the good old monolithic frameworks ? Some of them try, but it's really hard to beat 20 years of development, real-life use cases, third party tools and docs, etc. > deploying Python/Diango is a mess (at least without docker) Install your django app in a venv, serve it with gunicorn behind apache/nginx... done. No docker required. > Every Go frameworks I stumbled upon looked like they were made to serve APIs Indeed, that's pretty much what Go was made for. And it's also the current trend. > my project isn’t API first, it’s deliberately a traditional server side rendered app Stick with Django then, because it remains an excellent choice for such apps. And these apps remain an excellent solution to a vast array of problems. > front end fatigue is a big reason why my career is currently in pause I'd argue you don't have to follow this trend to be useful. Actually, something like Django+Unpoly or HTMX probably covers 99% of the use cases with very low frontend development.
- slim 2y ago
  did you miss this part in Frankenphp website ? :) Build standalone, self-executable and dependencies-free binaries for your PHP web applications, and command-line tools.
- sam0x17 2y ago
  PHP had the unique fun of when an attacker was able to write files to the server they could literally write new PHP files and get them to execute. I miss that worry somehow
  - ivanhoe 2y ago
    You can do that or something similarly bad in pretty much any language if you have write access to where the files are. That's really a server misconfiguration problem, not php problem. Huge misfortune of php is that because of the timing and huge popularity in relatively early days of web it got to be permanently associated with amateurs doing stupid shit. I was part of that early era, so trust me that php4 as bad as it was, was still fantastic compared to writing CGI scripts in C, or running mod_perl that you had to restart every time you edit some file.
  - tracker1 2y ago
    f-that... read-only containers for the win.
- cess11 2y ago
  Right, so CGI is quite old by now, which is basically this: a binary in a directory and a proxy that throws packets at it. It has its pros and cons. In some cases it's actually quite nice to have a platform like Wildfly or the BEAM, or you knew so little about the future load peaks that you started with cheap shared hosting and hence PHP so when you outgrow it FastCGI and nginx is a much better option than a great rewrite to Golang. Building in the languages and on the platforms you already know will always be much faster and more convenient than betting on someone else's 'bees knees'.
thomasfromcdnjs 2y ago
Yeah it has to be one of the best landing pages I have ever seen. Fun and instantly understood.

zer00eyz 2y ago

I moved from PHP to Golang a bit over a decade ago... Because binary deploys are the bees knees. I dont want 8 containers isolating a bunch of bad software or worse messed up dependency's (looking at you python, maybe some ruby and node code as well). Because rather than releasing installable software you packaged up "works for me" and shipped it to the world. I might play with this out of nostalgia but not so sure that I want these sorts of things in my production environment any more.

francislavoie 2y ago
This is PHP running inside a Go server, btw. Compiled with CGO. One binary, one process.
- zer00eyz 2y ago
  Wow the PHP is going to magically get into the binary? /s Yes I could build this with c-go + the PHP and statically link everything (and there might need to be a bit of prayer involved...) ... or I could just write GO and accomplish all the same things with fewer steps. That knotted up mess is why containers are popular.
  - francislavoie 2y ago
    Well, FrankenPHP avoids that prayer, cause it's already done for you lmao But obviously the point of using PHP is for its ecosystem, frameworks etc. Go is still missing a lot of that, the Go community has a weird aversion to frameworks.
    - zer00eyz 2y ago
      I wrote PHP from version 3 to version 6... I remember PHP before it had "frameworks"... PHP ate perl because the battery's were included, you didn't need CPAN, and it had an amazing manual... Python (pip), Ruby (gems) and Node (NPM) all looked much more attractive because they had rich library's at their core and symphony wasnt really useful yet. Yet Go eschews a lot of the same package management issues those other languages have. And a lot of go devs look at the standard library the same way early PHP devs looked at it "I dont need a lot more than this". It's not that go devs are framework adverse we only want what we need and nothing more. In a language that favors composition frameworks quickly become "baggage". It's kind of interesting to watch someone come from a language with a strong package ecosystem and watch them build their first go project. They tend to cruise GitHub and throw EVERYTHING in the cart. It takes them 3-4 days of working with all that before they are complaining up a storm! You hand that same dev SQLC, Validator, and point them at middle ware and the standard lib and ask them for API's and they come back 2 days later grinning ear to ear. Go, done well, is brutalism. Blocky, functional concrete buildings have an amazing charm to them... Go is blocky, its utilitarian, its expressive... You dont write cute code in go, you dont try to make go magical, you want clear easy to read and understand code... Your more likely to come back and add features long before you have to address the performance of go.
      - seszett 2y ago
        > version 6 PHP6? That was long ago because I don't even remember it! I don't have much to say otherwise, except you could very well say the same "Go is great" without having to shit on PHP and the project that is being discussed here. Especially since you don't really come off as very knowledgeable on what you're talking about.
        zer00eyz 2y ago
        It might shock you that I wrote perl before PHP... I have been in the game a LONG time. I was around for php being the language that EVERYONE shit on. I was around when PHP got somewhat huge and respectable. PHP buttered my bread for a number of years and I was one of its bigger advocates. My lament here isnt about PHP at all.. It's about the instructions here: https://frankenphp.dev/docs/embed/ https://frankenphp.dev/docs/embed/ to generate a monolithic binary... It's about the execution of this script https://github.com/dunglas/frankenphp/blob/main/build-static.sh https://github.com/dunglas/frankenphp/blob/main/build-static... None of that is very go like at all. Having spent a lot of time with PHP I recognize a good portion of what turns up in that shell script. That having been said there are parts of it (the curl of the diff) with NO context that I would pause and go figure out what the hell that was. It really needs a note as to WHY it's there so I dont have to go hunting. It looks like the shell script is meant to work in the docker container... A real build system might be in order here (make, basel, mage).
  - withinboredom 2y ago
    There are things Go excels at and there are things PHP excels at. They don’t always overlap. For example, you can write a simple web app in 100 lines of php code, and a process manager in 100 lines of Go code. If you flip the languages around, the number of lines explodes.
    - zer00eyz 2y ago
      I started writing PHP back in the 3 and 4 days... I have been writing go for over a decade. If I had to add a few dynamic elements to a static HTML site, php is still king. If we're building an API, go will win hands down. Not only in LOC but performance, and reporting. When you get into whole pages (think blogs or shopping or... ) a lot of that is going to depend on what framework you're grabbing on the PHP side. There arent a lot of "batteries included" solutions on the golang side... You might end up writing fewer lines of code in the first week but by the end of the month were going to be at feature parity and your quickly going to fall behind. The moment I need a SPA, on page interactive GUI you're going to end up with a JS framework and an API back end... here again, go will shine.
      - withinboredom 2y ago
        > If we're building an API, go will win hands down. I'm not so sure of that. Writing business logic in PHP is usually more concise than in Go, and more flexible. Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP.
        zer00eyz 2y ago
        >> Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP. Not at all. There are some that would be painful to write "by hand". An expansive and nested set of null fields would suck if I had to spell it all out... https://sqlc.dev https://sqlc.dev << changes everything. If you add in the YAML (and I hate yaml) you can get your JSON to DB mapping in there, as well as your validations (all output as struct tags). Everything else that you're going to want (transforming inputs to/from json, logging, auth) is some pretty simple middleware.
  - eru 2y ago
    > Wow the PHP is going to magically get into the binary? It's fairly simple to pack assets into a binary. (Not sure, if they are doing that. But it wouldn't involve any magic.) Compare also https://doc.rust-lang.org/beta/core/macro.include_bytes.html https://doc.rust-lang.org/beta/core/macro.include_bytes.html Btw, making a tarball or a zipfile is also a way to put multiple files into one binary file. You might have even heard of self-extracting zip files? They were very popular, before Windows got a build-in unzipper, I think.
    - kdunglas 2y ago
      Optionally, you can embed the PHP scripts in the final binary using a Go feature similar to `include_bytes`: https://frankenphp.dev/docs/embed/ https://frankenphp.dev/docs/embed/ But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both).
      - eru 2y ago
        > But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both). Yes, but that's completely independent from whether / how you embed the scripts? (Which you do via the the procedure described in your first link?) Btw, how does your version of PHP compare to Facebook's Hack? I had opportunity to use Hack a few years ago, and I think it's the best language they could have made (from PHP as the fixed starting point).
conradfr 2y ago
This is the one good thing non-Go web developers are jealous about Go.
- BartjeD 2y ago
  .Net and rust and many other languages also support binary deploy. You raise the impression this is a unique property of 'go', how come? You guys have go tunnel vision because you work with it?
  - conradfr 2y ago
    That was not my experience when I worked with .Net, IIS and the whole thing but it was a long time ago so good to know :)
    - lomase 2y ago
      How long ago? Nowdays most people dont use ISS for docker builds, it usually runs on Linux containers.
    - tracker1 2y ago
      .Net is a lot more sane now... since Core releases (mostly). Linux deploys with docker are pretty typical these days.
  - withinboredom 2y ago
    Go started it. Or at least, popularized the static build, single binary docker files. Naturally, you’ve been able to do this since forever with many languages like C/C++ etc.
    - pjmlp 2y ago
      Among people that have used nothing besides scripting languages.
      - jchw 2y ago
hipadev23 2y ago
why would it be 8 (or any N>1) containers for a php/node/python/ruby app?
- gertop 2y ago
  Python is pretty messy to deploy without a container. Sure you can (and should!) use a virtual env, but by that point using docker isn't much more efforts. Rails and Node and PHP have at least the decency to have the project's dependencies contained inside the project's own directory by default.
  - hipadev23 2y ago
    nah not questioning containers. questioning why he wrote 8 (obviously exaggerated) and why it’s not 1.
    - deergomoo 2y ago
      Nginx/Apache/Caddy + php-fpm + something like MySQL if your database lives on the same server as your application. PHP in its default form isn’t a persistent process[0], so you will typically have a web server accepting the requests and forwarding them onto PHP to generate a response. 0: it actually usually is these days for performance reasons, with a pool of processes that are reused. But the mental model is one short-lived process per request
      - hipadev23 2y ago
        and if the Go dev needs a database, or a cache, or an actual fully-featured HTTP daemon processing the requests? I’m just confused about their focus on “single binary” when applications in those languages tend to be a single-container plus the same supporting services their single binary is going to need too.
  - gnz11 2y ago
    That’s the default of the package managers (i.e. composer, npm, etc) not the language. Setting up a virtual env for Python is a one liner. Hardly messy. I’d argue that deploying a Python web app with mod_wsgi or gunicorn isn’t any more difficult than deploying a PHP web app with PHP-FPM. If anything I’ve seen far more misconfigured PHP-FPM setups than gunicorn setups.
pjerem 2y ago
I’m a total noob in Go but is there something that approaches completeness of the good old monolithic frameworks ? I’m in a pause in my career and I’m having a great time working on a "side" project in Django currently. Everything just works and makes sense, I just have to write business code and it gives me a nice app. I’d be happy to try Go for fun and because deploying Python/Diango is a mess (at least without docker) but my project isn’t API first, it’s deliberately a traditional server side rendered app. Every Go frameworks I stumbled upon looked like they were made to serve APIs and In the case of a 1 man team, it defeats the purpose of easy deployment since you will anyway need to code and deploy a full blown frontend (and front end fatigue is a big reason why my career is currently in pause).
- zer00eyz 2y ago
  GO + HTMX + standard templates... or some folks swear by templ On the API side (not what you wanted, but good looking) is sqlc + validator Between all of those you have everything you want for a website. Week 1 go is going to be a lot slower than Django or Rails. You're going to have a bit of bootstrapping to do for your project. By the end of the first month you will be a week or two behind but performance parity will be the same (you should have roughly the same feature cadence). A good framework brings a lot to the table. With go you have to "solve" for that yourself. "How do I log a request" would be one of those first questions... the answer is "the standard logger is pretty good" and "Middleware is awesome". It's a question that has a simple, short, very common answer. One that works for web apps or CLI apps or ... It takes a bit but you end up embracing the idea that less is better
  - tracker1 2y ago
    Was going to say the same... Similarly .Net (razor views) + HTMX is pretty nice as well. There's YouTube content for both, on the .Net side, there's some JetBrains extensions to make the HTMX experience relatively seamless.
- JodieBenitez 2y ago
  > I’m a total noob in Go but is there something that approaches completeness of the good old monolithic frameworks ? Some of them try, but it's really hard to beat 20 years of development, real-life use cases, third party tools and docs, etc. > deploying Python/Diango is a mess (at least without docker) Install your django app in a venv, serve it with gunicorn behind apache/nginx... done. No docker required. > Every Go frameworks I stumbled upon looked like they were made to serve APIs Indeed, that's pretty much what Go was made for. And it's also the current trend. > my project isn’t API first, it’s deliberately a traditional server side rendered app Stick with Django then, because it remains an excellent choice for such apps. And these apps remain an excellent solution to a vast array of problems. > front end fatigue is a big reason why my career is currently in pause I'd argue you don't have to follow this trend to be useful. Actually, something like Django+Unpoly or HTMX probably covers 99% of the use cases with very low frontend development.
slim 2y ago
did you miss this part in Frankenphp website ? :) Build standalone, self-executable and dependencies-free binaries for your PHP web applications, and command-line tools.
sam0x17 2y ago
PHP had the unique fun of when an attacker was able to write files to the server they could literally write new PHP files and get them to execute. I miss that worry somehow
- ivanhoe 2y ago
  You can do that or something similarly bad in pretty much any language if you have write access to where the files are. That's really a server misconfiguration problem, not php problem. Huge misfortune of php is that because of the timing and huge popularity in relatively early days of web it got to be permanently associated with amateurs doing stupid shit. I was part of that early era, so trust me that php4 as bad as it was, was still fantastic compared to writing CGI scripts in C, or running mod_perl that you had to restart every time you edit some file.
- tracker1 2y ago
  f-that... read-only containers for the win.
cess11 2y ago
Right, so CGI is quite old by now, which is basically this: a binary in a directory and a proxy that throws packets at it. It has its pros and cons. In some cases it's actually quite nice to have a platform like Wildfly or the BEAM, or you knew so little about the future load peaks that you started with cheap shared hosting and hence PHP so when you outgrow it FastCGI and nginx is a much better option than a great rewrite to Golang. Building in the languages and on the platforms you already know will always be much faster and more convenient than betting on someone else's 'bees knees'.

thomasfromcdnjs 2y ago

Yeah it has to be one of the best landing pages I have ever seen. Fun and instantly understood.