1. You've left out a key advantage crucial to this question. Yes, you will be importing a lot of general-purpose code that may slow execution. However, this performance loss is balanced by the performance gain you get from using code that is likely much more optimized than your own. The authors of the framework specialize in authoring the framework, so in the vast majority of cases, it is unlikely that a solitary developer's code will outperform the framework's unless there is a very substantial advantage to tailoring to a specific application. Plus, when the framework gets faster, all your apps that run on it get faster simultaneously.

2. I don't think the analogy works. A more appropriate one might be to compare writing C to writing assembler. A framework will save you a vast amount of time, but also ensure a lot of the low-level stuff gets done right, and make your code more modular and portable. Grinding away for hours on tedious low-level coding doesn't teach you anything except an appreciation for things like frameworks.

3. Though the developers of frameworks can never know every potential application, they generally err on the side of giving you more flexibility. They want to save you from tedious and repetitive work, not tie your hands. Cherry-picking and bypassing bits of the framework is common, and does not need to be done with messy and un-portable hacks. I know of at least a couple of frameworks that provide lots of documentation about how to subclass and override stuff should you find it necessary (and people often do).

You're basically asking the questions that matter while learning about development frameworks, and I'll try to answer them as best as I can.


- Your first question regarding the performance trade-offs between execution time and development time actually has very little merit, as there are many patterns available out there for writing components that only execute the code you require out of it, while maximizing available resources. At a high level, I'm talking about modular design, and direct request dispatching and mapping logic that make request handling just as fast as if you were directly running your code without the use of a framework at all. Most of the frameworks i've worked with implemented a very fast dispatch system, and your typical method call and content generation will probably be completed in about 10ms, while the browser will take about 10 times longer to render that content, so server-side framework performance penalty is negligible at best.


Performance optimization is an important part of web development, so it's important that you learn about it regardless of whether you decide to use a framework or not. Obviously the error your friend has made was in implementing multiple JS libraries and likely many CSS files. Every JS file, CSS file, or image referenced by CSS used in your page, need to be loaded before displaying any page. A typical HTTP request takes a while to go back and forth through the network, so 99% of the "slow" applications you see out there are slow because of the large number of requests they make. The 'Yslow' plugin for firefox's "Firebug" extension will help you through the process of eliminating those problems in your own apps.



- Your concerns regarding bugs, or having to sometimes work around the framework are valid and legitimate. Most frameworks have bugs, and I'm sure your own application template is not exempt from that rule. It's important to do your homework when it comes to picking the right framework, and to learn how to work around the bugs of the framework without circumventing the framework all-together. This is done pretty easily in my experience. The mantra of high-level architectural software design "High Cohesion, Loose Coupling". This design minimizes the risk for bugs to become show-stoppers. My advice is to look at Zend Framework (PHP) or Django (Python) for reasonable implementations of that concept.


You can read more about high cohesion and loose coupling here:


http://en.wikipedia.org/wiki/Cohesion_(computer_science)
http://en.wikipedia.org/wiki/Loose_coupling


- I'm pretty sure my previous point addresses your last point properly. Once again, it's all about trying to pick a well-designed framework and learn how to use it as it was designed to be used. This may feel limiting and restricting for the first couple of projects but it really isn't. Instead of seeing a framework as a jail, see it as a set of very well designed components that have gone through dozens of rounds of optimizations, all glued together by an elegant and clean and flexible workflow.



My point of view is that the most flexible solution is to use a very loosely-coupled framework like Django or Zend on the server-side, and another loosely coupled UI framework like Dojo on the front-end. This gives you the optimal degree of versatility while still providing you with very well designed components that you can implement in any way you see fit.