

Why you should Not use a web framework - nish20
http://checkedexception.blogspot.com/2010/04/why-you-should-not-use-web-framework.html

======
stevenwei
My takeaway from this article is don't use bizarre Java web frameworks that
force you to configure everything through boilerplate xml files that you end
up having to constantly change.

No clear argument is presented against why I shouldn't use a web framework
that helps me avoid writing the same bullshit over and over again to deal
with:

    
    
      - user accounts, permissions, password resets
      - general admin panels
      - form validation, csrf protection
      - sessions, 'flash' messages
      - pagination
      - image uploads, resizing, thumbnailing
      - internationalization
    

One might argue that the downfall of some web frameworks are their lack of
flexibility when you need to move beyond the out of the box solutions.

But honestly the only thing I get out of that article is don't write web apps
in Java when there are much better tools for the job.

------
kls
Stop using server frameworks to do web development, there is no need anymore,
it is useless overcomplexity that is not needed. If you are doing Java use
JAX-RS and stand up some RESTful services (Netbeans will generate them off of
a JPA annotated class). Then build your web front end with W3C compliant
technologies (HTML, Javascript, CSS). When you have the epiphany to go mobile
or IVR you don't have to rewire a bunch of config files (get sick of the
headaches and rewrite separate classes for mobile) to display in a new medium.
you just build a front end for that technology and call the business logic
that sits behind your service architecture.

It is a much faster development approach because in the end when you deliver
to new platforms the logical work flow changes due to screen size constrains
or the fact that it is a voice activated system.

------
tjpick
I'm getting more and more convinced that the best way frameworks can work is
to be like scaffolding when building a house etc. By the time the structure is
built, you don't need the scaffolding any more so you tear it down. By the
time you've built your web app it should stand on its own and you shouldn't
see the framework any more.

CSS frameworks are flexible in this way if you use them in such a way that you
butcher the css rather than your html, but server side web frameworks don't
seem to work that way. It'd be closer to 1st pass code generation than it
would be to an app server that you run inside of. If anyone knows of a good
server side framework like this, esp in python, sing out. (thanks)

------
nish20
The problem with the scaffolding analogy is ongoing maintenance and upgrades
coupled with the fact that software is never really "done". Most of the time
you release it, knowingly, in an incomplete state because it is mostly done
and functional enough. If you take your framework away at that point you have
to either admit that you really didn't need it in the first place or open the
application to the same inconsistencies it would be susceptible to without it.

------
mootothemax
From the article:

 _When is the last time you rewired struts application inside the struts-
config.xml so it did something different or reused an action and forwarded
somewhere else when you were done_

Uhm, never. That's exactly why I hated using NHibernate with C# and ASP.NET,
and precisely why, if I have quick and fast-changing web requirements I go
with PHP and Kohana instead. It's all in choosing the right tool for the job.

------
drivebyacct
This is an argument against Java web frameworks. I agree with his analysis in
that context.

