The devil is in the details. From experience, upgrading framework code is time-consuming. It's mainly because frameworks have a layer of architecture that you app needs to adhere to. When the architecture changes, so must the app.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).
Comments
The devil is in the details. From experience, upgrading framework code is time-consuming. It's mainly because frameworks have a layer of architecture that you app needs to adhere to. When the architecture changes, so must the app.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
"When you roll your own, that is a non-issue."
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).