Hacker News Reader

>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

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.

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

Unfortunately none of my Qt code is open source.

> 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:

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!

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

> It's not libraries OR frameworks

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

This is probably a reasonable sentiment in the abstract, but in the concrete instance of UI development, what are we to do? Are there any production quality UI libraries? There are certainly many primitive libraries that can be composed to build a UI library; however, these are largely written in C, so even integrating them into your build is a Herculean effort, and further these tend to be very specialized (accessibility, text rendering, etc) such that you need to be an expert in each sub domain simply to parameterize them correctly. Further still, I suspect there is a lot of cross-cutting concerns, for example, the text rendering library must work well with whichever rendering approach you take for rendering other widgets, accessibility is not easily decoupled from your layout engine or widget library, etc. How much of this is reasonable to take on before it’s more reasonable to throw in the towel and use a framework (or worse: a whole browser)?

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

> The worst thing about frameworks is that they force their architectural style on you.

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.

Good points! If you're making one small app after the other, frameworks save some time and effort.

But if you can use a framework then that is going to save you a ton of work, both upfront and in maintenance costs. Since developer resources are almost always limited, that means you end up with more time left over for actual application features.

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

When I started working on Krita 2003, it was already using Qt, of course, so I didn't have much of a choice -- if I wanted to work on Krita. But then, in a nice piece of circular reasoning, I choose to work on Krita because it was using Qt. Back then, I only knew Java, and Qt made C++ look like Java. One of the big problems I see in Qt is how the Qt developers are somehow ashamed of that heritage and want to make Qt steadily less Java-y and more Boosty or std-y.

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.

It is not that they are ashamed, rather Trolltech made a series of decisions that make sense in the context that Qt was originally designed and the C++ compilers used by the demographic of paying customers, which does seat well with ISO C++ of all things crowd.

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

I’m a QWidgets guy, I understood what he is saying.

Qt isn't a compiler-specific framework.

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.

Meh, having used Qt since 2000, I've never found that a problem in practice. After all, there've always been conversion functions.

Qt not using std::string made a lot of sense when everyone though UTF-16 was the future. A 16 bit default string type was just what modern i18n friendly language or framework had to have. It’s only in the past several years with the rise of UTF-8 everywhere that it looks like a mistake.

I'm not questioning your perspective.

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.

Ah that is why C excels in localisation and internationalisation.

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

2003 was a long time ago: C++ has evolved, Java has stagnated and is falling out of fashion, and many traditional Qt peculiarities like nonstandard strings and collections or the custom preprocessor have gradually transitioned from idiosyncratic but justified to unreasonably antiquated and possibly unacceptable. I think making Qt as "Boosty" as possible is necessary for it to remain relevant.

Might be failing out of fashion, yet Microsoft just bought a Java company, is now an OpenJDK contributor and is one of tier 1 languages at Azure and Amazon SDKs.

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.

I probably came across as a bit too rant-y. I'm not blaming anyone for using frameworks and I use them all the time myself. And I'm definitely not criticising Krita for using Qt.

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.

My rule of thumb for pulling in an external dependency is whether or not I’d be willing to maintain a private copy myself. For most libraries, that’s a yes— they have only a few entry points that my program uses, and it’s (relatively) easy to step through the execution path from there until finding the problem.

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.

It’s kind of the same advice as for adding tests to a Big Bal of Mud project:

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.

Very much on point. If the core of your business, or application, depends on external code, you are taking a huge risk integrating it into your code base.

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

This is not true in most cases. Most situations rely entirely on integrating 3rd party code, and the risk to the business is zero. Most tools and services dont last long enough to justify reinventing the wheel.

Absolutely. Sometimes it feels like some projects want nothing more than stick their tentacles into your business layer. I don't have a lot of OCD but that sort of thing definitely triggers it.

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!

The re-inventing the wheel thing always starts with good intentions and works fine until you have to throw in hundreds of hours to maintain a beast that nobody likes but everybody has to use. You end up being locked in your own solution and instead of blaming your supplier you can blame yourself.

I tend to agree with you but I do think it depends on a lot of factors like team size, churn rate of that team, how long the project will exist, etc.

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.

I agree, frameworks can be beneficial to productivity.

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.

Krita started in 1999, but back then, there was no discussion at all; Krita was a KDE project so it would use Qt. The project was actually created because of a bit of ruckus over a patch that integrated Qt with GIMP.

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