[HN Gopher] The demise of the mildly dynamic website (2022)
___________________________________________________________________
The demise of the mildly dynamic website (2022)
Author : thunderbong
Score : 158 points
Date : 2024-06-19 16:17 UTC (6 hours ago)
(HTM) web link (www.devever.net)
(TXT) w3m dump (www.devever.net)
| politelemon wrote:
| > What captured people's imaginations about AWS Lambda is that it
| lets you a) give any piece of code an URL, and b) that code
| doesn't consume resources when it's not being used. Yet these are
| also exactly the attributes possessed by PHP or CGI scripts. In
| fact, it's far easier for me to write a PHP script and rsync it
| to a web server of mine than for me to figure out the extensive
| and complex tooling for creating, maintaining and deploying AWS
| Lambda functions -- and it comes without the lock-in to boot.
| Moreover, the former allows me to give an URL to a piece of code
| instantly, whereas with the latter I have to figure out how to
| setup AWS API Gateway plumbing correctly. I'm genuinely curious
| how many people find AWS Lambda interesting because they've never
| encountered, or never properly looked at, CGI.
|
| Well, assuming you are genuinely curious and not just using an
| expression!
|
| The difference is that the 'web server' is still consuming
| resources when the code is not in use. They aren't equivalent at
| all. The web server is hosted on an OS and both require ongoing
| maintenance.
|
| Further, the appeal of Lambda is in its ease of onboarding for
| newcomers; I can run a piece of .NET or JS or Python locally and
| directly without a lambda 'layer' to host it, just invoke the
| handler method.
|
| I'm not sure what complex tooling that the author is referring to
| though, it's a zip and push.
| chasd00 wrote:
| In a lot of these discussions the point gets raised about the
| work to maintain a self-hosted server. When i've done it I
| install the os (usually ubuntu server), turn off unused
| services, setup the firewall to only allow required ports, and
| then it just sort of sits there and does its thing. Uptimes
| have been measured in years in some cases and the server just
| sits there happily serving whatever html and connecting to
| whatever db forever.
| pixl97 wrote:
| I mean, typically hosting a static site that's fine, but with
| the number of exploits these days and the ability for people
| to chain them together, maybe you don't even realize your box
| has been exploited?
|
| Uptimes in years means your box, especially without updates
| has something it could be targeted with.
| graemep wrote:
| Most of those that are find for a static site but not
| dynamic are those that are not fixed by just applying
| updates from the distro.
|
| You still need to update your app code even if you are
| using someone elses servers, so its the same either way.
| pixl97 wrote:
| Note that the parent said "uptimes measured in years", so
| they are either using a more complex system with multiple
| servers, or they are not doing security updates.
| josephcsible wrote:
| Do you enable unattended upgrades and kernel live patching?
| If not, then that doesn't seem secure.
| cutler wrote:
| `dnf upgrade` or `apt update && apt upgrade` once a month
| isn't so much work. If either includes a kernel upgrade
| then it's `reboot now` and I'm done.
| josephcsible wrote:
| But if you're doing that, it's not just sitting there,
| and you'd never get anywhere close to years of uptime.
| icedchai wrote:
| Once you add API gateway, IAM roles/permissions, VPC, security
| groups, it gets a lot more complicated. Then you want to host a
| static web site, reverse proxying to API gateway, add
| CloudFront, WAF, etc. You'll go crazy setting this up manually,
| so you'll also want Terraform or CloudFormation to make it
| repeatable.
|
| For anything complex, you'll run into "slow start" issues and
| have to look at provisioned concurrency.
|
| Lambda also sucks for dependencies. Zips and "layers" can only
| be so large. Eventually you'll hit the limit and have to move
| to containers. There are also other limitations, like payload
| sizes. Eventually you might run into that, too.
|
| Also, it would be nice if Lambda just reused the CGI interface
| instead of inventing its own thing.
| owenversteeg wrote:
| Yeah, it's an absolute explosion of complexity, and with it
| comes the risk that you miss something and are faced with a
| security issue or giant bill or both.
|
| What I would kill for is something in between all of this and
| FTPing PHP around like it's 1999. I've hunted for years for
| middle-ground solutions and haven't found anything. Security,
| cost, performance etc are important, sure, but what I really
| yearn for is a simple, easy, bulletproof solution like the
| days of yore when a handful of simple scripts could chug on
| for decades. Two decades ago you could set up a simple site
| that needed no attention for twenty years. Today's
| technologies require constant attention and updates and if
| you blink then everything requires an update that's not
| compatible with your code. Meanwhile, PHP from 2004 can be
| trivially run in 2024. What's the PHP-and-FTP of today? Does
| it exist?
| jacobgkau wrote:
| > They aren't equivalent at all. The web server is hosted on an
| OS and both require ongoing maintenance.
|
| From a technical standpoint, surely the servers running Lambda
| have an OS and require maintenance internally by Amazon at some
| level (even if it's dev-ops-abstracted away for their
| operators). It's just their responsibility instead of yours,
| and it's also their responsibility to find other work for those
| servers when your code isn't running (or bear the cost of an
| idle server). It's like if they were letting you push PHP
| functions to their web server, using the quoted comparison.
|
| Useful from a business standpoint, yes. Revolutionary, maybe
| not as much as it seems at first glance. That's the takeaway I
| got.
| Joker_vD wrote:
| And, of course, they don't just "bear the cost of an idle
| server". Just like any other fixed costs in any other
| industry, those costs get smeared over the charged prices.
| Unless there is some serious economy of scale (i.e. ops at
| Amazon managing to handle the upkeep of a 1000 of their
| servers for less than 1/1000 it costs you to manage 1 of your
| server), you're ending up paying somewhat more. But then
| again, you don't have to spend time to manage your own server
| which is probably a positive trade-off.
| Uehreka wrote:
| > Useful from a business standpoint, yes.
|
| This business standpoint is the whole thing, I don't see many
| people arguing otherwise. And the business standpoint is in
| fact quite revolutionary.
|
| Amazon can have a team of like 5 engineers maintaining VM
| images and as a result 500,000 other people don't have to.
| And so you can host a "server" that's only "on" when it's in
| use, and usually end up paying less than $1/mo.
|
| In fact, you could likely run all of your side projects in
| lambda and if they're "conventional web server" type things
| you could still end up paying less than $1/mo across all of
| them.
|
| Compare that to a $5/mo droplet for every side project (you
| probably don't want to bunk multiple services into a $5 VM)
| and it definitely adds up before even considering updating
| the OS on those droplets.
| Sharlin wrote:
| Running PHP on a VM in a data center doesn't cost you anything
| either while the VM isn't doing stuff, and you still have
| something to ssh into and manage and investigate without layers
| of abstraction bolted on top. And PHP-on-httpd is pretty much
| one of the most newcomer-friendly straight-to-coding
| environments ever developed.
| sophacles wrote:
| Where can I get a VM in a data center that doesn't cost me
| anything?
| superkuh wrote:
| Server side includes are _still_ the perfect amount of power if
| you want to do templating stuff like comments.html footer.html or
| right_menu.html includes across all site pages. And the attack
| surface is so minimal and code so stable there 's basically no
| increased risk using SSI over just html with nginx and similar
| webservers.
| bandrami wrote:
| Ah but! The problem is SSI includes the bang directive, which
| outputs the results of a shell command.
|
| Once that's available, people will demand and abuse it, and
| we're back at cgi-bin.
| superkuh wrote:
| > SSI includes the bang directive,
|
| Not in ngx_http_ssi_module or any modern webserver I've used?
| As for "people"? What people? I guess your implicit
| assumption is this is a group or commercial project? I was
| thinking more website made by a human person.
| RedShift1 wrote:
| But can you write Doom with SSI?
| doublerabbit wrote:
| I suppose in theory.
|
| Pass the button press of the clicked button iframe to a
| headless version of the game.
|
| Capture and transfer the output to an transparent png back
| via an http meta refresh in another iframe.
| flobosg wrote:
| (2022)
| dang wrote:
| Added. Thanks!
| dang wrote:
| Discussed at the time:
|
| _The Demise of the Mildly Dynamic Website_ -
| https://news.ycombinator.com/item?id=31236290 - May 2022 (91
| comments)
| rkozik1989 wrote:
| Did everyone just forget about Varnish HTTP Cache or something?
| Or are we just using the new shiny ball because its new?
| snovymgodym wrote:
| I like this article except for the part about Lambda. The author
| doesn't seem to get that for some use cases there are serious
| benefits to having bits of code that run only when you need it,
| and only getting billed for those runs instead of getting billed
| for a VM or container runtime that's always present.
|
| Obviously if your application involves processing a predictable
| high volume of requests, then you're probably better off running
| it on your own server/container, but depending on your use case
| there are times where Functions-as-a-service are the prefect
| solution.
|
| The part about "why use lambda when cgi-bin exists" reminds me of
| the HN comment on the DropBox announcement from 2007 where the
| guy says something like "this is cool but why would anyone use it
| when you can just whip together ftp and svn on a debian box and
| have the same thing?"
| decasia wrote:
| I think it kind of goes both ways. There are times when you
| absolutely want lambda functions instead of cgi-bin scripts.
| But conversely - there are times when you absolutely want cgi-
| bin instead of lambda. (For interfacing with other linux
| services or packages, for example). The two tools don't always
| substitute for each other.
| pixl97 wrote:
| I mean, that is the difference between using something
| because it's the flavor of the day and using something
| because it's the best tool for the job.
| Stratoscope wrote:
| Here's the full quote:
|
| > For a Linux user, you can already build such a system
| yourself quite trivially by getting an FTP account, mounting it
| locally with curlftpfs, and then using SVN or CVS on the
| mounted filesystem. From Windows or Mac, this FTP account could
| be accessed through built-in software.
|
| https://news.ycombinator.com/item?id=8863
| ikari_pl wrote:
| i just remembered how FTP server was built-in in Windows,
| easy to set up, and IPs were public, so yeah, it was easy to
| share a local folder directly (but you had to know what
| you're doing anyway, and same for the other person).
|
| good times.
| jimbokun wrote:
| Which is 100% true. And it's also true Dropbox was a great
| product because it provided this functionality for the vast
| majority of the population who don't have the time or
| interest to learn all those tools.
| decasia wrote:
| I think the spirit of this article is correct, although some of
| the digs at modern web tech and SPAs seem to be beside the point.
|
| I used to have a "mildly dynamic website." It was a $5 digital
| ocean box. It ran nginx with php-fpm, mostly so it could have a
| Wordpress install in a subdirectory, and it had a unicorn setup
| for an experimental Rails app somewhere in there.
|
| Given that environment, the "mildly dynamic website" experience
| that TFA talks about was absolutely true. If I wanted a simple
| script to accept form input, or some little tiny dynamic
| experimental website, I could trivially deploy it. I could write
| PHP (ugh) or whatever other backend service I felt like writing.
| I ported the Rails app to golang after a while. It was fun. It
| made for a low cost of entry for experimental, hackish things.
| It's a nice workshop if you have it.
|
| The thing is -- if you are running this setup on your own linux
| virtual machine -- it requires endless system maintenance.
| Otherwise all the PHP stuff becomes vulnerable to random hacks.
| And the base OS needs endless security updates. And maybe you
| want backups, because you got lazy about maintaining your ansible
| scripts for system setup. And the price of the $5 virtual linux
| box tends to go up over the years. And the "personal website"
| model of the web has kind of declined (not that it's altogether
| dead, just marginalized by twitter/facebook).
|
| So I got exhausted by having to maintain the environment (I
| already do enough system maintenance at work) and decided to
| switch to static HTML sites on S3. You can't hack it anymore. But
| so far -- I can live with it.
| pixl97 wrote:
| And then you forgot to add "I had to stick it behind cloudflare
| because someone decided to DDOS it and send me 500GB/s traffic
| for no apparent reason at all.
|
| The early web was the wild west. The modern web has turned into
| small fry trying to hide in the shadows of megalodons so they
| don't get ate by a goliath.
| edflsafoiewq wrote:
| Shared hosting is probably better, and AFAIK more common, for
| the mildly dynamic website. The host handles a lot of the admin
| tasks like OS updates that you have to handle yourself with a
| VPS.
| adamomada wrote:
| When I was checking out the grav flat-file CMS, they had a
| recommendation for PaaS (php as a service)
|
| https://learn.getgrav.org/16/webservers-hosting
| massysett wrote:
| NearlyFreeSpeech.NET is good for this. Their main tier -
| "production" sites - are very inexpensive and the admins take
| care of OS and server-software updates. They have another
| tier - "non-production" sites - that are even cheaper and can
| be perfectly sufficient for a personal homepage. The admins
| maintain these servers as well but they might do beta testing
| on them.
|
| The environment is fully hackable and has PHP, SSH, SFTP,
| MariaDB, dominant languages like Perl and Python, obscure
| languages like Haskell and Lisp, etc etc.
| mk12 wrote:
| +1 for NearlyFreeSpeech! I've used them for years paying
| only 40-45 cents a month. I love that I can just ssh in and
| mess around. My site is mostly static but recently I wanted
| to add a private section for specific family and friends.
| So I implemented OAuth 2.0 login with 2 php files and an
| .htaccess rule.
| svieira wrote:
| And even more obscure languages like Forth and Octave. The
| only thing to watch out for is that they run FreeBSD
| (instead of a more "normal" distribution) so if you're used
| to Linux-as-seen-on-Debian-or-Ubuntu there are a few things
| that are different (but so cozy).
| wwweston wrote:
| This. For people looking for hosting as a service that don't
| need scale (and even for some people who think they do)
| shared hosting is often the best low-admin + low-cost
| solution. Buuut you can't brag about your cloud setup.
| chubot wrote:
| _The thing is -- if you are running this setup on your own
| linux virtual machine -- it requires endless system
| maintenance._
|
| Yeah, this is exactly what I talk about this post -- why do I
| used shared hosting?
|
| _Comments on Scripting, CGI, and FastCGI_ -
| https://www.oilshell.org/blog/2024/06/cgi.html
| dreadnip wrote:
| > it requires endless system maintenance. Otherwise all the PHP
| stuff becomes vulnerable to random hacks
|
| How so? I've seen PHP websites & apps run for 10+ years in
| production without updates. Even longer with a simple "sudo apt
| update" every few months and a "composer update" every year or
| so. The maintenance rate is actually very very low.
| crazygringo wrote:
| Years ago a Digital Ocean virtual server of mine stopped
| working because I had never upgraded Ubuntu. After a few
| years, the version of Ubuntu was no longer supported by the
| Digital Ocean hypervisor (?) and couldn't mount or boot at
| all.
|
| In my experience, yes you absolutely need maintenance. In the
| past I've had to upgrade from HTTP to HTTPS, upgrade to newer
| versions of external API and embedded components because the
| old ones were deprecated, handle a domain registrar shutting
| down, and then yes absolutely PHP updates and upgrades for
| security that then start giving you warnings because less
| secure versions of functions are being deprecated...
|
| I literally cannot imagine how you would keep a PHP site
| running on a virtual server for 10 years without any
| maintenance. I need to address an issue probably roughly once
| a year.
| fpoling wrote:
| I am puzzled that your site required constant maintenance. I
| run a similar setup that I hardens using systemd service
| restrictions with nothing running as root. Then I subscribed to
| Debian and couple more mail lists with security announcements.
| It turned out I needed to spend like 20 minutes per month to
| maintain it.
|
| I also find that PHP works much better than Go regarding
| maintenance efforts. With Debian I have automatic updates of
| all PHP dependencies that I need so security announcements is a
| nice single source of truth. But with Go I would need to setup
| monitoring of dependencies for updates myself and
| recompile/deploy the code as necessary.
| solardev wrote:
| This perspective isn't really making an apples-to-apples
| comparison. The author is comparing modern framework bloat to the
| simplicity of a standalone PHP script, but disregarding the
| underlying stack that it takes to serve those scripts (i.e., the
| Linux, Apache/Nginx, MySQL/Postgres in LAMP).
|
| Back in those days, it was never really as simple as "sftp my
| .php file into a folder and call it a day". If you were on a
| shared host, you may or may not have access to any of the PHP
| config, needed for things such as adjusting memory limits (or
| your page might not render), which particular PHP version was
| available (limiting your available std lib functions), which
| modules were installed (and which version of them, and whether
| they were made for fastcgi or not). Scaling was in its infancy
| those days and shared hosts were extremely slow, especially those
| without caching, and would frequently crash whenever one tenant
| on that machine got significant traffic. If you were hosting your
| own in a VM or bare-metal, things were even worse, since then you
| had to manage the database on your own, the firewall, the SSH
| daemon, Apache config files in every directory or Nginx rules and
| restarts, OS package updates, and of course hardware/VM resource
| constraints.
|
| Yes, the resulting 100-line PHP script sitting on top of it all
| might be very simple, but maintaining that stack never was (and
| still isn't). Web work back then was like 25% coding the PHP and
| 75% sys-admining the stack beneath it. And it was really hard to
| do that in a way that didn't result in customer-facing downtime,
| with no easy way to containerize, scale, hot-standby, rollover,
| rollback, etc.
|
| =====================
|
| I'd probably break down this comparison (of LAMP vs modern JS
| frameworks) into questions like this, instead:
|
| 1) "What do I have to maintain? What do I WANT to maintain?"
|
| IMHO this is the crux of it. Teams (and individual devs) are
| choosing JS frameworks + heavy frontends because even though
| there are still servers and configurations (of course), they're
| managed by _someone else_. That abstraction and separation of
| concerns is what makes it so much easier to work on a web app
| these days than in the PHP days, IMO.
|
| Any modern framework now is a one-command `create whatever app`
| in the terminal, and there, you have a functioning app waiting
| for your content and business logic. That's even easier than
| spinning up a local PHP stack with MAMP or XAMPP, especially when
| you have more than one app on the same disk/computer. And when it
| comes time to deploy, a single `git push` will get you a highly-
| available website automagically deployed in a couple minutes,
| with a preconfigured global CDN, HTTPS, asset caching, etc. If
| something went wrong, it's a one-click rollback to the previous
| version. And it's probably going to be free, or under $20/mo, on
| Vercel, Cloudflare Pages, Netlify, etc. Maybe AWS Amplify Hosting
| too, but like Lambda, that's a lot more setup (AWS tends to be
| lower-level and offers nitty-gritty enterprise-y configs that
| simpler sites don't need or want).
|
| By contrast, to actually set up something like that in the PHP
| world (where most of the stack is managed by someone else), you'd
| either have to find a similar PHP-script-hosting-as-a-service
| like Google App Engine (there's not many similar services that I
| know of; it's different from a regular shared host because it's a
| higher level of abstraction) or else use something like Docker or
| Lando or Forge or GridPane to manage your own VM fleet. In the
| latter cases you would often still have to manage much of the
| underlying stack and deal with various configs and updates all
| the time. It's very different from the hosted JS world.
|
| The benefit of going with a managed approach is that you're
| really only needing to touch your own application code. The
| framework code is updated by someone else (not that different
| from using Laravel or Symfony or Wordpress or Drupal). The rest
| of the stack is entirely out of your sphere of responsibility.
| For "jamming" as an individual or producing small sites as a
| team, this is a good thing. It frees up your devs to focus on
| business needs rather than infrastructure management.
|
| Of course, some teams want entirely in-house control of
| everything. In that case they can still manage to their own low-
| level VMs (an EC2 or similar) and maintain the whole LEMP or Node
| stack. That's a lot more work, but also more power and control.
|
| A serverless func, whether in JS (anywhere) or PHP (like via
| Google Cloud Run), is just a continuation of this same
| abstraction. It's not necessarily just about high availability,
| but low maintenance. You and your team (and the one after them,
| and the one after that) only ever have to touch the function code
| itself, freeing you from the rest of the stack. It's useful the
| same way that being able to upload a video to YouTube is: You can
| focus on the content instead of the delivery mechanism.
|
| 2) Serverside resource consumption
|
| It's not really true that "PHP scripts don't consume any
| resources (persistent processes, etc.) when they're not being
| used", any more than a JS site or serverless func isn't consuming
| resources when they're not being used. Both still require an
| active server on the backend (or some server-like technology,
| like a Varnish or Redis cache or similar).
|
| Neither is really an app author's concern, since they are both
| hosting concerns. But the advantage of the JS stuff is that it's
| easier and cheaper for hosts to containerize and run
| independently, like in a V8 isolate (for Cloudflare Workers).
| It's harder to do that with a PHP script and still ensure safety
| across shared tenants. Most shared PHP environments I know of end
| up virtualizing/dockerizing much of the LAMP stack.
|
| 3) Serverside rendering vs static builds vs clientside rendering
|
| As for serverside rendering vs static builds, the article doesn't
| really do a fair comparison of that either. This is a tradeoff
| between delivery speed and dynamicness, not between PHP and JS.
|
| Even in the PHP world, the PHP processor itself offered caching,
| then frameworks like Wordpress would offer its own caching on top
| of that, then you would cache even the result of that in Varnish
| or similar. That essentially turns a serverside rendered page
| into a static build that can then be served over a CDN. This is
| how big PHP hosts like Pantheon or Acquia work. No medium or big
| size would make every request hit the PHP process directly for
| write-rarely, read-often content.
|
| In the JS world, you can also do serverside rendering, static
| builds, clientside renders, and (realistically) some combination
| of all of those. The difference is that it's a lot more
| deliberate and explicit (but also confusing at first). But this
| is by design. It makes use of the strength of each part of that
| stack, as intended. If you're writing a blog post, chances are
| you're not going to edit that more than once every few
| weeks/months (if ever again). That part of it can be statically
| built and served as flat HTML and easily cached on the CDN. But
| the comments might trickle in every few minutes. That part can be
| serverside rendered in real time and then cached, either at the
| HTTP level with invalidations, or incrementally regenerated at
| will. And some things need to be even faster than that, like
| maybe being able to preview the image upload in your WYSIWYG
| editor, in which case you'd optimistically update the clientside
| editor with a skeleton and then verify upload/insertion success
| via AJAX. The server can do what it does best (query/collate data
| from multiple sources and render a single page out of it for all
| users to see), the cache can do what it does best (quickly copy
| and serve static content across the world), and the client can do
| what it does best (ensure freshness for an individual user, where
| needed).
|
| It is of course possible (and often too easy) to mis-use the
| different parts of that stack, but you can say the same thing
| about the PHP world, with misconfigured caches and invalidations
| causing staleness issues or security lapses like accidentally
| shared secrets between users' cached versions.
| solardev wrote:
| (too long... here's part 2):
|
| 4) Serverless as "CGI but it's trendy, [with vendor lock-in and
| a more complex deployment process]"
|
| What vendor lock-in? Most of the code is just vanilla JS. There
| might be a different deployment procedure if you're using
| Cloudflare vs Lambda vs Vercel vs Serverless Framework, but
| those are typically still simpler than having to set up an SFTP
| connection or git repo in a remote folder. With a framework
| like Next, a serverless function is just another file in the
| API folder, managed in the same repo as the rest of your app.
| Even without a framework, you can edit and deploy a serverless
| function in a Cloudflare Sandbox with a few clicks and no
| special tooling. If you later want to move that to another
| serverless host (what an ironic term), you can copy and paste
| the code and modify maybe 10-15% of it to get it running again.
| And the industry is trying to standardize that part of it too.
|
| And I think this directly relates to #1: It's not so much that
| serverless is high availability (which is nice), but more than
| they are well... server-less. Meaning maintenance-less for the
| end user. You don't have to manage a whole LAMP stack just to
| transform one object shape into another. If you already have a
| working app setup, yes, you can just add another script into
| your cgi-bin folder. But you can do the same in any JS
| framework's API folder.
|
| 5) Framework bloat
|
| I feel like what this author really doesn't like is heavy
| frameworks. That's fine, they're not for everyone. But in
| either the PHP or JS world, frameworks are optional.
|
| I guarantee you Drupal is heavier and more bloated than any
| popular JS framework (it's also a lot more powerful). Just like
| the PHP world has everything from Drupal to Wordpress to
| Symfony to Laravel, JS has Next, Remix, Astro, Svelte, Vue,
| etc. HTMX has Alpine. Ruby has Rails. Etc.
|
| On the contrary, you can certainly write a few paragraphs of
| HTML as a string and render it in any of those frameworks,
| either as a template literal (PHP heredoc) or using JSX-like
| syntax.
|
| That's not really what the frameworks try to solve. They are
| there for addressing certain business needs. In the case of the
| heaviest framework of them all, Next, it goes back to #3 and
| #4, about optimally separating work between the server, cache,
| and client. If your app is simple enough that you don't need
| that complexity, then either don't use that framework, use its
| older "pages" mode, or use another framework or none at all. If
| you don't need deterministic component rendering based on
| state, don't use React. If you don't need clientside state,
| don't use Javascript at all.
|
| Similarly, you can write a dead-simple PHP page with a few
| server-side includes and heredocs, or maintain a labyrinthine
| enterprise Drupal installation for a few blog posts and
| marketing pages (not recommended... no, really, don't do that
| to yourself... ask me how I know).
|
| In either case, it's again a question of "what do I want or
| need to maintain it". Choosing the right level of power vs
| simplicity, or abstraction vs transparency perhaps, is an
| architectural question about your app and business needs, not
| the language or ecosystem underneath it.
|
| 6) Vendor lock-in
|
| You can host PHP anywhere. You can also host JS anywhere these
| days. In fact I'd argue there are more high-quality,low-cost JS
| hosts now than there ever were similar PHP hosts. Shared PHP
| hosts were a nightmare, because PHP was not easy to
| containerize for shared tenancy. JS hosting is cheap in
| comparison.
|
| Most of the frameworks in either world are open-source. Not
| many are not-for-profit (Drupal is, but Laravel Forge/Forge and
| Vercel/Next have similar business models of open-source
| frameworks coupled with for-profit hosting).
|
| In either case, though, it's really your application logic
| that's valuable (and even then, questionably so, since it'll
| likely end up completely rewritten in a few years anyway).
|
| Ultimately we're all at the mercy of the browser developers.
| Google singlehandedly made shared hosting very difficult for
| everyone with the introduction by forcing HTTPS a few years
| back. It singlehandedly made the heavy JS frontend possible
| with its performant Javascript engine. WASM is still recent.
| WebGPU is on the horizon. New technologies will give rise to
| new practices, and new frameworks will soon feel old.
|
| But JS is here to stay, because it's the only language that can
| natively interact with the DOM clientside. If your core
| business logic is written in almost-vanilla JS (or even JSX, by
| now), portability between JS frameworks isn't as hard as
| porting between different languages (like PHP to JS, or PHP to
| Ruby). Using it for both the client and server and in between
| just means fewer languages to keep track of, a shared typing
| system, etc. In that sense there's probably less vendor lock-in
| with JS than there is with PHP, which fewer and fewer companies
| and hosts support over time. PHP is overwhelmingly just
| Wordpress these days, which itself has moved to more dynamic
| React-based elements too (like in the Gutenberg editor).
|
| I think the problem with the JS ecosystem is actually the
| opposite: not lock-in, but too many choices. Between the start
| and end of this post, probably five new frameworks were
| released =/ It's keeping up that's hard, not portability. You
| can copy and paste most of the same code and modify it slightly
| to make it work in another framework, but there is rarely any
| obvious gain from doing so. For a while there Next seemed like
| it was on track to becoming the standard JS framework, but then
| the app router confused a lot of people and now simpler
| alternatives are popping up again. For that much, at least, I
| can agree with the article: everything old is new again.
| troupo wrote:
| > What vendor lock-in? Most of the code is just vanilla JS.
|
| That runs in a specific environment with vendor-specific IAM
| configurations, vendor-specific DNS configurations, vendor-
| specific network configurations, vendor-specific service
| integrations, vendor-specific runtimes and restrictions,
| vendor-specific...
| solardev wrote:
| That sounds like an AWS thing? There's a lot of frameworks
| that can deploy straight to Vercel, Cloudflare Pages,
| Netlify, etc. without all that.
|
| And if you really want to manage all that, it would apply
| to both PHP sites and JS and anything else. That's really
| more of a discussion of fully vs partially managed cloud
| solutions, not PHP or JS or any framework in particular.
| svth wrote:
| Thank you for that lengthy diatribe, which I heartily agree
| with. It's really all about separation of concerns.
| 101008 wrote:
| I feel identified with the first part of the article. I remember
| the problem about navigations and headers (and right sidebars!).
|
| The first solution was of course framesets, but they were kind of
| ugly. Then iframes came, and they were almost perfect solution
| (at least for me). With no borders, they looked like an include.
| The only problem (and depending of your website) it was that the
| height was fixed (for headers that may not be a problem, but it
| was for left and right sidebars).
|
| Of course, with PHP and includes everything became trivial. I
| kind of miss the old `index.php?cont=page1`...
| jimbokun wrote:
| I sometimes wonder what the hell AWS Lambda is and whether or not
| I should care. Now I have a succint answer:
|
| > What captured people's imaginations about AWS Lambda is that it
| lets you a) give any piece of code an URL, and b) that code
| doesn't consume resources when it's not being used. Yet these are
| also exactly the attributes possessed by PHP or CGI scripts.
|
| From now on, when anyone mentions "AWS Lambda" I'm going to
| replace with "CGI" in my head.
| throwaway22032 wrote:
| Basically everything AWS is things we already have but more
| expensive because someone else does the easiest bit for you.
| tracerbulletx wrote:
| I don't know how anyone who experienced how Ops worked at
| companies before AWS can say things like this. Is AWS right
| for everyone economically? No. It is an impressive automation
| of software operations, that has driven the industry forwards
| by leaps and bounds. Yes.
| jjk166 wrote:
| Some people don't want to create a universe every time they
| want an omelet.
| afavour wrote:
| The author's assertion isn't correct though.
|
| Yes, technically speaking a PHP script that isn't being
| executed isn't _itself_ costing you money. But it's stored on
| server that is running 24 /7 and _is_ costing you money.
|
| Set up in the traditional way, CGI/PHP is priced by server
| uptime, be that per hour, per day, per month, whatever. The
| server runs all the time, it waits for requests, it processes
| them.
|
| By contrast Lambda only costs money _while your code runs_.
| There's a big difference there. Pricing of the two is different
| enough that a Lambda isn't automatically cheaper but it's
| misleading to suggest it's just a CGI /PHP script. And we
| haven't even started on the differences around scaling etc.
| magicalhippo wrote:
| So it's like code-only shared hosting, billed by CPU-time
| rather than wall-time, and with a load balancer in front.
| afavour wrote:
| And it scales to multiple servers to accommodate traffic
| without your input. But essentially, yes.
|
| Not to sound uncharitable but I'm confused by statements
| like the OPs who profess to not understanding what Lambda
| is... it's not actually that complex!
| jimbokun wrote:
| Didn't know enough about it to know whether I should care
| enough about it to investigate more.
| salawat wrote:
| And mind the opportunity cost: You never learn how to set
| such a thing up yourself; and AWS runs off to the bank.
| Where you could have had an asset, (frequently a good
| idea), that you can do something with.
|
| Remember, the innovation of cloud was to add a payment,
| IAM, and config layer on top of basic compute tasks.
| chubot wrote:
| There's nothing stopping anyone from implementing a cloud
| that runs CGI or FastCGI that scales down to zero (with per
| second billing), and scales up to infinity.
|
| It's just that nobody has chosen to do so
|
| Though I suppose not without reason. Google App Engine was
| one of the first "PaaS", billed on a fine-grained level, and
| it WAS initially based on CGI. Later they changed it to in-
| process WSGI, probably because working around CGI startup
| time is difficult / fiddly, and FastCGI has its own flaws and
| complexity.
|
| I think it would have been better if they had developed some
| of the open standards like SCGI and FastCGI though. I think
| it could have made App Engine a more appealing product
|
| _Comments on Scripting, CGI, and FastCGI_ -
| https://www.oilshell.org/blog/2024/06/cgi.html
| fernandopj wrote:
| You have to consider that AWS Lambda does have "cold start"
| - if your code wasn't run for about 10 minutes it isn't
| "hot" anymore and will have a penalty time cost to its
| first next request. This is not billable but it is a
| latency, explained here [1]
|
| [1] https://docs.aws.amazon.com/lambda/latest/operatorguide
| /exec...
| chubot wrote:
| Yes it's exactly like FastCGI ... if you make enough
| requests, then you have a warm process.
|
| If you don't, then you may need to warm one up, and wait.
|
| So yeah I think AWS Lambda and all "serverless" clouds
| should have been based on an open standard.
|
| But TBH FastCGI is not perfect, as I note in my blog
| post.
|
| The real problem is that doing standards is harder than
| not doing them. It's easier to write a proprietary
| system.
|
| And people aren't incentivized to do that work anymore.
| (Or really they never were -- the Internet was funded by
| the US government, and the web came out of CERN ... not
| out of tech companies)
|
| The best we can get is something like a big tightly-
| coupled Docker thing, and then Red Hat re-implements it
| with podman.
| EGreg wrote:
| I think that Cloudflare Workers have been optimized to
| avoid the cold start problem far better than Amazon
| Lambda.
|
| Do you know about them?
| WorldMaker wrote:
| > scales down to zero (with per second billing)
|
| > It's just that nobody has chosen to do so
|
| If we're having fun with "everything old is new again",
| then I do remember some classic hosts for things like
| "Guestbook" perl CGI scripts would charge in those days
| per-"impression" (view/action), it's not quite CPU time but
| a close approximate you'd hope, and the associated costs
| would scale down to zero whether or not their hosting tech
| actually did. (Also, some of them certainly didn't scale to
| "infinity", though they tried.)
| gumby wrote:
| > By contrast Lambda only costs money while your code runs.
|
| There is no fee for uploading it, only a fee for executing?
| In that case could I upload a function that only disgorges a
| static payload? Then I could store a multi-GB file for free
| and just invoke it in order to download the data.
| icedchai wrote:
| You still get charged for data / bandwidth egress, of
| course. Either way, that multi-gig response wouldn't work.
| You'd discover lambda can only generate a 6 megabyte
| response!
|
| Lambda has all sorts of weird limitations: https://repost.a
| ws/questions/QUjXEef9ezTTKpWqKRGk7FSg/limita...
| tshaddox wrote:
| I believe there is no usage fee for uploading functions,
| but there's a size limit per function and an account-wide
| total storage quota on uploaded functions.
|
| https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted
| -...
| untech wrote:
| I understand the sentiment, but to be fair, CGI doesn't give
| you an infinite scalability. AWS Labmda based solution is far
| less susceptible to something like HN hug-of-death.
| loloquwowndueo wrote:
| But it's entirely susceptible to your wallet being hugged to
| death if someone decides to ddos you.
| afavour wrote:
| That's a trade off many businesses are very happy to make!
| Spike in traffic = spike in sales. For an actual DDOS
| there's always WAF firewalling.
|
| I have to admit I don't get the lambda hate. You don't have
| to use them but there is a valid use case for them.
| coryrc wrote:
| Instead your wallet gets ddos'd.
| chubot wrote:
| CGI can definitely scale infinitely!! It's stateless.
|
| PHP can scale to all of Facebook's front ends, and so can
| CGI. Because they are stateless.
|
| Same with FastCGI. FastCGI just lets you reuse the process,
| so you don't have the "cold start" every time
|
| _> CGI had the original "cold start problem"_
|
| It's just that nobody has implemented a cloud that uses the
| CGI or FastCGI interfaces.
|
| I quoted this same article in a blog post yesterday:
|
| _Comments on Scripting, CGI, and FastCGI_ -
| https://www.oilshell.org/blog/2024/06/cgi.html
| afavour wrote:
| This maybe gets to the core of why the author's assertion
| is incorrect: they're comparing a programming language to
| an execution environment.
|
| Yeah, PHP can scale infinitely... if you provide it with
| the necessary server resources to do so. PHP is not going
| to scale infinitely on a Raspberry Pi.
|
| This dynamically scaling server resource _is Lambda_. Hell,
| you can even run PHP on Lambda these days the comparison
| really doesn't work.
| liveoneggs wrote:
| We often hit lambda max quotas and scaling limits:
|
| https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-.
| ..
|
| https://docs.aws.amazon.com/lambda/latest/dg/lambda-
| concurre...
| troupo wrote:
| > but to be fair, CGI doesn't give you an infinite
| scalability.
|
| That your startup with three users will never need.
|
| Your startup with a million users will not need it either
| hooverd wrote:
| Lambda doesn't either. Unless you ask AWS support nicely.
| pram wrote:
| Lambda has its places, but I've noticed devs consistently using
| it for things where it doesn't make any goddamn sense. Like
| processing messages from a Kafka consumer, the function is
| running 24/7. People think it's a container or something.
| Sharlin wrote:
| News at eleven: devs use tech for utterly inappropriate
| purposes just because it happens to be cool at the moment.
| morkalork wrote:
| I can definitely see lambdas being abused when the process
| for requesting dedicated resources is too arduous.
| jbmchuck wrote:
| https://docs.aws.amazon.com/prescriptive-
| guidance/latest/pat...
| liveoneggs wrote:
| yes where I work there is an alert for when a lambda is not
| running. I have proposed wrapping the lambda code in a
| while() loop on a fargate many many times to save $thousands
| of dollars but I lack the political power to actually do it.
| derefr wrote:
| Lambda is also _distributed_ , though -- while CGI scripts just
| live on the webserver itself. So if you're old like me and want
| a crisper mental model, the actual '90s equivalent of Lambda
| would be:
|
| * a cluster of "diskless" web-server (let's say Apache)
| machines with a round-robin load-balancer in front of them;
|
| * where these web servers are all using mod_userdir, pointing
| /~*/ at, let's say, "/wwwhome/*/www/" -- and with `Options
| +ExecCGI` enabled for all UserDirs;
|
| * where /wwwhome on all these web-server machines is a read-
| only NFS mount from the /home dir of a shared disk server;
|
| * and where each user of this service has an FTP-enabled user
| and home directory on the disk server.
|
| Given this setup, if a user bob FTPs a script to
| /home/bob/www/foo.pl on the disk server, then anyone can
| trigger that script to execute on some arbitrary web-server in
| the cluster by hitting http://lb.oldschool-
| lambda.example.com/~bob/foo.pl.
|
| (I'm actually curious whether this exact architecture was ever
| implemented in the 1990s in practice, maybe by a university or
| ISP. It seems totally feasible.)
|
| ---
|
| One other major difference I should point out, is that Lambda
| functions are _versioned_ -- you don 't overwrite a function,
| you just deploy a new content-hash-named copy of it and then
| update some "symbolic names" to point at it, but can always
| call a fixed version by its content-hash.
|
| Implementing enforced versioning wouldn't require any changes
| to the above architecture, though, so it doesn't matter here.
| (It'd "just" be a fork of ftpd that would transparently map
| between a versioned backend view and an unversioned frontend
| view. Very much like what Amazon S3 does for versioned buckets,
| actually.)
| troupo wrote:
| > Lambda is also distributed, though -- while CGI scripts
| just live on the webserver itself.
|
| Most of the stuff people use lambdas for they could run from
| the cheapest Digital Ocean droplet or cheapest Hetzner
| server.
|
| You need "omg distributed" _perhaps_ after your millionth
| user, and even then it 's highly debatable.
| derefr wrote:
| You're thinking about the (rather few) advantages
| distribution confers for single-tenant scaling. But the
| distribution here is mainly for other reasons:
|
| * _operational_ fault-tolerance: arbitrary servers in the
| cluster hosting the function can fail or be taken down for
| repair without any workloads going down. This allows the
| ops team that owns the cluster to freely keep the cluster
| 's machines up to date with OS package updates, reboot them
| as needed, swap them out for newer-generation hardware,
| move them to new racks in new DC buildings, etc. (This is
| also something you get from a VM on most larger clouds --
| but only because the VM itself is a workload running on a
| hypervisor cluster, where the cluster's control-plane can
| live-migrate workloads to drain host nodes for
| maintenance.)
|
| * horizontally scaling the cluster as a whole, to keep up
| with more and more users sticking more and more workloads
| onto it, and more and more requests coming in for those
| workloads. As load increases, just add more diskless web
| servers. (This also means that in the rare case where your
| workload _is_ too popular to fit on a cheap VPS, the ops
| team is doing your personal infrastructure scale-out for
| you for free, as part of scaling the capacity of the
| service as a whole.)
|
| * maintaining _your_ multi-tenant Quality-of-Service in the
| face of _other_ users who have hugely-expensive workloads.
| On that 90s cgi-bin webserver -- or on a modern VPS -- if
| someone else deploys some workload that pins all the CPU
| cores for five seconds each time anyone calls it, then that
| impacts how long it takes _you_ to serve calls to _your_
| workload, because your request has landed on the same
| machine and is waiting in some kernel queue behind that
| other workload 's CPU bottleneck. VMs solve this by
| reserving capacity per workload that's "always on" even
| when the workload is idle. Lambda solves this by collecting
| resource-accounting statistics for each function and
| resource-utilization metrics for each backend, and putting
| that info together at the load-balancer level to plan a
| hybrid of least-conn and resource-packing routing to
| backend nodes.
|
| ---
|
| But even ignoring all that, the point of the "distributed-
| ness" of the Lambda architecture _on the low-usage end_ ,
| is the "scales to zero" part that it shares with CGI.
|
| Unlike VMs, you aren't paying anything per month for a
| function nobody is calling. And for a workload that does
| get called, but only runs for N aggregate CPU-seconds each
| minute, you're only paying N/60 of what you'd pay for a VM
| (which runs every CPU-second of the every minute.)
|
| If you have _one_ script _and_ you have $5 /mo burning a
| hole in your pocket, then sure, I guess you _could_ put it
| on a DO droplet? (But you could just as well deploy a
| function that will cost you _less_ than $5 /mo.)
|
| But if you have _ten_ scripts, where some of them might be
| high-utilization (you 're not sure yet, depends on how many
| people hit the web pages that call them) while others are
| definitely extremely low-utilization -- then your options
| are either "becoming a hobbyist DevOps engineer,
| utilization planning a packing arrangement of VMs or
| hardware to optimize cost, installing metrics to ensure
| things aren't falling over, getting emails when it does,
| re-planning things out, and migrating them as necessary"...
| or just deploying 10 functions and getting what will
| probably be a bill each month for <$1.
| troupo wrote:
| You write a long wall of text that does boring to dispute
| what I wrote.
|
| The cheapest DO droplet is 4 dollars a month. It is more
| than capable of running "10 scripts", and will last your
| startup with three users indefinitely long.
|
| If you're concerned about _that_ cost, lambdas will not
| save you
| derefr wrote:
| Maybe we write very different kinds of scripts. For my
| startup, such a "script" might be:
|
| 1. An hourly itemized invoicing batch job for incremental
| usage-based billing, that pulls billable users from an
| ERP DB, grabs their usage with a complex Snowflake query
| (= where our structured access logs get piped), then does
| a CQRS reduction over the credit-and-spend state from
| each user's existing invoice line-items for the month, to
| turn the discovered usage into new line-items to insert
| back into the same ERP DB.
|
| 2. A Twilio customer-service IVR webhook backend, that
| uses local speech-processing models to recognize keywords
| so you don't have to punch numbers.
|
| 3. An image/SVG/video thumbnailer that gets called when a
| new source asset (from a web-scraping agent) is dropped
| into one bucket; and which writes the thumbnail for said
| asset out into another bucket. (For the SVG use-case
| especially, this requires spinning up an entire headless
| Chrome context per image, mostly in order to get the
| fonts looking right. We actually handle that part of the
| pipeline with serverless containers, not serverless
| functions, because it needs a custom runtime
| environment.)
|
| #1 is an example of a low-utilization "script" where we
| just don't want to pay for the infra required to run it
| when it's not running, since when it _is_ running it
| "wants" better-than-cheapest resourcing to finish in a
| reasonable time (which, if you were deploying it to a VM,
| would mean paying for a more expensive VM, to sit mostly
| idle.) We do have a k8s cluster -- and this was
| originally a CronJob resource on that, which made sense
| at first -- but this is an example of a "grows over time"
| workload, and we're trying to avoid using k8s for those
| sort of workloads, because k8s expects workloads to have
| fixed resource quotas per pod, and can't cope well with
| growing workloads without a lot of node-pool finessing.
|
| #2 and #3 are high-utilization (one in CPU and RAM, one
| in requiring a GPU with VRAM) "scripts", where only one
| or two concurrent executions of these would fit on a
| $4/mo DO droplet; and where ten or twenty of these on a
| more vertically-scaled VM or machine would start to
| strain the network throughput of even a 2.5Gbps link.
| Many cheap-ish machines, each with their resourcing
| (including their own network bandwidth), all
| instantaneously reserved and released at one machine per
| request is a perfect match for the demand profile of
| these use-cases.
| MOARDONGZPLZ wrote:
| I'm guilty of this sort of "kids these days" thinking as
| well. But really the AWS lambda free tier is very generous
| and I don't get any sort of bill unless there's a very
| large spike in usage. With DO or Hetzner I pay for the
| server to be up and get a monthly bill no matter what.
|
| I would even somewhat reverse your assertion: use Lambda
| until you have a need for a real server infra and then
| upgrade to things like Hetzner.
| EGreg wrote:
| Lambda is like CloudFlare workers.
|
| They are deployed AT THE EDGE TO THE CDN, and therefore can
| handle requests without hitting your network and database.
|
| For example I recommend your servers sign all the session IDs
| they give out, so they can easily be discarded if the signature
| doesn't match or if they've been blacklisted. Such decisions
| can be made without doing any I/O, or by checking a local cache
| that was built up when eg a blacklisted session ID was tried
| just recently.
|
| They can also spin up huge numbers of instances and fan out
| requests to MANY different servers, not just yours and your
| domain names. They allow client-first development, where you
| might not build ANY back end at all, just use some sort of JAM
| stack.
|
| And now, CloudFlare Workers supports a key-value store and a
| SQL database so it is sort of an environment that will
| autoscale all your deployments in CDNs around the world and
| take care of the eventual consistency too.
| troupo wrote:
| > where you might not build ANY back end at all, just use
| some sort of JAM stack.
|
| So, a backend
|
| > And now, CloudFlare Workers supports a key-value store and
| a SQL database
|
| So, a backend.
| EGreg wrote:
| A back end with autoscaling on CDN.
|
| Not a single server, like you'd set up.
| amluto wrote:
| I think the real ability that got lost is the ability to easily
| mix and match multiple logically separate things. Once upon a
| time, if you have some slightly dynamic material and you also
| wanted to add some PDFs from the technical writers, the webmaster
| would do it in five minutes. Want a video? Just add a file. Need
| a form? Fire up some PHP or whatever. Want a support contact or
| FAQ? No big deal.
|
| Now even big companies outsource their PDF hosting and viewing to
| a third party, they outsource their FAQ and support contact to a
| different fancy startup, surveys and similar forms to to yet
| another company, and the list goes on. The all-in-one website
| seems to be dead.
| foundart wrote:
| +1 for the article's link to the "CADT Model"
| https://www.jwz.org/doc/cadt.html
| ss64 wrote:
| This is missing any discussion of the dynamic functionality you
| can add with a bit of vanilla JavaScript.
| PKop wrote:
| No it isn't. Did you read the article?
| jak2k wrote:
| I like the idea of just renaming an `html` file to `php` and
| adding a bit dynamic stuff.
|
| A webserver that could do this with JavaScript/TypeScript would
| be cool! (Or maybe I should learn php...)
| leobg wrote:
| Yeah, I was shocked when, coming from PHP, I realized that in
| Python, in order to serve a website, you have to start and
| maintain an extra server process.
| leobg wrote:
| Makes me think of Pieter Levels who used to run a 60k/mo SaaS
| with hundreds of paying users from a single index.php on a bare
| metal server.
|
| (I don't know if he still does it that way.)
| syrusakbary wrote:
| I'm amazed on how well this article fits with a new product that
| we have been working on at Wasmer. AWS Lambda is great, but it
| doesn't really solve the cold start problem of dynamic languages.
| Nor does FastCGI.
|
| We are very close to launch Instaboot, a new feature for Wasmer
| Edge that thanks to WebAssembly is able to bring incredible fast
| cold-starts to dynamic languages. Bringing 90ms cold-start times
| to WordPress (compared to >1s in state-of-the-art cloud
| providers).
| kolme wrote:
| Fun fact: nextjs was inspired by PHP and can generate static
| pages that you can throw into a web server.
|
| Another technology that kind of covers the use cases of the
| article (the mildly dynamic pages) would be htmx and friends.
| 1vuio0pswjnm7 wrote:
| "Or, suppose a company makes a webpage for looking up products by
| their model number. If this page were made in 2005, it would
| probably be a single PHP page. It doesn't need a framework - it's
| one SELECT query, that's it. If this page were made in 2022, a
| conundrum will be faced: the company probably chose to use a
| statically generated website. The total number of products isn't
| too large, so instead their developers stuff a gigantic JSON file
| of model numbers for every product made by the company on the
| website and add some client-side JavaScript to download and query
| it.... This example is fictitious but I believe it to be
| representative."
|
| As an end user, I have seen this perplexing design pattern quite
| often. As soon as I see it, I just get the URL for the JSON file
| and I never look at the web page again. It is like there is so
| much bandwidth, memory and CPU available but the developer is not
| letting the user takes advantage of it. Instead the developer is
| usurping it for themselves. Maybe a user wants to download data.
| But the developer wants to run Javascript and keep _all_ users
| staring at a web page.
|
| Why not just provide a hyperlink on the rendered search results
| page pointing to the JSON file, as an alternative to (not a
| replacement for) running Javascript. What are the reasons for not
| provding it.
|
| On some US government websites, for example, a hyperlink for the
| the CSV/JSON file is provided in the rendered search results
| page.^1
|
| That is why a non-commercial www is so useful, IMHO: the best
| non-commercial websites do not try to "hide the ball".
|
| Perhaps they have no incentive to try to force users to enable
| Javascript, which is a practical prerequisite for advertising and
| tracking.
|
| 1. ecfr.gov and federalregister.gov are two examples
| spacebuffer wrote:
| Semi-related: what's the best place to learn the old school style
| of working with php, I already know laravel but it feels so far
| removed from normal php that I am not confident working with it
| on it's own.
| hu3 wrote:
| I would try some "old style" php frameworks. Like CodeIgniter
| or Yii.
|
| If you want even simpler, then maybe try Slim framework. You'll
| have to add your own data access lib.
|
| If you want Grug brain PHP then there's
| https://github.com/bcosca/fatfree
|
| You can also use composer package manager to build your
| framework with libs like routing, sql query builder, etc.
| wild_egg wrote:
| > Fast and clean template engine
|
| Is PHP not already a template language?
|
| The whole idea of PHP frameworks always confused me. Why do I
| need a router when I can simply add new files at the routes I
| want?
| lovasoa wrote:
| This article resonates with me. I do love "mildly dynamic
| websites", and have fond memories of my days hacking together PHP
| websites 15 years ago.
|
| And what I am working on today might be called a bridge for the
| "dynamicity gap". I'm making an open source server to write web
| apps entirely in SQL ( https://sql.ophir.dev/ ). It has the "one
| file per page" logic of PHP, and makes it easy to add bits of
| dynamic behavior with just a normal INSERT statement and a SELECT
| over dynamic data.
___________________________________________________________________
(page generated 2024-06-19 23:00 UTC)