
Web Development as Tag Soup - sant0sk1
http://www.codinghorror.com/blog/archives/001155.html
======
menloparkbum
Most projects that use a template based approach to layout end up looking like
this. The example in the article is relatively straightforward, in my
experience. Things get even uglier when your hot AJAXy javascript gets tossed
into the template.

We ended up here because for the past 10 years the imagined process for web
app development was that you had a programmer working on the "back end" and
this back end spit out stuff to some templates, which a "web designer" could
modify when you wanted to change the look and feel. Rails is a project started
by people coming from the web design world, so the default approach is to use
the typical division between back end and templates.

The workflow which splits things into back end + html templates, with
differently skilled people productively contributing to each side of the app
doesn't exist in reality. You'll eventually need some logic in the template.
The web designers don't want to modify a template filled with logic, so what
happens is the programming team gets "wireframes" from the designers, and then
modify the templates themselves.

If you're a programmer, and you prefer to generate your html programatically,
there are many tools that do this. A few have been mentioned already: seaside,
markaby. This approach is great if the programmers have control over the
development process from the back end to the front end. However, if you are
working with an existing team, you've got 10 years of process inertia fighting
against you. Thus, as is the usual answer on Hacker News, your best bet is to
start your own company where you can apply the tools and processes with which
you are most effective.

~~~
Tichy
One advantage to the tag soup approach is that you can just take the templates
the designer gives you. Usually they have been created with some WYSWG-
software like dreamweaver and contain hundreds of nested tables and divs.
Translating all that to a completely different language would be a nightmare.
Much easier to identify the parts you have to manipulate programmatically and
leave the rest of the code alone...

(This goes mostly for client projects, for my own projects I might have other
standards. Although in fact for my moon calendar web site, I ended up doing
the same).

------
mojuba
_But I have to wonder: is there a better way?_

The answer is a language that can use a unified syntax for both generating
markup and server-side functionality at the same time. There's probably only
one candidate at the moment, and that's Lisp with a special set of macros that
translate to HTML tags on output. The beauty of it is that S-expressions
nicely map to markup and can execute stuff on the server. This macro library
does exist and I think I saw it here at YCnews. It was a video and
unfortunately I can't find it now.

There's one bit missing in this solution though: the client side. Can Lisp be
translated to JavaScript? Something suggests that's perfectly possible.

~~~
gnaritas
Lisp is hardly the only answer. Smalltalk does this just fine in the Seaside
framework, which threw out templates to get rid of this exact mess. We write
our html, server side code, and client side ajax code pretty much entirely in
Smalltalk.

    
    
        renderContentOn: html
            50 timesRepeat: 
                [ html div 
                    class: #SomeStyle; 
                    onClick: (html element hide);
                    with: 'Who needs HTML?' ]

~~~
Tichy
What I don't like about this approach is that it forces me to learn a new
language just to create HTML. I don't mean Smalltalk, but the specific "HTML
generation API".

I have to know HTML anyway (because eventually I will have to debug it), so it
seems preferable to me to also code the output in HTML.

Another approach against tag soup I have seen is xmlc, which manipulates the
DOM tree of the HTML template. The xmlc project doesn't seem to be very active
anymore, though.

~~~
ajross
Just curious: how is xmlc not an extra "HTML generation API" that you have to
learn?

I mean, it seems we're stuck here. Either we use tag soup templates, or we use
some abstraction to express the structure of the page in the language of the
generator code. The former requires less training and discipline, but
complicates maintenance. The latter is a framework to which you'll need to
adhere. No free lunch.

~~~
Tichy
You have a point. I guess whatever you do, you need something to output HTML,
and something to code logic. What I like about xmlc is that it stays within
the standards. DOM is maybe too much to know for HTML developers, but still.
It actually worked quite well to have "designers" create HTML templates and
manipulate them in the servlet. The designer doesn't need to know anything but
HTML, except that he has to use id tags where values in the template have to
be manipulated.

Overall, I guess web development is always ugly :-(

------
dhotson
I've always liked _why's approach with Markaby:
<http://code.whytheluckystiff.net/markaby/>

It's "Markup as Ruby". Quite an elegant hack I must say. :)

~~~
omouse
You can do the same with Smalltalk and Seaside of course ;)

~~~
noahlt
Does anyone know of something similar for Python?

------
olavk
He is using convoluted presentational HTML interleaved with logic. This makes
it a mess. For example, the upper half of the code seem to be some kind of
tabular data, while the lower half seem to use table-markup without any reason
at all. This could be made much simpler by using clear semantic markup. He is
even mixing style info into the HTML by using things like &nbsp; and
class="gray" - this shows a complete misunderstanding of the concept of
separation of content and presentation.

Now, there may be legitimate reasons why you would use presentational markup -
e.g backwards compatibility with old browsers, or very complex layout or
effects. In that case a transformation should be done - using XSLT, custom
tags, or whatever is appropriate for the framework. This markup transformation
should be separated from the logical markup just like CSS is.

The code is a bit ugly too - the f and c variables see to be used to switch
styles for the first row and for every other row. Again, this is
presentational and should be handled by CSS or some kind of transformation
system.

Lots of comments suggest that the code could be improved by using round or
square brackets instead of pointy bracket. This does nor really reduce the
complexity though, the important thing is to simplify by abstracting styling
and layout away from logic and structure.

------
sh1mmer
In order to put data into the output format you have to have some form of tag
soup because that's the only way to put information and display logic into
HTML.

The question in my mind is more, are you a developer or web sites or a
developer of tools.

Something like .net components or JSP taglibs allows the developer to off load
data/widget to a tool developer by just calling a widget.

The two problems I see with that a) historically the people building a lot of
those widgets produced markup that _sucked_ b) it's kinda inflexible

------
jjburka
That code sample is either really old or a good example of why you should read
up on the framework your using

------
alexk
I've went away from template-like solutions for this reason, moved to
XSLT/EXSLT and very happy now.

------
mattmcknight
I like using the builder approach in Ruby.

x.html {

    
    
      x.head
    
      x.body {
    
        for i in 1..5 {
    
            x.div(:id => i) {
    
               "yo"

...

but my designer likes the templating stuff better. With a good IDE, it does
become pretty easy to tell the code from the template.

------
amarcus
our webapp is written in php and using javascript ajax calls we keep all php,
html and js code seperate

