Ripping out the display code and converting it into a more consolidated set of templates, or as an intermediate step, into a data structure that is then served to React or any HTML templating system makes a lot of sense IMO! But I've been dreading the large refactor that is necessary, going through all the call-trees etc.

Moving the site away from mod_perl onto Plack also makes a lot of sense. I have a local Mojolicious server that serves a development copy of the Perlmonks site already, but it mostly wraps the single entry into Everything.

I'm not a big fan of React or the other JS-display frameworks, especially for what can be primarily a static site. Moving the chatterbox into a separate component that refreshes (say) via Javascript might make sense, but I think doing this using HTTP endpoints like with https://htmx.org makes more sense. Also, being able to serve the site as static HTML is one of our approaches to stem the constant barrage of bad AI scrapers.

I have a scrubbed copy of Perlmonks (without the votes, email addresses, personal messages etc.) as a MySQL dump if you're interested, and a tools to create that dump at https://github.com/Corion/Perlmonks-Dump, and https://github.com/Corion/Perlmonks-SQLite.

I've ported Perlmonks to the Docker-based E2 build ecosystem; https://github.com/jaybonci/perlmonks. Open to feedback, but I'm happy to make a bunch of improvements if we can figure out how we can handle the change management volume. I'll follow up with you over email.


    --jaybonci

My thoughts, for whatever they might be worth... I think a modern, JS-based site is exactly what the perl programming community needs. But trying to retrofit this site to be that would be both difficult and risky. I believe the effort would be much better spent creating a new site from scratch, particularly given that the state of technology for making web sites has progressed orders of magnitude beyond what was possible 25 years ago, both in terms of ease of creation and the power of the created sites.

See my most recent PMD on the topic. Be sure to read the thread, because it goes into some detail about the issue of porting|referencing content from this site, among other things.

In any case, I think we (perlmonks) need to revisit the question of javascript-tolerance among the members. It has traditionally been a despised non-starter, but opinions may have shifted over time. I for one would much prefer a lean, responsive site than one which serves monstrous composite pages in the name of "efficiency".

I think we (perlmonks) need to revisit the question of javascript-tolerance among the members.

Last year's poll results seemed to suggest that the site was currently pretty much in the sweet spot of what the users see as desirable/tolerable. If consideration is now being given to going much more into a JS-driven experience, it's going to be hugely disruptive for everyone unless it degrades gracefully to a still-usable interface for the non-JS cadre of users.

IMHO, MetaCPAN strikes the balance reasonably well. You can use it pretty well without JS but enabling it only improves that experience. It also renders quickly either way.

---

🦛

One does not have to go super hard in the paint for a Javascript based website. I am for E2 for a few reasons:
• User acquisition and User Experience - E2 is moving its display logic code to 100% React based. The modern web works this way, and as a "trying to not lose money" business, getting more users in the door is important. It also allows me to more rapidly reformat my site for Page Ranking because most SEO considers mobile media selectors to be table stakes. As perl users are likely to find PM due to a more niche topic, this is less of a concern
• Scalability - Having E2 move towards a full API-driven experience with a javascript client on top of it allows for us to do clever things like serve initial page state for Guest Users from S3 or some other CDN. This is HUGE in terms of cost savings in that Guest Users never have to hit the database. It also means that the servers are doing less of the rendering logic, and are slinging fewer bits on each request. We've squeezed out a ton of additional performance by moving even just the nodelets to React-based processing. The React downloads are appropriately lazy-loaded, meaning about a 1M download the first time you hit E2 on a particular build ID. Assets are managed through an asset pipeline in AWS, which is only necessary because I'm using ARM64-based vms. For bare metal servers, the production deployment can be considerably simplified.
• No really better system in Perl - I've tried things like Mason2, and they are more of a pain than what I really want to deal with. Since I'm using Claude Code to maximize my development velocity, React is well understood by Sonnet, and really meets our business objectives.
• Automated React testing in Jest - It's very easy to tell between Jest and Playwright if something breaks on the website. I've got a lot more to do, but the test coverage has also very much helped velocity, and it allows Claude to drop in and find problems with a major degree of accuracy.

In terms of going down a road like E2, I think there are some quick wins that are a perl-based implementation without doing React pretty quickly if that's of interest. We've stabilized the toolset and approach, and am willing to help this community through it.



    --jaybonci

I think a modern, JS-based site is exactly what the perl programming community needs.

I'm not convinced. Yes, JS has some advantages, probably mainly for the chatterbox, and maybe for an improved posting editor. All other functions on the perlmonks website work just fine without JS.

The main problem with perlmonks is currently the response time, or the lack of any response. We all know that problem, and I think it is driving away the last few remaining users. (When was the last time you saw a posting younger than 12 months with a three-digit reputation? The current best node of the year, Re: Perl Best Practices -- 20 years later, has a rep of 49.) We need something effective to prevent the almost permanent overload, and we need it yesterday. Rewriting the code takes way too long, and when it has finished, there won't be any users to enjoy perlmonks any more.

Perlmonks has already been changed to be a little bit more unfriendly (no more anonymous access to "slow", expensive pages). Let's make it way more unfriendly. Require a valid login for anything. Don't bother using the Everything Engine for that. Let the webserver decide (e.g. by checking if the login cookie exists), and make the webserver redirect anonymous access to a static login page. Create a very small, fast, new program (using FastCGI or anything else faster than CGI) that handles form submission from the static login page. It just needs to verify the login against the database, no dynamic loading of perl code needed. That should make all bots hit just the static login page, and perhaps the login program. Maybe add some Javascript captcha to the login page to make bot access even harder.

<Update:>

Of course, we also need a static page and a small program for creating a new account, or there won't be any more new monks. Again, it should not require much code. Just put the bare minimum data required into the database, set the cookie, and redirect to the monasty gates. Again, make it hard for bots. Require a captcha, and perhaps other counter measures.

</Update:>

If that works, maybe add a whitelist to the webserver for well-behaved bots, that (based on their IP addresses) allows access to the Everything Engine even without the login cookie (still anonymous). That way, the well-behaved bots from the relevant search enigines can still add perlmonks content to ther index.

And when that is stable, we can think about improving and/or rewriting the monasty program code.

Back to the JS idea. I have to work with some "modern" Javascript-based Web Applications. I refuse to call them web pages, because they really are fat clients that load the entire application code in the browser (either open or hidden in a "native" app that just bundles a browser engine and a loader for the web page). The one is "Early", a time tracker. It wastes a lot of screen space and lacks the easiest way to track time: A simple table. The murch worser ones are Jira and Confluence. Basically the same approach, but with an extra game: Every pixel on any page is a little mine. Almost like Mine Sweeper, but you can't flag anything. Click anywhere on the web page and the mine will blow up, changing data that you did not intend to change. The same is true for almost any key, because any key may be a keyboard shortcut to shooting yourself into your foot. And very recently, I encountered "ClickUp". Again, it loads tons of Javascript that is never used, simply because many functions of ClickUp simply do not work in my Firefox.

That's not how Perlmonks should work and behave.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

The everything engine is a dog to scale. I've killed off eval(), and am normalizing a lot of the functionality to consistent APIs. Once we have a more skinny featureset, it'll be easier to add engine improvements, like having the nodecache be pre-seeded by a static JSON file, or a memcached/redis caching tier, or porting the site over the FastCGI to be done with mod_perl. It's a lot of cleanout, but it's necessary for the future of the site. The theory is that if the two code bases are close enough, you guys can steal those pre-hardened approaches and benefit.


    --jaybonci