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

371–380 of 550 posts

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

#371

Post by lll-o-lll »

onion2k wrote: post #233
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.

If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. Or you just carry on using the deprecated version. It doesn't stop working. If your team is sufficiently skilled you fork the framework and carry on developing it yourself. There's lots of options other than just giving up. Besides, how often is a framework deprecated?…

Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit more mature back when you started.

So many of the decisions you make when needing to move quickly at the start of your growth curve, are the ones that slowly kill you after market saturation.

Being able to swap out a db would be nice.

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

#372

Post by bayesian_horse »

baobabKoodaa wrote: post #234
bayesian_horse wrote: post #198

Earlier quoted context omitted.

What even is a framework-free web application? Do you have to write the HTTP server yourself?

The author started their post by defining what they mean by "framework" and it's pretty clear that your snark "do you have to write the HTTP server yourself" is way off from that definition. Also, if you don't have any experience with framework-free web applications - to the point where you can't imagine how one might exist - perhaps it would be a good idea to familiarize yourself with one? Yes, they exist. I've writ…

I don't accept the distinction between frameworks and libraries. Once past the most trivial stages, any codebase uses frameworks, often multiple of them. But they aren't all published or named as such. Often you create them yourself. I have myself written lots of things that work like a framework. Inversion of control is a powerful pattern.

There really is no clear cut difference between a library and a framework. All depends on the mental model what you call what.

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

#373

Post by lll-o-lll »

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…

Just like with Silverlight. .net 1.0, wcf, .net remoting, app domains…

MS told me it was for always and forever!

Cries

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

#375

Post by kohlerm »

Not sure I agree with this . A dependency is a dependency and you should always think about whether you want that dependency. Whether it is a framework or not is not really the important point. The important point is how much does this dependency "lock in". e.g. if inversion of control is a framework "thing", doesn't that in principle minimize the impact of the dependency?

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

#376

Post by saiya-jin »

m00x wrote: post #213
Test0129 wrote: post #130

Earlier quoted context omitted.

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will…

> You're bound to their bugs If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors. Not using frameworks is just an ego problem, or a lack of skills.

I completely agree, unless you are doing something unique, low level where ie latency is the king (which most of us don't), frameworks and libraries shine for 99% of the cases.

Some brilliant folks are just bored by usual rather generic work, and their idea of 'fun' is to keep reinventing the wheel that specifically fits current problem. Actual benefits to business be damned, intellectual fun is more important. Once those folks leave (and they always leave eventually), its mayhem for the remainder of the team/company.

For me, this kind of 'autistic' brilliance is overall just professional incompetency that shows over long time period and I avoid hiring such folks. One can babysit them and steer them but its rarely worth it within usual teams.

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

#377

Post by Lukas_Skywalker »

inopinatus wrote: post #201
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…

Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether…

I‘d say Rails is a combination of framework and libraries.

Some parts (ActiveSupport, the part that simplifies e.g. date calculations) are clearly libraries. They can be used outside of Rails as well, because they totally ignore the shape of your other code.

Other parts (ActionPack, the component that calls your code depending on the incoming web request) are working like a framework. Your code must adhere to their requirements, otherwise it won‘t work.

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

#378

Post by lll-o-lll »

spion wrote: post #350

I agree that there is a problem here, but I think its a slightly different one. Frameworks and libraries both save you time and require you to invest some time. The main question is whether the savings will be bigger than the investment, and that question can be hard to answer. In most cases we tend to err on the side of framework optimism - we presume a framework or library will always save time (don't reinvent the…

Thanks for taking the time to write this insightful comment.

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

#379

Post by lotam »

ensignavenger wrote: post #70
couchand wrote: post #36

Earlier quoted context omitted.

The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in…

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…

I do agree with that, problem is all the other django-related packages that come with it, especially Django Rest Framework (framework is in the name here). I like some parts of it, e.g. Authentication, permissions, but IMO we often have to bend our code so it fits DRF views, and above all their serializers (which I despise). Obviously we could drop this part of DRF, but it would mean to drop DRF entirely, and I'm not sure everyone is ready to do just that.

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

#380

Post by lotam »

srcreigh wrote: post #144
ensignavenger wrote: post #70

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…

The Serializer class is the worst frameworky piece I know of. These are basically classes which force you to use overridden methods to link HTTP with DB operations. Requires tons of hacks to work around all the time. And just cuz it’s optional doesn’t mean it’s not frameworky. A solid platform just wouldn’t offer any frameworky elements.

Aren't you talking about DRF's Serializers ? Django itself does not have serializers. But otherwise, I completely agree with that statement.
Post reply on HN