To the point about the plugin: HTML is pretty much the foundational technology of web applications. Without HTML, you’ve pretty much got nothing. If you’re writing a framework for making web applications, why on earth would you have the component that generates the foundational piece of it in an optional extension??

I’ll grant you, many if not most of the tag templates you listed are hold-overs from a much earlier iteration of that code, (hence most of them are not actually used, and will likely be removed). But let’s be clear: most people don’t want to develop like you do. When choosing between hand-coding HTML (i.e. forms, etc.), or using helpers that save you time *and* buy you flexibility, most people (myself included) would choose the latter. When I go from dev to production, I don’t want to have to think about going through all my templates and replacing all my calls to external assets.

“And it certainly doesn’t mean that it’s okay to disperse additions to the site’s collection of scripts from any-old-place within the application.”

So does this mean that if you need a specific JS library on *one* page in your site, you include it in *all* your pages? This is an anti-optimization at best.

Finally, as my astute colleague Alexander points out, no one is twisting your arm about this. If you like coding straight HTML, by all means, do so.

I see code like this and I wonder (\lithium\template\Helper\Html;24-52)

protected $_strings = array(
  'block'            => '<div{:options}>{:content}</div>',
  'block-end'        => '</div>',
  'block-start'      => '<div{:options}>',
  'charset'          => '<meta http-equiv="Content-Type" content="{:type}; charset={:charset}" />',
  'doctype'          => '<!DOCTYPE {:version} PUBLIC "{:dtd}" "{:url}">',
  'image'            => '<img src="{:path}"{:options} />',
  'js-block'         => '<script type="text/javascript"{:options}>{:content}</script>',
  'js-end'           => '</script>',
  'js-link'          => '<script type="text/javascript" src="{:path}"{:options}></script>',
  'js-start'         => '<script type="text/javascript"{:options}>',
  'link'             => '<a href="{:url}"{:options} rel="nofollow">{:title}</a>',
  'list'             => '<ul{:options}>{:content}</ul>',
  'list-item'        => '<li{:options}>{:content}</li>',
  'meta'             => '<meta{:options}/>',
  'meta-link'        => '<link href="{:url}"{:options} />',
  'para'             => '<p{:options}>{:content}</p>',
  'para-start'       => '<p{:options}>',
  'style'            => '<style type="text/css"{:options}>{:content}</style>',
  'style-import'     => '<style type="text/css"{:options}>@import url({:url});</style>',
  'style-link'       => '<link rel="{:type}" type="text/css" href="{:path}"{:options} />',
  'table-header'     => '<th{:options}>{:content}</th>',
  'table-header-row' => '<tr{:options}>{:content}</tr>',
  'table-cell'       => '<td{:options}>{:content}</td>',
  'table-row'        => '<tr{:options}>{:content}</tr>',
  'tag'              => '<{:name}{:options}>{:content}</{:name}>',
  'tag-end'          => '</{:name}>',
  'tag-start'        => '<{:name}{:options}>'
);

Is that rly necessary?

I’ve seen many applications where html keeps working its way further away from the view templates. Letting a helper generate HTML is a constraint I would not soon violate. But then who cares right? That’s what helpers are for. To help. But does this belong in the framework or would it be more appropriate as a plugin?

CSS and JS bundling and minification are definitely huge wins for production. That doesn’t mean that the HTML has to be generated in a helper. And it certainly doesn’t mean that it’s okay to disperse additions to the site’s collection of scripts from any-old-place within the application. If I want to know what scripts are being added to a page, I want to see that in the layout. For separate applications with individual bundles, nested or separate layouts might be appropriate.

But this is all just me being bitter and bitching about how I would do things differently. Nitpicking aside li3 looks like an interesting framework. I’m planning to release a framework of my own (1/1/2010). I’ll ping you when its up, and hope you’ll see a different approach to what an application framework can be.

- Kev

First of all, I love HTML, especially HTML5. I still get goosebumps every time I type “<!doctype html>” into a new layout template.

I don’t use helper methods because I’m afraid of HTML, and thinking that that’s all those helper methods do for you is incredibly short-sighted.

Let’s take the simplest case first: the charset( ) method, while easy enough to type out manually, ties into the character set settings for the entire framework. It ensures that your data is queried, processed, and displayed in the same consistent character encoding (usually UTF-8, but not always). This not only prevents your pages from displaying broken characters, but has huge security implications as well. Ensuring a consistent (and enforced) character set across the board protects you from several classes of character encoding exploits.

For anyone who’s spent more than 5 minutes with YSlow or front-end optimization in general, the CSS and JavaScript include helpers should be obvious. Not only can I use those to compress (JSMin, Minify, etc.) and pack my assets into a single file (which becomes completely seamless to me as a developer), I can set my site up to only do this in production mode.

Further, with asset timestamps, I don’t have to clear my cache in development every time I make a change to a JS or CSS file. More importantly, I don’t have to tell my users to clear theirs. It just works.

Finally, I’m if you haven’t heard about the new “resource packages” feature which will be part of the next version of Firefox, it’d be worth your while to check it out. With my helpers, I can support resource packages with 1 new class, a couple lines of configuration, and zero template changes.

Next time you try to critique someone else’s design, you would do well to spend a few minutes trying to put yourself in that guy’s shoes. You might stand a better chance of sounding more informed.

Hope that helps,
- Nate