Twitter recently recommended a tweet to me (all hail the algorithm) touting what the author viewed as the top 5 web development stacks.”

JavaScript/​Node.js options dominated the four-​letter acronyms as expected, but the fifth one surprised me: LAMP, the combination of the Linux operating system, Apache web server, MySQL relational database, and Perl, PHP, or Python programming languages. A quick web search for similar lists yielded similar results. Clearly, this meme (in the Dawkins sense) has outlasted its popularization by tech publisher O’Reilly in the 2000s.

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:

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.

Note how the various four-​letter JavaScript stacks (e.g., MERN, MEVN, MEAN, PERN) differentiate themselves mostly by frontend framework (e.g., Angular, React, Vue.js) and maybe by the (relational or NoSQL) database (e.g., MongoDB, MySQL, PostgreSQL). All however seem standardized on the Node.js runtime and Express backend web framework, which could, in theory, be replaced with non-​JavaScript options like the more mature LAMP-​associated languages and frameworks. (Or if you prefer languages that don’t start with P”, there’s C#, Go, Java, Ruby, etc.)

My point is that LAMP” as the name of a web development stack has outlived its usefulness. It’s at once too specific (about operating system and web server details that are often abstracted away for developers) and too broad (covering three separate programming languages and not the frameworks they favor). It also leaves out other non-​JavaScript back-​end languages and their associated frameworks.

The question is: what can replace it? I’d propose NoJS” as reminiscent of NoSQL,” but that inaccurately excludes JavaScript from its necessary role in the front-​end. NJSB” doesn’t exactly roll off the tongue, either, and still has the same ambiguity problem as LAMP.”

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
  • etc.

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.

12 thoughts on “LAMP is dead! Long live (Perl) web frameworks!

  1. Ah the conundrum of changing technologies! Given the correct skill set anyone can write just about anything using any set of technologies. Question is does the end result meet the business objectives. I go back to Roller Coaster Tycoon 1: http://www.chrissawyergames.com/faq3.htm. Yeah it was a success and well done.

  2. I don’t entirely agree. I recently used Mojolicious for a project and it sits behind an nginx reverse proxy. My implementation might be a little weird but it works surprisingly well with nginx server side includes. Most of the web applications that I run are served via an nginx reverse proxy. As you already mentioned, PHP is still tightly coupled with traditional web server software so that remains yet another reason for me to use this stack.

    The acronym has possibly outlived its usefulness when taken literally. OpenBSD, nginx, and PostgreSQL have replaced Linux, Apache, and MySQL on my end but the concept is still fundamentally the same.

  3. My current $WORK project would be classified as M‑P: MySQL, Perl. No web frame work. We had one in the beginning, cut it out, saw the 50% drop in response time, and never looked back. It also uses Linux and ngix, but replacing them with something else would be easy. (And so would be replacing MySQL with another relational database, almost all my SQL confirms to the standard).

    But $WORK would not mind rewriting it in Java (but I do).

  4. Ahhh, the Perl fashion industry is alive and well! Yes, pay attention — you need to forget about that Perl LAMP application that has 50,000+ hours of development time that you have been running over 19 years and executes flawlessly while making lots of money at the same time for your company! It’s time to throw it all away and rewrite everything because yet-​another-​person™ in the Perl community thinks that you are out of step with the times”. Puleeeze don’t tell me you are still using CGI, Mod Perl, and LAMP! That’s the Perl hall of shame!!! Only a [insert appropriate demeaning noun] would use those ancient tools to support applications.

    Early on (mid-​90s to early 00s), the Perl community ran on TMTOWTDI (there is more than one way to do it). We supported each other and worked to improve things. Sure, new things came out, but we never declared legacy code as inadequate or insufficient because some new module could accomplish the same thing. But we got rid of that community cohesion a long time ago and replaced it with TINWTDI (there is no way to do it) because we realized that everyone that does not agree with us is an idiot and can’t possibly understand how important [insert new feature] is.

    So throw it all way and rewrite it again, and soon you too can strut down the Perl fashion runway and reveal the glory of all your pretty feathers! Besides, who the hell wants to enhance features in a working application to make more money when you can refactor your code to support the latest what-​ever-​it-​is over and over and over again?

    IMO, if we spent half of much time fixing the legacy code that made Perl great in the first place, rather than inventing yet another object system, creating yet-​another magical framework, or removing yet-​another feature used in the code base by thousands of legacy apps, we probably would not be on this accelerated path to irrelevance and potential demise. But then again, I have never been much of a fashionista. Besides, I prefer works well, well written, and maintainable” to shiny new thing, you’re an idiot if you jump on this new thing” any day.

    I’m glad the C programming community does not have the same propensity to constantly throw the old away and replace it with yet-​another new thing like the Perl community does. I’ll crawl back under my rock now …

    • How about when the Business wants yet another new feature on the CGI which has been slowly accumulating features over the last 19 years? Don’t break it because the business depends on it to keep making lots of money! Can you even unit test it?

      Sure, you’ll never get rid of it because it embeds too much business logic to untangle, but even the resident masochist wouldn’t write anything new in CGI.

  5. I can’t believe you left out the JERK stack! (Javascript, Express, React and Kubernetes (of course)) lol

  6. 20 years ago I started building a business solution (CRM+ERP) in Perl (LAMP stack) on CentOS. I’ve been maintaining this system in isolation, without much learning or any guidance, mostly repeating simple coding basics a thousand times, using a linux terminal and vim 🙂 Today it looks like this:
    60 library files (.pl), 175,000 lines of code, 1576 functions (subs), 374 global variables(!!).
    I also don’t use any frameworks, because the system has it’s own internal framework for rapid development and UI.

    As mentioned above, how do you remodel such a complex, live system? I’ve been hoping to modernise it, but its so delicate to change business logic and a framework that evolved over 20 years.

    Lately I’ve been focussing on building tools to help improve the quality of the code. Eg. before you apply a patch, the changes gets analysed and potential issues highlighted. I’m also restructuring the code and adding better error/​exception reporting. Beyond that it’s an adventure. It’s daunting to even imagine migrating to a new model or language (also — I love Perl :). I’ll continue to try improve the bad and add the good, but its a journey. I’ve have to grow and learn — challenging stuff.

    I hope Perl will be around for many years to come.

    • Oh, it will be around. As far as your issue is concerned, check out a book on dealing with legacy code like Peter J. Scott’s Perl Medic, which although dated, contains good suggestions on adding tests and gradually restructuring. You don’t have to use a framework, and there are CPAN modules that will help you, e.g., adapting CGI scripts to PSGI applications.

Comments are closed.

    Mentions

  • 💬 Dr. Elden Wayne Whalen III, ShD