movabletype
mojo
movabletype | mojo | |
---|---|---|
2 | 51 | |
400 | 2,654 | |
0.0% | 0.4% | |
9.9 | 7.9 | |
6 days ago | 26 days ago | |
Perl | Perl | |
- | Artistic License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
movabletype
-
Reminiscing CGI Scripts
Oh, weird. I was around before CGI scripts became commonplace on the web, and worked on a handful of projects in that space -- mostly in Perl, but also a bit in ColdFusion (shudder). I think there are some inaccuracies here, but didn't expect to read about someone exploring "old" CGI script technology today.
> CGI scripts mostly went out of fashion because of their limitations around performance.
Nah, performance was fine. It's mostly always been the case that the code running on the server isn't the bottleneck.
CGI scripts went out of fashion for several reasons that fall into the categories "too complex to maintain" or "there's this new thing called PHP...".
CGI scripts were often written in Perl, but also sometimes good ol' C, and occasionally some other oddball thing. But, Perl ruled the CGI script space. Over time, CGI scripts became more complex, as software often does. When people wanted something more than a simple mail-form, or a page visit counter, or a guestbook (remember those?), they'd often be faced with downloading, installing, and then maintaining a complex Perl application, which was a nightmare. Wanna see what a big Perl application looks like? Check out https://github.com/movabletype/movabletype.
Perl just didn't lend itself to well-structured code. I say this as someone who really liked Perl, TMTOWTDI and all that, and resisted moving away from it for years. But really, once your CGI script started spanning multiple .pl files, you were gonna have a bad time.
The other thing we didn't have was good templating. Handlebars and the like now just didn't really exist then. There were all kinds of ways to sort of gin up a templating system, but there were no standards and everything was homebrewed. This was really icky if you wanted to do something like make a site with a web editor -- forget all the wysiwyg stuff, just rendering the html in a clean and safe way and spitting it back out was a bit of a faff.
Along came PHP. It had a few advantages right out of the gate: (a) you could inline it in html, and I really can't overstate just how amazing that was at the time -- suddenly you didn't need templates anymore, you just used the html you already had; (b) it came with a good enough standard library of calls that were mostly comprehensible; and (c) contrary to Perl, which Perl hackers readily referred to as "line noise", PHP's syntax was pretty clean. (Younger developers may scoff at the idea of PHP being easier to read than any other language, but it was true at the time, and older developers may grumble that it was possible to write clean Perl, and that's true too, but it's also true that Perl culture encouraged and delighted at horrid and inscrutable gibberish.)
The one other thing PHP had going for it was mod-php, which was easy for sysadmins to install and worked right alongside mod-perl, which pretty much all of them knew how to install already. So, every little web host added support for PHP practically overnight.
> When a CGI script is executed, it initiates a new process for each request. While this approach is straightforward, it becomes increasingly inefficient as web traffic volume grows.
This is true, but largely irrelevant to why CGI scripts fell out of favor. Lots of people on-prem'd or colo'd their own stuff back then (I had a beige box on an ISDN once upon a time!), and it was really hard to get enough traffic to make a machine fall over because it was spawning too many processes. Usually your bandwidth would get saturated before that happened.
There was, maybe, a brief period where this was sort of a thing, where 56k modems were everywhere that DSL wasn't and people started to pay companies to run stuff for them, but even then -- as now -- the bottleneck was usually not in the number of running processes.
> Modern application servers like Uvicorn, Gunicorn, Puma, Unicorn or even Go’s standard server have addressed these inefficiencies by maintaining persistent server processes. This, along with the advantage of not having to bear the VM startup cost, has led people to opt for these alternatives.
Heh, heh. Some people may be using those because they read on somebody's blog that everybody else is using those so they should probably use those too, but I could become a wealthy man betting $100 to every dollar that any web dev who thinks switching from LAMP, php-fpm, nginx, or whathaveyou to Spangly Animal Server is gonna be their big performance win hasn't actually done a comprehensive performance profile of their application. You are burning waaaaay more milliseconds on your JS dependencies than you are on spawning a new thread.
-
DEV.to and Perl
Movable Type is written in Perl: https://github.com/movabletype/movabletype
mojo
- Mojolicious
-
CSS in Perl
Initial thoughts
-
Perl 5.38 Released
If you end up doing web development, check out Mojolicious:
https://mojolicious.org/
-
How can I host a perl based website on a vps?
If you choose to go down the Mojolicious road, there's lots of deployment information and guides in the Mojolicious Cookbook.
-
Mojo may be the biggest programming language advance in decades
I guess this will make it harder to search for Mojo(licious)-related stuff. 😩
-
Getting the result/reject values from a Mojo::Promise using async subs
But if I want the return value of 'test_p' or the error message 'This is an error', I can't seem to figure that out. I tried looking at the promise tests (https://github.com/mojolicious/mojo/blob/main/t/mojo/promise.t) but that didn't seem to work either.
-
Choose boring tools
Several! The 3 big players in order of release are Catalyst, (released in 2005), Dancer2 (Dancer was first released in 2009, but went through a complete re-write as Dancer2 around 2013), and Mojolicious (released in 2010).
-
Guidance on Building a Web Application in Perl
This project sounds to me like the perfect excuse to learn Mojolicious if you're interested in converting your scripts into a web application using Perl.
-
i3mojo -- an i3status replacement in Perl
Awesome! I still use Perl on a pretty regular basis both for work and fun. I really enjoy it. Definitely take a look at Mojolicious if you haven't already. It's primarily focused on being a web framework (both server and client), but it's nicely modular so you can use bits and pieces of the stack. In i3mojo, I used the Mojo::IOLoop event loop, Mojo::Base as a base class system, and Mojo::UserAgent as a web client for some plugins.
-
The beauty of CGI and simple design
Last time I used Perl for anything web it was via https://mojolicious.org/
It even does event-based and websockets
What are some alternatives?
blogs.perl.org - Templates and stuff for the blogs.perl.org web site
Flask - The Python micro framework for building web applications.
go - The Go programming language
node - Node.js JavaScript runtime ✨🐢🚀✨
Django - The Web framework for perfectionists with deadlines.
LANraragi - Web application for archival and reading of manga/doujinshi. Lightweight and Docker-ready for NAS/servers.
Express - Fast, unopinionated, minimalist web framework for node.
CPython - The Python programming language
Laravel - Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation for your next big idea — freeing you to create without sweating the small things.
Apache - Mirror of Apache HTTP Server. Issues: http://issues.apache.org
mdbootstrap - React 18 & Bootstrap 5 & Material Design 2.0 UI KIT
amcharts4 - The most advanced amCharts charting library for JavaScript and TypeScript apps.