So first, my perspective. I still live with code that was written more than 10 years ago by me and others. Maintainability is something that is very important to me -- something I wish had been more important to us back then. But hey, we did the best we could with what we knew at the time.
Today, I try as hard as I can to avoid building my code on top of frameworks. Because in the end I've decided that all of them are leaky abstractions. Ultimately, I not only have to understand my code, but I also have to understand the intricate bowels of the framework to make it behave correctly. Sure it saves time in simple cases, but I always find what I thought was simple or common is not quite the same as what the framework devs thought.
So I use the MVU pattern. I've used it in Elm and F#. MVU isn't what I would call a framework, although it does come with some pre-packaged functionality (view rendering especially). But it's not quite what you think -- almost all the types and functions you create in MVU are to solve your problems, not to satisfy technical requirements of a framework. Less of the things you learn are non-transferable. And in fact I have learned a great deal from this pattern that I have also applied to the back-end.
The end result is something that is ridiculously maintainable. But there are downsides. The main one that comes to mind is upfront effort to learn. It's different. And since it is a fairly uncommon way of doing things, there is less information than you might like available. And sometimes what is there leads you down less optimal paths. But the great thing is that since it is so maintainable, you are not unduly penalized for those early mistakes. You can fix them -- with some effort, but without much risk. Some people complain that it has boilerplate. Maybe it does in some places or with some strategies. But when I consider the framework wiring boilerplate I don't have to write (or worse, the invisible magic wiring deity that I hope I don't make angry), I think it is roughly equivalent.
I've been meaning to write an article about it, but I've been heads down in a project and haven't had the extra bandwidth.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So first, my perspective. I still live with code that was written more than 10 years ago by me and others. Maintainability is something that is very important to me -- something I wish had been more important to us back then. But hey, we did the best we could with what we knew at the time.
Today, I try as hard as I can to avoid building my code on top of frameworks. Because in the end I've decided that all of them are leaky abstractions. Ultimately, I not only have to understand my code, but I also have to understand the intricate bowels of the framework to make it behave correctly. Sure it saves time in simple cases, but I always find what I thought was simple or common is not quite the same as what the framework devs thought.
So I use the MVU pattern. I've used it in Elm and F#. MVU isn't what I would call a framework, although it does come with some pre-packaged functionality (view rendering especially). But it's not quite what you think -- almost all the types and functions you create in MVU are to solve your problems, not to satisfy technical requirements of a framework. Less of the things you learn are non-transferable. And in fact I have learned a great deal from this pattern that I have also applied to the back-end.
The end result is something that is ridiculously maintainable. But there are downsides. The main one that comes to mind is upfront effort to learn. It's different. And since it is a fairly uncommon way of doing things, there is less information than you might like available. And sometimes what is there leads you down less optimal paths. But the great thing is that since it is so maintainable, you are not unduly penalized for those early mistakes. You can fix them -- with some effort, but without much risk. Some people complain that it has boilerplate. Maybe it does in some places or with some strategies. But when I consider the framework wiring boilerplate I don't have to write (or worse, the invisible magic wiring deity that I hope I don't make angry), I think it is roughly equivalent.
I've been meaning to write an article about it, but I've been heads down in a project and haven't had the extra bandwidth.