Anyone NOT using a Web Framework? Why?

Question

I'm well aware of the many reasons to use a web framework. I'm just wondering whether anyone out there is using absolutely no web framework whatsoever to develop their web projects.

I would really love to know the reason(s) why you're not using a web framework.

For the sake of this discussion, your programming language of choice does not matter.

Some possibilities for discussion:

• You don't hide behind an ORM.

• You don't rely on any sort of templating system.

• You think MVC is a really nice TLA but lacks an essential vowel or two.

• No need for any additional javascript framework tomfoolery.

• You just write as much code as possible in your native programming language(s).

Summary of reasons thus far:

• Language learning opportunities.

• Specific performance reasons (write-intensive transaction processing).

• Seeking more nuanced control over your data and applications (less abstraction).

• You're building your own framework! Prove to yourself that you can succeed (or fail) just like the big framework-building gurus.

• Integration issues with unpopular/legacy technologies (exotic databases or protocols come to mind).

• Big company, lots of code, no talent nor buy-in present to move to a web framework.

• Some frameworks really lock you in and cannot perpetually grow along with your needs. These few black sheep don't make it easy to jump outside of the framework, write some custom code, and easily jump back in. When you finally escape the asylum, you'll never look back.

Answer 1

Right now I am developing one project, MyWebKeepAlive, which is a website keepalive service and I am using only out of the box .NET 3.5 compontents. Now, this does include ASP.NET Ajax. Otherwise I am not using any third party items, or JQuery. There is one single page that uses the AjaxControlToolkit.

Why did I make this decision? Well After using development frameworks (DotNetNuke) and Javascript frameworks (jQuery) so much recently, I wanted to take it back to the basics, and use this project as a real live dive into the standard way of doing things. Get an opportunity to try out new .NET 3.5 features etc.

Answer 2

I am not using a framework for a few things, in a few languages, my reasons are:

1. I don't need all that functionality. I need short, concise, minimal code
2. I want to learn the language, not the framework (when learning)
3. Like anything, less is sometimes more
4. Good abstraction allows you to start with what you need, and build on it. You might end up with your own framework 2 years later ... but it does what you need and has grown with you
5. Alot of buzz-words and come-and-go-trends seem to be attached to frameworks. They are just libraries and abstractions. Chill out.

People will say "Use a framework like Djano or Domojomomo or ich bin ein framework" or whatever ... but everything has its place I recon.

Saying that, I have just spent the day ironing out a headache with mod_wsgi ... and I suspect some of my 'roll your own' interfacing is to blame. So you could argue:

let framework people write frameworks, you write code. That is what they do best

But I don't know. Im conflicted, and a control freak in some respects.

Answer 3

Well, I tend to look first to see what frameworks are available to help me perform my task, and usually one works, but a couple of reasons I have avoided them in the past are:

1 ) Performance - If you have a very transactional system that doesn't benefit from caching, such as credit card transactions, IM, etc... Or if I am writing a mobile web application and find that the framework that I like doesn't perform as well, I'll drop back to hand coding.

2 ) It gets in the way - If I have a need to do something that doesn't fit into a normal web driven database paradigm, but uses http and session state management.

Mostly, however I have found tools that work well, but occasionally, especially on the mobile side I have found that some frameworks perform badly, but it is rare anymore that I am in that situation. I am not sure if this is because the frameworks are better, or that the computers are so much faster, but there are so many different frameworks ranging from light to heavy, and most of the heavy ones let you adjust what you need via packages that you can usually find something good.

Answer 4

Well, if you don't use any framework, you will probably develop your own while you implement your web application.

This can be fun, but note that there are some frameworks which are already very much barebones.

Answer 5

Um, because my personal sites are static pages in HTML 3.2 written in vim and tested using lynx?

Answer 6

Frameworks are great when starting out, but when you actually need to get serious and expand your web application (and when you start bumping into serious issues with performance, scalability, etc) they usually fail. Abstractions are great for productivity, but they reduce the power you have over how your application works internally. For example, ORMs prevent you from doing any major optimizations on your queries, thus resulting in lower database performance. Cal Henderson gave a really good keynote about this. (It's over an hour, but it's funny and informative, and I'd highly recommend watching it.)

On a more personal level, I like basic, lower-level frameworks that give me the productivity bonus I need in the beginning, but without the lack of control that most developers run into with more popular frameworks like Rails or Django. I also prefer writing my own SQL code for anything serious instead of using a full-blown ORM. Not only is that a huge speed boost, but I'm an optimizer, so I like to fine-tune my queries and database schemas.

EDIT: I should probably note that I'm talking about popular frameworks like Django and Rails. There's absolutely nothing wrong with using a framework in general. In fact, you kind of have to use some kind of framework if you want your code to be at all maintainable. But for most bigger projects it's better to roll your own, or use a bare bones framework.

Answer 7

Skip the framework as a learning exercise. It's one thing to know why frameworks are good or bad by reading about them. It's another to learn why they're good by solving the same problems they solve and bad by making the same mistakes they make.

Skip the framework to shave another millisecond off your app's response time.

Skip the framework to see if you can do better.

Answer 8

Check out why Cal Henderson hates Django.

Sums it up rather brilliantly (and with very convincing slides. He had me at the web-framework smugness pie chart :) )

Answer 9

A couple reasons, depending on the circumstances:

• At my most recent previous job, we had static and dynamic pages that went back to before web frameworks were around. No one had the time to select a framework and port all the previous work to it. This was especially true since there wasn't a lot of new development happening. Also, most of the people involved aren't IT professionals; some can create an HTML page, and a few can even write a CGI script, but no one (other than me) had any desire to go to a framework, and I never had the time.

• In my new job, for which I just finished my first web app, we're not using a framework on that site, so I'm just going with the flow. Furthermore, I had to learn two new languages to write the app, and adding the learning curve for a framework would have slowed me down even more.

• Also, I voluntarily maintain a small non-profit site where I've thought about using a CMS or framework to reduce my workload. However, at this point the learning curve for such outweighs the maintenance work, so I have not done it (yet).

Answer 10

Greenspun's Tenth Rule states:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Replace the words "C or Fortran" with "unframeworkified web" and "Common Lisp" with "some web framework", and you have the answer to your question.

Web frameworks are there to help you. Writing complex programs and ensuring that they are good, secure, and testable, when you've got to do all of the plumbing in addition to writing the few parts that matter, is a challenge. But when all of the plumbing is taken care of for you, writing and verifying your programs is much easier.

Answer 11

My main programmatical web application is to generate information about my professional papers. The master information is stored in a BibTeX file, and it's propagated to my web pages by some Lua scripts.

I don't use a web framework because:

• I've been doing this longer than most web frameworks have been alive.

• The implementations of web frameworks change faster than my needs, so within a few short years I would find myself having to update my code in order not to have to be stuck keeping legacy versions of the framework around. (This has actually happened to me with PHP; for another project I'm sitting on legacy PHP4 code.)

• A framework would probably want me to use a "real" database. BibTeX is a crappy database but it is the standard for academic papers, and it suits my needs adequately. One information store allows me to generate my web pages and my vita and it also provides an easy way for me to cite my own and others' papers. Information about other people's papers has already been collected by others, and I don't have to worry about a database schema.

• It would take me longer to learn how to use the framework than to build what I need myself.

Answer 12

Server-side I always use a framework. On the client however, I often use JavaScript without a framework when the need for JavaScript is limited.

Answer 13

All the great remarks and observation here are not just about Web framework, but any framework.

Frameworks fit in and out, and they have been ultra popular in last 12 years or so.

Don't expect that to last forever, they change and they have many issues, beyond common sheep following and somewhat positive market forces and effects. Then productivity slowly dries up, new models emerge, new vendors want more new blood etc. It's simple economics but the well-known effect is that they vanish to obscurity over time and as inferior to anything that outlasts them, usually simplicity (think of Google infrastructure and simplicity vs say Java or .NET stack).

Figuring out what the last bit is all the fun. Generalising a Web-as-service or even Web in Django, ASP.NET or JSP is always bound to get whacked by a specialised solution. Same for WPF, Silverlight or Flash or indeed games or databases, anything.

By all means use them, but never expect them to be the final say, mantra or something every dog on the street cannot reproduce quicker or better.

Answer 14

Here is a summary of the many replies as well as a few of my own. We can make this list go on forever.

1. I don't need all that functionality. I need short, concise, minimal code.
2. I want to learn the language, not the framework (when learning).
3. Like anything, less is sometimes more.
4. Good abstraction allows you to start with what you need, and build on it.
5. Alot of buzz-words and come-and-go-trends seem to be attached to frameworks. They are just libraries and abstractions. Chill out.
6. I've been doing this longer than most web frameworks have been alive.
7. The implementations of web frameworks change faster than my needs.
8. It would take me longer to learn how to use the framework than to build what I need myself.
9. It gets in the way.
10. Extra unecessary overhead isnt warranted and decreases performance.
11. They reduce the power you have over how your application works internally.
12. Inability to access the underlying code to aide with debugging.
13. Framework/Vendor lock in can lead to an inflexible system with management forcing applications into it that aren't a good fit to begin with.

Answer 15

I don't use one for quick easy lightweight projects

Answer 16

I typically build all new projects and prototypes in frameworks, as they (usually!) provide a more rapid development environment.

For successful projects, and when the specification is frozen, we often redevelop them outside a framework - streamlining the application by removing all the unnecessary cruft and increasing performance (often dramatically).

Its very useful to know the internal architecture of your application - this is often abstracted by the use of a framework.

Answer 17

I'm currently working on a web application that does not use a web framework. The biggest reason is that the site is heavy ajax driven to the point that things like views and templates don't matter. It just sends data via JSON.

The second reason is that web frameworks generally love relational databases. I'm not sold that this particular application requires one. Right now while I'm making up my mind I'm actually using MySQL as a key:value store. Were the value is stored in JSON. This lets me get away with some witchcraft that simply cannot be done with a relational model.

Furthermore I don't want to limit what I'm doing to a single language. I may do certain things in Python and others in C or Scala or even bash.

This is really based on this project itself. If my City Camber of Commerce came up to me and asked me to make a site for them, you can be that I would be grabbing for django or MVC or whatever to do the site.

In the end I just like not having a black box. I like that if there is something my code doesn't deep down, I can fix it.

I will give this advice though. If you write any non-trivial website, you will inf act end up using a framework. That could be something like RoR or something you made yourself. You will have to develop how you will do templates, how you will handle your database, and build all your own abstractions. If not you will end up with a tangle of code you probably won't want to work in again.

Answer 18

I'm currently working on a site where no known framework is used. After a month of working in a non-framework environment, you will notice lots of repetition from the admin to the client pages. Those repeat yourself situation will push you to investigate some of those frameworks out there. There's always a learning curve with frameworks but they will definitely facilitate your everyday job.

However, if the amount of legacy code in that non-framework environment is big, it will be very hard to make the switch to a formal one. Maintenance can be tedious on the long run. Nobody can tell you if you should choose framework vs no framework, experience it and you will have the answer.

Answer 19

Here's some reasons: http://checkedexception.blogspot.com/2010/04/why-you-should-not-use-web-framework.html