SOLVING PROBLEMS THAT WE CREATED

TL;DR; Rethinking Web Dev... Everybody has tools that they use, and some tools they acquired to fix problems that someone else caused. I remember when I was the Service Manager for a GM dealership. Every month GM would send us new "special tools." These tools would eventually migrate from the corner of my desk to the "tool room." This tool room was not the place where all mechanics placed the tools they bought with their own money, but these were company tools. It didn't contain any "common" tools as you might call them for the average mechanic like a socket set, pullers, pliers, etc. No, this room contained the sockets, pullers, pliers and tools that didn't even resemble a typical tool that were specially designed for a very specific application. Then would come in the cars of that year and the mechanic would look up the repair guide and it would mention special tool GM-####, in order to complete the repair, the technician would need to locate the special tool to diagnose or repair the vehicle. More than once we would have the parts necessary to repair the vehicle, but could not for lacking of a special tool and we had to order or borrow it. If you are interested, the special tool website is actually public web: gmglobaltools.com. What I want to call out though is that many of these tools only existed because the engineers designed something that could only be diagnosed or repaired with a specially designed tool. I want to use this story to step into a deeper subject of web development, and our use of "special tools". I've been doing research recently into some new, yet old, tech. If you want to peek into my world and get deep into web development (there is a reason why I call it "development" and not "design"), then check out a few of the following: NATS.io data-star.dev protobuf.dev htmx.org go.dev html css js I say new, because some of these are really new like D* (data-star) isn't even out of beta v1 yet (really close though), but I say really old, because it takes roots back to the fundamental of how the web works, like html that was used on the first website (info.cern.ch) in 1993. I have been "burned" so many times lately, well in my whole IT career of 18+ years, because I have chosen elements in my tech stacks because they were popular, maintained, recommended, or just to sum it up, the fad. Many times it even looks like the solved the problem I was facing, when sometimes years later I resolved that they only solved a problem I created and yielded to creating more problems. It's the same truth, "if you don't learn from the past you are doomed to repeat it." It makes me look at what we have been doing with the recent fads of Web Dev, and makes me ask the question... ARE WE SOLVING PROBLEMS THAT WE CREATED? Ok, so I use the "we" very generally to include all the master minds of web development and not just the few of us that might ever read this post. While doing some research I was watching a few tech talks while washing the dishes tonight and since my hands were wet the player continued to a video I had not anticipated watching: "Building the Hundred-Year Web Service with html" by Alexander Petros [https://youtu.be/lASLZ9TgXyc?si=2QA7NT_50-wtprEw] Alex's opening introduction really caught my attention because I studied bridge architecture in high school in my first research project (thank you Mrs. Debbie Taylor. Readers please don't blame her for my bad grammar and run on sentences, she tried harder than I listened, haha!) Anyways, the intro brought to light some poor decision patterns I held as I try to be a web developer that builds something that lasts for generations. I usually think about problems as they exist today without taking into consideration what the problem might look like in 100 years. Now if I do solve the problem of today and do it well enough, it very well may stand the test of time. However, if I think fundamentally at what problem I am trying to solve and if that problem will exist and how it might exist in 100 years then I might solve it differently. I use to do quite a bit of what I call "traditional web work" and that involves things like basic template driven website development. These usually always end up with the same problems and similar solutions but they don't usually include much in terms of future proofing. "How easily can a different template or theme be changed out?" while that is usually considered "easy" when you actually attempt it at a deeper level, you quickly find all the oddities you did to "fix" the old theme that now have to be refactored to work for the new theme or template. And that doesn't even include staying up to date with the changing SaaS solutions that most web sites deeply depend upon whether that be WordPress, WIX, Laravel, React, or whatever. I look back now and see much of this work (while being beneficial and producing results) to have been done in a way that caused more problems in the future than what it solved for the curren

Mar 16, 2025 - 07:55

TL;DR; Rethinking Web Dev...

Everybody has tools that they use, and some tools they acquired to fix problems that someone else caused. I remember when I was the Service Manager for a GM dealership. Every month GM would send us new "special tools." These tools would eventually migrate from the corner of my desk to the "tool room." This tool room was not the place where all mechanics placed the tools they bought with their own money, but these were company tools. It didn't contain any "common" tools as you might call them for the average mechanic like a socket set, pullers, pliers, etc. No, this room contained the sockets, pullers, pliers and tools that didn't even resemble a typical tool that were specially designed for a very specific application. Then would come in the cars of that year and the mechanic would look up the repair guide and it would mention special tool GM-####, in order to complete the repair, the technician would need to locate the special tool to diagnose or repair the vehicle. More than once we would have the parts necessary to repair the vehicle, but could not for lacking of a special tool and we had to order or borrow it. If you are interested, the special tool website is actually public web: gmglobaltools.com. What I want to call out though is that many of these tools only existed because the engineers designed something that could only be diagnosed or repaired with a specially designed tool. I want to use this story to step into a deeper subject of web development, and our use of "special tools".

I've been doing research recently into some new, yet old, tech. If you want to peek into my world and get deep into web development (there is a reason why I call it "development" and not "design"), then check out a few of the following:

NATS.io
data-star.dev
protobuf.dev
htmx.org
go.dev
html
css
js

I say new, because some of these are really new like D* (data-star) isn't even out of beta v1 yet (really close though), but I say really old, because it takes roots back to the fundamental of how the web works, like html that was used on the first website (info.cern.ch) in 1993.

I have been "burned" so many times lately, well in my whole IT career of 18+ years, because I have chosen elements in my tech stacks because they were popular, maintained, recommended, or just to sum it up, the fad. Many times it even looks like the solved the problem I was facing, when sometimes years later I resolved that they only solved a problem I created and yielded to creating more problems.

It's the same truth, "if you don't learn from the past you are doomed to repeat it." It makes me look at what we have been doing with the recent fads of Web Dev, and makes me ask the question...

ARE WE SOLVING PROBLEMS THAT WE CREATED?

Ok, so I use the "we" very generally to include all the master minds of web development and not just the few of us that might ever read this post.

While doing some research I was watching a few tech talks while washing the dishes tonight and since my hands were wet the player continued to a video I had not anticipated watching: "Building the Hundred-Year Web Service with html" by Alexander Petros [https://youtu.be/lASLZ9TgXyc?si=2QA7NT_50-wtprEw]

Alex's opening introduction really caught my attention because I studied bridge architecture in high school in my first research project (thank you Mrs. Debbie Taylor. Readers please don't blame her for my bad grammar and run on sentences, she tried harder than I listened, haha!) Anyways, the intro brought to light some poor decision patterns I held as I try to be a web developer that builds something that lasts for generations. I usually think about problems as they exist today without taking into consideration what the problem might look like in 100 years. Now if I do solve the problem of today and do it well enough, it very well may stand the test of time. However, if I think fundamentally at what problem I am trying to solve and if that problem will exist and how it might exist in 100 years then I might solve it differently.

I use to do quite a bit of what I call "traditional web work" and that involves things like basic template driven website development. These usually always end up with the same problems and similar solutions but they don't usually include much in terms of future proofing. "How easily can a different template or theme be changed out?" while that is usually considered "easy" when you actually attempt it at a deeper level, you quickly find all the oddities you did to "fix" the old theme that now have to be refactored to work for the new theme or template. And that doesn't even include staying up to date with the changing SaaS solutions that most web sites deeply depend upon whether that be WordPress, WIX, Laravel, React, or whatever. I look back now and see much of this work (while being beneficial and producing results) to have been done in a way that caused more problems in the future than what it solved for the current state.

I look at a different project IFBMT, and I see that from a deeper level I approached some things wrong, but on a higher level I did some things well and that leads to its seeming success. The attempt to recevelop IFBMT into MissionBase with a modern framework and a state-of-the-art database platform should have worked by comparison of the fads of the trendy web. But that is just the problem, we set out to fix problems that I created, and while fixing those problems we only created additional problems up to the point that we had to make the hard decision to abandon the 2.0 project that visually was a success, but was a failure to launch. I have attempted a few times since to restart a new version of IFBMT, but each time seem to run into similar problems. The success of IFBMT was not just because it solved a niche problem that was unresolved and closed the three-way gap between donor management systems, contact relationship management systems, and independent baptists, but because it did it in such a way that it has been practically hands off running for the most part since 2018. Compared to other web apps, IFBMT (v1) is close to end of life. I say that not because it is planning to shut down any time soon, just because LTS usually ends for a version after 5 years, with most version 1 being replaced in only 2 years. So what is it that has helped it stand up so long with so relatively little maintenance and support? (a standing rhetorical question, I am continuing to answer - thoughts on using very LTS versioned tech stack?)

I now venture down a different brain pathway of where my professional career has taken me and I found another diamond (howbeit dull) in the rough with HL7 v2. It amazes me that HL7 v2 is almost the same age as I am, released in 1989! Literally the reasoning for my job is because hospitals and 3rd party applications are still utilizing a technology standard that is widely supported and hailed as the superior (arguably, it is not) mechanism for exchanging healthcare data. HL7 is a strange animal because there have been attempts and even whole new architectures released and pushed to replace v2, yet it persists forward nonetheless. Version 3 was not widely adopted due to it's complexity, lack of backwards compatibility with the widely used v2, and the steep learning curve associated with its implementation. The latest version of HL7 (commonly referred to as FHIR) is not even meant as a replacement for HL7 v2, but rather as a way to compliment it and offer a more modern approach to healthcare data exchange using RESTful web services. Just some interesting thoughts here...

REST is seen all across web dev today, but I wonder how many actually know what problems it solved and how well it still does at solving that problem. This takes us back from healthcare data exchange back into Web Dev. REST stands for REpresentational State Transfer, and is a software architectural style first defined in 2000 (a quarter century ago now). in my honest opinion, modern frameworks don't rely on REST as much as they should. The standard's purpose was to establish a standard for how servers could communicate and exchange data, leading to a simpler and more flexible approach to API design. REST fundamentally solves many of the SOLID principals and approach to development if the rest (no pun intended) would just be done correctly as well. REST if coupled with the correct architecture has been proven to solve scalability issues as well that has plagued many a startup (mine included). Now let's rethink the FE of the FullStack web developer...

Web Dev is divided into two lands, the Front End (FE) development, and the Back End (BE) development. The FE is the end user's device and what they see, do, and control. The BE is the server (think organization's controlled computer providing the web page.) What modern reactive frameworks have mostly done is pulled most of the load off from the BE and offload it onto the FE with tools like React. The naming of React with Reactive development is almost as amusing to me as the term Relate in correspondence to Relational Databases, but that is a tangent for a different post. While reactive websites handle asynchronous data streams and event-driven scenarios, they usually fault in the part of making the FE do all of the logic to make that happen. Let the FE do best what the FE does, and let the BE do best what the BE does. That is a novel concept, but one that we (web developers) keep trying to break and misconstrue. And why do we keep trying to break this concept, because we are attempting to solve problems that we created. The fads say to go "server-less" for scalability, but is that really the best approach? Maybe for static web content, but why attempt to completely absolve something that isn't the answer to every problem. And by using this solution, we simply create a world of others.

If you are a Web Dev, or anyone still reading this post: first, thank you; secondly, we probably disagree on many technical things and that is ok, but more importantly; thirdly, can I challenge you to rethink how you develop for the web? Why do you use the web stack you are using? How long can your project stand without being touched and it still solve the problem. Will the problem you are solving be a long-lasting problem (what might it look like in 100 years)? What would you do if you had to drastically simplify your project to just the bare necessities to solve the problem?

More thoughts later, but it is getting late for tonight/this morning.

[graphic from churchcanvas.ai which I HIGHLY recommend!]