掲示板 Forums - renshuu developmental goals for 2026

This is more for me to get it onto "paper" than anything else, but I wanted to share my developmental goals/realities for renshuu in 2026.

This isn't development in the sense of features, but more developer-level stuff.

1. More servers?

I originally had hopes to add some regional servers (One in EU, one in Japan) in 2026. Unfortunately, that no longer seems like a reasonable expectation. While running frontend servers in each region is possible, it's the database server that, as far as I can tell, is going to require too much complexity and be too fragile for me to manage as a solo developer. Because renshuu is very much a community service (even if you do not actively involve yourself in the community, there is a ton of community data that you are most likely passively consuming), and so having a ton of data replicated across the multiple regions would be required.

On top of the complexity of maintaining those servers, I suspect that the speed improvements from having closer servers would be negated by the time it would take to keep servers updated when new data got written to one of the servers. renshuu's data (and infrastructure) is far from clean enough so that I could separate out the data into separate databases based on type, and for example, keep personal user data in one spot (whatever was closest to you), because most of the sql queries are joins across data stores (renshuu data, personal data, and community data), and rewriting all of that to call on things separately would be way too much work).

The servers now still run pretty quickly, and have room to grow before I'd need to consider a faster server or more servers (in the same data center).

2. Data trimming

Instead, I think I and the community would get more "bang for the buck" if I, instead, work on trimming down the amount of data that travels between the server and everyone's browsers or renshuu apps. While I won't be able to remove the lag in connecting a server that may be far away, I can do a lot with making the amount of data that needs to be downloaded (and processed by the browser/webview) much smaller.

renshuu has a LOT of javascript, and given that so much of it was written before a)I knew what I was doing and b)javascript matured as much as it has (in terms of dom manipulation, for example), I could rewrite a good chunk of it. There's a few pieces of low-hanging fruit to focus on:

A. Remove jQuery. It's probably 25% of the total js download size, and I only really need a small section of it. Looking into replacement libraries like cash.js so I can keep the "jquery code" in the codebase while cutting down on download size. There are a number of jquery-based libraries I use (for example, the autocomplete box you see appear in some spots like the community lists) that could be replaced with smaller and simpler libraries that utilize what vanilla js has.

B. Better partial downloads. renshuu already does a pretty good job of splitting out js so while there is one big chunk that is downloaded, most of it is only grabbed on pages that need it. This could be further improved, though.

jquery (and all the libraries that rely on it) are probably the easiest to get rid of, though. I already found (a few weeks ago) an entire library that I no longer used (but was still part of the js file), so there are surely other files that can be trimmed.

In addition to js, my css is an absolute mess. I hope to open up a renshuu user mods section in 2026 that allows users to offer up js/css to mod renshuu (with an approval step in place), but the css is not going to go very far if I don't standardize a bit more of it.

I'm not looking to do a top-down rewrite of all the css in renshuu, but a gradual look through the css files to extract what I can (into variables, helper classes), and see what classes are no longer used. (This is much harder than it should be, but it is what it is)

3. Better lazy-loading or delayed loading of dom elements

This is already done extensively in renshuu, but I do think that a lot of the page loads are still a bit too big in terms of the actual amount of html transferred. I don't intend to migrate to react, but a bit more client-side dom construction and a more critical look at how much data needs to be transferred from renshuu will help a lot.

In general, I think there's a lot of elements (like the dictionary) which are loaded off screen, but could be delayed entirely until accessed for the first time. Some of the elements are too entrenched to just "flip a switch" to have that happen, but a piece-by-piece approach could work.

4. Continued work on DB loading

This is the perennial problem, but the DB is still the bottleneck for most page generation. The server is never saturated, but I'd like to continue to work on some of the critical paths to see if I cannot eek out more performance from the server that we already have.