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 really connect to the things existing frameworks provide, you'll have to build your own custom framework by collecting all the libraries you need and making them work together the way you want. Maybe you can make a framework out of it so the next person that has the same requirements as you doesn't have to go through this process again.
In Flask, you call the framework, then it calls you back etc. It is a minimal framework that you can use as a library along other "plugins" (which are libraries in fact) you like.
A framework is a set of decisions that have already been made for you - which might include 'we should use these libraries', but could also be 'we'll put our CSS files here' or 'all URLs will look like this'. That can be a huge help - unless any of the decisions are wrong for your use case.
Deciding to use a library might, of course, also force some other decisions, because the library has dependencies, but the decisions should be more constrained than they are for a framework.
If you're going to not use a framework, then end up creating a framework, then you've defeated the point of not using a framework and you might as well have used an existing framework and saved yourself the effort.
It's entirely possible to build applications without infecting it with anything that looks like a framework if you resist the urge to create unnecessary abstractions and keep coupling to an absolute bare minimum. Keep it simple and focus on the task at hand.
Because a framework is basically a set of libraries that work together to help you get to a certain goal.
Arguably a framework is a lot more than just a set of libraries - it's a formal specification for how you layout your code, from what directory you put a class in to how you do your database migrations. Dropping a few libraries in to an app won't make you work in a specific way. Using a framework will.
Frameworks tend to be more tightly coupled than libraries. They impose more opinion onto your code and make it harder to achieve modularity. They also tend to show up in languages which lack critical features for achieving proper modularity.
It depends whether the framework is based on IoC containers or not.Rails and Django certainly are what you describes,Symfony 2 isn't.
Truth is,with dependency injection, one doesn't need a framework.But most people writing Ruby or Python apps don't understand the value of a registry that lazy-loads objects and it's dependencies.They mix module systems with IoC .
> Because a framework is basically a set of libraries that work together to help you get to a certain goal.
In theory, sure, and as another poster said that's exactly what the PHP-FIG (PHP Framework Interoperation Group) have achieved over the past year or two. However, in practice, the big frameworks that most developers and employers use give you much more than just a set of easily plugged together libraries, typically enough more that you end up building software on-top of that framework, and extracting your product out onto another or swapping a library out becomes nigh-on impossible.
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 factor.
Having worked professionally for several companies who had 8 to 10 year old proprietary code bases, I'm a big fan of using frameworks for web development.
If a company isn't going to use a framework, they had better architect and spec out their app with heavy documentation. I would argue this is more for the stability and future of the app and company than it is for ease of hiring purposes.
Without a spec or framework, you run the risk of ending up with various styles of code (often times some really terrible stuff) sprinkled throughout the codebase, constant arguments between devs (as there is no established standard within the code) and a mountain of "tech debt".
> 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.
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.
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.
This is a real problem, certainly. In very bad cases (anyone remember programming COM from C++?) the burden of making a simple function call from one part of your code to another can be soul-destroying.
This is why I think the modern kitchen-sink standard libraries might be missing a trick. Instead of trying to provide everything out of the box, often to an acceptable but not best-in-class standard, what if our programming languages concentrated on just establishing conventions and providing universal tools with relatively small standard libraries, and then emphasized tools to connect different libraries from other sources together? That is, could they make it easier not just to import modules from different libraries but also to convert data types and match calling conventions and initialize/close down run-time systems?
Plenty of ideas have already started down this path, from implicit type conversions or coercion to full-blown lens libraries, simple calling convention annotations to full-blown FFIs and wrappers, and so on. However, to my knowledge, no mainstream language today has an explicit design goal to make integration of multiple modules that have related functionality but different conventions as easy as possible. I wonder how far we could run with that strategy.
This is the idea of my current language I'm brainstorming: modules as the central unit of design. I want to figure out how to encourage developers to write software as a collection of loosely coupled modules, rather than monolithic blobs. I hope that a module-centric design would let us make assertions about types, purity, and other FP-esque things.
Right now it's just in the "I'd like this and this" stage, but I hope to work on it more this year.
Sounds interesting, and I wish you luck. I think if we had more and better options for gluing together good quality modules, some of the related arguments that push towards frameworks over libraries today would also be diminished. Then we could make decisions based on the fundamental frameworks vs. libraries question of you-call-us or we-call-you, without any bias from what should ideally be independent questions of consistency and interoperability.
Libraries by definition have a narrower scope and hence are more easily adapted to new situations.
Frameworks by their nature affect the whole codebase.
This is the low-coupling/high-cohesion benefit of libraries as seen in many places in software engineering.
A codebase with low coupling is inherently more flexible and maintainable. Libraries and well defined, sensible interfaces are critical to good engineering.
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.
Depends on the problem. If my problem is that I want to sell stuff on a website, or have a blog that lets me promote my organisation, etc, then a framework is a great solution even in the long run.
I agree with the sentiment of the of the article. Dependencies should be isolated and not spread out all across your application. Even though both don't have tight definition, I think it's fair to say that a framework is usually larger in scope and API surface area than a library and usually impose a certain way of coding (and toolchain) on you. Isolating your dependencies (gui, persistence, ...) is a lot easier when you use a small library than using a framework that pretends to have all the answers.
It is true that you have to lay out more infrastructure yourself working this way but I feel that this is a really good thing because it makes you really think about the problem you are trying to solve, and don't just think in terms of the patterns your framework offers (e.g. MVC: "I have some logic, so I'll put it into a controller!"). This usually leads to code that is a lot easier to understand and is easier to test. Also, every application is different and with the framework way of doing will always end up having to shoe-horn things.
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.
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.
On the contrary, if the only connection between my code and the kind of "framework" you're describing is the entry point, my code is 99% not dependent upon frameworks. I am free to structure the remainder however I wish and to incorporate libraries on my terms wherever reusing their code is helpful.
Even if those libraries might encapsulate some functionality that calls back to some OS API, they do so when I want to use that functionality, not when the OS requires me to make that API call. So for practical purposes I don't think your analogy between system/platform software and frameworks holds at all.
Alright, to be more strict, let me quote the definition per Wikipedia:
> In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. [1]
I fail to see how I'm stretching this definition at all, especially if you read further into the wikipedia article. I believe it's critical that I acknowledge when I'm wrong, lest I stay stagnant in my understanding, but I don't think I'm wrong here, unless somebody wants to point out a specific area.
Userland software customizes and reuses default behavior of the OS for application-specific purposes. Web pages customize and reuse default behavior defined by the HTML, CSS, and JavaScript specifications. Same goes for Operating Systems on top of the BIOS and on top of the hardware itself.
Frameworks are useful, basically unavoidable, and critical to take the time to understand if we're going to be effective at any level, be it consuming them or providing them.
It depends on the language. For example, in PHP there's the 'framework interop group'[1] who are working on a set of standards that enable developers to easily take code from one framework and use it in another (so long as it's written to the standard). Framework modules become libraries. So you choose the framework that suits your project best, develop your code in that style, but you're able to pull in modules from other frameworks as and when you need them.
It seems to be a really good idea. It solves the exact problem that the author has.
I’ve heard this argument over the years many times. It’s actually a hard discussion to have the more general the terms that are used. What exactly is a “Framework”? When does a library cross the boundary and become a Framework? What is the original author’s definition of “develop software”? That perspective matters here, because if what he’s saying is create a novel solution to a problem that hasn’t been solved before, that is a lot different from creating a webservice that inserts or retrieves some data from a database. Frameworks are essentially just a tool to get the job done. Some are better than others, and they come in all sizes. You really have to get specific to have a discussion like this that makes sense. If I tasked a Java developer with building a webservice that took some information and put in a database, I could reasonably expect them to use some implementation of jax-ws or jax-rs. If used properly those frame works are very powerful and convenient. Most implementations are well documented, and the communities around them are vast and experienced. Assuming the programmer was relatively experienced and had somehow never heard of either of those frameworks, I might expect some kind of servlet solution (arguably still a framework). Now if what the author is saying is that building a webservice isn’t development, that’s a different discussion. Many paths are heavily traveled. Using a Framework if you have to follow one of them is taking advantage of the knowledge gained by a large number of people that have already made the trip.
There is some truth to what the author is saying. Frameworks do tend to be opinionated, and they will tell you to write your code in a particular fashion to play nicely with the rest of the kids in the framework's playground.
However, I think there's more here that the author skirts around. He laments the fact that "in-fashion" changes to a framework force you to refactor your code. I'm not so sure that this is purely a negative thing. Let's take the upcoming Laravel 5 as an example; on the face of it, Laravel 5 is a drastic departure from Laravel 4.2. The directory structure is completely different, and the way you interact with The System is changing in a subtle but significant way (middleware). Is this cause for consternation? Perhaps. It requires developer time to upgrade, which is not free. But the gain is twofold: you benefit from using newer and, ostensibly better, structure around your app; and you grow as a developer, because you learn a new way to do something familiar.
I'm not saying here that the author's assertion that this is unnecessary is incorrect; just that there are benefits to being forced into change.
Also, regarding libraries: just because two libraries deal with the same topic or technology does NOT guarantee that they'll make the same assumptions about abstraction. Even on the device driver level, you can't take that for granted.
The first few truly complicated frameworks I learned were very useful. IIRC, they were Borland's OWL, MFC, Win32/kernal stuff, and .NET internals.
They were useful because learning them and walking through code while debugging showed me all sorts of best practices (and worst practices). When I wanted to use the GDI I grabbed a handle, basically a hash in a lookup table somewhere. This made sense. When I was programming custom VBX controls, I used the USER part of the WM_ space and sent messages back and forth. Loved the message loop paradigm.
But then something funny happened. Frameworks no longer helped me complete a complex project, they actually got in the way of doing it, by adding a lot of intellectual overhead for very little return. I started seeing new programmers pick up some training, start using a framework, and then get completely lost when their work took them anywhere off the "happy path". People would spend a hell of a lot of time learning framework X, only to eventually realize that the next job required framework Y.
As I got older, my recall isn't what it used to be, which actually turns out to be a good thing -- it forces me to focus on important things instead of minutiae. I got much more radical about web apps. I'm happy with static web pages that are interactive for most everything. I don't code things that do deep-dives into the guts of the stack. I'm looking to provide the most value in the least amount of time (and cognitive overhead). I moved to pure FP.
So now my order is: 1) Code it myself, 2) Use a precanned library, 3) Use a framework
The frameworks I use are very small: JQuery, .NET, maybe one of two others. I like it that way.
It depends what you're developing. If you develop a product (startup) that will change the world, you spend a lot of time, you put your heart into this product, you should understand every line of code, so you develop a product not framework. If you create site by site every week or day for your clients, you need a framework.
Or, what you are building requires somewhat complex components, but you'd rather focus on something else? Many frameworks have their own component libraries.
It has extremely powerful feature set (based on the other features of the framework) out of the box and you can very fast switch your focus on other things besides re-implementing the wheel.
I simply haven't found some of these things as simple libraries. They nearly always come within complete frameworks, because they have had to implement a lot of stuff that really just requires other features from frameworks. And, no, I'd rather not spend a year implementing that feature set.
Frameworks are great for startups. Before market fit, they make it easy to quickly build (and tear down) functionality. Afterwards, they make it easy to integrate new members into your team. At either stage, you don't want to spend your time reinventing the wheel or teaching the intricacies of your bespoke wheel to someone else.
I wouldn't really trust a Haskell programmer to be able to identify a hack.
There are a lot of platitudes here whirling around a central point: Frameworks are more restrictive than libraries.
But, omgwtf, that's exactly the point of frameworks - they enforce convention in exchange for faster development. Also, newsflash, any large software project is going to have its own conventions. Okay, so, if you're still following me, get ready to take a leap. What if we have conventions that can apply to more than one project to reduce the ramp-up time for programmers to contribute?
The neophytes on HN eat this kind of stuff up, without ever considering that the thing the author is whining about is exactly the intent.
In my personal experience, with any non-trivial application with continued (read as multiple years) of development frameworks tend to get in the way (I want to do this, but the framework wants me to do that even though this is better for my use case).
Building your own "framework" from a good collection of libraries tends to not have this problem. Also, if it does have that problem (this library is getting in my way) you can usually more easily exchange the library for a different one.
Note that developers tend to disagree on the definition of framework. When I say framework i'm saying something like Rails or Django that is a big monolithic thing that your application is built upon.
That's one of the reasons I like the Node ecosytem: the culture is really about finding the right library and designing clean interfaces so that you can switch when you need to. Having worked with Grails in the past was such a pain in comparison ...
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.
You never needed a framework until recently when you had to deal with the conceptually disjoint modern web and the pile of languages it takes to do anything reasonably complex. We never had to use frameworks when writing against Win32, Swing, iOS, Android, etc. Certainly, there were frameworks -- such as MFC. But they quickly fell out of favor because the structure they imposed wasn't helpful at all. (Way back when, we figured out that the framework superclass is an anti-pattern.)
Win32, Swing, iOS, et al aren't really frameworks in the same sense that something like Rails is. Win32 doesn't care if you name your code something that clashes with The Revelation Given To Great Prophet DHH; all it cares about is that your WNDPROC behaves like it should. The OO variants of this only care that you derive your UI classes from the framework's classes so you can be notified of relevant events. Nor did these old 'frameworks' (as often incorrectly stated) prescribe the underlying architecture. They didn't force you into MVC for every single project, they didn't force you to use a database for persistence.
Monolithic frameworks are a modern fetish; borne out of a Stockholm Syndrome for the Business: "how will we hire easily replaceable workers?" / "how will we spin someone up in the minimum amount of time?". The answer: programming by MadLibs.
Developers advocate for them because they provide immediate gratification for doing very little work. They confer a mediocre architecture on all projects, which is perceived as preferable to the hard work of designing and architecting a system from scratch. They are a form of blame-shifting by developers: they can offload some of the risk and the Hard Parts of development to a Smart Person/The Community and run to them for help when it breaks. This is not a bad thing, but it does stunt the design impulse, and limits their growth as developers.
In the case of Rails, choosing Rails is no guarantee of project quality, or even conventions. Are you using Postgres, Mongo, or a combination of data stores? If it's the latter, then AR's transactional niceties are out the window! Are you using regular Rails views, presenters, or decorators? When you structure your controllers, are you using The Rails Way (fat models), or services, or more Bernhardt-esque design (app lives in lib/)? All of these things require spin-up time to learn the where and the why.
I do think frameworks are a symptom of propping up conceptually weak abstractions (e.g. the web) and languages. It should be concerning to you that all the metaprogramming in the world + a fully dynamic runtime cannot produce a framework that makes it easy to produce minimally coupled run-of-the-mill business software that doesn't require horrendous hacks like Rails' Spring.
Buy a copy of Growing Object Oriented Software, Guided By Tests. The author builds something sans framework, letting the construction of the software guide him to the best design. The resulting software is lean, supple, and easy to extend.
If you work in a company with 10 different teams that all do different things and all need to develop different applications that work together, you need a framework.
If you want to leverage an existing fully-functioning suite of interoperable function abstractions to extend a small amount of custom behavior in a minimal amount of time, you need a framework.
This whole article is ridiculous because it's essentially comparing using an existing product to developing a new product, and calling the former a hack, and the latter some sort of higher art form.
Also, of course Win32, iOS and Android aren't a framework - they're platforms. You still have to build a framework for the platform. And Swing isn't a framework either, it's a toolkit; you use it to write software for a 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 really connect to the things existing frameworks provide, you'll have to build your own custom framework by collecting all the libraries you need and making them work together the way you want. Maybe you can make a framework out of it so the next person that has the same requirements as you doesn't have to go through this process again.