Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

91–100 of 550 posts

Re: Using a framework will harm the maintenance of your software

#91

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

Are we using different Djangos? Let’s take it for granted you’re using it with HTTP since it’s a web framework (this would all apply with WS). You routes call your views. Your views load your models. These feed into your templates, which go into a response. You can tweak what’s going on at each step (DRF) but there’s definitely a way it’s all supposed to work together. It’s classic IOC.

I use Django with and without HTTP.

All a Django View is is a function (or in the case of a class-based view, a method of the class) that takes a request object and returns a response object... this is pretty fundamental to HTTP, so any HTTP app will do this. Its not Django dictating it, its the nature of HTTP.

You don't have to use any of those parts of Django if you don't want to.

I often opt to use Jinja2 instead of the Django Template Engine. I happen to like the Django ORM, so I usually do use it, but you certainly don't have to, I have certainly used Django without models before. Your views don't do anything with models unless you tell them to.

Re: Using a framework will harm the maintenance of your software

#92
post #23

Earlier quoted context omitted.

> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess. Companies who try to build any type of codebase end up with a mess. Always. No exception. There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to…

> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is

Every single codebase doing anything nontrivial is mess. Show me a code base that you can marvel at it's beauty, elegance, and how neat and tidy everything is organized and one of two things will be true about it.

1. It has never touched the real world, real hardware, or real users.

2. All the mess is hidden in some dependencies that handle the integration points with the outside world.

You cannot escape the fact that the world is full of sharp edge cases, no perfect abstraction exists, all models of the real world are approximate, there is no architecture that survives changes to business requirements, and all assumptions made about the environment where your code runs will eventually be false, which makes a mess out of code that was once nice and tidy.

Re: Using a framework will harm the maintenance of your software

#93
To put it simply, this reflects an amateur understanding of frameworks. I know where the author is coming from, because I've been there/done that/tried that. It sounds nice on paper, but experience has shown that this is a poor way to approach software development.

I see this kind of mindset with developers who think only about code, and not about solving problems at scale with other people.

Re: Using a framework will harm the maintenance of your software

#94

> Companies that have, "A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow," are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers. (formatting edited) 1) I'd like to see real data behind this claim. (feels very anecdata and I have reversely correlated anecdata) 2) Companies that have large codebases or large d…

That's from the state of DevOps surveys. Those aren't causal and define performance oddly.

I'd speculate that companies that benefit from that sort of standardization probably don't care about blindly maximizing deploys/day (maybe nightly plus emergencies is enough) or minimizing time from coding started to deployment finished (maybe a better starting point is when the request is first made, or maybe they're optimizing for development throughout instead).

Re: Using a framework will harm the maintenance of your software

#95
post #50

Earlier quoted context omitted.

No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and…

This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the…

I remember people saying this in a PHP days and almost without fail their code would be littered with security bugs. They don't a template language, and there would be a XSS vulnerability. They don't need an ORM, and there would be a SQL injection vulnerability. They don't need a form library, and there would be a CSRF vulnerability.

Now-a-days there are less security vulnerabilities and more buggy messes powered by Express.JS. API's with shitty query string parsers than crash the server.

The average developer should just be using a framework.

Re: Using a framework will harm the maintenance of your software

#96

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

All frameworks are collections of libraries and that usually means you can import and use parts of the framework. Django is exactly what the author is saying is hard to maintain. And mostly all things Django start via wsgi, asgi or manage.py. As the lead developer on three Django based commercial saas products, there is a trade off. Spend your time reinventing the same basic things or spend your time building your pr…

In my experience its not Django that makes apps hard to maintain. Your experience is certainly valid, it just has not been my experience with it at all.

Re: Using a framework will harm the maintenance of your software

#97
post #87

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

> This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim. Do you really think that there isn't a single person who claims that frameworks are good who has never written an application without one? Well, now you know me. I've tried writing a website without React, and I ended up writing a buggy half-implementation of React. (In my defense, I didn't…

Your comment appears to reaffirm the consequent. Your comment suggests you tried to not use a framework once, but failed only to write a bad framework, which suggests you are incapable of writing code without frameworks. Is there something more to draw from this?

Re: Using a framework will harm the maintenance of your software

#98
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

A framework is what happens when you write a ton of similar apps and factor out the common parts.

The quote here is no more literally true than the original lisp quote, but (just like the original) that doesn't stop it from being true in spirit.

Re: Using a framework will harm the maintenance of your software

#99
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs.

Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this article has an awesome example. There's a snippet of code of a controller checking to see if a User exists with the given email. Any Rails veteran would know that you can just call `User.create` in the controller and rely on validations for that kind of check. But that's another problem with frameworks - you have to know the whole thing in order to use it well.

Re: Using a framework will harm the maintenance of your software

#100
Maintainability is how long it takes you to solve a problem. If the reliability of the framework exceeds that of code you could write then we're limiting the overall scope that must be maintained to begin with. Now on to what issues look like with frameworks, if you use the framework as designed, the code should follow convention - convention improves maintainability. If your framework can't do what's asked, it's been misapplied and another tool is needed. Using a tool improperly is terrible for maintenance
Post reply on HN