6 ms·

This may be a bit of an extreme view, but I don't like frameworks at all. In general. They are nice for little "hello world" applications that demonstrate how

• ivanhoe 6y ago
  > 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.
  • Netcob 6y ago
    Good points! If you're making one small app after the other, frameworks save some time and effort.
• chrispauley 6y ago
  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.
  • Netcob 6y ago
    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.
• kd5bjo 6y ago
  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.
• quietbritishjim 6y ago
  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.
  • boudewijnrempt 6y ago
    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.
• jasode 6y ago
  >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 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.
  • Moru 6y ago
    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.
    • dagmx 6y ago
      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
      • freedomben 6y ago
        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.
• hohenheim 6y ago
  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.
  • thinkingkong 6y ago
    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.
  • flr03 6y ago
    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.
  • Netcob 6y ago
    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!
• throwaway894345 6y ago
  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).
• hinkley 6y ago
  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.
• deleted 6y ago
  [deleted]