Separation of concerns rebuttal

NOTE: this blog post is a rebuttal of an article I wrote about separation of concerns while still in school. The article can be found on the home page. I've left the article there to show writing style and growth over time.

I do not normally want to talk completely down about someone who has taken the mantle of teaching. It’s a thankless job much of the time. Yes, I have poked at a professor in the past, questioning their methods or their motivations, but I don’t think I’ve ever out and out slammed a professor’s ideas…until now.

I was tempted to write this in a more formal manner, but I’ve decided to keep it an informal blog post and give my full weight behind the emotions behind the post as well as the facts. In the future, I might take this post as a base and make it a formal paper, but for now it’s going to be a personal rebuttal to the paper I wrote about separation of concerns. That paper was written with clear instructions on the topic. In the weeks leading up to the due date, the professor in question had taught that separation of concerns meant that any language, be it programming or markup or otherwise, should be in its own file and absolutely no other language should be in that file. If the file extension was .HTML, then under no circumstances should there be any inline CSS or JavaScript. We were not even allowed to put in an onclick attribute on our HTML button. I found this most difficult when we were working with PHP and templating. The temptation to use an echo statement was always strong but forbidden under this professor’s watch.

Since then, I’ve graduated and moved into freelancing. Not one to ever really be satisfied, I have a long list of things that I want to learn. Tutorial I want to go through, concepts I want to understand better, frameworks I want to use. The list goes on to the point that I ran astray and had to reign in where I was going. But I digress, that’s for my post about the roadmap I’ve made for myself. My point is, I’ve discovered through using new technologies that the idea of separation of concerns that this professor taught is not only incompatible with many modern technologies, it’s outright naïve to think that a professional web developer would operate in that mode. Even in highly opinionated frameworks such as Ruby on Rails and Django, I find a wide variety of opinions on what constitutes good code. While the before mentioned onclick attribute attached to an HTML button seems innocent enough, it would have meant a deduction of around 5 points per attribute in this professor’s class.

Before I go on, let me recognize the defenses to his method. For one, he was also teaching us the MVC architecture. This simplified version of separation of concerns might have been an aid in learning this more complicated structure. On the other hand, he hammered his opinions so hard that it didn’t seem like he was using one to help in teaching the other. Second, he was teaching us PHP and CodeIgniter, both backend technologies. Backend work is typically more opinionated than frontend due to the responsibilities inherent in the job. Opinionated practices make for more consistent practices, especially in a team environment. More consistent practices can assuredly mean more secure code.

And here we go with the reason I wanted this to be an informal blog post: my experiences since graduation. It’s not that he taught the concept of separation of concerns in this simplified manner, it’s that he hammered it so hard at us that he shaped the way we coded our early projects, even after leaving his class. When I decided it was time to look at Svelte, my brain was not ready for what the tutorial was teaching. React and Svelte want you to create modular, reusable code that is neatly packaged in single file modules that contain all the JavaScript, HTML and CSS that are needed for that module to work. I was still trying to put the CSS and JavaScript in a separate static folder. I had to rewire my thinking and it took a real struggle with code for that to happen. At one point, I was putting the PathSix Games site in SvelteKit. On the index page, I had two JavaScript files. I have one that gives me a delayed scroll effect with the character portraits and another that is a fetch program to grab the first paragraph of the latest blog post and post it at the bottom of the home page. Neither are complicated at all. As a matter of fact, both are simple. Easy peasy lemon squeezy. And yet, I could NOT get both programs to work. One would work on a load and then the other would work when the page was refreshed. One might work a couple of times in a row, but largely they were taking turns working. It was because I had them in two separate files in the static folder and linked separately at the bottom of the page. I put both scripts at the top of the main page.svelte file and guess what…magic. They both worked.

You know what? All that frustration to finally realize that Svelte has its own version of separation of concerns that is both very valid and very elegant. By creating modules, Svelte guides you to those reusable packages that can make life easier in the long run. And the separation is still there! JavaScript is in a script tag at the top of the page, the HTML is in the middle and the CSS is at the bottom inside its style tag. Opinionated backend will separate the presentation , business logic, and data access into layers so that different aspects of the business can function and grow without adversely affecting the others. In no way am I refuting the concept of separation of concerns. What I am refuting is the inflexible hammer that we were presented in a class that taught backend concepts. And let me make sure you understand, he was clear in that he thought this is how all professionals should handle their code. Of course, he also believed that everyone should know PHP because ‘PHP runs the web.’ Maybe that gives you a better insight into my personal feelings as I move into new technologies that rewire the way I think.

Posted on: 2024-08-17 22:25:03.182469