Posted on
by
clear light bulb planter on gray rock
Photo by Singkham on Pexels.com

Twitter recent­ly rec­om­mend­ed a tweet to me (all hail the algo­rithm) tout­ing what the author viewed as the ​“top 5 web devel­op­ment stacks.”

JavaScript/​Node.js options dom­i­nat­ed the four-​letter acronyms as expect­ed, but the fifth one sur­prised me: LAMP, the com­bi­na­tion of the Linux oper­at­ing sys­tem, Apache web serv­er, MySQL rela­tion­al data­base, and Perl, PHP, or Python pro­gram­ming lan­guages. A quick web search for sim­i­lar lists yield­ed sim­i­lar results. Clearly, this meme (in the Dawkins sense) has out­last­ed its pop­u­lar­iza­tion by tech pub­lish­er O’Reilly in the 2000s.

Originally coined in 1998 dur­ing the ​“dot-​com” bub­ble, I had thought that the term ​“LAMP” had fad­ed with devel­op­ers in the inter­ven­ing decades with the rise of language-​specific web frame­works for:

Certainly on the Perl side (with which I’m most famil­iar), the com­mu­ni­ty has long since rec­om­mend­ed the use of a frame­work built on the PSGI spec­i­fi­ca­tion, dep­re­cat­ing 1990s-​era CGI scripts and the mod_​perl Apache exten­sion. Although general-​purpose web servers like Apache or Nginx may be part of an over­all sys­tem, they’re typ­i­cal­ly used as prox­ies or load bal­ancers for Perl-​specific servers either pro­vid­ed by the frame­work or a third-​party mod­ule.

Granted, PHP still relies on web server-​specific mod­ules, APIs, or vari­a­tions of the FastCGI pro­to­col for inter­fac­ing with a web serv­er. And Python web appli­ca­tions typ­i­cal­ly make use of its WSGI pro­to­col either as a web serv­er exten­sion or, like the Perl exam­ples above, as a prox­ied stand­alone serv­er. But all of these are deploy­ment details and do lit­tle to describe how devel­op­ers imple­ment and extend a web application’s structure.

Note how the var­i­ous four-​letter JavaScript stacks (e.g., MERN, MEVN, MEAN, PERN) dif­fer­en­ti­ate them­selves most­ly by fron­tend frame­work (e.g., Angular, React, Vue.js) and maybe by the (rela­tion­al or NoSQL) data­base (e.g., MongoDB, MySQL, PostgreSQL). All how­ev­er seem stan­dard­ized on the Node.js run­time and Express back­end web frame­work, which could, in the­o­ry, be replaced with non-​JavaScript options like the more mature LAMP-​associated lan­guages and frame­works. (Or if you pre­fer lan­guages that don’t start with ​“P”, there’s C#, Go, Java, Ruby, etc.)

My point is that ​“LAMP” as the name of a web devel­op­ment stack has out­lived its use­ful­ness. It’s at once too spe­cif­ic (about oper­at­ing sys­tem and web serv­er details that are often abstract­ed away for devel­op­ers) and too broad (cov­er­ing three sep­a­rate pro­gram­ming lan­guages and not the frame­works they favor). It also leaves out oth­er non-​JavaScript back-​end lan­guages and their asso­ci­at­ed frameworks.

The ques­tion is: what can replace it? I’d pro­pose ​“NoJS” as rem­i­nis­cent of ​“NoSQL,” but that inac­cu­rate­ly excludes JavaScript from its nec­es­sary role in the front-​end. ​“NJSB” doesn’t exact­ly roll off the tongue, either, and still has the same ambi­gu­i­ty prob­lem as ​“LAMP.”

How about pithy sort-​of-​acronyms pat­terned 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 com­mu­ni­ty and indus­try adop­tion. If you’re involved with back-​end web devel­op­ment, please let me know in the com­ments if you agree or dis­agree that ​“LAMP” is still a use­ful term, and if not, what should replace it.

    Mentions

  • 💬 Dr. Elden Wayne Whalen III, ShD

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

  1. Ah the conun­drum of chang­ing tech­nolo­gies! Given the cor­rect skill set any­one can write just about any­thing using any set of tech­nolo­gies. Question is does the end result meet the busi­ness objec­tives. I go back to Roller Coaster Tycoon 1: http://www.chrissawyergames.com/faq3.htm. Yeah it was a suc­cess and well done.

  3. I don’t entire­ly agree. I recent­ly used Mojolicious for a project and it sits behind an nginx reverse proxy. My imple­men­ta­tion might be a lit­tle weird but it works sur­pris­ing­ly well with nginx serv­er side includes. Most of the web appli­ca­tions that I run are served via an nginx reverse proxy. As you already men­tioned, PHP is still tight­ly cou­pled with tra­di­tion­al web serv­er soft­ware so that remains yet anoth­er rea­son for me to use this stack.

    The acronym has pos­si­bly out­lived its use­ful­ness when tak­en lit­er­al­ly. OpenBSD, nginx, and PostgreSQL have replaced Linux, Apache, and MySQL on my end but the con­cept is still fun­da­men­tal­ly the same.

  5. My cur­rent $WORK project would be clas­si­fied as M‑P: MySQL, Perl. No web frame work. We had one in the begin­ning, cut it out, saw the 50% drop in response time, and nev­er looked back. It also uses Linux and ngix, but replac­ing them with some­thing else would be easy. (And so would be replac­ing MySQL with anoth­er rela­tion­al data­base, almost all my SQL con­firms to the standard).

    But $WORK would not mind rewrit­ing it in Java (but I do).

  6. Ahhh, the Perl fash­ion indus­try is alive and well! Yes, pay atten­tion — you need to for­get about that Perl LAMP appli­ca­tion that has 50,000+ hours of devel­op­ment time that you have been run­ning over 19 years and exe­cutes flaw­less­ly while mak­ing lots of mon­ey at the same time for your com­pa­ny! It’s time to throw it all away and rewrite every­thing because yet-​another-​person™ in the Perl com­mu­ni­ty 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 appro­pri­ate demean­ing noun] would use those ancient tools to sup­port applications.

    Early on (mid-​90s to ear­ly 00s), the Perl com­mu­ni­ty ran on TMTOWTDI (there is more than one way to do it). We sup­port­ed each oth­er and worked to improve things. Sure, new things came out, but we nev­er declared lega­cy code as inad­e­quate or insuf­fi­cient because some new mod­ule could accom­plish the same thing. But we got rid of that com­mu­ni­ty cohe­sion a long time ago and replaced it with TINWTDI (there is no way to do it) because we real­ized that every­one that does not agree with us is an idiot and can’t pos­si­bly under­stand how impor­tant [insert new fea­ture] is.

    So throw it all way and rewrite it again, and soon you too can strut down the Perl fash­ion run­way and reveal the glo­ry of all your pret­ty feath­ers! Besides, who the hell wants to enhance fea­tures in a work­ing appli­ca­tion to make more mon­ey when you can refac­tor your code to sup­port the lat­est what-​ever-​it-​is over and over and over again?

    IMO, if we spent half of much time fix­ing the lega­cy code that made Perl great in the first place, rather than invent­ing yet anoth­er object sys­tem, cre­at­ing yet-​another mag­i­cal frame­work, or remov­ing yet-​another fea­ture used in the code base by thou­sands of lega­cy apps, we prob­a­bly would not be on this accel­er­at­ed path to irrel­e­vance and poten­tial demise. But then again, I have nev­er been much of a fash­ion­ista. Besides, I pre­fer ​“works well, well writ­ten, and main­tain­able” to ​“shiny new thing, you’re an idiot if you jump on this new thing” any day.

    I’m glad the C pro­gram­ming com­mu­ni­ty does not have the same propen­si­ty to con­stant­ly throw the old away and replace it with yet-​another new thing like the Perl com­mu­ni­ty does. I’ll crawl back under my rock now …

    • How about when the Business wants yet anoth­er new fea­ture on the CGI which has been slow­ly accu­mu­lat­ing fea­tures over the last 19 years? Don’t break it because the busi­ness depends on it to keep mak­ing lots of mon­ey! Can you even unit test it?

      Sure, you’ll nev­er get rid of it because it embeds too much busi­ness log­ic to untan­gle, but even the res­i­dent masochist would­n’t write any­thing new in CGI.

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

  8. 20 years ago I start­ed build­ing a busi­ness solu­tion (CRM+ERP) in Perl (LAMP stack) on CentOS. I’ve been main­tain­ing this sys­tem in iso­la­tion, with­out much learn­ing or any guid­ance, most­ly repeat­ing sim­ple cod­ing basics a thou­sand times, using a lin­ux ter­mi­nal and vim 🙂 Today it looks like this:
    60 library files (.pl), 175,000 lines of code, 1576 func­tions (subs), 374 glob­al variables(!!).
    I also don’t use any frame­works, because the sys­tem has it’s own inter­nal frame­work for rapid devel­op­ment and UI.

    As men­tioned above, how do you remod­el such a com­plex, live sys­tem? I’ve been hop­ing to mod­ernise it, but its so del­i­cate to change busi­ness log­ic and a frame­work that evolved over 20 years.

    Lately I’ve been focussing on build­ing tools to help improve the qual­i­ty of the code. Eg. before you apply a patch, the changes gets analysed and poten­tial issues high­light­ed. I’m also restruc­tur­ing the code and adding bet­ter error/​exception report­ing. Beyond that it’s an adven­ture. It’s daunt­ing to even imag­ine migrat­ing to a new mod­el or lan­guage (also — I love Perl :). I’ll con­tin­ue to try improve the bad and add the good, but its a jour­ney. I’ve have to grow and learn — chal­leng­ing stuff.

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

    • Oh, it will be around. As far as your issue is con­cerned, check out a book on deal­ing with lega­cy code like Peter J. Scott’s Perl Medic, which although dat­ed, con­tains good sug­ges­tions on adding tests and grad­u­al­ly restruc­tur­ing. You don’t have to use a frame­work, and there are CPAN mod­ules that will help you, e.g., adapt­ing CGI scripts to PSGI applications.

Comments are closed.