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.

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

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.

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.

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:

https://blog.simpleinjector.org/2016/06/whats-wrong-with-the...

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.)

Note that the issues the Krita team ran into aren’t a consequence of frameworks in general, but of the management of the Qt framework in particular (although the entire graphics industry deserves lots of blame of their insane, spurious, and ever-changing APIs). Web browsers have much more difficult problems than Qt and manage to provide a relatively stable developer experience. Further, the issue of “your work has to mirror all of their design mistakes”, I think this is a consequence of depending on someone else to write part of your code, irrespective of whether that code is a framework or library; however, the benefit of libraries is that they are usually loosely coupled such that you can relatively easily swap one out for another (but as previously discussed, I don’t think this is the case for UI libraries in practice).

Sometimes, and sometimes that's a good thing:

- If ones own skills in coming up with a good app architecture are not so great (and that applies to the vast majority of devs). It can't stop bad devs from shooting themselves in the foot, but can help less experienced good devs to avoid straying away and taking wrong shortcuts,

- If ones own architecture style is sufficiently similar to the framework's than it saves time on repetitive, scaffolding work.

IMHO if you build more or less similar type of apps, and you absolutely can't find the right framework for you, then just build your own, save time. Eventually you will end up with something equivalent to the one anyway.

(And by "use" I mean use directly, not through some framework-abstracting metaframework you've written yourself - I think it's very obvious that's going to be a disaster. The whole point of a framework is to abstract over different APIs, so if you have to abstract on top of them then they serve no purpose. It brings to mind horror stories of hand-rolled database engines written on top of other database engines!)

I think your comment leaps directly from "if you can't use a framework directly then you're best off writing your own" (fair point) to "I don't like frameworks at all", without tackling the key bit in middle: how often is it possible to use a framework directly? The truth is, most applications can be built just fine with a framework like Qt. There is a gap between "hello world" and Krita that encompasses almost all practical programs.

Even in Krita's case, with all the pain they've encountered, they're still not seriously discussing abandoning Qt. They're even talking about maintaining their own patch set! Given how much experience they obviously have on the subject I think that shows there is value even in a framework that doesn't fully work for you. (I know that's an appeal to authority but I think there's some value in that argument.)

One compromise is to use a framework like Qt for all the boring bits of your program, like the dialog boxes and window decorations, then write your own wrapper for low-level APIs for the main display area if it needs it. I must admit I'm not sure how feasable this actually is given that something else in ultimately in control of the overall rending - maybe it isn't at all given that Krita doesn't do it.

Over the years, we've had a lot of pain, of course... But then again, a lot of fun, too, and without Qt we wouldn't have been able to create an application like Krita. Every alternative just is worse, much worse.

Meanwhile, C++ lost its full stack status, the only mainstream OS that still offers C++ GUI tooling, is Windows, and none of MFC, ATL or UWP/WinUI APIs are "Boosty".

What keeps Qt relevant as the surviving C++ GUI framework not stuck in 90's tooling idioms are the paying customers, and those have quite clear ideas which compilers and ISO C++ versions they want to have Qt on.

Meanwhile std::string still doesn't provide everything that compiler specific frameworks have been doing since mid-90's.

The problem with Qt not using std::string is when you (gasp!) want to integrate with non-Qt libraries that do use std::string. It has nothing to do with what std::string offers or does not offer compared to any other string implementation. std::string was the string implementation for C++ since before Qt began, and by not using it for their strings, they delivered a significant message about their desire to integrate easily with non-Qt libraries.

But I looked at using Qt in 1999 and easily decided against it, in part for this reason. Those of us coming from a *nix background got the UTF-8 thing much earlier than people affected by the Microsoft worldview.

Thankfully having a *nix background helped Sun getting Java design regarding UTF just right.

Qt, as most frameworks, simply has the ability to get you stuck between a rock and a hard place. It's all a bit of a gamble of course. Similar to writing plug-ins for specific programs or apps targetet at app stores for a living. Someone can just decide to kick you out for no reason. I'm sure Qt doesn't intend to do that, they probably just want to do right by that almost-all-programs group. When you're that popular, ANY decision will hurt a lot of people.

What I'm trying to say is that I wish there was more of an effort in the programming community to avoid these asymmetric relationships. We already make a huge commitment by deciding what programming language to use, which often already comes with a built-in framework or standard library, a package manager and maybe even an IDE. For example, in the .NET world you have to constantly keep up with Microsoft's latest ideas on how to complicate the ecosystem by introducing yet another thing that is supposed to solve all problems at once, including those introduced by the previous attempts. If you're already in one abusive relationship, the last thing you want is two abusive relationships.

Frameworks, on the other hand, are more troublesome. They tend to have one entry point at the top that deals with everything any user might want to do, so locating a fault involves digging through lots of code unrelated to my particular usecase.

You don’t.

What you do is start trying to rescue code by pulling out as many pure functions as you can, and begin converting the rest. The purity doesn’t even have to be absolute - any code that only manipulates one kind of shared state also works. For instance, the body of an HTTP response. By separating the code that makes the request for the code that parses it. This code only mangles (reorganizes) JSON responses from this REST endpoint. It doesn’t care if we are using Swing or QT, HTTP 1.1 or HTTP3. It doesn’t even care if there is a UI or a network call (eg, in a test harness).

MVC is a continuum. You’ll never get all the way there if only for very real performance reasons, but “keep as much of the logic out of the UI as you can” makes sense as long as the visual workflow and the logic behind it agree about what is being done. You get into bad impedance mismatches when someone wants to build an “engine” that solves a different problem than the business has because they find the business kind of boring and decided to engineer it away instead of just moving on, or getting over it.

Before zen: chop wood, carry water.

After zen: chop wood, carry water.

Sometimes it is better to invent a wheel that does exactly what you need, and nothing more. Software is sometimes about NOT reusing code.

Example: object-database mappers making you put database-specific things into your domain entities, or innocently implementing the unit of work pattern. It's right there, all you have to do is let us in!

On a very small development team I've seen a framework be a big help to productivity as there were a lot of little wheels we didn't have to recreate and didn't have to search for a library every time we needed another small feature like that. Certainly there were bumps along the road to learn the nuances of the framework (this is compounded by changing versions of the framework) however those almost always ended up being minor headaches in the scope of a larger feature and maybe extended timelines by a day or two.

I do not want to convey here that my experience is true for every team or every framework, rather that I have had one specific set of experiences with one specific framework that has pulled me from condemning frameworks as a whole while still not being a huge fan.

These days our team is humongous: we have seven sponsored developers!

I think my feelings about them mostly have to do with a lack of control over your own creations on multiple levels. Personally I'm a bit slow and I can't hold a lot of things in my head at once, so all of these nice-to-have code quality principles are actually pretty important to me.

I can deal with a library being a bit of a black box, as long as I can make some basic assertions about it such as which parts are thread-safe, what sorts of exceptions to expect and so on. Usually it doesn't take too long to learn how to use it well enough.

With a framework, the learning part is much more convoluted. The tutorials and documentation are usually written for "task-based" learning, i.e. you have a specific goal and the documentation just tells you which buttons to push, which levers to pull in that case. And stack overflow will fill in the blanks. When your (preferably very small) app is covered by that, you're golden.

But when you're doing something more complex or have a specific issue, you need the "model-based" approach. You need to understand the architecture behind the framework, and usually that means you'll have to read most of the source code with zero guidance. And you'll probably have to wade through lots of code that is only there to avoid some boilerplate in "hello world"-level projects. Most people won't do that, and then they're stuck with an incomplete mental model based on a patchwork of experiences. It can get pretty cargo-cultish sometimes when you end up configuring something you don't understand because in your experience it makes things run better.

I admit that I'm oversimplifying/overgeneralizing and frameworks are popular because they tend to help people meet deadlines. And I use them too. But it feels wrong, like I don't really know what I'm doing.