Re:The Future of Perl
by mmcclimon on Wednesday March 24, 2021 @07:26AM
(#26565792)
I work for Fastmail, and helped write Topicbox, the backend of which is entirely written in modern Perl. The frontend obviously uses JavaScript, and talks to the backend using JMAP (RFC 8620), which we helped to develop; Topicbox was using 100% JMAP well before Fastmail itself did.
[ Parent
| on HN ]
Why can't the back-end of Topicbox do the JMAP stuff and then serve up some HTML? Beyond "because that's how we built it and it must be thus", it's quite hard to see why the front-end would need so much JavaScript to render nothing more than a chain of emails.
Re:The Future of Perl
by brongondwana on Wednesday March 24, 2021 @08:32AM
(#26566322)
If you're just loading a single page, then yeah - it's pretty useless. If you're spending any time in Topicbox then the benefits of push updates and dynamic preloading pay off, and it's pretty lightweight as Javascript goes.
But yeah, in a perfect world where we had infinite time to develop it, we'd have the backend serve up a non-javascript static version of the content in response to direct links - if nothing else because it makes things a lot nicer for search engines - and then the javascript would load in and take over if enabled to allow you to keep moving through the site like usual.
> and talks to the backend using JMAP (RFC 8620)
FastCGI and mod_perl would have been a better choice.
JMAP operates over http and the backend http server is almost certainly PSGI based, which obsoletes both FastCGI and mod_perl as deployment approaches.