Making life better by not using Java web frameworks? [closed]

I'm so tired of having to learn yet another Java web framework every other day.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC to name just a few - all this countless frameworks out there try to address the same issues. However, none of them really solves the fundamental problems - that's why there are still coming up more and more new ones all the time.

Most do look very bright and shiny on the first impression because they simplify doing simple things.
But as soon as it comes to the implementation of a real world use case one is running into problems.
Often the frameworks don't provide any help but are hindering one and limiting the options by forcing things to be implemented according to the frameworks own logic and environment.

In short, I see the following disadvantages when using a framework:

1. There mostly is a steep learning curve and you first need to understand sometimes quite academic concepts and know meaning and location of a bunch of configuration files before you can get started.
2. The documentation usually is more or less awful, either missing a public accessible online reference, is helpless outdated, confuses different incompatible versions or all of this together and often doesn't provide any helpful examples.
3. The framework consist of zillions of classes which makes it practically impossible to understand the intended use only by browsing the sources.
4. Therefore you need to buy some "XYZ in action for dummies in 21 days" kind of books which have a bad user interface because they are missing a full text search and are heavy to carry around.
5. To really use one of this frameworks you need to learn by heart how things can be done the way the framework requires it by remembering the adequate classes and method names until your head is full of stupid and useless information you can't use for anything else.
6. There is a big overhead, slowing down your applications performance and making your brain feeling numb when try to understand what really is going on.
7. In the real world there is usually no time to get well familiar with something new because of the pressure of being productive. As a consequence of this learning by doing approach one always looks only for the fastest way to get the next task done rather than really understanding the new tool and it's possibilities.
8. The argument that following a standard would allow people who are new to a project to quickly get started is not valid in my view because every project uses a different framework even within the same company (at least in my case).

It seems to me that the following quote from Albert Einstein fits here very well:

“We can't solve problems by using the same kind of thinking we used when we created them.”

Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next.
This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules.
This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.
While perfectly adjusted to the requirements of the current project, it also was easy expandable and had a very high performance due to zero overhead.

So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
What should I say to my boss when we're starting tomorrow the next project with a new framework again?
Or are there maybe frameworks which really make a difference?
Or some hidden advantages I have ignored?

Solution 1:

Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next. This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there

Forgive me for believing that not one second.

but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules. This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.

So basically you developed your own framework over the course of months or years, tailored to your own needs, and could work very fast with it because you knew it intimately.

And yet you can't understand why others do the same and then try to turn the result into something useable by everyone?

Where's this great framework you developed? If it's so powerful and easy to use, where are the dedicated communities, thousands of users and hundreds of sites developed with it?

every project uses a different framework even within the same company (at least in my case)

Well, that's your problem right there. Why would you throw away the expertise gained with each framework after each project?

The idea is to choose one framework and stick with it over multiple projects so that you get proficient in it. You have to invest some time to learn the framework, and then it saves you time by allowing you to work on a higher level.

Solution 2:

The problem with coming up with your own framework is that you will make all of the same mistakes that all of the established frameworks have already stumbled on and addressed. This is true particularly when it comes to security.

Just ask Jeff and the guys about what they had to consider when implementing the WMD in stack overflow. I'd rather use what they have produced in a project rather than implement it from scratch. That is just one example.

Solution 3:

Here is a quote from Kev from the thread What’s your most controversial programming opinion? which fit's in here really well:

I think that the whole "Enterprise" frameworks thing is smoke and mirrors. J2EE, .NET, the majority of the Apache frameworks and most abstractions to manage such things create far more complexity than they solve.

Take any regular Java or .NET OMR, or any supposedly modern MVC framework for either which does "magic" to solve tedious, simple tasks. You end up writing huge amounts of ugly XML boilerplate that is difficult to validate and write quickly. You have massive APIs where half of those are just to integrate the work of the other APIs, interfaces that are impossible to recycle, and abstract classes that are needed only to overcome the inflexibility of Java and C#. We simply don't need most of that.

How about all the different application servers with their own darned descriptor syntax, the overly complex database and groupware products?

The point of this is not that complexity==bad, it's that unnecessary complexity==bad. I've worked in massive enterprise installations where some of it was necessary, but even in most cases a few home-grown scripts and a simple web frontend is all that's needed to solve most use cases.

I'd try to replace all of these enterprisey apps with simple web frameworks, open source DBs, and trivial programming constructs.

Solution 4:

The problem is of course not just with Java frameworks. I've lost count of the number of C++ MFC projects I've seen floundering around trying to shoe-horn their requirements into the Document/View model (which really only workks for text and graphic editors - database applications are particularly difficult to shoehorn).

The secret of succesful framework use is to change your application to match the framework, not the other way around. If you can't do that, don't even think of using the framework - it will end up being more work than if you had written the app from scratch with the help of some good, reliable and well-documented utility libraries.