Tech Stack Philosophy: Lightening The Client

I don't pretend to have all the answers. Often times, my response to a colleague's question is "I don't know", quickly followed by "but let's find out!" It is not possible for a single person to know all possible variables or outcomes for a specific problem or situation. The key is to understand the problem and be able to ask the right questions. You wouldn't believe the amount of times where I was not the person that solved the problem but rather the person that asked the right question that sparked someone else's genius.

Looking to make an Impact

In the second quarter of 2019, I was hired by Honorlock, an online exam proctoring solution, to be a leader on a growing development team. They had an innovative product and were making an impact in the education technology industry.

I would argue that the most exciting time to join a development team is when the company is in a growth phase. Joining a startup company, though full of opportunity and possibility, can be extremely stressful. Working with an established company is good for exposure and career growth, but the impact a single developer can have will be limited as the company already knows who they are and where they need to go in their respective industry.

But a company that is no longer a startup and is gaining traction, that is where a single developer can really make an impact. You are able to contribute to the core product and make a substantial impact on the direction.

Growing Pains

Every company goes through some level of growing pains. Most of the time, it centers around how to effectively handle the rapidly increasing user base. It definitely is a great problem to have, but you also don't want to get into a situation where you deliver a sub-par experience and users begin to leave for a competitor.

For Honorlock, they were trying to do too much too fast. Their innovation was what put them on the map in the first place. The development team was continually finding creative solutions for difficult problems. When I first started combing through the code base, I was impressed with the interesting ways they implemented features. The code was a bit of a hot mess, but the genius behind the hot mess was quickly evident.

...a large portion of students use budget Chromebooks so the less we ask of the client, the better.

Team and Coding Maturity is a Process

When I joined the team, there were several files that were over four thousand lines long. Four thousand lines long... four thousand. Not just one file, but several. Controllers were thousands of lines long, Blade Views were thousands of lines long and even the chrome extension had thousands of lines of javascript. Over the first five years of the company's existence, the code grew like weeds. We needed to start putting best practices in place, isolating classes and disentangling features from one other.

Starting at the Front End

My first focus was to improve the experience for the end user. This included the student and the instructor. I am not a jQuery hater, but with the recent evolution in javascript, keeping it as a dependency was unnecessary. At the moment, the user's computer was taking on a decent amount of the load and logic. We knew it was important to move that away from the user.

Our goal is to phase out jQuery completely. With the advent of ES6, and subsequent releases, most of the benefits of jQuery have been nullified.

I put together a Javascript Frameworks wiki for the team that would describe what we should use in certain situation. Here is the readers' digest:

• jQuery is to be phased out.
• jQuery was being used for everything from array manipulation to animations.
• When some level of reactivity is required, AlpineJS should be the first option.
• Simple interactions are easily managed with AlpineJS along with more complex state management.
• Use of VueJS is not entirely discouraged, but it should be used with extreme prejudice.
• I like VueJS, but when you are looking to reduce the strain on the user's computer, even VueJS can be a bit heavy handed. Keep in mind a large portion of students use budget Chromebooks so the less we ask of the client, the better.
• When constant server communication is required, Laravel Livewire is a great solution.
• Using Livewire to return server-generated HTML is crazy easy. The client doesn't need to parse JSON and iterate over anything. Just give me my HTML and I will plop it on the page.

The approved client stack was defined and I began evangelizing. Instead of using Bootstrap drop downs, we swapped them out for AlpineJS drop downs. Instead of a two thousand line mess of jQuery functions, we moved a large feature into VueJS which allowed us to improve the user experience in addition easing future development on the respective feature.

It wasn't difficult, but it did take time to educate the team enough to know when to use which library. Through a fair amount of code reviews, I was able to present the strengths of each library I was introducing. No single library can fill all needs, but putting together a cohesive stack with well-defined use cases goes a long way to ensuring all developers are on the same page as they are developing features.

I am a fierce proponent of providing a smooth user experience and continually err on the side of less is more. The more we can handle on the server side the better. The more bulk we can remove from the client-side, the better. The easier it is for future development, the quicker we will move and the more stable the environment will become. Simplify the front-end and not only will users thank you but so will your development team.