4 ms·
I'm not a PHP advocate, but I'll take this one: PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that d
by brlewis 16y ago
I'm not a PHP advocate, but I'll take this one:
PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.
The ideal web application is the one that best fits the unique characteristics of the data being manipulated. When exploring how a web app should work, you should be thinking at all levels: view, controller, model. A framework that forces you to separate all three from the start is a bad framework. It pushes you toward generic data manipulation forms and reports. If those generic tools are the best ones for the data model being manipulated, why involve a programmer at all?
We would have much more interesting and varied web applications out there if the prevailing "wisdom" of MVC would die.
- jemfinch 16y ago> When exploring how a web app should work, you should be thinking at all levels: view, controller, model. And separating those aspects programmatically makes it easier to think about them, not to mention program the ideas that occur to you when thinking about them separately. > If those generic tools are the best ones for the data model being manipulated, why involve a programmer at all? If intertwining essentially unrelated ideas is the best way to write programs, why use high level languages at all? MVC--just like garbage collection, just data abstraction, just like most other high level languages features--is about modularity and separation of concerns. > We would have much more interesting and varied web applications out there if the prevailing "wisdom" of MVC would die. How do you reconcile this with the fact that there occurred a veritable explosion of various interesting web applications when MVC was (re)discovered by the webdev crowd?
- brlewis 16y agoThe explosion you speak of is sites making better use of JavaScript, a movement that took off with the launch of gmail in 2004. Paul Buchheit talks about the thinking and communication that created gmail. He doesn't mention MVC; he talks a lot about rapid prototyping. He shares some of his then-current thinking in the form of a single 600-line source file. Read the post: http://paulbuchheit.blogspot.com/2009/01/communicating-with-code.html http://paulbuchheit.blogspot.com/2009/01/communicating-with-... EDIT: HN discussion: http://news.ycombinator.com/item?id=444615 http://news.ycombinator.com/item?id=444615
- mechanical_fish 16y agoLet me take this in a slightly different direction. The problem with paradigms (such as MVC, ORM, and OOP) is that no one paradigm is perfectly suited for all problems, but people tend to forget that. (Why do they forget? Because there are advantages to picking one set of paradigms and focusing on them to the exclusion of all others: It focuses your toolkit development and your documentation and makes the story of your platform easier to tell. Thus, we have systems like Rails, where everything from Hello, World on up requires at least passing knowledge of MVC and objects, and the whole system is designed around the assumption that you are building an MVC web app, using an ORM with a certain standard layout, placing files in standard locations, et cetera.) Unfortunately, there is one very important class of problem that most frameworks are ill-suited for: Very, very simple programs. Programs like the ones you write when you're new. Like a one-field "sign up for my mailing list" application, or a "guess the number between 1 and 100" application like the one I rewrote dozens of times in my Applesoft-BASIC-tinged youth. PHP offers the new programmer the simplest thing that could possibly work. You edit your HTML file, sprinkle a line of PHP into it, and save it with a .php extension, and (assuming your $5/month web host set up Apache correctly) lo, you have a web application! But you won't get any distance into (e.g.) Rails before the books and the docs insist on sending you to school, instead of straightforwardly doing what you want. "We know you want to write a one-page app", say the docs, "but first we'd like to give you a miniature degree in software development. We want to teach you about installing software on a Unix system, and using the command line, and what objects are, and what an ORM is, and what MVC is and why you should care". Or, perhaps, you will use a walkthrough to generate your Hello, World. You will either use the scaffolding -- e.g. type some mystical incantations that seem to have nothing to do with HTML, or Ruby, or the web, and that have to be done on the command line and preferably not in Windows -- or you will edit multiple files in multiple places to set up your tiny view, and your tiny controller. Then you have Hello, World. To go any farther will require some more training. Budget a day or two to read the book. Maybe buy another book. Heroku has gone to heroic efforts to remove some of these stumbling blocks, but there's only so much they can do. Rails is a professional tool for professionals. Like emacs, it takes time and determination to learn. And, like emacs, you're not likely to be motivated to learn it until you have cut your teeth on the equivalent of Notepad. But, in web development, the equivalent of Notepad is PHP. None of the other frameworks bother with such silly stuff. I'm convinced that the big strength of PHP is that new people can pick it up fast. And this strength just builds on itself, all the way up to systems like Drupal. Not only because new PHP programmers gradually become experienced PHP programmers via a steady ramp, but because even an extremely advanced and complex PHP program has many edges -- like the templates -- which inexperienced programmers will want to be able to edit. And they can, because PHP is evolved to be simple and straightforward.