MVC is NOT right for every project, and it is not the best way to build all applications. Neither is PHP, Perl, C, C++, FORTRAN, ASP, etc. You pick the tool you need for the job, the one that is right for the company you are with, the one that is right for that project, etc.
People such as myself who are pro-MVC are not saying "MVC is right for every need". MVC is one of the many tools you need to have in your bag if you're calling yourself a Web developer or say you know "Web services".
As several of the other comments have said, speed of development is only one factor in the cost of a project.
Other costs are: can I change it easily as the business needs change, or as back end systems change? Can I easily add modules? Can I easily go back and optimize a piece of code that 3 months of use has revealed wasn't written correctly and easily switch that code in and out without impacting other modules? Can I keep the people doing the view (typically graphics artists and Web editors) and people doing the actual logic of talking to the back ends (geeks, in other words) concentrated on their area of expertise? Do I need to hire generalists (people who can do view and model/control, and there aren't many of them. That's why a lot of interfaces look like crap, or a lot of great looking interfaces run crappy)? Does a change in look and feel cause a major headache for all?
What is not being advertised is that those people who are current local phone (over digital cable) customers of AT&T broadband (Comcast does not do phone over cable) are going to be quietly ignored. Comcast does NOT want to support local phone service; local phone service will cease to be advertised, sold, pushed, etc.; they're hoping for slow attrition of existing customers once the merger is done.
As for moving the high speed users between networks - it shouldn't be as much as a clusterfuck as the @Home move was; they have all of the data this time and they control the networks.
One other clarifications:
Michael Armstrong is moving to Comcast. Plus Armstrong is looking a little better (not much, but a little) now that it's been revealed that QWest and WorldCom were fudging their numbers in a big way, while AT&T didn't play that game. (Interesting muse: what would have happened to AT&T if the other companies had not, well, lied? Wall Street forced AT&T's stock price into the toilet because they were comparing the T to companies that were pulling numbers out of their ass)
There is not a single authoritative book that covers all browsers primarily because each browser has gone its own way in terms of standards (IE has JScript, ActiveX, etc.; Mozilla's options have been listed ad nauseum; Opera, Netscape, etc) I've generally followed the spirit outlined in Macintosh Human Interface Guidelines, Windows Interface Guidelines (both of the previous are very old), Designing for Web Usability, and my own common sense based on what I've seen that works.
I will state to all of those who say "well, do a true client/server" that saying that is short-sighted. Part of the design process has to look at it from the company point of view, in addition to "what is really sexy or easier for me to develop."
As an example, a typical company also has to think about support costs, as you now have to deal with "how are the client machines configured; what are they running"; "how do I deal with updates/changes"; "who is going to deal with installing the client everywhere?", etc. (and, yes, those same issues come up with "browsers", but browser compatibility and configuration issues are often more cut and dried) Basically, the tradeoff facing many companies is "cost of developing an application that takes a developer a tedious length of time to get the menus right and test with various browsers and systems" versus "cost of developing an application that will need support on the client side and that someone will need to test on various systems".
Additional factor for many companies is that people have become accustomed to the Web; so a well designed Web application should have a lower learning curve and a cheaper support curve - in general (and I'm generalizing wildly) Can I think of specific cases where I've done a client/server intranet app rather than a Web intranet app? Yup. Each case is different and must be judged on its own merits.
Slashdot Mirror
People such as myself who are pro-MVC are not saying "MVC is right for every need". MVC is one of the many tools you need to have in your bag if you're calling yourself a Web developer or say you know "Web services".
As several of the other comments have said, speed of development is only one factor in the cost of a project.
Other costs are: can I change it easily as the business needs change, or as back end systems change? Can I easily add modules? Can I easily go back and optimize a piece of code that 3 months of use has revealed wasn't written correctly and easily switch that code in and out without impacting other modules? Can I keep the people doing the view (typically graphics artists and Web editors) and people doing the actual logic of talking to the back ends (geeks, in other words) concentrated on their area of expertise? Do I need to hire generalists (people who can do view and model/control, and there aren't many of them. That's why a lot of interfaces look like crap, or a lot of great looking interfaces run crappy)? Does a change in look and feel cause a major headache for all?
What is not being advertised is that those people who are current local phone (over digital cable) customers of AT&T broadband (Comcast does not do phone over cable) are going to be quietly ignored. Comcast does NOT want to support local phone service; local phone service will cease to be advertised, sold, pushed, etc.; they're hoping for slow attrition of existing customers once the merger is done.
As for moving the high speed users between networks - it shouldn't be as much as a clusterfuck as the @Home move was; they have all of the data this time and they control the networks.
One other clarifications:
Michael Armstrong is moving to Comcast. Plus Armstrong is looking a little better (not much, but a little) now that it's been revealed that QWest and WorldCom were fudging their numbers in a big way, while AT&T didn't play that game. (Interesting muse: what would have happened to AT&T if the other companies had not, well, lied? Wall Street forced AT&T's stock price into the toilet because they were comparing the T to companies that were pulling numbers out of their ass)
There is not a single authoritative book that covers all browsers primarily because each browser has gone its own way in terms of standards (IE has JScript, ActiveX, etc.; Mozilla's options have been listed ad nauseum; Opera, Netscape, etc) I've generally followed the spirit outlined in Macintosh Human Interface Guidelines, Windows Interface Guidelines (both of the previous are very old), Designing for Web Usability, and my own common sense based on what I've seen that works.
I will state to all of those who say "well, do a true client/server" that saying that is short-sighted. Part of the design process has to look at it from the company point of view, in addition to "what is really sexy or easier for me to develop."
As an example, a typical company also has to think about support costs, as you now have to deal with "how are the client machines configured; what are they running"; "how do I deal with updates/changes"; "who is going to deal with installing the client everywhere?", etc. (and, yes, those same issues come up with "browsers", but browser compatibility and configuration issues are often more cut and dried) Basically, the tradeoff facing many companies is "cost of developing an application that takes a developer a tedious length of time to get the menus right and test with various browsers and systems" versus "cost of developing an application that will need support on the client side and that someone will need to test on various systems".
Additional factor for many companies is that people have become accustomed to the Web; so a well designed Web application should have a lower learning curve and a cheaper support curve - in general (and I'm generalizing wildly) Can I think of specific cases where I've done a client/server intranet app rather than a Web intranet app? Yup. Each case is different and must be judged on its own merits.