2023 Manifesto

In progress (and will probably be rewritten completely...)

Some issues and thoughts on the current state of member-page:

• The development environment is too difficult to set up and obtuse in its workings.
  • Docker isn't necessarily a great experience while developing. It would be preferable to only have to run a simple node script.
  • Our env-files need to be manually distributed to every team member. Some secrets have to be set to be able to even run the application properly.
• We're not using TypeScript in strict mode which means we're missing out on a lot of type safety.
• While the overall route structure is nice, the codebase is a bit of a mess. There are way too many layers of indirection making it hard to grasp the entirety. Data travels from the Postgres database, through our query builder Knex.js in our datasources, to our GraphQL resolvers, to our backend schema, to our frontend queries, to our component hooks. That's a lot to grasp, and that just covers how data flows from backend to frontend! In addition to that, one must understand how Next.js and React work before you can really get started writing a single line of code. This desperately needs to be made easier.
• We rely on outdated dependencies. Currently, we can't really update our core dependencies including MUI, React and Next. I think that poses a danger to the longevity of the project. While we don't have to be at the absolute bleeding edge we should definitely aspire to keep our code up-to-date with current stable versions of these projects. That makes it easier when searching for help online and ensure we have the latest fixes for issues.
• In addition to the technical issues, I and some members in our team have voiced concerns about our website having an inferior design compared to other guilds, most notably the E-guild, but to a lesser extent many of the other guild as well. That's obviously not a great look for a guild made up of programmers and I would like us to be able to take pride in our website.

With all that in mind, what is the path forward?

• Updating Next.js and rewriting our data loading is the obvious choice. But it's hard to understate just how big of a change the app router and server components are. Recall how web apps used to be written before React, before Angular, before jQuery. There was no client-side data fetching and as such no split between frontend and backend development (instead we had stuff like Rails and PHP). RSC brings us back to that paradigm by default, allowing us to opt in to client-side logic wherever we need it with a "use client" directive. Personally I find that syntax a bit lacking and I think the line between server and client logic is somewhat diffuse. Either way it's a massive effort to rewrite all of our components to use the new data fetching logic and it's a transition that's quite disruptive to the React ecosystem. In addition to that the transition is not done yet - server actions are still experimental.
• The outlook of migrating all of our code to the app router and rewriting components as RSC pushed me to consider other options - this article brings up a lot of great points about the challenges of RSC and this one reminds us that there are options other than React. The details of why our new tech stack looks the way it does is left to that part of the wiki, but it's fair to say there's little reason to go with React today other than its ecosystem and popularity. On a side note - in some sense it's like choosing between iOS and Android - the choice of iOS is often motivated by it being more popular and that it's said to have a better ecosystem. Android users would scoff at that of course and point to its extensibility and on-paper performance (although in this case, React really is a lot slower).
• Finally, a clean break allows us to rethink the UI design. While we're in the process of porting our code to a more modern tech stack we might as well think a bit more about our design choices to try and achieve a nicer design.

by @danieladugyan