The Dynamic Site builder is my largest personal project consisting of over 100 modules to make developing sites and software easier.
Options for websites were limited when I started my company in 2009. What began as a struggle to create the site I wanted resulted in an entirely different career and this framework [starting in 2012].
(click to expand)
I began creating my first real website in 2009 for the launch of my business, Creative Design Influence (CDI). Originally I only planned on building my own, but that proved to be a much harder task than anticipated. The only real options then were custom, Wix, SquareSpace, and WordPress – I disliked Wix outright due to its quality. I did not like the idea of being forever tied to SquareSpace (which wasn’t even mobile friendly at the time), and felt overwhelmed by WordPress given I’d never programmed a thing in my life at that time. I quickly transitioned from a tool I had used to make a church website as a kid (Homestead’s Site Builder) to creating it with code using Macromedia’s DreamWeaver. Using static site builders meant every pixel was locked in, which led to endless tinkering and an end product that looks far from perfect. I had built basic HTML sites in high school so how hard could it be, right? Hard. Pretty damn hard.
Before long I was coding in PHP (2011) and began understanding programming. By 2014 I was a JavaScript savant – which is great because NodeJS was gaining popularity. I had built hundreds of useful code blocks for everything from fancy UI animations to entire site backends. I gleefully named my collective code as the DSB – and it worked great! Sorta.
I never really liked PHP and after I got used to JavaScript, NodeJS was awesome! I much preferred the JavaScript ecosystem and it was promising to be a fruitful way to build sites and applications. By this time I had already ceased B2C operations (2012) in my business and focused solely on B2B. In 2014 I discontinued the company with the goal to make my DSB a Software-as-a-Service (Saas). I was technically ready to launch in 2013, but, as they so often do, things in life happened. I still suffered from perfectionism and instead of launching my MVP decided to completely redo the code base in NodeJS (while also supporting PHP).
Looking back I should have launched regardless of the trials in my personal life. I found comfort in writing code and enjoyed the challenging process of developing a unified framework. Unfortunately I was a bit too comfortable – by 2016 I was low on savings and had to get back to paid work. I interviewed with several companies but ended up resuming freelance services offering nothing but web related services. I actually enjoyed this (aside from the selling aspect). Having learned many lessons from my past the perfectionist in me was quashed and I prioritized bringing products to market as soon as they were viable. It has been a profitable endeavor for me.
The code base (the DSB) still exists, but given the slew of other frameworks that have came out during this time I felt no need to continue it. The project isn’t official dead, but it might as well be. I made more than enough to cover the cost so I’m happy about that – plus I learned a TON about web development, programming, software engineering, and more that I’ll likely use for the rest of my life.
Once I had a solid backend in PHP I converted it to NodeJS. I continued building out Node/JS based modules working on the PHP as little as possible. After several refactors it was “done”.
(click to expand)
Once I had HTML and CSS down I needed a way to make maintaining websites easier. I paid a friend that had a computer science degree to let me pick his brain for 2 hours. This answered most of what I needed to know about creating a dynamic back end for modern sites. I strived to not repeat myself in the code, making things as modular and recursive as possible. This unfortunately led to longer development times but did afford me plug-and-play code pieces I could use on multiple sites. I had a fairly robust system by the end of 2013, even owning a complete content management system for clients to edit their sites. However, as is the case with large projects, it always seems like there is more to do. I wanted to switch to NodeJS to take advantage of Express and Webpack. I “copied” my dynamic back end from PHP to JS and for maintained 2 code bases (originally the Node version of the DSB was just for development as most people used shared servers which only supported PHP). This and some other large software I was creating at the time compounded the technical debt and eventually led to mild burnout. It all “worked”, as I don’t release anything unless it meets the minimum, but it wasn’t pretty. No sir it was not pretty at all (at least in my opinion).
The code was actually pretty good, but I wanted something artistic – something beautiful, awe inspiring – something developers could look at and say “damn, that’s some nice code!”. This took me down a road of never-ending tweaks and new modules (aka Scope Creep) that only increased the workload even more. There was so much I wanted to and could do! Unfortunately I had lost all site of the original purpose, refactoring and polishing the code several times until I had something I actually liked. I am just one person – something I knew pushing my MVP towards market and working 16-hour days for weeks at a time. Other frameworks sprang up and that’s what everyone wanted, so I learned them in case I needed them (the only one I like/prefer to use is Vue but you know how job listings are) and discontinued real efforts on the DSB. It still gets periodic updates, security patches, etc. but new features are slow to develop and for the most part it’s only used for client sites where it makes the most sense.
Just build something. The framework you use doesn’t matter as long as it makes sense for the project you’re using it on. Leave huge code bases to those being paid for it or open-source developers, because it takes a LOT to develop something so large well.
I also learned software engineering, programming/web development, how to organize complex projects, what to NOT do when creating a MVP (minimum viable product), that trends are stupid and you should build based on facts>feelings, and that by the time we’re through with this framework war AI will have already taken over.