Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

Post reply on HN
Print view View original

301–310 of 550 posts

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

#301

Post by magicalhippo »

Using a framework will affect the maintenance of your software. So you need to consider that aspect before using it. If it will harm or hinder you, depends entirely on the specifics of both the framework and your project.

For example, source code availability is a big factor. Is your project short lived, say a prototype, or do you need it working for 10+ years? If the former, source code availability of the framework might not be an issue, if the latter then you certainly want the framework source.

Another point is if you need to track the latest version of the framework for some reason, or can you live with an old version. On Windows for example, you can still use Delphi 7, released in 2002, with its VCL framework to develop applications. Won't look pretty but will work.

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

#303

Post by Someone »

flohofwoe wrote: post #214
valenterry wrote: post #153

Earlier quoted context omitted.

> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end? No, the main difference between frameworks and what you describe is…

I don't agree with this simplistic distinction between framework and library. There are plenty of libraries that call back into user code. A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk, while a library is a much smaller and flexible building block (also a building block for frameworks). But there's a lar…

Another, a bit less gray zone, distinction is that you can have only one framework in your program, but can use multiple libraries.

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

#304

Post by mightyRodri »

throwaway284962 wrote: post #283
quickthrower2 wrote: post #86

Earlier quoted context omitted.

The adhoc framework will also be half known to 5% the current team and barely known outside of happy path use cases to the rest. If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Or chuck in another hack and move the ticket to done and walk away slowly with stretched out arms.

> If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting…

> Which is not so difficult, because that busy person is in the same organisation as you

Hopefully. But not necessarily. This argument is spinning in circles. In house projects can be abandoned just as oppen-source ones can. For me that was Powermock for example.

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

#305

Post by quickthrower2 »

throwaway284962 wrote: post #283
quickthrower2 wrote: post #86

Earlier quoted context omitted.

The adhoc framework will also be half known to 5% the current team and barely known outside of happy path use cases to the rest. If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Or chuck in another hack and move the ticket to done and walk away slowly with stretched out arms.

> If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting…

> Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal.

{evil laugh.mp3}…

Ideally yes but in reality: all teams have bottlenecks, and nearly all teams have assholes. Is fixing your problem on their OKR or whatever.

Free / open source code can be fixed by anyone: the volunteer owner (who you could even bribe to fix it), any contractor with experience, or someone in the org. This is the beauty with free software. It enables people to fix their printer drivers even if they didn’t write it originally.

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

#306

Post by valenterry »

8note wrote: post #278
valenterry wrote: post #260

Earlier quoted context omitted.

I think the last sentence is really true. And yes, there are libraries that call back into user code, which makes them framework-like in this regards. > A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk This is the kind of definition were 50% will call something a framework and the other half will call it a…

This kinda suggests that most node modules are in fact frameworks, in that they accept callbacks. Callback hell however, is not something I'd associate with a framwork

Yeah, if this is not just an once-off async callback (where you could just use a promise) but somthing more complicated, then this is indeed more framework-like and for me would be a reason to try to avoid it.

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

#307

Post by Attrecomet »

theshrike79 wrote: post #175
mmis1000 wrote: post #150

Earlier quoted context omitted.

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

You can affect this by picking the framework properly. The chances of Spring Framework, React or .Net being deprecated are zero to none. Even if they are sunset, there will be a) years of warning b) a cottage industry of open-source options. Or you can hamper your project by abstracting EVERYTHING in your software to be 100% free to switch any library or framework at a moment's notice with minimal work. In essence bu…

Or, as TFA suggests, you separate your concerns with a framework just as you'd hopefully do with other elements of software development. While TFA starts out with strong language against frameworks (as defined in TFA), the conclusion is pretty sound, IMO.

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

#308

Post by wink »

pmontra wrote: post #189
throwaway0asd wrote: post #73

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…

Sometimes I stated writing a web app with Sinatra, which is about the less frameworkish thing you can do in Ruby unless you are also writing your own router. I regularly end up having to 1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord. 2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well te…

Counterpoint, and let's assume mostly parity of flask :: sinatra and rails :: django.

I've usually used Flask and even when I needed a few db operations you could easily contain that to a small part of the code and stepping up to django would have felt like a huge step up in complexity. But I guess it really depends on what you're actually writing - your use case sounds a bit like "something like wordpress" from a "customer uses this" point, and mine were mostly "small REST API endpoint for something".

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

#309

Post by raesene9 »

snovv_crash wrote: post #286
ldng wrote: post #259

Earlier quoted context omitted.

And of course you regularly check back for bugs and security issues, right?

Usually the security issues come from the wrapper code that tries to hammer the square peg of an algorithm into the round hole of the abstraction they provide. Dropping the wrapper code is the safest thing you can do.

I used to be a web app security tester. I loved it when I got an app that didn't use a framework for development because I knew I'd get some security issues for sure.

In the context of web applications, frameworks mean that your devs don't have to be experts in SQL Injection, XSS, SSRF, Session management etc etc etc.

My experience over several hundred tests was that without a framework there weren't many apps that could get that right first time. If they were lucky the pentesters found the issues, if they were unlucky, it was attackers.

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

#310

Post by raesene9 »

goodpoint wrote: post #217
megaman821 wrote: post #95

Earlier quoted context omitted.

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…

> The average developer should just be using a framework. Yes, and the non-average shouldn't.

The tricky part is that many more developers think they're capable of handling all these issues than actually are.

Web app security is a genuinely tricky area with lots of edge cases. Good frameworks provide abstractions that mean you don't have to deal with a lot of those problems for most mainstream cases.

Post reply on HN