10 ms·

The Demise of the Mildly Dynamic Website

4 points by hlandau 4y ago

dusted 4y ago
That is such a well articulated observation, it resonates strongly with my own experience. I grew up on PHP, it was the first thing beyond BASIC I ever wrote, and I wrote a lot and enjoyed it so much. It really was this magic thing, that you just modified whatever file you needed to modify, throw it on the server, and hit f5 to see your changes reflected.. No processes to restart, no state to be lost, you jammed, and it was a very gentle way to learn.
- hlandau 4y ago
  Author here. I have very, very similar childhood memories of PHP. It really was a magic thing to mess around with - I think a lot of people had this experience. I suspect back then a lot of people learnt webdev this way. Sadly I suspect it's less common now. Back then the "LAMP" stack was common enough that there were turnkey packages for Windows that setup "LAMP" for you. Was one called Wampp, or something? I forget. At first I liked using a particular proprietary web server for Windows called 'Sambar Server' which made learning easy due to its PHP support and web GUI config editor. Later setting up Apache, PHP and MySQL on a new Windows install became a common habit for me, once I learnt how to do it. I would make PHP websites and host them locally, then show them to people by giving them the IP (and this was over dialup!)
  - markdown 4y ago
    WAMP for Windows, MAMP for Mac.
    - oldsecondhand 4y ago
      There's also XAMPP
  - deleted 4y ago
    [deleted]
  - commandlinefan 4y ago
    > similar childhood memories of PHP. I really wish y'all would stop making me feel old by reminding me that there are now grown-ups who were children when PHP existed.
- Random_Person 4y ago
  This pretty much describes my day job and I love it. Is our codebase a hot mess? Yeah, we have lots of debt from previous devs, but we're working on it!
- commandlinefan 4y ago
  I remember working with PHP and initially being impressed by its simplicity but quickly being overwhelmed by its restrictiveness. I could tell that there was some sort of higher level of abstraction that could make it more maintainable long term - I even came up with some simplifications of my own that made routine maintenance easier (for me). The problem I've seen is that everybody else had the same thought and came up with their own "simplifications" that they did a much better job of marketing than they did of marketing and now we're stuck using their "frameworks" because to do otherwise invites accusations of "wasting time reinventing the wheel".
  - tored 4y ago
    What is nice is that it easier than ever to write minimal framework, somethings I think you should accept, like using composer and some of the common libraries, however bootstrapping is something I prefer to do myself. I'm having a renaissance with minimal PHP framework. My current iteration looks something like this, and it is only a few functions to do it (I do use a router library, no point of reinventing that) return #[Route(method: 'GET', route: '/projects/{project_uid}/edit')] #[Template(path: __DIR__ . '/template/template.php)] function (Request $request, ProjectRepository $projectRepository) { $projectUid = ProjectUid::of($request->vars['project_uid'] ?? ''); if ($projectUid === null) { return [__DIR__ . '/../errorView.php', [400, 'Missing project_uid']]; } $project = $projectRepository->getProjectByProjectUid($projectUid); if ($project === null) { return __DIR__ . '/../notFoundView.php'; } ?> <div class="container"> <h1><?= escape($project->title) ?></h1> </div> <?php }; Attributes is huge imporovemt to writing a small framework, attributes can not only be used for help setting up routing, HTML templating but other things as middlewares, output buffering, dependency injection. I think we should resist the takeover of large frameworks, and the thing is if you are architecting your application properly, it should be framework independent anyway. Unfortunately many ideas in large frameworks makes it harder or at least invites the developer to make the framework takeover the application.
philihp 4y ago
I can empathize with your lament that it used to be easy to spin up a quick website. It sounds to me like your experience as a software developer blocks you from willfully making mistakes we've all learned the hard way. SSI still works, and you can turn it on with Nginx. It's still quite limiting and fragile. PHP still works, but as your project grows, unless you have equally experienced PHP developers, you'll see things get out of hand quickly with scope issues. CGI will still work, but similar to PHP, it's a headache to setup the sandbox so a malicious or naive committer doesn't clobber the environment. At least PHP's defaults were pretty sane until someone does something cute and bypasses magic quotes and introduces some SQL injection. Let's give AWS Lambda some credit though, it's virtualized and containerized CGI and can scale to handle loads that you'd think your backend was written in Elixir.
- ad404b8a372f2b9 4y ago
  For what it's worth, since you mentioned it, I've found Elixir & Phoenix to be incredibly easy to setup for that purpose. In an hour I had a website running plain HTML and CSS and a few pages with server-side dynamism. In two I had a database, secure auth and stripe integration, it is insanely fast. I think the issue is more cultural than technical to be honest. If you want to learn how to make a website the first thing you're told to do is install node and spin up npm, it's nonsensical. You can't even buy an HTML template anymore, I wanted some nice looking CSS for my website, I searched all over, even bought a few and they all came with 20 scripts out of the box. Even the supposedly pure CSS libraries that advertise themselves as JS-free come with Javascript (just try to make a responsive header in Bulma). It is an insane culture that seems to have forgotten that HTML and CSS are sufficient to implement 99% of what's online today.
  - ryanbrunner 4y ago
    I think while this is true, one thing that was lost with PHP style development is a model that's an easy stepping stone from "a directory full of HTML files". With PHP (and other things like classic ASP) the model was the exact same - it's just that instead of an HTML file, you would request a PHP file and then that would be what was run. The output of that file is what the user would see. With modern-day backend frameworks, that relationship is severed. Your user makes a request, it goes through a bunch of "stuff", and ends up executing a function. How that happens isn't nearly as obvious. It's learnable for sure, but it takes what is a 5 second explanation to something that most brand new developers chalk up to magic for a while.
1vuio0pswjnm7 4y ago
"These are sometimes used to host full-blown web applications but I don't see them being used to facilitate mildly dynamic functionality. mod_perl and mod_lua, for example, don't really offer any kind of functionality allowing you to dip [in] and out of Perl/Lua code inside HTML." I want to understand this statement however I only use Lua with haproxy to achieve "mildly dynamic" pages. It is difficult for me to understand what exactly the author wants to do without an example. Are there any good examples showing that the author is correct, i.e., that it is impossible to "dip in and out" of Lua inside HTML. Certainly I recall projects that purported to offer Lua as a CGI-like interpreter, "Lua Server Pages", or something similar. Have they not delivered on their promises. For example, see http://keplerproject.github.io/cgilua/manual.html http://keplerproject.github.io/cgilua/manual.html https://fuguhub.com/LuaServerPages.lsp https://fuguhub.com/LuaServerPages.lsp http://barracudaserver.com/Lua-Server-Pages.html http://barracudaserver.com/Lua-Server-Pages.html http://xupnpd.org/luasp/ http://xupnpd.org/luasp/ https://redbean.dev/ https://redbean.dev/
- hlandau 4y ago
  Author here. I wasn't aware people had made Lua Server Pages and so on. Thanks, these are an interesting resource and I may actually investigate experimenting with these at some point. If there's a distinction to be made, it's that things like mod_php provided this embedded script functionality out of the box, whereas it looks like these things are separate modules that need to be stacked on top of something like mod_lua. That's not necessarily even a bad thing, as it means more of the stack is readily customised, but it does mean people aren't given an obvious, bright path to get started with in the way LAMP was. You have to seek it out for yourself.
- 1vuio0pswjnm7 4y ago
  Another example is NetBSD's httpd, bozohttpd, which can use Lua, or any interpreter, to run CGI scripts. Lua is included in the NetBSD userland. (OpenBSD by contrast includes Perl.)
- wazoox 4y ago
  With perl, you can use Template::Toolkit, and there's even "PLP" that emulates exactly PHP behaviour, but using Perl as a language, and "<: :>" markers instead of "<?php ?>".
deleted 4y ago
[deleted]
seydor 4y ago
There is nothing "Dynamic" about a website like imgur.com or twitter.com or reddit.com. They are megabytes of javascript heavy and are things you check every once in a while, not things that change before your eyes. I find twitter's 'new tweets' popups annoying and in any case i refresh the page because it s already too heavy from too much infinite-scrolling
- eimrine 4y ago
  Infinite scrolling works bad even in CLI (try open a directory contains 1M files). And I agree that interactivity on websites you have mentioned works mostly against user.
  - seydor 4y ago
    just finished struggling with my bank's redesign, because apparently transations needs to be infinitely scrolled in chunks of 5
parasti 4y ago
Frontpage, now that's a word I haven't heard in a long time. I used to make little pages with Frontpage and inspect the generated text to learn HTML.
- kaetemi 4y ago
  Same. Visual tools at the time were just nice ways of learning the underlying systems. And who needs server side scripted includes, when you can use table and frame tags all you like.
- frosted-flakes 4y ago
  There are a lot of Frontpage websites out there still. Here's one of mh favourites, and still being updated: https://timhunkin.com https://timhunkin.com
dissent 4y ago
> PHP has the world's simplest deployment model for web applications: copy some files to a directory And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. Then configure php too, again taking care to do it securely. Only then you can drop a bunch of files in a docroot and have PHP process them. And put some .htaccess files in so that things that aren't supposed to be directly executed can't be. I think it all just appeared simple, but it wasn't. It was dumb luck and lowest common denominator configurations on shared hosting that made it appear easy.
- krapp 4y ago
  Yes, if you have to set up and configure a webserver from scratch, and compile things, deployment in any language is difficult. But for the most common use cases, PHP is still easier.
  - woojoo666 4y ago
    That assumes you have PHP already installed on the server right? I mean if you already have nodejs on the server, you can also just drop files in
    - jonwinstanley 4y ago
      All the really cheap hosts have PHP installed for you. Not saying they are good, but someone starting out wouldn’t ever start installing things like that.
    - teh_klev 4y ago
      Shared web hosting is still a big thing outside of our developer bubble. PHP is 99.9% guaranteed to be installed in these types of offerings, or it's a one click install on your control panel page.
    - kragen 4y ago
      In my experience, node.js won't run random files it finds in the current directory, and normally it won't reload them if they change after it starts either. And you have to configure your URL space separately from copying files around; it's not as simple as copying homepage.php to homepagenew.php, hacking on it until it works, and then renaming homepagenew.php to homepage.php.
nicoburns 4y ago
I've been working on a "mildly dynamic website" using a modern stack: A simple Rust webserver (about 30 lines setup in the Axum framework) running in a trivial Docker image (just copies in the binary + static assets) hosted on fly.io (which is completely managed and free for up to 3 VMs). It's been great: I have all the flexibility of a dynamic template engine and a turing complete language running before that. But equally if I want to hardcode HTML then I can. And because it's Rust its still wicked fast (I'm getting 50ms page loads including all assets) and resource usage is almost non-existent (it's running on a VM with 256mb ram).
- chasd00 4y ago
  I’ve done the same with nodejs, express, ejs, and bootstrap. I deploy with git to dokku running on linode with letsencrypt setup. That’s a lot of words but it’s bot as complex as it sounds and once it’s setup, enhancements are easy. I run a small laser cutting service for the rocketry hobby. That stack works pretty well for me. Edit: payments are handled by stripe
blenderdt 4y ago
I still build mildly dynamic websites in PHP once in a while. But this is only useful when it is a very small website (max 5 pages?) because you have to work with a directory structure to go without framework. The moment your site gets a little bigger you need some kind of routing. This means you start redirecting all requests to one PHP file. Then you start using forms and you need a database, a little framework for responses, and so on. So you very quickly need a framework. This can of course be a very small framework. The point is, small frameworks are so easy to setup you start skipping the 'mildly dynamic website' part because it doesn't scale at all.
- sjamaan 4y ago
  > The point is, small frameworks are so easy to setup you start skipping the 'mildly dynamic website' part because it doesn't scale at all. Tell that to a non-developer who has a $1 a month shared hosting account who would like to spruce up their website a little bit with (let's say) a visitor counter.
  - Macha 4y ago
    So Vultr starts at $2.50 a month and Linode at $5 a month. $1 in 2000 dollars is $1.67 today, and most of those $1/month hosts were introductory offers anyway. I seem to remember the cheapest real hosting I got in the day was $30/year, and those hosts now charge £4/month and $7/month respectively, though to be fair they include a domain these days.
superkuh 4y ago
Using server side includes support that your nginx/apache/etc webserver binary already has is another very small attack surface way to mild dynamism. I know it sounds 90s and stupid but it's really very useful with no downsides.
lbj 4y ago
I guess we don't format our webpages anymore
- kixiQu 4y ago
  https://maya.land/bookmarklets/readable/ https://maya.land/bookmarklets/readable/ <-- I have a "do" folder for various useful bookmarklets, and this one has gotten some mileage
Puts 4y ago
> Or maybe they just stuck it out and edited every page manually when they wanted to change the header or footer. We had a tool for this called frames!
- commandlinefan 4y ago
  I remember frame-based sites not working right with the back button - I seem to recall that it was mostly the difficulty of getting them to behave properly when the user clicked "back" that made most web developers abandon them.
softcactus 4y ago
As someone fairly new to software, I was brought up on React, Node.js, Flask, Typescript, and AWS Lambda as my tech stack. Is there a definitive resource where I can learn about the older methods of web dev that are talked about in this article?
- hlandau 4y ago
  Author here. I'm glad you asked. Basically if you want an "authentic" experience: - Install Apache with mod_php and a MySQL (/MariaDB) server. Your distro will probably make this fairly easy (with Debian it's just apt install libapache2-mod-php7, etc., for example). You might need some PHP extensions as well, like for MySQL. - For more information read about the "LAMP" stack, though keep in mind modern materials will probably encourage you to use some PHP framework. - Create a file named info.php and put in it "<?php phpinfo();". - Visit the file on the web server. Congratulations, you've done the classic PHP hello world. - Have fun doing random stuff. If you want to do anything serious you will probably want to use (or craft your own) framework, but try seeing what you can do with just 'bare' PHP. PHP also has a built in sessions facility which comes in handy in a pinch. - Remember that going to php.net/FOO does a search of PHP documentation for FOO - they have a 404 handler which does a search for functions. This has been a feature of the PHP website from the very beginning and it's very neat. - Challenge yourself not to use JavaScript. I'm not even saying don't use it (but definitely do use progressive enhancement), but it's a good exercise to give an impression of when people would have done things on the server side instead. You might also look at some older PHP web software - for example things like old-style web forums like phpBB, SMF, etc. to get an idea of how things were done. If you're willing to spend (very few) dollars, you could sign up with a cheapo PHP shared host (they still exist, even if VPSes are big now) and see what you can do with it. (I've used nearlyfreespeech.net in the past, and they're particularly cheap. I have no affiliation with them.) I guess most people probably install WordPress, but back in the day people would craft their own sites in PHP, each with their own character.
commandlinefan 4y ago
> the average modern web developer has no comprehension of what the web actually is And suggesting that there's anything wrong with this is "gatekeeping".
FerretFred 4y ago
I really like the flexibility of Linux, PHP and .. bash scripts that run from cron and populate my SSI files :) My site is lightweight and I don't use frameworks for PHP so load time is exceedingly quick. I take comfort in the fact that if power availability gets tough, I'll be able to transfer the site to something like a Raspberry Pi.
xg15 4y ago
I've been wondering why the approach that many imageboards had to dynamic content didn't catch on further. Essentially, on those boards, HTML wouldn't be rendered for each request but instead regenerated and stored on each update (POST request etc). The update script would generate a plain html file and store it in the www directory of a static web server, overwriting the previous version of that file. For GET requests, the server simply returned the current version of whatever file was requested. This allowed the server to employ the full range of optimizations for static files (caching, partial content headers, etc) while still essentially serving dynamic content. Of course, this kind of architecture makes only sense if updates are rare compared to GETs and if very little of the content depends on individual user identity. However e.g. for blogs or news sites, both conditions are usually given. If there are small amounts of individualized content, this content could be pulled in via scripts.
- hlandau 4y ago
  Good point. Movable Type, one of the oldest blogging engines, used CGI Perl scripts for the admin interface and generated static files. I believe if someone made a comment it would cause the relevant pages to be regenerated in just this way. I've sometimes pondered generating "static" sites which comprise PHP files, where PHP is only used for the actually dynamic parts. So common headers/footers are regenerated only when changed, but things that change constantly are still dynamic. But this would probably be pointless optimization; if one is using PHP, one may as well use it.
- spiffytech 4y ago
  Netlify pushes this model for static sites. Their idea is to have your CMS or app backend trigger a rebuild every time content changes. That's slow if you have a lot of pages, so they have a way to lazy-rebuild pages when they're first accessed.
moth-fuzz 4y ago
Honestly this type of workflow is what I love(d) about rails. ERB is a nice enough templating language such that most trivial functionality is pretty much HTML, but dynamic content can be added in in a php-like way. Equally 'jammable' is the server side code as well - Database is abstracted away, and all server side APIs and application code is all the same ol' Ruby. Django is similar with their own system for python, and equally easy to use. These web frameworks were exceedingly popular at one point, to the point where when node came along, along came express.js with it touted as "rails for node". But aside from rails itself, and possibly django, and php in a more minimal sense, there really isn't this kind of thing anymore? Why did we abandon it? I guess the common criticism is "it doesn't scale" but it seemed perfectly fine for me and my needs, and countless others, right up until every major rails project on github was "last updated: 2014". Feels like the rug was pulled out from under our feet. An exodus without cause, an ark without a flood.
matt_kantor 4y ago
I've noticed this gap too, and started a (very alpha, experimental, and lately neglected) side project[0] that attempts to fit into this niche: a web server oriented explicitly towards "mildly dynamic" use cases. In its current form deployment/updates are definitely not as easy as with shared PHP hosting (I have ideas for how to improve that eventually) and it probably won't scale well to lots of traffic or lots of dynamism (e.g. it spins off separate processes to handle scripting/computation, just like CGI does), but it's been fun to work on and I think helps me cope with the ennui I feel whenever I'm faced with the modern "best practice" of "let's make everything a SPA". [0]: https://github.com/mkantor/operator https://github.com/mkantor/operator
wink 4y ago
I've stumbled upon your website from linked articles from time to time and I really like the new layout. It's kinda as bare-bones (in a good sense) as the old one but just that much nicer to read.
PaulHoule 4y ago
I'd disagree about Lambda functions. I wouldn't use them for most things but I built an email mailing list manager that uses Lambda for several things such as bounce handling, subscribes, verification, unsubscribes, etc. Sometimes I go (more than a few) months without looking at the system. Then I write a blog post that hits it big and get a few hundred sign ups in a few hours. If I were trying to deploy the manager as part of a web site the calculations would be different, but as a stand-alone application I dread the thought of running the manager as a cloud instance or VPS. If I ran the system on a really adequate instance it would cost way too much to run. If I ran the machine on an instance I could afford, every six months or so the system would get a burst of traffic, go swap crazy (quit running AND possibly running up an extra $200 a month in EBS I/O charges) and need maintenance to get it back up. The API gateway for the Lambda function is almost Salesforce.com expensive on a per-request basis but it cheap when you consider the value of an email subscription and that I never have to think about the thing.
vhodges 4y ago
You might be interested in https://stitcherd.vhodges.dev/ https://stitcherd.vhodges.dev/ a side project of mine. It's pretty basic right now, but can already handle a number of use cases for injecting dynamic content into a mostly static site. (Essentially SSI using css selectors and DOM changes on the server side). Alas I haven't had much time to work on it lately, but I plan to use it for something at $DAYJOB so it will get some attention at some point.

4 points by hlandau 4y ago

That is such a well articulated observation, it resonates strongly with my own experience. I grew up on PHP, it was the first thing beyond BASIC I ever wrote, and I wrote a lot and enjoyed it so much. It really was this magic thing, that you just modified whatever file you needed to modify, throw it on the server, and hit f5 to see your changes reflected.. No processes to restart, no state to be lost, you jammed, and it was a very gentle way to learn.

hlandau 4y ago
Author here. I have very, very similar childhood memories of PHP. It really was a magic thing to mess around with - I think a lot of people had this experience. I suspect back then a lot of people learnt webdev this way. Sadly I suspect it's less common now. Back then the "LAMP" stack was common enough that there were turnkey packages for Windows that setup "LAMP" for you. Was one called Wampp, or something? I forget. At first I liked using a particular proprietary web server for Windows called 'Sambar Server' which made learning easy due to its PHP support and web GUI config editor. Later setting up Apache, PHP and MySQL on a new Windows install became a common habit for me, once I learnt how to do it. I would make PHP websites and host them locally, then show them to people by giving them the IP (and this was over dialup!)
- markdown 4y ago
  WAMP for Windows, MAMP for Mac.
  - oldsecondhand 4y ago
    There's also XAMPP
- deleted 4y ago
  [deleted]
- commandlinefan 4y ago
  > similar childhood memories of PHP. I really wish y'all would stop making me feel old by reminding me that there are now grown-ups who were children when PHP existed.
Random_Person 4y ago
This pretty much describes my day job and I love it. Is our codebase a hot mess? Yeah, we have lots of debt from previous devs, but we're working on it!
commandlinefan 4y ago
I remember working with PHP and initially being impressed by its simplicity but quickly being overwhelmed by its restrictiveness. I could tell that there was some sort of higher level of abstraction that could make it more maintainable long term - I even came up with some simplifications of my own that made routine maintenance easier (for me). The problem I've seen is that everybody else had the same thought and came up with their own "simplifications" that they did a much better job of marketing than they did of marketing and now we're stuck using their "frameworks" because to do otherwise invites accusations of "wasting time reinventing the wheel".
- tored 4y ago
  What is nice is that it easier than ever to write minimal framework, somethings I think you should accept, like using composer and some of the common libraries, however bootstrapping is something I prefer to do myself. I'm having a renaissance with minimal PHP framework. My current iteration looks something like this, and it is only a few functions to do it (I do use a router library, no point of reinventing that) return #[Route(method: 'GET', route: '/projects/{project_uid}/edit')] #[Template(path: __DIR__ . '/template/template.php)] function (Request $request, ProjectRepository $projectRepository) { $projectUid = ProjectUid::of($request->vars['project_uid'] ?? ''); if ($projectUid === null) { return [__DIR__ . '/../errorView.php', [400, 'Missing project_uid']]; } $project = $projectRepository->getProjectByProjectUid($projectUid); if ($project === null) { return __DIR__ . '/../notFoundView.php'; } ?> <div class="container"> <h1><?= escape($project->title) ?></h1> </div> <?php }; Attributes is huge imporovemt to writing a small framework, attributes can not only be used for help setting up routing, HTML templating but other things as middlewares, output buffering, dependency injection. I think we should resist the takeover of large frameworks, and the thing is if you are architecting your application properly, it should be framework independent anyway. Unfortunately many ideas in large frameworks makes it harder or at least invites the developer to make the framework takeover the application.

philihp 4y ago

I can empathize with your lament that it used to be easy to spin up a quick website. It sounds to me like your experience as a software developer blocks you from willfully making mistakes we've all learned the hard way. SSI still works, and you can turn it on with Nginx. It's still quite limiting and fragile. PHP still works, but as your project grows, unless you have equally experienced PHP developers, you'll see things get out of hand quickly with scope issues. CGI will still work, but similar to PHP, it's a headache to setup the sandbox so a malicious or naive committer doesn't clobber the environment. At least PHP's defaults were pretty sane until someone does something cute and bypasses magic quotes and introduces some SQL injection. Let's give AWS Lambda some credit though, it's virtualized and containerized CGI and can scale to handle loads that you'd think your backend was written in Elixir.

ad404b8a372f2b9 4y ago
For what it's worth, since you mentioned it, I've found Elixir & Phoenix to be incredibly easy to setup for that purpose. In an hour I had a website running plain HTML and CSS and a few pages with server-side dynamism. In two I had a database, secure auth and stripe integration, it is insanely fast. I think the issue is more cultural than technical to be honest. If you want to learn how to make a website the first thing you're told to do is install node and spin up npm, it's nonsensical. You can't even buy an HTML template anymore, I wanted some nice looking CSS for my website, I searched all over, even bought a few and they all came with 20 scripts out of the box. Even the supposedly pure CSS libraries that advertise themselves as JS-free come with Javascript (just try to make a responsive header in Bulma). It is an insane culture that seems to have forgotten that HTML and CSS are sufficient to implement 99% of what's online today.
- ryanbrunner 4y ago
  I think while this is true, one thing that was lost with PHP style development is a model that's an easy stepping stone from "a directory full of HTML files". With PHP (and other things like classic ASP) the model was the exact same - it's just that instead of an HTML file, you would request a PHP file and then that would be what was run. The output of that file is what the user would see. With modern-day backend frameworks, that relationship is severed. Your user makes a request, it goes through a bunch of "stuff", and ends up executing a function. How that happens isn't nearly as obvious. It's learnable for sure, but it takes what is a 5 second explanation to something that most brand new developers chalk up to magic for a while.

1vuio0pswjnm7 4y ago

"These are sometimes used to host full-blown web applications but I don't see them being used to facilitate mildly dynamic functionality. mod_perl and mod_lua, for example, don't really offer any kind of functionality allowing you to dip [in] and out of Perl/Lua code inside HTML." I want to understand this statement however I only use Lua with haproxy to achieve "mildly dynamic" pages. It is difficult for me to understand what exactly the author wants to do without an example. Are there any good examples showing that the author is correct, i.e., that it is impossible to "dip in and out" of Lua inside HTML. Certainly I recall projects that purported to offer Lua as a CGI-like interpreter, "Lua Server Pages", or something similar. Have they not delivered on their promises. For example, see http://keplerproject.github.io/cgilua/manual.html http://keplerproject.github.io/cgilua/manual.html https://fuguhub.com/LuaServerPages.lsp https://fuguhub.com/LuaServerPages.lsp http://barracudaserver.com/Lua-Server-Pages.html http://barracudaserver.com/Lua-Server-Pages.html http://xupnpd.org/luasp/ http://xupnpd.org/luasp/ https://redbean.dev/ https://redbean.dev/

hlandau 4y ago
Author here. I wasn't aware people had made Lua Server Pages and so on. Thanks, these are an interesting resource and I may actually investigate experimenting with these at some point. If there's a distinction to be made, it's that things like mod_php provided this embedded script functionality out of the box, whereas it looks like these things are separate modules that need to be stacked on top of something like mod_lua. That's not necessarily even a bad thing, as it means more of the stack is readily customised, but it does mean people aren't given an obvious, bright path to get started with in the way LAMP was. You have to seek it out for yourself.
1vuio0pswjnm7 4y ago
Another example is NetBSD's httpd, bozohttpd, which can use Lua, or any interpreter, to run CGI scripts. Lua is included in the NetBSD userland. (OpenBSD by contrast includes Perl.)
wazoox 4y ago
With perl, you can use Template::Toolkit, and there's even "PLP" that emulates exactly PHP behaviour, but using Perl as a language, and "<: :>" markers instead of "<?php ?>".

deleted 4y ago

[deleted]

seydor 4y ago

There is nothing "Dynamic" about a website like imgur.com or twitter.com or reddit.com. They are megabytes of javascript heavy and are things you check every once in a while, not things that change before your eyes. I find twitter's 'new tweets' popups annoying and in any case i refresh the page because it s already too heavy from too much infinite-scrolling

eimrine 4y ago
Infinite scrolling works bad even in CLI (try open a directory contains 1M files). And I agree that interactivity on websites you have mentioned works mostly against user.
- seydor 4y ago
  just finished struggling with my bank's redesign, because apparently transations needs to be infinitely scrolled in chunks of 5

parasti 4y ago

Frontpage, now that's a word I haven't heard in a long time. I used to make little pages with Frontpage and inspect the generated text to learn HTML.

kaetemi 4y ago
Same. Visual tools at the time were just nice ways of learning the underlying systems. And who needs server side scripted includes, when you can use table and frame tags all you like.
frosted-flakes 4y ago
There are a lot of Frontpage websites out there still. Here's one of mh favourites, and still being updated: https://timhunkin.com https://timhunkin.com

dissent 4y ago

> PHP has the world's simplest deployment model for web applications: copy some files to a directory And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. Then configure php too, again taking care to do it securely. Only then you can drop a bunch of files in a docroot and have PHP process them. And put some .htaccess files in so that things that aren't supposed to be directly executed can't be. I think it all just appeared simple, but it wasn't. It was dumb luck and lowest common denominator configurations on shared hosting that made it appear easy.

krapp 4y ago
Yes, if you have to set up and configure a webserver from scratch, and compile things, deployment in any language is difficult. But for the most common use cases, PHP is still easier.
- woojoo666 4y ago
  That assumes you have PHP already installed on the server right? I mean if you already have nodejs on the server, you can also just drop files in
  - jonwinstanley 4y ago
    All the really cheap hosts have PHP installed for you. Not saying they are good, but someone starting out wouldn’t ever start installing things like that.
  - teh_klev 4y ago
    Shared web hosting is still a big thing outside of our developer bubble. PHP is 99.9% guaranteed to be installed in these types of offerings, or it's a one click install on your control panel page.
  - kragen 4y ago
    In my experience, node.js won't run random files it finds in the current directory, and normally it won't reload them if they change after it starts either. And you have to configure your URL space separately from copying files around; it's not as simple as copying homepage.php to homepagenew.php, hacking on it until it works, and then renaming homepagenew.php to homepage.php.

nicoburns 4y ago

I've been working on a "mildly dynamic website" using a modern stack: A simple Rust webserver (about 30 lines setup in the Axum framework) running in a trivial Docker image (just copies in the binary + static assets) hosted on fly.io (which is completely managed and free for up to 3 VMs). It's been great: I have all the flexibility of a dynamic template engine and a turing complete language running before that. But equally if I want to hardcode HTML then I can. And because it's Rust its still wicked fast (I'm getting 50ms page loads including all assets) and resource usage is almost non-existent (it's running on a VM with 256mb ram).

chasd00 4y ago
I’ve done the same with nodejs, express, ejs, and bootstrap. I deploy with git to dokku running on linode with letsencrypt setup. That’s a lot of words but it’s bot as complex as it sounds and once it’s setup, enhancements are easy. I run a small laser cutting service for the rocketry hobby. That stack works pretty well for me. Edit: payments are handled by stripe

blenderdt 4y ago

I still build mildly dynamic websites in PHP once in a while. But this is only useful when it is a very small website (max 5 pages?) because you have to work with a directory structure to go without framework. The moment your site gets a little bigger you need some kind of routing. This means you start redirecting all requests to one PHP file. Then you start using forms and you need a database, a little framework for responses, and so on. So you very quickly need a framework. This can of course be a very small framework. The point is, small frameworks are so easy to setup you start skipping the 'mildly dynamic website' part because it doesn't scale at all.

sjamaan 4y ago
> The point is, small frameworks are so easy to setup you start skipping the 'mildly dynamic website' part because it doesn't scale at all. Tell that to a non-developer who has a $1 a month shared hosting account who would like to spruce up their website a little bit with (let's say) a visitor counter.
- Macha 4y ago
  So Vultr starts at $2.50 a month and Linode at $5 a month. $1 in 2000 dollars is $1.67 today, and most of those $1/month hosts were introductory offers anyway. I seem to remember the cheapest real hosting I got in the day was $30/year, and those hosts now charge £4/month and $7/month respectively, though to be fair they include a domain these days.

superkuh 4y ago

Using server side includes support that your nginx/apache/etc webserver binary already has is another very small attack surface way to mild dynamism. I know it sounds 90s and stupid but it's really very useful with no downsides.

lbj 4y ago

I guess we don't format our webpages anymore

kixiQu 4y ago
https://maya.land/bookmarklets/readable/ https://maya.land/bookmarklets/readable/ <-- I have a "do" folder for various useful bookmarklets, and this one has gotten some mileage

Puts 4y ago

> Or maybe they just stuck it out and edited every page manually when they wanted to change the header or footer. We had a tool for this called frames!

commandlinefan 4y ago
I remember frame-based sites not working right with the back button - I seem to recall that it was mostly the difficulty of getting them to behave properly when the user clicked "back" that made most web developers abandon them.

softcactus 4y ago

As someone fairly new to software, I was brought up on React, Node.js, Flask, Typescript, and AWS Lambda as my tech stack. Is there a definitive resource where I can learn about the older methods of web dev that are talked about in this article?

hlandau 4y ago
Author here. I'm glad you asked. Basically if you want an "authentic" experience: - Install Apache with mod_php and a MySQL (/MariaDB) server. Your distro will probably make this fairly easy (with Debian it's just apt install libapache2-mod-php7, etc., for example). You might need some PHP extensions as well, like for MySQL. - For more information read about the "LAMP" stack, though keep in mind modern materials will probably encourage you to use some PHP framework. - Create a file named info.php and put in it "<?php phpinfo();". - Visit the file on the web server. Congratulations, you've done the classic PHP hello world. - Have fun doing random stuff. If you want to do anything serious you will probably want to use (or craft your own) framework, but try seeing what you can do with just 'bare' PHP. PHP also has a built in sessions facility which comes in handy in a pinch. - Remember that going to php.net/FOO does a search of PHP documentation for FOO - they have a 404 handler which does a search for functions. This has been a feature of the PHP website from the very beginning and it's very neat. - Challenge yourself not to use JavaScript. I'm not even saying don't use it (but definitely do use progressive enhancement), but it's a good exercise to give an impression of when people would have done things on the server side instead. You might also look at some older PHP web software - for example things like old-style web forums like phpBB, SMF, etc. to get an idea of how things were done. If you're willing to spend (very few) dollars, you could sign up with a cheapo PHP shared host (they still exist, even if VPSes are big now) and see what you can do with it. (I've used nearlyfreespeech.net in the past, and they're particularly cheap. I have no affiliation with them.) I guess most people probably install WordPress, but back in the day people would craft their own sites in PHP, each with their own character.

commandlinefan 4y ago

> the average modern web developer has no comprehension of what the web actually is And suggesting that there's anything wrong with this is "gatekeeping".

FerretFred 4y ago

I really like the flexibility of Linux, PHP and .. bash scripts that run from cron and populate my SSI files :) My site is lightweight and I don't use frameworks for PHP so load time is exceedingly quick. I take comfort in the fact that if power availability gets tough, I'll be able to transfer the site to something like a Raspberry Pi.

xg15 4y ago

I've been wondering why the approach that many imageboards had to dynamic content didn't catch on further. Essentially, on those boards, HTML wouldn't be rendered for each request but instead regenerated and stored on each update (POST request etc). The update script would generate a plain html file and store it in the www directory of a static web server, overwriting the previous version of that file. For GET requests, the server simply returned the current version of whatever file was requested. This allowed the server to employ the full range of optimizations for static files (caching, partial content headers, etc) while still essentially serving dynamic content. Of course, this kind of architecture makes only sense if updates are rare compared to GETs and if very little of the content depends on individual user identity. However e.g. for blogs or news sites, both conditions are usually given. If there are small amounts of individualized content, this content could be pulled in via scripts.

hlandau 4y ago
Good point. Movable Type, one of the oldest blogging engines, used CGI Perl scripts for the admin interface and generated static files. I believe if someone made a comment it would cause the relevant pages to be regenerated in just this way. I've sometimes pondered generating "static" sites which comprise PHP files, where PHP is only used for the actually dynamic parts. So common headers/footers are regenerated only when changed, but things that change constantly are still dynamic. But this would probably be pointless optimization; if one is using PHP, one may as well use it.
spiffytech 4y ago
Netlify pushes this model for static sites. Their idea is to have your CMS or app backend trigger a rebuild every time content changes. That's slow if you have a lot of pages, so they have a way to lazy-rebuild pages when they're first accessed.

moth-fuzz 4y ago

Honestly this type of workflow is what I love(d) about rails. ERB is a nice enough templating language such that most trivial functionality is pretty much HTML, but dynamic content can be added in in a php-like way. Equally 'jammable' is the server side code as well - Database is abstracted away, and all server side APIs and application code is all the same ol' Ruby. Django is similar with their own system for python, and equally easy to use. These web frameworks were exceedingly popular at one point, to the point where when node came along, along came express.js with it touted as "rails for node". But aside from rails itself, and possibly django, and php in a more minimal sense, there really isn't this kind of thing anymore? Why did we abandon it? I guess the common criticism is "it doesn't scale" but it seemed perfectly fine for me and my needs, and countless others, right up until every major rails project on github was "last updated: 2014". Feels like the rug was pulled out from under our feet. An exodus without cause, an ark without a flood.

matt_kantor 4y ago

I've noticed this gap too, and started a (very alpha, experimental, and lately neglected) side project[0] that attempts to fit into this niche: a web server oriented explicitly towards "mildly dynamic" use cases. In its current form deployment/updates are definitely not as easy as with shared PHP hosting (I have ideas for how to improve that eventually) and it probably won't scale well to lots of traffic or lots of dynamism (e.g. it spins off separate processes to handle scripting/computation, just like CGI does), but it's been fun to work on and I think helps me cope with the ennui I feel whenever I'm faced with the modern "best practice" of "let's make everything a SPA". [0]: https://github.com/mkantor/operator https://github.com/mkantor/operator

wink 4y ago

I've stumbled upon your website from linked articles from time to time and I really like the new layout. It's kinda as bare-bones (in a good sense) as the old one but just that much nicer to read.

PaulHoule 4y ago

I'd disagree about Lambda functions. I wouldn't use them for most things but I built an email mailing list manager that uses Lambda for several things such as bounce handling, subscribes, verification, unsubscribes, etc. Sometimes I go (more than a few) months without looking at the system. Then I write a blog post that hits it big and get a few hundred sign ups in a few hours. If I were trying to deploy the manager as part of a web site the calculations would be different, but as a stand-alone application I dread the thought of running the manager as a cloud instance or VPS. If I ran the system on a really adequate instance it would cost way too much to run. If I ran the machine on an instance I could afford, every six months or so the system would get a burst of traffic, go swap crazy (quit running AND possibly running up an extra $200 a month in EBS I/O charges) and need maintenance to get it back up. The API gateway for the Lambda function is almost Salesforce.com expensive on a per-request basis but it cheap when you consider the value of an email subscription and that I never have to think about the thing.

vhodges 4y ago

You might be interested in https://stitcherd.vhodges.dev/ https://stitcherd.vhodges.dev/ a side project of mine. It's pretty basic right now, but can already handle a number of use cases for injecting dynamic content into a mostly static site. (Essentially SSI using css selectors and DOM changes on the server side). Alas I haven't had much time to work on it lately, but I plan to use it for something at $DAYJOB so it will get some attention at some point.