Blog

What’s wrong with commerical web application frameworks
Posted by admin in Programming on 01.03.07
5 Comments

Some fellow posted a commerical notice to the comp.lang.php newsgroup. For a mere $79 per developer, you can get a PHP framework that does all the same stuff as the free, open-source PHP frameworks.

And it has all the same problems, too.

In a previous post I was ranting about generating HTML from the PHP code. When you generate HTML and CSS from inside the PHP code, then programmers end up working on problems that designers could solve much faster. Consider this problem, which the PHP Developers Kit offers as an example of all the wonderful things you can do if you use their framework:

The workhorse of PHP Kit is the container class . It is a box containing other objects, like text, links, paragraphs and even other containers. It is under CSS control so you may create a container using several dozen options, like background color, border style, border color, font size and font color.

Note: the containers above displayed correctly in Microsoft IE when displayed inline (left to right). However, Mozilla Firefox version 1.5.0.4 displayed them left to right but with no width or height except for the width of their borders. When displayed as block (one above the other), Mozilla displayed their size correctly. The display property (inline or block) is not suppose to effect an element’s assigned width and height.

So, um, you really should be able to control these containers from your code, but when you run into a problem with different browsers interpreting your CSS differently, you’re stuck solving it. All CSS issues should be the domain of your designers, not your programmers, but when all the CSS is controlled by PHP code, then solving this problem is shifted from the designers to the programmers. This leads to workflow problems – in too many web design shops the programmers have too much work and the designers too little, and frameworks such as this are to blame. Frameworks like this shift work from designers to programmers. That’s bad economics.

(Again, frameworks like this are fine for the individual freelancer who does all the programming and all the design work themselves. But these frameworks would be economically harmful to web design firms that work on large sites and need programmers and designers to work together.)

Comments

If the html is simple divs etc., you could just define your css after the code/PHP has generated it; just override the previously declared styles.

While I generally agree on your view of no html in your php, I think there are exceptions. It’s really about choosing what for when and where. For example, form elements being generated by code is acceptable to me. Even as a designer, I would think that looking at a page with a few php/template tags would be better than a page with lots of html; it’s still code. Less control, but as long as the code is doing what you want then there is no worry. And you could always either override/extend the classes generating the code or hack it. :)

Matt on 01-08-07 at 10:01 am

“Less control, but as long as the code is doing what you want then there is no worry.”

That’s a rather large exception to make. I think we could make that exception of all software projects. “Nasa doesn’t really need debug carefully, ‘as long as the code is doing what you want then there is no worry.’”

On a more practical level, I’ll say again, if an individual is doing both the programming and the designing, then putting HTML into the PHP might speed things up for them, but as soon as the jobs of programmer and designer are split, then anything that robs designers of their power is likely to lead to work-flow problems. And those cost money.

Lawrence Krubner on 01-08-07 at 6:54 pm

“And you could always either override/extend the classes generating the code or hack it. :) ”

Only a programmer can do this. Designers can’t do this on their own. If the designers need this done, then they need to wait on the programmer to do it. And then, once again, you end up with a work-flow problem that damages the productivity of the firm. Either the firm’s profits will be reduced or the costs must be past along to the client, driving up what they must pay for the project.

Lawrence Krubner on 01-09-07 at 12:26 am

“Less control, but as long as the code is doing what you want then there is no worry.�,

What I should have said was, “Less control, but as long as the *library/framework* is doing what you want then there is no worry.â€?. So, if you have something that is giving you the solution that you need, then great. Not really about the actual “code” just working. Testing is essential.

“And you could always either override/extend the classes generating the code or hack it. :) �,

Kind of kidding with that, but really I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.

Matt on 01-10-07 at 12:06 am

“I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.”

I’m sorry I haven’t stressed this, but the opinions I’m expressing have grown up on me slowly over the last 5 years. In 2002 I started work on a PHP/MySql content management system and I made every mistake that I’m now critical of. Back then, I wrote functions to simplify my forms, such as:

textInput(”author”);

All the HTML was in the function. It’s exactly what I’m now critical of. So what I’m expressing in this series of posts isn’t premature optimization. It’s way overdue optimization. I’m looking back at the mistakes I’ve made over the last 5 years and I’m trying to express what I’ve learned so others might now avoid making the same mistakes I’ve made.

Lawrence Krubner on 01-11-07 at 3:41 pm
Trackbacks


Leave a Reply