Re^2: Taking advantage of E2 improvements

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.

🦛

Comment on Re^2: Taking advantage of E2 improvements

Replies are listed 'Best First'.
Re^3: Taking advantage of E2 improvements by JayBonci (Curate) on Nov 27, 2025 at 00:49 UTC
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	[reply]

Replies are listed 'Best First'.

Re^3: Taking advantage of E2 improvements
by JayBonci (Curate) on Nov 27, 2025 at 00:49 UTC

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

[reply]