5 ms·

Web Development as Tag Soup

35 points by sant0sk1 18y ago

amarcus 18y ago
our webapp is written in php and using javascript ajax calls we keep all php, html and js code seperate
dhotson 18y ago
I've always liked _why's approach with Markaby: http://code.whytheluckystiff.net/markaby/ http://code.whytheluckystiff.net/markaby/ It's "Markup as Ruby". Quite an elegant hack I must say. :)
- omouse 18y ago
  You can do the same with Smalltalk and Seaside of course ;)
  - noahlt 18y ago
    Does anyone know of something similar for Python?
  - dhotson 18y ago
    Oh awesome.. I've been meaning to look into Seaside for ages already. I'll definitely check it out. From what I understand, that super-impressive Dabble DB demo used Smalltalk and Seaside. Have you seen it?
mojuba 18y ago
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.
- dpapathanasiou 18y ago
  Can Lisp be translated to JavaScript? Check out ParenScript (http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/).
- DanielBMarkham 18y ago
  F# and the WebDevelopment toolkit offers one language (OCaml) that can be used both client and server-side, including continuations and such across the client-server boundary. The OCaml code translates seamlessly into JavaScript.
- gnaritas 18y ago
  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?' ]
  - henning 18y ago
    The obvious alternatives to string templates are: - embedding client-side markup as a DSL in the language to generate HTML (Markaby/Seaside) - component/control-based systems (ASP.NET, JSF I guess) I prefer the first.
    - Tichy 18y ago
      I think Hacker News is using the component/control-based approach with Arc? Just curious.
      - henning 18y ago
        I thought it was macro-based HTML generation, which is typical of Lisp web libraries.
jjburka 18y ago
That code sample is either really old or a good example of why you should read up on the framework your using
olavk 18y ago
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   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 18y ago
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
menloparkbum 18y ago
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 18y ago
  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).
- olavk 18y ago
  The traditional view is that HTML is a messy presentational format with lots of repeated boilerplate and lots of subtle gotchas in the syntax. In that view, it makes sense to separate HTML from the logic into templates, where the markup is basically handled as opaque strings by the template engine. However, with semantic markup, each HTML element actually have a functional significance. The HTML is now the model, not the view. This does not solve the labor division problem you describe, rater it turns it into a completely different problem. Now HTML is basically the domain of the programmers, and CSS (and perhaps some amount of XSLT) is the domain of the web designer. It it still not clear to me how these should work together.
alexk 18y ago
I've went away from template-like solutions for this reason, moved to XSLT/EXSLT and very happy now.
mattmcknight 18y ago
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.

35 points by sant0sk1 18y ago

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

I've always liked _why's approach with Markaby: http://code.whytheluckystiff.net/markaby/ http://code.whytheluckystiff.net/markaby/ It's "Markup as Ruby". Quite an elegant hack I must say. :)

omouse 18y ago
You can do the same with Smalltalk and Seaside of course ;)
- noahlt 18y ago
  Does anyone know of something similar for Python?
- dhotson 18y ago
  Oh awesome.. I've been meaning to look into Seaside for ages already. I'll definitely check it out. From what I understand, that super-impressive Dabble DB demo used Smalltalk and Seaside. Have you seen it?

mojuba 18y ago

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.

dpapathanasiou 18y ago
Can Lisp be translated to JavaScript? Check out ParenScript (http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/).
DanielBMarkham 18y ago
F# and the WebDevelopment toolkit offers one language (OCaml) that can be used both client and server-side, including continuations and such across the client-server boundary. The OCaml code translates seamlessly into JavaScript.
gnaritas 18y ago
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?' ]
- henning 18y ago
  The obvious alternatives to string templates are: - embedding client-side markup as a DSL in the language to generate HTML (Markaby/Seaside) - component/control-based systems (ASP.NET, JSF I guess) I prefer the first.
  - Tichy 18y ago
    I think Hacker News is using the component/control-based approach with Arc? Just curious.
    - henning 18y ago
      I thought it was macro-based HTML generation, which is typical of Lisp web libraries.

jjburka 18y ago

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

olavk 18y ago

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   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 18y ago

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

menloparkbum 18y ago

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 18y ago
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).
olavk 18y ago
The traditional view is that HTML is a messy presentational format with lots of repeated boilerplate and lots of subtle gotchas in the syntax. In that view, it makes sense to separate HTML from the logic into templates, where the markup is basically handled as opaque strings by the template engine. However, with semantic markup, each HTML element actually have a functional significance. The HTML is now the model, not the view. This does not solve the labor division problem you describe, rater it turns it into a completely different problem. Now HTML is basically the domain of the programmers, and CSS (and perhaps some amount of XSLT) is the domain of the web designer. It it still not clear to me how these should work together.

alexk 18y ago

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

mattmcknight 18y ago

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.