You're viewing a comment by Marty Gentillon and its responses.

Marty Gentillon Permalink
March 11, 2016, 22:50

Fundamentally, frameworks are essential to development. Nearly every application depends on one. You can hardly even do web development without a framework, and if you try, the first thing you will do is to write one. In fact, if you are an application developer of any kind, I strongly suspect that your application is using a framework right now. The only real exceptions I can think of would be if you were developing an operating system, or building an embedded system.

Think about it, In order to terminate a web request, there are at least a half dozen things that have to be done. Things that are the same for all requests. Things that you don't want to write more than once. Things like reading the socket, deserializing and verifying the data, checking authentication, taking metrics, recording logs, and handling protocol details. To add a new resource, you don't want to worry about these details, and if you had to, your system would be massively more complicated.

Enter the framework, to handle a new resource, all you have to do is write a handler, add a template, add a schema, update the routing, and record a few other details. Of these, only the first is really essential, and some frameworks will auto generate others.

The next question arises: what kind of framework should you use? Do you want something with an all included mindset like Spring? Do you want something with a composable slightly bare bones approach like Clojure's Ring and Compojure? Do you want something more in the middle like Ruby on Rails? Do you roll your own?

There are tradeoffs here, Frameworks like Spring tend to be complicated, limit one's flexibility, and require a bit more work to understand. Not an ideal situation surely, but, if your application's needs happen to match the framework particularly well, they can save you from having to write a massive amount of code.

Bare bones frameworks tend to give you more flexibility and are often better designed, but require a large amount of customization. Usually, this is a better tradeoff, as the increased flexibility will pay dividends, but it can result in fewer initial features, and slower initial development (as you build the framework up to the level you need).

Rolling your own framework from scratch is nearly universally a bad idea, requires an expert, and should only be attempted if you can't find something that meets your needs. Fundamentally, there are a large number of problems in developing an application that you won't know about until you encounter them. Using something that was developed by experts and has lived in the wild means that someone has probably already fixed half of these problems. Using something that has has multiple users means that when you encounter a problem, there will be someone to help. Don't give up these advantages trivially.

Remember, you are going to own your framework. So, pick it with care. How stable is it? How complicated is it? Take a brief look at the framework's code, does it stink? Take a look at the framework's API, do you like it? Understand the framework's features, are they what you need? Think about how your application should work, will this framework get in the way?

Reply To This Comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "cloud_508": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.