Web Development as Tag Soup

A post Web Development as Tag Soup by Jeff Atwood in Coding Horror. Very good blog indeed.
There are so many things to say about this problem. Maybe because it touches the Sacred Graal : separation of concern : Presentation and Business Logic.

Overall, there is no silver bullet, but people tends to forget that a Web Application, Web site or intranet can be very different projects and they compare Oranges to Apples. The client and development team changes everything.

Obviously, there are tons of comments, I will try to extract some :

- Mixing HTML / Javascript / server code : is it that bad ? Can there be a "good tag soup" ? "You recently championed Embracing Languages Inside Languages."

- Everyone is promoting his solution : generally a templating engine, but with some discipline to reduce the amount of code in the soup.

- A part of the problem is readability : <a href="<%=foo%>"><%=bar%></a>. Some suggest that "attribut soup" might be more readable. At least it is well formed XHTML : <p tal:content="string:foo"/>. Others consider that it is still a kind of Soup.

- "MVC tends to lead to file proliferation. It takes at least 5 files to create a single page: 3 JSP (using Tiles), 1 servlet, and 1 bean. I have to open 5 files to change a page."


Aims :

- Testability : code in the controller is easier to test than code in the HTML page.

- Wysiwyg : If the HTML is in the server code : only server-side developer can touch it. Designer won't be able to change and refine it. It is best to have well formed HTML templates to work with.

- i18n : what if the text is in the server-side code and in the HTML !

- Same kind of problems with escaping strings and unicode : Javascript, HTML, forms ... all different ways for your text from the Database to your front end !

- Readability, maintenance

- reuse, component


Solution proposed :

- Template Attribute Language : TAL (Python, PHP, Java ...) or XMLC (Java). A bit like the Wicket templates.

- Google XML Pages (GXP) Not very impressive yet. Wuld have to be coupled with some tools or IDE to be compeling.

- Get rid of HTML : GWT (almost), JavaFX, Flex, Curl ...

- Get rid of old paradigm : from Server-side generated HTML switch to SOFEA, Thin Server Architecture.

- more declarative language : XForms ...

- Use an all in one IDE + framework (JSF, JSTL ...) : Eclipse RAP, Netbeans, ...


Argument in favor of Tag Soup :
I quote :

Using more abstraction is just plain wrong, because:
1) you want to control what the output HTML will look like, so forget about a 'builder' tool, like a series of doc.addTag("P",content,attributes) ... it's Ok for passing data through some XML markup, but HTML documents are to complex to keep a clear idea of what the output will be this way. Customizing the layout is going to be a mess.
2) You want to use a 'template' library to avoid using too much logic inside your markup. This ends up being a joke, because you still want some logic, and you end up re-inventing a worse language that has to do loops, conditionnals, formatting, while your base language has certainly a better, more elegant syntax.
3) "simpler" intermediary language, like some XML markup then transformed to HTML through XLST leads you to the same pitfalls. You think you can avoid having logic in your markup, you end up reinventing another language, having to learn that language, to find out you get even more complexity.

The problem with tag soup is just the same of any language in any situation when you lazily prefer writing spaghetti code than creating meaningful functions, explicit variable names, clear indentation, well divided problem solving. Any programming language embedded in HTML is OK, anything else is a waste of time. What you need is to do all the complex stuff outside that embedded HTML file : do the business stuff and read all the records in the controller, and when you need complex formatting or logic rules, do it in helper functions that you'll define in a library accessible from your embedded html. In that embedded HTML, use your primary language, except everything must be very concise and trivial. Anything non-trivial as to be in outside helper functions with meaningful names. How do we program in general ? When we write a method we make sure all the code is about the microproblem you're trying to solve through that method, and anything too complex has to be in other methods, right ? That's just the exact same thing happening here. Being in the middle of HTML markup doesn't mean you can forget those programming rules. It's lame to blame your programming language when you put yourself in a mess, and that applies here too.