Live data from Hacker News

Frameworks are for hacks, libraries for seeds

sencjw.com

11–20 of 50 posts

Re: Frameworks are for hacks, libraries for seeds

#11
post #5

When you're using libraries, you're actually making your own custom framework. Because a framework is basically a set of libraries that work together to help you get to a certain goal. If there's already a framework that helps you get to a certain goal, it can save you a lot of work to use that existing framework instead of making your own. It can also save you a lot of security issues. But if your requirements don't…

You call a library, but a framework calls you.

A framework IS the entry point to your application. If you use libraries you write your own entry point.

Re: Frameworks are for hacks, libraries for seeds

#12
post #10

Frameworks are also good in a long run. When a new member on the team starts to work on a project, it is much easier to pick up on some popular framework like Rails than your own one. First, because you can easily find a guy who worked with Rails framework and knows it inside out, unlike yours custom-written one. Second, the whole infrastructure, like regular updates, documentation and community is also a major facto…

> because you can easily find a guy who worked with Rails framework and knows it inside out

That's only relevent when you are hiring someone to deal with the monstrosity of a rails app that you ended up with because the abstractions didn't quite work for the problem you were trying to solve.

I've found it very easy to use some Rails best practices in a Sinatra app and not have to deal with all the routing/controller cruft in Rails, while still getting sensible filesystem conventions.

Re: Frameworks are for hacks, libraries for seeds

#13
I think this is also about choosing your battles wisely. When you build something new you will find it is hard. You will have a lot of flexibility choosing how to go about it. It's not necessary to reinvent the wheel on every front. That's why I love frameworks (Bootstrap, Ruby on Rails, templates, even spreadsheets for business plans etc.).

Frameworks quickly allow you to go from 0-80% without having to start from scratch. You just take something that already exists and then fill in the gaps with your values, colors, content etc.

I agree with gitaarik that in the grand scheme of things libraries are also like a framework.

Re: Frameworks are for hacks, libraries for seeds

#14
The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. It gets especially tricky if one library uses a garbage collector, and another library uses a different one. You could get cycles between objects managed by different libraries, which would never get collected (ouch!)

But in any case, I prefer that over working with a framework. Frameworks pretend to have everything figured out, but in reality they have not, and they are a pain to work with if you deviate the slightest from the "master plan".

Also, libraries are more easily replaced than frameworks, which is a huge advantage. And they invite you to think modularly, rather than monolithically, which helps to keep complexity down.

Re: Frameworks are for hacks, libraries for seeds

#15
If indeed that's the case, then welcome to the era of the quick hack.

From the nanosecond the user hits the power button on their little box, and the BIOS loads 0x7c00 and executes it (loosely defined, frameworks call your code), we're in framework world.

You want your browser loaded? Better hope that the user clicks it, and the OS calls your code, because otherwise you're malware (and you were still loaded by the OS). Want users to visit your site? Unless you're a virus, you're gonna have to wait for their browser to navigate there. Another framework.

The idea that frameworks are not for writing software to me is just ridiculous. It's the only way useful modern software can be written. Unless of course you yourself have created the hardware, OS, and layer upon layer of userland software that you're going to rely upon, you really need to acknowledge that your code is 99% dependent upon frameworks.

Re: Frameworks are for hacks, libraries for seeds

#17
post #11
post #5

When you're using libraries, you're actually making your own custom framework. Because a framework is basically a set of libraries that work together to help you get to a certain goal. If there's already a framework that helps you get to a certain goal, it can save you a lot of work to use that existing framework instead of making your own. It can also save you a lot of security issues. But if your requirements don't…

You call a library, but a framework calls you. A framework IS the entry point to your application. If you use libraries you write your own entry point.

And there's exceptions to each case.

I can see the distinction that people are trying to make here but it's far from a binary one.

Re: Frameworks are for hacks, libraries for seeds

#18
post #10

Frameworks are also good in a long run. When a new member on the team starts to work on a project, it is much easier to pick up on some popular framework like Rails than your own one. First, because you can easily find a guy who worked with Rails framework and knows it inside out, unlike yours custom-written one. Second, the whole infrastructure, like regular updates, documentation and community is also a major facto…

> because you can easily find a guy who worked with Rails framework and knows it inside out That's only relevent when you are hiring someone to deal with the monstrosity of a rails app that you ended up with because the abstractions didn't quite work for the problem you were trying to solve. I've found it very easy to use some Rails best practices in a Sinatra app and not have to deal with all the routing/controller…

[deleted]

Re: Frameworks are for hacks, libraries for seeds

#20

Great article. It puts into words something that I've been feeling for many years, but have been struggling to express. It's not that frameworks are bad; they quite clearly have their place. It's that they are short term hacks, and as such there is a time and a place for using them, but they aren't a long term solution to a problem.

I couldn't disagree more. The more long term a project gets, the more you should have other people on hand. Using frameworks significantly shortens the ramp-up period for potential partners/employees, turning months or years into weeks.
Post reply on HN