Motivation
I founded Visualcom, a small Brazilian web development agency, in 2003. At that time, I was working with Macromedia Flash, responsible for the interactive and motion aspects of the projects, as well as customer support and project management. Basically, we were developing institutional sites with dynamic content, implemented using ASP, and customized interactive catalogues distributed on CD-ROMs in the early 2000s. At some point as an entrepreneur, I had the feeling that our development process could be cleaner, faster, more organized, and productive. To achieve these goals, it was necessary to go a level deeper in the technical aspects, so I started to learn HTML, CSS, Javascript, PHP, and MySQL.
An ocean of hours
After implementing dozens of projects with the raw stack of languages, I started studying Frameworks. First CodeIgniter; it was a huge step forward compared to the raw PHP projects we were creating. A documented structure, patterns, a community with discussions about how to solve common problems, etc. Hungry for knowledge and with solid experience in projects implemented with CodeIgniter, the second step was a Framework called Kohana. It was a fork of CodeIgniter, made by some talented community members of CodeIgniter. It was a great framework at that time. So, Laravel appeared; my first contact with the Framework was at Laravel 3. It ended the search for the framework I was looking for. No way back. If you know the mentioned frameworks until now, you'll note that at that time, they belong to "the same family." CakePHP, Zend Framework, and others I had some contact with, adopted different approaches as Frameworks, and by this, I mean: not worse, not better approaches, just different.
Adopting the same "family line" of Frameworks when we make a change allows us to quickly understand the new framework and generate value from it.
In parallel, the same happened on the other layers. From raw CSS to Sass, BEM Methodology, Grid 960, Bootstrap, and Tailwind CSS.
Well, Javascript. It's a separate case... The changes in the Javascript Ecosystem all these years were insane. From raw Javascript and jQuery to Package Managers, Bower, Node, Gulp, Grunt, Webpack, Module Systems, Backbone.js, Angular, React, Vue, Svelte, Frontend Routing Systems, Stores, States... Jesus Christ... what a journey 🤯
Not to mention the DevOps part. From raw FTP to Git Deploys, Pipelines, Docker, etc., etc.
Well, programming can be hard. We can't do it all by ourselves. It's an ocean of hours spent, and I believe time is one of the most valuable assets we have in life.
Some projects I developed over the years are not small ones, and must be maintained for a long time, I mean, in some cases, over a decade. If you don't have a clear mental model and are not organized, you are generating "bad karma" to be faced by yourself in the future. No excuses, earlier or later, you will have to implement new features, update something in the stack, etc. No one is going to make these changes for you, so it's better to take care of your future self, and if you work in larger teams, why not care about the future of others? At this point, I'm not talking about Frameworks anymore. I'm talking about adopting mental models that will help you achieve the requirements of your projects, explain your codebase to others, make the whole process enjoyable, and make you more productive. It's a never-ending journey, and what works for me may not work for you, and that's totally ok...
Ok, but another Admin Panel?
On the surface, Modular can look like "just another admin panel"... trust me, it's not. Developers and teams, looking for a solid foundation to build their projects, connecting the dots between different layers that compose a project, can benefit from Modular. I built it from a Full Stack Developer perspective, addressing some common problems I faced over the years, to name a few: Access Control Lists, Multiple Dashboards, Persistent Activity Logs, an easier routing system/connection between frontend and backend, ready-to-use and integrated UI components that can be easily autoloaded, faster builds, an easily scalable structure to expose APIs and to incorporate a frontend site if needed, etc... All this, trying not reivent the wheel, but using some great tools available in the ecosystem, and connecting them in a way that makes sense to me.
If something in this project resonates with you, I sincerely hope that in some way you can benefit from it. Thanks for your time reading this 💫