Building your own web framework can be a rewarding experience for any developer. Not only do you gain a deeper understanding of how web development works, but you also have the potential to create a tool that can be used in your own projects.
However, the question remains: should you use the framework you just built in your production projects? While it might be tempting to do so, I believe there are compelling reasons why you shouldn't.
I want to share with you my experience of building my own framework, the challenges I faced, and why I ultimately decided not to use it for my production projects. By the end of this article, you'll have a better understanding of why building your own framework is a valuable learning experience, but why you should stick to using established frameworks for your production work.
When I started learning Laravel, I decided to create my own framework from scratch. I wanted to understand how Laravel worked under the hood, and I thought it would be a good way to learn. I spent countless hours researching and coding, and eventually, I had my own custom framework up and running.
At first, I was excited to start using my new framework for all my projects. But as I began to use it more and more, I realized that it had a lot of flaws. There were bugs I hadn't noticed, features that didn't work as intended, and performance issues that slowed down my applications.
I tried to fix these issues, but it quickly became apparent that maintaining my own framework was a full-time job. I was spending more time fixing my framework than actually building applications. And every time I fixed one issue, another one seemed to pop up.
That's when I realized that building your own framework is a great way to learn, but it's not necessarily the best way to build software. Frameworks like Laravel and Symfony are widely used and well-tested, and they have a large community of developers contributing to their development. By using one of these established frameworks, you can focus on building your application rather than maintaining your framework.
Building your own web framework can be a fun and challenging project, but when it comes to production work, stability is key. Your clients rely on you to deliver a stable and reliable system that meets their needs. By using established frameworks like Laravel or Symfony, you can leverage the years of development and testing that have gone into these projects to create a more stable system.
Of course, that's not to say that building your own framework is a waste of time. On the contrary, building your own framework can be an incredibly rewarding experience that teaches you a lot about web development. Just don't expect to use it for production applications. Instead, use it as a learning tool to gain a deeper understanding of how frameworks work.
In conclusion, building your own framework can be a valuable learning experience, but it's not the best way to build software. Instead, use an established framework like Laravel or Symfony for your production applications. By doing so, you can focus on building great applications without getting bogged down by framework maintenance.
Top comments (7)
I built my own CMS that was essentially also a framework & used it for my own & client projects for many years. It was useful & educational. But I've now moved onto Symfony & I think I appreciate it more because of my past. 😁
Just like teaching a course: it forces you to learn a lot more than you would have otherwise known about the subject, even though you're not the students... but you are.
I am trying to create my framework/libraries to use it/them in other projects (when I have a time, I will start...), too.
I think the best way is to configure the dev env and the versions, between the projects, somehow in a way, that you can go fast to it and fix/update/change, this will include something like a centralized codebase, between the projects and the frame/library and you need to start thinking, not to implement the logic/functionalities of the projects with the framework (the framework rules), but IN the framework (change the rules). Exactly, the opposite for how a framework is used. The projects are the rules/framework and the framework is your project.
For the example, if you need to change something in a project, but it is not possible with the framework, you need to edit it.
Nice to read participate on hour experiences.
And I also understand your point very good.
I’m currently building a typescript framework for backends 😂.
Think the big difference is on the intention of building a framework.
If it is for your personal fun and learning curve, you are right. You might better use some mature framework for production stuff.
But if you really want to build a framework with the goal of “used by many others”, you probably must use your own framework.
Will you have bugs and issues? For sure!
But also, any other dev who is using your framework, will face the same issues.
If you don’t use it - why anybody else should use it?
And what happens if they facing issues?
They also need to get bugs and issues resolved.
If there are only people who rely on “use the mature one provided by other”, we wouldn’t have any good process at all.
Think the key is, to find other devs to help building the „own“ framework.
This is a great article and good advice. 👏
Thank you!
Very interesting, thank you!
Good article! Thanks