Twitter recently recommended a tweet to me (all hail the algorithm) touting what the author viewed as the “top 5 web development stacks.”
Originally coined in 1998 during the “dot-com” bubble, I had thought that the term “LAMP” had faded with developers in the intervening decades with the rise of language-specific web frameworks for:
- Perl (e.g., Catalyst, Dancer, Mojolicious),
- PHP (e.g., Laravel, Symfony, Zend/Laminas),
- and Python (e.g., Django, Flask, web2py).
Certainly on the Perl side (with which I’m most familiar), the community has long since recommended the use of a framework built on the PSGI specification, deprecating 1990s-era CGI scripts and the mod_perl Apache extension. Although general-purpose web servers like Apache or Nginx may be part of an overall system, they’re typically used as proxies or load balancers for Perl-specific servers either provided by the framework or a third-party module.
Granted, PHP still relies on web server-specific modules, APIs, or variations of the FastCGI protocol for interfacing with a web server. And Python web applications typically make use of its WSGI protocol either as a web server extension or, like the Perl examples above, as a proxied standalone server. But all of these are deployment details and do little to describe how developers implement and extend a web application’s structure.
How about pithy sort-of-acronyms patterned like database-frontend-backend? Here are some Perl examples:
- MRDancer: MySQL, React, and Dancer (I use this at work. Yes, the M could also stand for MongoDB. Naming things is hard.)
- MRMojo: MongoDB, React, and Mojolicious
- PACat: PostgreSQL, Angular, and Catalyst
Ultimately it comes down to community and industry adoption. If you’re involved with back-end web development, please let me know in the comments if you agree or disagree that “LAMP” is still a useful term, and if not, what should replace it.