I will approach this from two directions (+ raw HTML itself being de-facto third)

  1. Proprietary HTML-generating code
  2. Code generating facilities provided by a popular library

Proprietary HTML-generating code

Example -- in a project I've inherited, there is a code that generates HTML for you, using proprietary methods written by a previous developer. Developer not available for consultation, but it is fairly clear that this code [while helpful is some specific circumstances], ultimately complicates things more than it cares to make things simple. Namely, for portability reasons the best course of action seems to be to get rid of that code and to just use HTML itself. Why -- HTML is already portable, and well-understood. You can use various facilities to format, update, and extend HTML (with CSS, etc). You cannot easily do that when dealing with language functions.

Popular Library

In my case I am using Zend Framework 2 that has facilities to generate HTML elements for you, which you can then render and incorporate into your "view" modules. For a concrete example of syntax, you can refer to Zend Form Elements

The good news is that the code is likely used by thousands of developers and it is somewhat standard. However, still, even with full power of a framework, you lose certain abilities to manipulate raw HTML. For example, a simple task of adding a CSS class to a select box becomes ... going to HTML, and ... but wait select box is a variable... and variable is defined by a method call to a Select element. How do you add an attribute of a class to that box? You have to consult the framework's API manual and write code to do that. That is not always most intuitive.

For example, can you tell me how to add a class="right" to a <select> box in HTML document? I bet you can. Now, can you tell me how to do it using ZF2? (I didn't think so?) Oh well, maybe you can. But what about the next developer, maintaining the code after you?

Btw, the link to Select Box, in case you wanted to try figuring it out (I don't believe the way to do that is in the link, by the way, you'd have to dig deeper).


We already know HTML. (A base assumption). But what I mean here is generating HTML via .. HTML itself + when needed, using some basic language constructs themselves, like for, foreach, if-then-else (there is example below). But that HTML in essence, remains HTML and is not hidden by a proprietary or a popular HTML-generating interface.


To me there was little question as to whether or not I should get rid of proprietary HTML-generating constructs [in particular, questionably-implemented ones] and to simply use HTML. But it became much harder when I saw HTML-building constructs in a well-known library.

True these libraries exist to make things simpler sometimes. And sometimes it does help. For example, for a <select> box I can use an array of any size to populate the box, without resorting to more basic language constructs like foreach. In particular the library code becomes easier to use in more special cases, such as marking a selected (default) option in a <select> box. Using basic PHP you have to implement this force-selection yourself using for/if-then-else statements, when using a library you can use a construct like $select->setValue($desiredValue).

Example Library Code:

$select = new Element\Select('language');
$select->setLabel('Which is your mother tongue?');
        '0' => 'French',
        '1' => 'English',
        '2' => 'Japanese',
        '3' => 'Chinese',

$form = new Form('language');

//later in view can use something like this:
<? echo $form->render($select); ?>

Example HTML Code (using the more basic PHP)

<? foreach ($options as $value => $name) { ?>
    <option value='<? echo $value ?>'><? echo $name?></option?>
<? } ?>


Consider adding a class="right" to select box of either of the examples above. I contend that one is easier, and one is harder. And I am all for making life of a programmer easier.

Currently, I am battling the temptation to use the library facilities to create HTML for me, but at the same time, I am concerned that later I will regret doing so and wonder why I didn't do a little more of the basic work with PHP, to end up with raw HTML that I can use.

My question is .. is using a library worth it? Will the next developer curse me for using HTML-generating code and try to rip it out, even if I used HTML-generating code of a popular framework?

And in that sense, is HTML-generating code in general, considered harmful, considering observations above?

closed as primarily opinion-based by Robert Harvey, GlenH7, Doc Brown, Bart van Ingen Schenau, gnat Sep 30 '15 at 11:00

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    You said it yourself... There are good templating mechanisms and not so good templating mechanisms. The pragmatic programmer will pick one of the better ones to work with. I'm personally a huge templating fan... Templating saves tons of time, and provides few headaches if it's done well. – Robert Harvey Sep 29 '15 at 22:58
  • sadly I don't know how to reword the question. I just feel that in my case, said templating (which I think is less of actual templating but more programmatic HTML building) is in my way. – Dennis Sep 30 '15 at 20:48