← Back to context

Comment by gl-prod

3 years ago

What does Perl do in the web app?

Everything basically: Generating HTML, serving AJAX requests, communicating with other services, processing files, running DB queries etc etc. It even has a (questionable) feature embedding LuaScript using Lua::Inline and, hence, allows our clients to write little Lua scripts against our Perl API. Our application continuously runs over 20 years already and its user base kept growing ever since.

When I arrived I tried to move as much of the front end logic to JS but the backend remained in Perl as most business logic still lives there (and not in the DB). These days we try to implement new features in separate JS or TypeScript services and SPAs that, however, communicate with our REST API that is implemented in Perl/Mojolicious. This way we can hire cheaper JS devs (that never learned Perl) and people can still enjoy React and modern frameworks if they so wish. The most talented ones I try to sucker into little refactoring projects in Perl. Most JS developers that tried got fluent in Perl 5 only after a couple of weeks.

In the future we will try to move more business logic of the "Kernel" into the DB system since Postgres grew much more powerful compared to the time back when the application was invented. I believe this will be our only hope to actually shrink our Perl 5 code base eventually.

  • I thought it was just running some scripts. But that's interesting. Are there any performance differences between TS services and Perl ones?

    What about develop time? how long does it take to deploy a feature?

    • I think you'll find that most older, popular (or once-popular) languages perform better than you might think. Perl couldn't perform too badly or it'd have been unusable on 1990s hardware. Early webservers often had single cores clocked at sub-100Mhz, mid-tens megabytes of memory, and tiny, spinning rust hard drives—a bunch of modern web server stacks would struggle to run at all on that hardware, let alone to serve even tens of requests per minute.

      Go look up some real-world-(ish) performance benchmarks for various web frameworks if you want a real surprise. You might find it'd be hard to sell any scripting language other than PHP(!!!) for a project, if performance actually matters and for some reason you can't use a compiled language. Don't assume the new thing is better, or faster, even if that's its reputation. It may not be entirely earned.

    • Adding new features to a Mojolicious web service is quite painless, at least compared to CGI, Mason and other Perl stuff. Also a lot of code reuse is possible. Now we also have Mojo.js, brought to you by the same authors. It's basically the Perl framework with the same name rewritten in TypeScript.

      https://mojojs.org/

      1 reply →

    • "I thought it was just running some scripts."

      Ah, how times change.

      Perl was the original practical back-end development language for the web. There's a bit of opinion in that, but not a lot; there's not a lot of other contenders, unless you count writing raw C CGI programs which was never that popular.

      Perl performance isn't great, but then I don't consider TS/JS performance all that good either. Perl is a cut below JS nowadays because of the JIT that JS has but it's not impractically slow. If it wasn't impractically slow in literally the late 1990s, when it was powering nearly every dynamic site that existed, it sure isn't today.

    • Well, the heavy lifting is usually done by the Perl backend. So you cannot directly compare the performance between Perl and JS/TS services in this case. From my web dev experience so far I believe the language's execution environment rarely matters at all unless you're doing something stupid. That's because most webapps wait for their DB most of the time anyway. Native compilation like in golang or rust does not pay off unless you're writing a streaming service delivering videos.