The advantages & disadvantages to be had from using a Web Framework? [closed]

Question

This question is focused on extracting the advantages and disadvantages of using Web based Frameworks: such as Cake PHP, Zend, jQuery, ASP.NET). This question is completely language agnostic. Let me start with the notion of "Standing on the shoulders of Giants".

Advantages:

• Empowers Developers - by taking features that would have previously have taken 100's of lines of code and compressing them into one simple function call empowers developers to integrate more complex features into their Web Sites.
• Allow for Quicker development of applications - this is very relevant for people that need websites created in a very small window (has anyone any examples of this?)
• Lower Costs - allows programmers to pass cost savings onto the customer, a whole new range of customers generated that wanted a website but previously could not afford the higher development costs.

Disadvantages:

• Lost Understanding - by relying on the features of a framework a developer is in danger of loosing understanding on how things work (underneath the hood).
• The configuration cliff - once you go further than the configuration of your framework your productivity drops right off, it can be difficult to implement features outside of a frameworks configuration.
• Developer tramlines - you (the developer) has to do things the way that the developer want you to do things.

I wonder what people make of my points, and whether anybody disagrees with them? Also if people have additional points I would be grateful.

Answer 1

Here's the bottom line: it can be difficult to implement features outside of a frameworks configuration.

Let's go through this assumption by assumption.

Lost Understanding - by relying on the features of a framework a developer is in danger of loosing understanding on how things work (underneath the hood).

False. You'll never lose understanding of how things work. Frameworks aren't magical. They're just handy code you don't have to write yourself.

Believe it or not, you'll make mistakes using the framework. You'll have to debug right down to the lowest levels of HTTP to understand what you did wrong.

You'll never lose sight of what's going on under the hood. Unless, of course, your framework is so epic and perfect that you never have a problem.

The configuration cliff - once you go further than the configuration of your framework your productivity drops right off, it can be difficult to implement features outside of a frameworks configuration.

This makes precious little sense.

First. Building without a framework can make a trivial job into a large programming task that includes unit test, debugging, diagnostics, configuration control and all that other no-value work reinventing stuff that's in the framework. How is that "productivity"?

Second. Implementing things outside the framework is always a lot of work because -- ahem -- implementing anything outside a framework is always a lot of work. It has nothing to do with the time spent learning and configuring the framework. Implementing anything outside the framework is inherently hard.

Developer tramlines - you (the developer) has to do things the way that the [framework] developer want you to do things.

Correct. And this is often a good thing. Doing things a consistent way is more valuable than doing them your own personal preference way. It may require "learning" and "understanding" but these have value.

Security issues - giving people these tools to develop professional looking websites fast is a potential risk, people can quickly create professional looking websites for fraudulent companies.

What? This has nothing to do with the framework. Fraud is fraud, irrespective of the tools used.

Answer 2

Con: Eventual possible drop of support / Loss of Popularity

• If there are two web frameworks that do basically the same thing, and yours doesn't win, there is a chance the project will die. In this situation you are left to maintain the framework yourself (open source), rewrite the application, or continue with no updates (closed source).
• Depending on the framework, you may be forced to upgrade your application with the release schedule of the framework. Falling too far behind could make you ineligible for support. With no framework, you can work at your schedule. (This depends on if you need/want support or not).

Pro: Code for the business

• Frameworks let you not worry about grunt work, and focus on code that directly brings value to the business.
• Sometimes framework upgrades that (just work) let you deliver new features to your users practically "for free". Especially with frameworks that come with custom controls (like a grid that the new version may offer some kind of search/filter).

Answer 3

Advantages

• Faster development time
• Less bugs
• Quicker shared development
• Library support
• Easy DB interaction

Disadvantages

• "Boxed in" to the framework
• Often inflexible when wanting to extend or modify core behavior
• "Errors of doom" – errors that arise from the core or underlying architecture with no good traceback to where they originated. A perfect example is Spring errors when using Grails.

I advocate using frameworks for all but the simplest of projects. If you need to add a contact us form to an existing HTML site you can use one PHP file instead of moving to a framework.

Answer 4

A couple of things that come to mind are...

Advantages

• Code reuse - by using a framework, you are reusing code that is tested and true.
• Rapid development/prototyping.
• (often) integrated input validation that can be presumed to be secure (given the developer is using it correctly)

Disadvantages

• Loss of support. Coming to mind here is Symfony 1.4. I imagine Symfony will support 1.4 for quite some time, but knowing that 2.0 is not backwards compatible, 1.4 seems like a support dead-end in the coming years.
• Overhead; By using a framework, you are running thousands of lines that may not apply to your specific application, but apply to others. Some deem this a reasonable trade off, and some opt to write their code from the ground up for performance.
• Using the wrong framework for your specific needs. Not all frameworks are created equally.

Answer 5

It all depends on the framework you use.

If you're using ASP.NET, you're at a disadvantage: It's a leaky abstraction at best, and at worst makes it a pain to do things that are trivial in other frameworks that don't hide the fact that you're working on the web.

ASP.NET MVC seeks to fix that problem, and it does so well.

Frameworks exist so that we can spend more time getting work done, and less time building scaffolding. In that regard, I don't see any disadvantages, unless you really want to spend time building scaffolding.

Answer 6

I would want to add some points.

• One of the biggest problems with frameworks I find is that people stop to think. They just want to use the framework because it's cool or because they always use the framework. They dont stop to think if the use is justified.
• Licensing, people just seem to use frameworks without really looking at the licensing. This could have implications that they aren't aware off. Or think about what happens when the license changes.
• Using to much of the same kind of frameworks. Sometimes their can be a lot of frameworks that actually do pretty much the same thing. As a company you make educated choices and not have a different framework for every project.
• Keeping up with new versions might be a challenge

Still I think putting in a bit more effort to evaluate frameworks, assess the licenses, keep a clean list of frameworks per use and have a smart versioning strategy are worth it when you consider the Advantages.

Advantages:

• when you consistently use frameworks the learning time for projects decrease for people who already worked on your projects.
• your own quicker development
• your own empower developers

Answer 7

I speak from personal experience in the last 13 years. In my company we used struts, after a short curve it was great. In my next we used an architecture that was mostly opaque, somewhat struts like but grown, we could extend it but the core code was only jars. And so on. in the last 3 years have been working in a small company (number of dev < 30) and it was all our own jsps, servlets and ejbs. Looking at our multiple clients and the repetition of jsps, in 2012 was to make a j2ee filter that mimiced 20% of struts2. Why not use stuts 2? I wish we had but : could not get it passed our chief architect; not enough experience or time.

So we had intercepters some common jsps that our mini framework used. Now when I have had the time to go thru a struts 2 book I see that we have missed so much!

We do use some great algorithms and caches and UI but have lost a lot of hours and burdened with a lot of code that we have a 3 year plan to retire.