>This may be a bit of an extreme view, but I don't like frameworks at all. In general.
I don't think giving an opinion such as "I don't like frameworks" without any concrete source code of non-trivial projects is productive discussion. (My previous comment about "unnamed invisible frameworks" : https://news.ycombinator.com/item?id=14172165)
>They are nice for little "hello world" applications that demonstrate how easy it is to create and deploy a new project,
It's the opposite. A good framework that fits the problem domain does a lot of low-level gruntwork that frees the programmer to focus on higher-level tasks.
It's not libraries OR frameworks. Real-world complex applications can use both.
One of the problems with using a framework for a non-trivial project is that you get locked into the framework. If the framework decides to change something in an update that you depend on, it can mean non-trivial rewrites unless you could expect the development already. Most frameworks tries to be close to 100% backwards compatible and grow in complexity because of it. Others change a little at a time. And then some does big breaking changes or rewrites and calls it version 4.0. That makes it increasingly hard to find help online.
It really depends how you structure your code. While my Qt apps are very much coded against Qt, it’s actually pretty easy for me to currently switch them to other UI frameworks as needed. I’ve done this with some of my bigger tools going to other frameworks.
If you keep your logic separate from your UI, and interact via method calls, it’s not very hard to swap out the underlying object. Arguably, it’s the pattern Qt encourages anyway so that you can flexibly change your UI design in the future
> While my Qt apps are very much coded against Qt, it’s actually pretty easy for me to currently switch them to other UI frameworks as needed.
Are yours apps open-source or do you know some architectured in the same way ? Curious and interested to dive into a well designed Qt application with logic and UI separation.
Second this. I love context-based organizations like newer versions of Phoenix default to. I've been using that in apps for years.
Basically all of the application UI is in framework-independent code. When plugging in the UI portion, you never do logic on stuff, you just call functions/methods to get it done.
It's not perfect, but it makes it much easier to port to a different framework/toolkit in the future.
> I don't think giving an opinion such as "I don't like frameworks" without any concrete source code of non-trivial projects is productive discussion.
Fair enough, even though it's hard to point to a specific piece of code when talking about such abstract concepts. And I'm not working on any open source projects.
My go-to example is dependency injection and ASP.NET Core. For the most part, I really like the features and it's mostly okay as a framework, even though I'm not sure why it has to be one. When I started taking clean code and DI more seriously, I learned that ASP.NET Core gets these things wrong in a subtle way that turns the whole idea of DI into a bit of a farce. This post explains it really well:
I wish there was an easy way of removing the "framework" aspect from that thing and just have a bunch of libraries for handling HTTP requests, rendering pages, dealing with security and so on.
> A good framework that fits the problem domain does a lot of low-level gruntwork that frees the programmer to focus on higher-level tasks.
I agree that this is a noble goal, and I'm sure there are plenty of frameworks that are good enough. But sometimes you don't have a lot of choice, and in the worst case all of the useful libraries for your domain depend on a framework that you don't really want to use.
> It's not libraries OR frameworks. Real-world complex applications can use both.
I think they'll be using libraries either way. But they do have a choice whether to be completely dependent on a framework, and that's a pretty serious choice to make if it's a long-term project.
> My previous comment about "unnamed invisible frameworks"
I don't have a lot of experience with JS other than playing around with it every few years and discovering that none of the things I used last time are in use anymore. It scares and confuses me. But yes, if you write a lot of similar software projects, a framework is probably the way to go if you want to avoid writing the same low-level stuff that has been better written and definitely better tested by the framework people.
And yes, writing my own "invisible" framework is a bad idea, in my own experience too!
But that's why I'm trying to move away from the whole concept of having my code in some sort of harness in the first place. A lot of the repeat-y stuff can be handled by libraries just fine!
Framework, singular. Frameworks takes over the architecture of your application, I don't think they can be compatible with each other. I mean, you can use a QList from Qt alongside an std::vector from the STL, but good luck making several MOC systems coexist.
You pick one framework, stick with it, and die with it. (Or you're stuck with the latest unmaintained version.)
I write big complicated applications and I write all my frameworks myself. (I'm a one person team) It is very much doable. You can check out my frameworks at: gamepipeline.org
I don't think giving an opinion such as "I don't like frameworks" without any concrete source code of non-trivial projects is productive discussion. (My previous comment about "unnamed invisible frameworks" : https://news.ycombinator.com/item?id=14172165)
>They are nice for little "hello world" applications that demonstrate how easy it is to create and deploy a new project,
It's the opposite. A good framework that fits the problem domain does a lot of low-level gruntwork that frees the programmer to focus on higher-level tasks.
It's not libraries OR frameworks. Real-world complex applications can use both.