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

381–390 of 550 posts

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

#381

Post by Joel_Mckay »

lll-o-lll wrote: post #371
onion2k wrote: post #233

Earlier quoted context omitted.

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.

Large firms have the resources to overhaul infrastructure, and even with a project failure rate of 54% often manage to complete migrations.

Only small shops get hit hard when things go wrong.

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

#382

Post by onion2k »

lll-o-lll wrote: post #371
onion2k wrote: post #233

Earlier quoted context omitted.

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.

That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem.

You don't need a wrapper that understands the APIs for different databases when you're only using one database. What you need is to think about how you write your code.

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

#383

Post by hnfong »

hsn915 wrote: post #50
matthewmacleod wrote: post #40

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 was going to counter your claims, but I found a comment a couple days ago that perfectly sums up what I was going to say: https://news.ycombinator.com/item?id=33148071

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

#384

Post by theshrike79 »

lll-o-lll wrote: post #373
theshrike79 wrote: post #175

Earlier quoted context omitted.

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

Silverlight was around for 12 years (9/2007 - 1/2019). Not exactly a shooting star.

It was technically better than Flash in every way, but the Internet was in its "Micro$oft bad!" -mode at the time and shunned everything they made. They also took a bit too long to provide proper clients for OS X and Linux.

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

#385

Post by snovv_crash »

raesene9 wrote: post #309
snovv_crash wrote: post #286

Earlier quoted context omitted.

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 c…

A library could work here too, to turn off the footguns and provide safe tooling. No need for the library to also intercept all of the DOM callbacks for you as well.

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

#386

Post by mobiuscog »

Someone wrote: post #303
flohofwoe wrote: post #214

Earlier quoted context omitted.

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.

In the Java world, at least, you can absolutely have multiple frameworks in your program.

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

#387

Post by Joel_Mckay »

theshrike79 wrote: post #384
lll-o-lll wrote: post #373

Earlier quoted context omitted.

Just like with Silverlight. .net 1.0, wcf, .net remoting, app domains… MS told me it was for always and forever! Cries

Silverlight was around for 12 years (9/2007 - 1/2019). Not exactly a shooting star. It was technically better than Flash in every way, but the Internet was in its "Micro$oft bad!" -mode at the time and shunned everything they made. They also took a bit too long to provide proper clients for OS X and Linux.

If I recall it was mostly the DRM and codec-licensing that strangled most projects.

Silverlight itself was actually relatively good at the time, but HTML5 media tag standardization made it along with Real-player, QuickTime, and Flash effectively obsolete for their primary use-cases.

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

#388

Post by jokull »

The criticism is mainly on last-generation frameworks that came around before React and the like. They bundled together an all-in-one approach to writing web apps. Django comes with an admin tool!

The world has largely moved to richer frontends so stacks are more flexible.

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

#389

Post by BlargMcLarg »

throwaway0asd wrote: post #366
piokoch wrote: post #265

Earlier quoted context omitted.

Where do you draw the line between using and not using framework. Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests. Same with database conne…

It appears you are falsely using the word framework to describe abstraction . Language is not a framework. APIs are not frameworks. A framework is a tool providing conventions that dictate exactly how to proceed, typically demonstrated as a packaged architecture. The appeal, it seems, is not having to independently form many minor decisions. It appears bias, and possibly even neurological limitations, largely account…

>The appeal, it seems, is not having to independently form many minor decisions.

No. It's also to make the work easier and do the heavy lifting, too. Conventions alone are useless if the work becomes more difficult.

It's a vague term but it is pretty darn obvious what the desired intent is behind frameworks and why the endless discussions on their costs and benefits exist. Frankly, most developers couldn't care less about the semantics, they only care if the outcome is beneficial.

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

#390

Post by pjmlp »

vidarh wrote: post #367
pjmlp wrote: post #362

Earlier quoted context omitted.

CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.

The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).

At which point it is no longer C, rather a programing language that vaguely resembles ISO C.
Post reply on HN