8 ms·

I think a simple web stack should aspire to the simplicity of the PHP stack, twenty years ago: 1) Create a directory "foo" on your server 2) Make a file calle

I think a simple web stack should aspire to the simplicity of the PHP stack, twenty years ago: 1) Create a directory "foo" on your server 2) Make a file called "bar.php" in that directory 3) Write "Hello World!" in the file 4) Open http://localhost/foo/bar.php http://localhost/foo/bar.php in the browser and see "Hello World!" Lines of code or configuration so far: zero. 5) Add some actual code to bar.php 6) Reload the page and see the result Number of steps to rebuild or restart: zero. Then you can add templating, routing, logging, testing, anything. I'm not married to the PHP language, it's a mess. But the idea of keeping simple things simple is very important, and from what I see of today's developers, that idea has been utterly forgotten. Memory-holed. It's astonishing, I can barely believe that it happened. EDIT: Sorry, I just said this offhand and didn't mean to hijack the discussion. Feel free to downvote, so something more on-topic gets on top.

nabdab 7y ago
I remember fondly those early days with PHP before it dawned on me how many peculiarities it had. However to be fair these steps came only after you’d managed to set up the server which was non-trivial on its own. These days I feel like python/flask does it simpler. True you need to define a function and use a decorator, but saves you having to set up the server before getting started on site itself.
why-oh-why 7y ago
That sounds like what Zeit.co is doing. Now.sh is nearly zero-config for a static HTML index and any number of functions in many languages under /api/ In their version 1 they actually even looked for index.js in the root and evaluated that one, but now such a thing requires config (and it isn’t even clear on how to achieve it)
- girvo 7y ago
  I definitely hope this sort of idea takes off: it’s got a lot of promise to eventually take over from PHP for the “get a beginner rendering dynamic content to a browser quickly” use-case, which is how I learned to program 15 years ago!
agentultra 7y ago
This is a different kind of simple. The simple the OP seems to be going for is the "Ruby + Sinatra," "Python + Flask," "PHP + Laravel" type of simple: a few libraries with small APIs that can make a serviceable starting base. The audience for this are experienced and are not making their first web application.
gridlockd 7y ago
That's not actually simple, it's just convention over configuration. It actually complicates a lot of things, like routing and templating: Those files implicitly do the routing and templating, until they don't, which is where the mess starts. I'd much rather just write request handlers.
0xFACEFEED 7y ago
Did you forget the “A” in LAMP? It’s hardly zero configuration.
- MuffinFlavored 7y ago
  Anybody could make any language in any app deployed to anything as simple as `sh scripts/build.sh && teraform apply` in my eyes.
- avita1 7y ago
  While Apache is certainly not zero configuration, it is pretty easy to forget about the Apache part of the LAMP stack. When I got started making websites, I downloaded "WAMP" (windows-apache-mysql-php). It took care of all the configuration and I could, as the author said, drop my code in a www folder and be off to the races. Similarly, lots of hosting providers wouldn't expose the guts of Apache to developers. They would give you some sftp credentials, and let you upload whatever PHP files you wanted. No need to think about Apache configurations (except maybe a few htaccess files).
- wolco 7y ago
  On centos it was pretty near zero config. With Wamp it was a windows install file and had a neat stack together. Back on my c64 I turned it on, no booting and could just start writing code. We've moved away from this sadly.
thewarrior 7y ago
1) Install node js 2) npm install express 4) Define handler Seems simple enough ?
- deleted 7y ago
  [deleted]
- cpursley 7y ago
  Simple, except for the Javascript and npm bits...
- Vosporos 7y ago
  Simple, yes, but managing a MEAN stack (or even just Node + Express) is far from being "easy".
- girvo 7y ago
  I disagree with the others, and think this is indeed simple enough without caveats about setting it up (setting up WAMP is honestly just as much effort — not much), and what I’ve used to teach friends who wanted to learn some web programming with zero initial understanding. Explaining routes and handlers was a bit hard, compared to files. I wonder if there’s a “file based” version for Node that’d work like and express handler for the files route?
- Wintereise 7y ago
  For what it's worth, I agree with you. I associate installing node and installing LAMP/WAMP with similar levels of "difficulty." Sure, `http.createServer` is a few more lines of code compared to the equivalent PHP `hello world` but I don't see it as an insurmountable hurdle.
invalidusernam3 7y ago
I agree that software development has become (often) pointlessly over complicated in the past few years. For my personal projects I usually develop in Yii2, vanilla JS, SCSS, on MAMP. Source lives in Git, deploy via FTP. I track my progress on a simple kanban. I can push out really complex web applications in days. At work, currently we use headless Drupal 8 as an API layer, React/Angular frontend, automated deployments via Jenkins (that takes over 30 minutes), silly microservices, an over complicated Git strategy, with over complicated Jira/Confluence steps, security scans, pen testing. It takes months to release anything. They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website. The biggest difference is the amount of time and the cost.
- williamdclt 7y ago
  I could also edit live on my production server and the result would be the same: a website. I'm not saying that modern stacks aren't more complicated than they need, but I use a React frontend, a React-Native app, silly microservices, a non-trivial git strategy, non-trivial Trello steps, security scans, automated deployment via CircleCI and yet release multiple times a day. The biggest difference is that deployment always works, always passes tests, does not depends on who deploys, rollbacks automatically if healthchecks fail... You know, the sort of stuff that "reduces defects", "builds quality in", "fails fast" and all sort of concepts that people way smarter than us, working in industry way more mature than ours, have been elaborating for decades
  - james_s_tayler 7y ago
    Yup. I think people forget that things aren't the way they used to be because we made forward progress. Maybe that means things got more complex. It also means more things became possible and it became possible to not have things happen which you wish didn't. If everything worked so fine and dandy in the good old days, we'd still be there.
    - mettamage 7y ago
      > If everything worked so fine and dandy in the good old days, we'd still be there. I'm not a historian, but I'm pretty sure a historian could find a lot of counter examples to statements like this. That includes historians who know an aweful lot about programming languages.
bad_user 7y ago
Doing PHP programming was my first programming job, lasted for about 3 years. While I agree with you about the allure of PHP, to be honest, I will never choose PHP again or touch any projects that uses PHP. PHP is an awful, obsolete language, patched again and again to make it more modern. It's like wearing an old leather jacket that has been patched repeatedly, yet it still has a nasty smell. This is entirely subjective of course and I'll take old and trustworthy technologies technologies any day of the week. Except PHP isn't trustworthy and it never was. I have never seen a high level language plagued with so many security issues and this extends to apps built in PHP, like Wordpress. You could attribute that to sloppy coding, or to its popularity, yet if you take the top web vulnerabilities in the wild, most of them (like SQL injections, or remote code executions, or stupid bugs related to implicit conversions, session tampering, etc) aren't possible with modern libraries built in static languages, or at least very hard to accomplish by accident. For me there's also the issue that PHP is really inefficient. Any PHP app will crash your average server if it hits Hacker News, unless you end up caching the pages via Varnish or similar tricks that essentially avoid hitting the PHP interpreter. Configuring Wordpress to withstand a traffic spike can be very challenging, the best solution is to pre-generate the website, thus making it static, which is very weird considering for how long WP and PHP have been on the scene, you'd think there are better solutions by now. You say PHP is easy. I say that PHP is and will always be a security and scalability nightmare. And sure, it allows you to start something fast, but I can start as fast with my favorite technologies and without hitting a wall later. And of course, PHP is nice for beginners, but at the same time I believe you're painting yourself into a corner and it's very hard to grow from there. Besides the issues above, a beginner will be curious about trying new things. CLI utilities, desktop or phone apps, statistics, automation, embedded programming, etc. PHP is unsuitable basically for anything that's not querying MySQL and then spitting an HTML back, which means the learning curve will be worse, because you've picked a very limited hammer.
- james_s_tayler 7y ago
  Wow. That was the best insult-PHP-rant I've seen in my life.
- gambler 7y ago
  >I can start as fast with my favorite technologies and without hitting a wall later. What are your "favorite technologies"? Where can I get a hosting using your "favorite technologies" that would allow me to create dynamic server-size content just by editing a single file? (No command line fuckage.) Will the resulting solution be portable to other hosting providers?
leshow 7y ago
That assumes you've got apache set up, or nginx and php-fpm. It also uses the php interpretor. If you had to build a binary like Haskell would, your approach would be different (although you could run haskell in interpreted mode I wouldn't recommend it). It's also kind of unfair because PHP was created for making web pages, Haskell wasn't.
- johnday 7y ago
  If the lesson is "use languages specifically designed for the use case", then that's a lesson worth learning.
  - leshow 7y ago
    The lesson is you can't compare just the language parts of the setup without taking a holistic perspective. just PHP is not sufficient to make a 'hello world' page, you need an entire web server in the form of apache too
- adamrezich 7y ago
  I spent my high school (~2006) lunch and free periods teaching myself web development on the school computers in the library, running Portable Notepad++, Portable Firefox, and Portable XAMPP, off my third-gen iPod's hard drive. Very good times. XAMPP made LAMP on Windows beyond painless. I miss that old stack.
- oaiey 7y ago
  To the point. It is very naive to ignore the fact that the work was just outsourced to an IT guy. And the world in which Haskell, Java, JavaScript or .NET can deliver the same "simplicity" of PHP is just called Function as a Service/Serverless (just that this needs some more years before simplicity is actually reached). Ok, a bit stretchy ;)
cookie_monsta 7y ago
I get what you are saying and agree with the sentiment but you did omit the 10 or so steps required before your point #1.
Ericson2314 7y ago
I'm not sure this is simpler. Apache + php is probably far more lines of code. What the above is is rather all the complexity of just one rigid use-case swept under the rug.
seangrogg 7y ago
While you can theoretically get to this level of simplicity with various tools I think the difference isn't so much "can it be this simple?" so much as "does this level of simplicity fit my needs?" and that can be harder to quantify. The same thing you wrote in PHP done in Node.js in an arbitrarily named file served from root: require('http').createServer((_, res) => res.end('Hello World')).listen(80); Zero configuration. You could trivially add some lines from 'fs' to get it to read files instead and whenever you update those files it'll automatically serve the new ones. The problem isn't that it can't be simple. It's that the people cutting checks (or at least the people informing them) also want SSL, non-static pages, sanitized inputs, an attractive interface, log retention, data persistence, ease-of-access, etc. If people were paying me my current rate to send their users unstyled static text over HTTP I'd gladly walk away from all the process. But if they want me to maintain my sanity while writing a non-trivial web application I think integrating a type checker pays off after the first few thousand lines of code. And if I know things are going to get there from the outset then setting it up in advance isn't exactly insanity.
- deleted 7y ago
  [deleted]
- lhorie 7y ago
  Eh, that's not a great example. It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get the text to show on a browser. Having two different pages requires no knowledge of if statements, nor of 404 handling. On top of that, PHP silently manages a lot of plumbing for you: it will also do caching and streaming out of the box and it won't crash the server due to OS ulimit errors when you have a high number of concurrent requests hitting the same file. Heck, you could stream result sets from a database to a streaming HTML document in like a dozen lines of PHP with no libraries 10 years ago. The equivalent machinery to achieve something similar in e.g. the latest Next.js today is beyond abysmal in comparison.
  - egeozcan 7y ago
outworlder 7y ago
> Lines of code or configuration so far: zero. Yes. But by not having configuration, it delegates the configuration to the webserver. Which means that it(and even the language itself!) will exhibit surprising behavior (and even security vulnerabilities) if you deploy somewhere else. Sometimes, having to be explicit about config pays off.
_hardwaregeek 7y ago
It is intriguing that nobody's replicated PHP's ease of deployment. Every other language does require downloading some sort of runtime and setting up some sort of templating/page serving system. Would be an interesting experiment to start with essentially an HTML generating DSL like PHP, but with more modern language design.
- seisvelas 7y ago
  I think that to use PHP embedded in HTML documents (the classical way, with <?php ?> tags) is effectively just using mod_php for Apache as your templating/page serving system, right? I haven't used PHP in many many years, and even then only lightly, so forgive me if this is plain wrong. I do somewhat miss how easy it was to add a small amount of dynamic content to a page in those days without having to drastically alter how anything else worked. I used PHP in a lot of projects without ever really needing to learn it well, much the way I see a lot of web developers 'learn' SQL today. Perhaps that's why so much PHP code back then was a clusterfuck.
  - _hardwaregeek 7y ago
    Yeah I don't actually know. I don't write or really like PHP. But I do begrudgingly admit that PHP advocates have a point when they mention ease of deployment. I don't think any other language has really tackled that properly. Perhaps there's some dead simple Ruby ERB integration that works with a server? I'd love that a lot actually.
- hnick 7y ago
  They tried with Java (Tomcat/JSP) which from memory wasn't that bad to setup, and I even remember trying a Perl variation where you inlined Perl code instead of PHP, but the name eludes me right now. I guess PHP just had that first mover advantage. Don't forget that a lot of the simplicity is because your average shared hosting provider has already installed it for you.
NOGDP 7y ago
The steps you listed work in any language, that's just the browser rendering a text file :).
numlock86 7y ago
> Lines of code or configuration so far: zero. Which zero-conf server was serving PHP back those twenty years ago? I remember using LAMP (and WAMP) installers for local development back then, but getting everything to run on production was always a nightmare. > Number of steps to rebuild or restart: zero. This just made people not debug or test at all. Also it had the side effect of people coding directly on production or just overwriting everything via FTP on the fly. Yes, those were the simple times. But also the dark times.
javajosh 7y ago
Where is the step where PHP is installed and running on the machine, bound to port 80? This is a non-trivial step on every system (slightly less trivial if you bind to port > 1024 but still not for the absolute newbie). Note that you can go much simpler by just loading a file into the browser, and absorbing the dynamism in the front-end. (If you really want a proper URL, then launch a simple static http server in the same directory as the html file.) The great benefit here is that the browsers dev tools are far better than PHP's.

nabdab 7y ago

I remember fondly those early days with PHP before it dawned on me how many peculiarities it had. However to be fair these steps came only after you’d managed to set up the server which was non-trivial on its own. These days I feel like python/flask does it simpler. True you need to define a function and use a decorator, but saves you having to set up the server before getting started on site itself.

why-oh-why 7y ago

That sounds like what Zeit.co is doing. Now.sh is nearly zero-config for a static HTML index and any number of functions in many languages under /api/ In their version 1 they actually even looked for index.js in the root and evaluated that one, but now such a thing requires config (and it isn’t even clear on how to achieve it)

girvo 7y ago
I definitely hope this sort of idea takes off: it’s got a lot of promise to eventually take over from PHP for the “get a beginner rendering dynamic content to a browser quickly” use-case, which is how I learned to program 15 years ago!

agentultra 7y ago

This is a different kind of simple. The simple the OP seems to be going for is the "Ruby + Sinatra," "Python + Flask," "PHP + Laravel" type of simple: a few libraries with small APIs that can make a serviceable starting base. The audience for this are experienced and are not making their first web application.

gridlockd 7y ago

That's not actually simple, it's just convention over configuration. It actually complicates a lot of things, like routing and templating: Those files implicitly do the routing and templating, until they don't, which is where the mess starts. I'd much rather just write request handlers.

0xFACEFEED 7y ago

Did you forget the “A” in LAMP? It’s hardly zero configuration.

MuffinFlavored 7y ago
Anybody could make any language in any app deployed to anything as simple as `sh scripts/build.sh && teraform apply` in my eyes.
avita1 7y ago
While Apache is certainly not zero configuration, it is pretty easy to forget about the Apache part of the LAMP stack. When I got started making websites, I downloaded "WAMP" (windows-apache-mysql-php). It took care of all the configuration and I could, as the author said, drop my code in a www folder and be off to the races. Similarly, lots of hosting providers wouldn't expose the guts of Apache to developers. They would give you some sftp credentials, and let you upload whatever PHP files you wanted. No need to think about Apache configurations (except maybe a few htaccess files).
wolco 7y ago
On centos it was pretty near zero config. With Wamp it was a windows install file and had a neat stack together. Back on my c64 I turned it on, no booting and could just start writing code. We've moved away from this sadly.

thewarrior 7y ago

1) Install node js 2) npm install express 4) Define handler Seems simple enough ?

deleted 7y ago
[deleted]
cpursley 7y ago
Simple, except for the Javascript and npm bits...
Vosporos 7y ago
Simple, yes, but managing a MEAN stack (or even just Node + Express) is far from being "easy".
girvo 7y ago
I disagree with the others, and think this is indeed simple enough without caveats about setting it up (setting up WAMP is honestly just as much effort — not much), and what I’ve used to teach friends who wanted to learn some web programming with zero initial understanding. Explaining routes and handlers was a bit hard, compared to files. I wonder if there’s a “file based” version for Node that’d work like and express handler for the files route?
Wintereise 7y ago
For what it's worth, I agree with you. I associate installing node and installing LAMP/WAMP with similar levels of "difficulty." Sure, `http.createServer` is a few more lines of code compared to the equivalent PHP `hello world` but I don't see it as an insurmountable hurdle.

invalidusernam3 7y ago

I agree that software development has become (often) pointlessly over complicated in the past few years. For my personal projects I usually develop in Yii2, vanilla JS, SCSS, on MAMP. Source lives in Git, deploy via FTP. I track my progress on a simple kanban. I can push out really complex web applications in days. At work, currently we use headless Drupal 8 as an API layer, React/Angular frontend, automated deployments via Jenkins (that takes over 30 minutes), silly microservices, an over complicated Git strategy, with over complicated Jira/Confluence steps, security scans, pen testing. It takes months to release anything. They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website. The biggest difference is the amount of time and the cost.

williamdclt 7y ago
I could also edit live on my production server and the result would be the same: a website. I'm not saying that modern stacks aren't more complicated than they need, but I use a React frontend, a React-Native app, silly microservices, a non-trivial git strategy, non-trivial Trello steps, security scans, automated deployment via CircleCI and yet release multiple times a day. The biggest difference is that deployment always works, always passes tests, does not depends on who deploys, rollbacks automatically if healthchecks fail... You know, the sort of stuff that "reduces defects", "builds quality in", "fails fast" and all sort of concepts that people way smarter than us, working in industry way more mature than ours, have been elaborating for decades
- james_s_tayler 7y ago
  Yup. I think people forget that things aren't the way they used to be because we made forward progress. Maybe that means things got more complex. It also means more things became possible and it became possible to not have things happen which you wish didn't. If everything worked so fine and dandy in the good old days, we'd still be there.
  - mettamage 7y ago
    > If everything worked so fine and dandy in the good old days, we'd still be there. I'm not a historian, but I'm pretty sure a historian could find a lot of counter examples to statements like this. That includes historians who know an aweful lot about programming languages.

bad_user 7y ago

Doing PHP programming was my first programming job, lasted for about 3 years. While I agree with you about the allure of PHP, to be honest, I will never choose PHP again or touch any projects that uses PHP. PHP is an awful, obsolete language, patched again and again to make it more modern. It's like wearing an old leather jacket that has been patched repeatedly, yet it still has a nasty smell. This is entirely subjective of course and I'll take old and trustworthy technologies technologies any day of the week. Except PHP isn't trustworthy and it never was. I have never seen a high level language plagued with so many security issues and this extends to apps built in PHP, like Wordpress. You could attribute that to sloppy coding, or to its popularity, yet if you take the top web vulnerabilities in the wild, most of them (like SQL injections, or remote code executions, or stupid bugs related to implicit conversions, session tampering, etc) aren't possible with modern libraries built in static languages, or at least very hard to accomplish by accident. For me there's also the issue that PHP is really inefficient. Any PHP app will crash your average server if it hits Hacker News, unless you end up caching the pages via Varnish or similar tricks that essentially avoid hitting the PHP interpreter. Configuring Wordpress to withstand a traffic spike can be very challenging, the best solution is to pre-generate the website, thus making it static, which is very weird considering for how long WP and PHP have been on the scene, you'd think there are better solutions by now. You say PHP is easy. I say that PHP is and will always be a security and scalability nightmare. And sure, it allows you to start something fast, but I can start as fast with my favorite technologies and without hitting a wall later. And of course, PHP is nice for beginners, but at the same time I believe you're painting yourself into a corner and it's very hard to grow from there. Besides the issues above, a beginner will be curious about trying new things. CLI utilities, desktop or phone apps, statistics, automation, embedded programming, etc. PHP is unsuitable basically for anything that's not querying MySQL and then spitting an HTML back, which means the learning curve will be worse, because you've picked a very limited hammer.

james_s_tayler 7y ago
Wow. That was the best insult-PHP-rant I've seen in my life.
gambler 7y ago
>I can start as fast with my favorite technologies and without hitting a wall later. What are your "favorite technologies"? Where can I get a hosting using your "favorite technologies" that would allow me to create dynamic server-size content just by editing a single file? (No command line fuckage.) Will the resulting solution be portable to other hosting providers?

leshow 7y ago

That assumes you've got apache set up, or nginx and php-fpm. It also uses the php interpretor. If you had to build a binary like Haskell would, your approach would be different (although you could run haskell in interpreted mode I wouldn't recommend it). It's also kind of unfair because PHP was created for making web pages, Haskell wasn't.

johnday 7y ago
If the lesson is "use languages specifically designed for the use case", then that's a lesson worth learning.
- leshow 7y ago
  The lesson is you can't compare just the language parts of the setup without taking a holistic perspective. just PHP is not sufficient to make a 'hello world' page, you need an entire web server in the form of apache too
adamrezich 7y ago
I spent my high school (~2006) lunch and free periods teaching myself web development on the school computers in the library, running Portable Notepad++, Portable Firefox, and Portable XAMPP, off my third-gen iPod's hard drive. Very good times. XAMPP made LAMP on Windows beyond painless. I miss that old stack.
oaiey 7y ago
To the point. It is very naive to ignore the fact that the work was just outsourced to an IT guy. And the world in which Haskell, Java, JavaScript or .NET can deliver the same "simplicity" of PHP is just called Function as a Service/Serverless (just that this needs some more years before simplicity is actually reached). Ok, a bit stretchy ;)

cookie_monsta 7y ago

I get what you are saying and agree with the sentiment but you did omit the 10 or so steps required before your point #1.

Ericson2314 7y ago

I'm not sure this is simpler. Apache + php is probably far more lines of code. What the above is is rather all the complexity of just one rigid use-case swept under the rug.

seangrogg 7y ago

While you can theoretically get to this level of simplicity with various tools I think the difference isn't so much "can it be this simple?" so much as "does this level of simplicity fit my needs?" and that can be harder to quantify. The same thing you wrote in PHP done in Node.js in an arbitrarily named file served from root: require('http').createServer((_, res) => res.end('Hello World')).listen(80); Zero configuration. You could trivially add some lines from 'fs' to get it to read files instead and whenever you update those files it'll automatically serve the new ones. The problem isn't that it can't be simple. It's that the people cutting checks (or at least the people informing them) also want SSL, non-static pages, sanitized inputs, an attractive interface, log retention, data persistence, ease-of-access, etc. If people were paying me my current rate to send their users unstyled static text over HTTP I'd gladly walk away from all the process. But if they want me to maintain my sanity while writing a non-trivial web application I think integrating a type checker pays off after the first few thousand lines of code. And if I know things are going to get there from the outset then setting it up in advance isn't exactly insanity.

deleted 7y ago
[deleted]
lhorie 7y ago
Eh, that's not a great example. It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get the text to show on a browser. Having two different pages requires no knowledge of if statements, nor of 404 handling. On top of that, PHP silently manages a lot of plumbing for you: it will also do caching and streaming out of the box and it won't crash the server due to OS ulimit errors when you have a high number of concurrent requests hitting the same file. Heck, you could stream result sets from a database to a streaming HTML document in like a dozen lines of PHP with no libraries 10 years ago. The equivalent machinery to achieve something similar in e.g. the latest Next.js today is beyond abysmal in comparison.
- egeozcan 7y ago

outworlder 7y ago

> Lines of code or configuration so far: zero. Yes. But by not having configuration, it delegates the configuration to the webserver. Which means that it(and even the language itself!) will exhibit surprising behavior (and even security vulnerabilities) if you deploy somewhere else. Sometimes, having to be explicit about config pays off.

_hardwaregeek 7y ago

It is intriguing that nobody's replicated PHP's ease of deployment. Every other language does require downloading some sort of runtime and setting up some sort of templating/page serving system. Would be an interesting experiment to start with essentially an HTML generating DSL like PHP, but with more modern language design.

seisvelas 7y ago
I think that to use PHP embedded in HTML documents (the classical way, with <?php ?> tags) is effectively just using mod_php for Apache as your templating/page serving system, right? I haven't used PHP in many many years, and even then only lightly, so forgive me if this is plain wrong. I do somewhat miss how easy it was to add a small amount of dynamic content to a page in those days without having to drastically alter how anything else worked. I used PHP in a lot of projects without ever really needing to learn it well, much the way I see a lot of web developers 'learn' SQL today. Perhaps that's why so much PHP code back then was a clusterfuck.
- _hardwaregeek 7y ago
  Yeah I don't actually know. I don't write or really like PHP. But I do begrudgingly admit that PHP advocates have a point when they mention ease of deployment. I don't think any other language has really tackled that properly. Perhaps there's some dead simple Ruby ERB integration that works with a server? I'd love that a lot actually.
hnick 7y ago
They tried with Java (Tomcat/JSP) which from memory wasn't that bad to setup, and I even remember trying a Perl variation where you inlined Perl code instead of PHP, but the name eludes me right now. I guess PHP just had that first mover advantage. Don't forget that a lot of the simplicity is because your average shared hosting provider has already installed it for you.

NOGDP 7y ago

The steps you listed work in any language, that's just the browser rendering a text file :).

numlock86 7y ago

> Lines of code or configuration so far: zero. Which zero-conf server was serving PHP back those twenty years ago? I remember using LAMP (and WAMP) installers for local development back then, but getting everything to run on production was always a nightmare. > Number of steps to rebuild or restart: zero. This just made people not debug or test at all. Also it had the side effect of people coding directly on production or just overwriting everything via FTP on the fly. Yes, those were the simple times. But also the dark times.

javajosh 7y ago

Where is the step where PHP is installed and running on the machine, bound to port 80? This is a non-trivial step on every system (slightly less trivial if you bind to port > 1024 but still not for the absolute newbie). Note that you can go much simpler by just loading a file into the browser, and absorbing the dynamism in the front-end. (If you really want a proper URL, then launch a simple static http server in the same directory as the html file.) The great benefit here is that the browsers dev tools are far better than PHP's.