-
Notifications
You must be signed in to change notification settings - Fork 7
Current Webmaster's Opinions
This page might seem a little strange, but I'm adding it in case people end up reading the wiki (lmao). This is where the current Webmaster can share their opinions and philosophies on this project and software development in general. This is not the place to present things related to your political, religious or non-development related beliefs. Future Webmasters, make sure to update this page and put a little thought into why you took the role.
If you've stumbled upon this, hello, my name is Jon and the best way to reach me is on Discord (disdasdefa or UID 186605452199591937). I started this page and have been the Webmaster since May 2025. I also started the current iteration of this repo, wrote most of the wiki and will probably be reviewing your code. I think it's a good idea to understand why I've made certain decisions, but if some things are unclear feel free to reach out to me.
-
I felt I was getting rusty with my web development skills, had some things I wanted to test, but couldn't focus on a personal project long enough for me to finish them. This position forces me to learn new things, test out some concepts I learned and gives me some pressure to get things out the door.
-
I think web developers are perceived as the lowest form of software developer (due to tech influencers and yappers) and I want people to understand why it seems so "complicated" and "is a mess". I've spoken to some of the people in our program and some people hold strong opinions based on wrong information.
-
I wanted to work on my communication skills. Leading a project is a lot of work and requires you to communicate with people. When someone comes to me with a question about something I wrote or said, I use those moments to learn about what I could have done differently. Sometimes my requirements aren't clear. Sometimes I assume a knowledge level and need to change how much I should explain something. When I get frustrated with someone doing something wrong it's not because I think they should already know something (unless they really should), it's usually because I probably need to change how I communicate.
-
Teaching is a good way to keep me sharp. I used to tutor high schoolers and it was surprising to see how much stuff leaked out of my brain over the years. It was also a good way to make me understand things at a foundational level and learn to communicate effectively.
I think everyone will have an opinion on what they believe the best software development style is. I define a software development style as "your process to searching for and implementing solutions to software issues". Solutions can range from which library or language you use, down to the choice of a switch-case or if-else statement. An issue can be as small as a bug or designing an entire distributed application. You probably fall under one of these categories:
- You know the best solution to things
- You don't know many solutions, so you stick to familiar ones
- You don't really have preferred solutions to most problems
I think I'm a mixture to 2 and 3.
Category 1 is something that I will hesitate to ever be under. In software development, there are usually multiple ways to do the same thing. To find the best solution that means you need to know why every other solution isn't good enough. For algorithms, this is probably possible, but when you're doing something bigger, like building a web application, there are completely different paths you can take that will end up at the same destination. If you've been a developer for less than a decade, then I doubt you're at the point where you can claim anything is the best.
Category 2 is something I hope to work on. I do personal projects to learn new libraries; sometimes I end up liking something, sometimes I don't. I generally stick to the ones I like and use them to work on projects. This means I build up my skills using that piece of tech. In general this is good, as you build up your confidence, but this confidence might turn to arrogance. Becoming proficient in a piece of tech might make you believe that your tool is the only tool and everything should use that tool (see the cult of Rust).
Category 3 is where we should be if we're new to something. We should learn and understand every piece of tech we use, so when we encounter new problems we can make the right choice. If you're still a newbie (which I believe I am) then that ensures that you will not stagnate. If you're a few years down the line and you still believe you're in category 3 then you might want to try and start working category 2. You'll eventually need to figure stuff out by yourself and have good reasons as to why you chose what you did.
I just spent a bunch of time talking about the type of developer I am, so let me explain the reasons for why the project is set up this way.
Tiny history lesson
Angular started the whole SPA craze with its first version, AngularJS. This framework changed the way people built web applications, from server-side rendered PHP applications to client-side rendered JavaScript applications. You'll find no shortage of people that hated PHP and once AngularJS took off people hated it too! This wasn't really a "it's popular, so it got haters" sort of deal, AngularJS was legitimately confusing, had a pretty bad developer experience and was pretty darn slow. I worked with it for a few years and I agree with the haters.
Google decided to rewrite Angular from the ground up and made a few key changes that made its developer experience way better. Since it used TypeScript certain bugs were harder to implement, diagnostics would give you issues beyond syntax problems and code became easier to understand.
Nowadays, AngularJS is no longer officially supported, while Angular is still getting an update every 6 months. So if someone says they dislike Angular and start describing AngularJS, you can safely exit the conversation because you're dealing with a yapper.
We went from static pages (HTML/CSS/JavaScript), to server-side rendered applications (Laravel, Django) to client-side rendered applications (Angular, React, Vue) back to server-side rendered applications (with Vercel pushing SSR in Next.js to get people hooked onto their platform), to frameworks using a compiler to make static pages (Astro). You can probably see why web developers look stupid.
-
Chances are you've heard of React/Next, Svelte, Vue and other frontend JavaScript libraries. The only other frontend framework I have recent experience with is React, which I have... certain opinions about. I admit I'm inexperienced with React and the frameworks derived from it, but I foresaw (and saw) problems that could be remedied by doing things the Angular way™. Throw a rock into a room full of your peers that do web development and there's a good chance you'll hit a person that primarily uses React or one of its derivatives, like Next.js. Since React is so popular you'll find no shortage of people that can help you work with it. I thought it would be nice to give people an option to learn something else, so that's one point for it.
-
Angular has a certain way of doing things. There are usually escape hatches for what it's doing, but for the most part you'll be guided by the framework. This makes it much harder to get too fancy and introduce a bunch of messy code. If you need to do something, you can probably use something Angular comes with. Need to share data across the entire app? Use a service. Want to apply some complicated logic to multiple components? Use a directive. No need to find a library and hope it stays maintained, the Angular crew gotchu. This makes it easier for people to hop in and start working on the project.
-
TypeScript. Using a non-typed programming language would make future maintenance in the future. Imagine removing a key from an object, but you didn't realize some other part of the application used that key. That happened a lot when I worked with JavaScript, so let's make our lives easier and stick to TypeScript.
I'm using this for icons. The Angular Material UI icon library is also available, but Angular Material is a bit too... bland for me. Makes me feel like I'm making a Google application.
An animation library used for more complicated animations. So far it's been underutilized, but maybe in the future it'll be integral to the user experience of the site. I'm really bad at making things look nice and this made it easier to make certain animations. I'll usually default to CSS animations, anything that's too complicated will be made in GSAP.
Web development is full of libraries that seem to do the same thing, just a little bit differently. Most just add an abstraction layer. These can be great if the goal is speed, but you run the risk of inserting bugs and not knowing how to fix them. Just because something is trendy that doesn't mean that it's good or will be maintained for a long time. I usually favour the future and learning fundamentals, so here's a few popular pieces of tech that didn't make the cut.
You're basically just writing CSS in HTML. This makes the HTML harder to read. I think it's best to know what's going on when you write CSS and if you don't get what every single Tailwind class is doing under the hood then that's a good way to make something sloppy or introduce bugs.
Part of the role is to teach people how web development works. When you add a layer of abstraction things start becoming black boxes. If a bug pops up then you might not know where it came from. Even worse, you might just be putting a band-aid on something that needs surgery. I know I'm using a complicated framework like Angular, but the reason for that is because you're probably going to end up using a framework, so you might as well learn one. Your skills will sort of transfer. It's a balance I've needed to find and I think if we make our own components then we'll make ourselves more knowledgeable about how those libraries work.
In the future, I'd like to see if we could make our own component library, something that could be shared across other CSSS projects.
This is weird topic to me. I've heard people complain about AI bringing doom and gloom... only for them to use it for their assignments. I'm not against LLM-generated code and will probably accept a bunch of it during my time in this role. If the code looks fine, integrates into the codebase fine and works fine then what's the issue? Now, if I notice something about your code that seems off then I will ask you about it. If you can't explain what's going on without using an LLM to tell you what to say then that's when I have a problem. I expect people to be able to justify why they did certain things and maintain things they submit.
My view of LLMs generating code is it's probably useful once you understand how to code. I don't use LLMs to generate code for me; I've had too many failures from them before and I don't think I'm good enough to use them yet. I think it's like someone using a calculator before knowing how to do arithmetic; sure it gets you an answer, but can you tell that something is wrong when it happens? Calculators are never wrong, they just do what you tell them to, so if the answer you get isn't right then the issue is the person pressing the buttons.
A note about using LLMs for Angular, make sure the code you get from them uses the new paradigm (signals, standalone components, etc.) or I won't review your PR.