5 ms·

You're Doing It Wrong

16 points by bdfh42 18y ago

judofyr 18y ago
Markaby is pretty sweet: html do head { title "Boats.com" } body do h1 "Boats.com has great deals" ul do li "$49 for a canoe" li "$39 for a raft" li "$29 for a huge boot that floats and can fit 5 people" end end end
- mechanical_fish 18y ago
  Thanks. I modded up the parent submission, in part, because I was pretty sure I'd seen several of these syntaxes by now and I wanted to precipitate a shootout in the comment section. ;) More examples, please! Here's some haml, from the haml site. (I don't actually know haml, but perhaps I soon will:) #content .left.column %h2 Welcome to our site! %p= print_information .right.column= render :partial => "sidebar" Grading these competitions is hard, since it depends on taste and you can't always tell from a short example how something will perform in the field. haml may be a bit too terse (though I say that without being convinced that it's true; terse is generally good), and on first glance it will confuse the daylights out of an otherwise HTML-savvy person who has never seen it before. But I certainly like it compared to tag soup.
- arohner 18y ago
  Just because everyone else is doing it. I like Compojure (library for Clojure): (html [:head {:title "Boats.com" }] [:body [:h1 "Boats.com has great deals"] [:ul [:li "$49 for a canoe"]] (sidebar)]) render(:partial, sidebar) is accomplished by just calling another function that generates html.
deleted 18y ago
[deleted]
swombat 18y ago
Sweet, sweet irony. It's not every day that you see a post titled "You're Doing It Wrong" that's, well, doing it wrong. I've worked on plenty of sites of varying complexity. If your templates have anything more than trivial logic in them, You're Doing It Wrong! Adding complex programming constructs back into the templating language is NOT the way forward. It's the way BACKWARDS. It's where we came from. Templating languages are intentionally simple because you're NOT supposed to have lots of complex logic in your template. Sure, you might have a little bit of if/then/else and a bit of looping, but beyond that, if you need anything more than that, you're doing it Very Wrong. As for ending up with huge templates - again, Jeff is Doing It Wrong. To avoid having monster spaghetti templates, you're supposed to break down your templates into their elements, much like you break down your large pieces of functionality into classes and methods.
- alexk 18y ago
  My app evolved in the following way: templates with logic/inline JS -> templates without logic/ external js -> almost no templates/ JS + Ajax to draw the page on the fly
geebee 18y ago
I liked this post, and I think it speaks to a major problem in areas of software development that involve a lot of logic but are considered "not programming." A lot of effort is put into technologies that allow "non-programmers" to work with these tiers of app development, and I think they generally backfire. The most common one is tag libraries in place of scripting. The Java world is probably the biggest offender here. The JSTL started out as a way to create cleaner looking pages - and maybe it has - but the spec got to the point where they were recreating the entire Java language as a separate set of tags. Supposedly, these tags are easier for "non-programmers" to use, but by the time you're setting properties for objects and using conditionals and loops, you may as well admit you're a programmer. I'm no big fan of long jsp pages, but I prefer Rails's approach to scripting: if a task requires programming logic, use a programming language. Ultimately, I found the "you're doing it wrong if you include scripting in a view" to be very unconvincing, especially if the tags you replace it with end up recreating the programming language you're not supposed to be using in the first place.
jimbokun 18y ago
Scala also has in-line XML literals. Pretty much every Lisp has a way to express markup directly as S-expressions.
fortybillion 18y ago
It's amusing to watch server programmers come up with a thousand different ways to abstract away HTML. If you've ever worked with a good interaction designer, the best thing you can do is let them write views in something as close to HTML as possible. Every attempt to auto-generate sections of the view is something that will need to be worked around at some point. A lot of these frameworks seem to come from the mentality that design is just a programming problem that can be solved by pushing code out from the backend. A lightweight templating language (smarty, velocity, etc etc) should be all you really need. Poking holes in the HTML and inserting data is precisely the right way to do it.
nihilocrat 18y ago
So he wants to use PHP, then. Uh, I mean, the way PHP used to be written, with code and HTML mixed. I'm dumbfounded that he does not notice the circular nature of his proposal.
jseifer 18y ago
I really hope this doesn't start a trend of not using templates. Templates may not be perfect, but they're the best we've done so far (Seaside aside).
bad_user 18y ago
> Templating tends to break down because it forces you to treat code and markup as two different and fundamentally incompatible things. Well of course code and markup are two different things, but incompatible? Not really. We use HTML templates simply to let the designers play with the templates without our interference. It also makes changes easier to integrate. Otherwise we could use a DSL and transform the syntax tree in valid xhtml (which many people are already doing). > Rather than poking holes in HTML to insert code, we should simply treat HTML as code. Actually that means poking holes in your code to insert HTML. And it's worse IMO. While I like some of the articles Jeff has published on his blog, but I've long since deleted the blog's feed from my list because the signal to noise ration is really awful.
tjic 18y ago
I first ran into this issue several years ago, while I was using PERL (blargh). PERL has packages that allow you to put your HTML inside your code, or allow you to put your code inside templates. It soon became clear to me that neither is the win - the only real difference is "if I don't escape (via a quote character or a <? or a <%), what is a character considered - HTML or code?". The problem is that code is there are two different conceptual trees - the HTML tree with nested elements, and the code tree with nested logic, and these trees do not have a 1:1 correspondence. This is not a simple problem, and there are not simple answers. Programming in Ruby and Rails for the last few years, I've become a fan of partials, but the tradeoff that you get is that for greater ability to read one file, you lose locality of reference ( http://en.wikipedia.org/wiki/Locality_of_reference http://en.wikipedia.org/wiki/Locality_of_reference ) - you might have a table row in one file, and the data data in another file entirely. In general, I am a huge fan of straight text based editing, and always raise a dubious eyebrow at proposals for graphical editors and strange new editing tools. ...but I seriously wonder if there's some solution off in the space of a different kind of editor that lets you switch back and forth between viewing the code tree and the presentation tree...
brlewis 18y ago
He's about 1/3 of the way to reinventing BRL.

16 points by bdfh42 18y ago

Markaby is pretty sweet: html do head { title "Boats.com" } body do h1 "Boats.com has great deals" ul do li "$49 for a canoe" li "$39 for a raft" li "$29 for a huge boot that floats and can fit 5 people" end end end

mechanical_fish 18y ago
Thanks. I modded up the parent submission, in part, because I was pretty sure I'd seen several of these syntaxes by now and I wanted to precipitate a shootout in the comment section. ;) More examples, please! Here's some haml, from the haml site. (I don't actually know haml, but perhaps I soon will:) #content .left.column %h2 Welcome to our site! %p= print_information .right.column= render :partial => "sidebar" Grading these competitions is hard, since it depends on taste and you can't always tell from a short example how something will perform in the field. haml may be a bit too terse (though I say that without being convinced that it's true; terse is generally good), and on first glance it will confuse the daylights out of an otherwise HTML-savvy person who has never seen it before. But I certainly like it compared to tag soup.
arohner 18y ago
Just because everyone else is doing it. I like Compojure (library for Clojure): (html [:head {:title "Boats.com" }] [:body [:h1 "Boats.com has great deals"] [:ul [:li "$49 for a canoe"]] (sidebar)]) render(:partial, sidebar) is accomplished by just calling another function that generates html.

deleted 18y ago

[deleted]

swombat 18y ago

Sweet, sweet irony. It's not every day that you see a post titled "You're Doing It Wrong" that's, well, doing it wrong. I've worked on plenty of sites of varying complexity. If your templates have anything more than trivial logic in them, You're Doing It Wrong! Adding complex programming constructs back into the templating language is NOT the way forward. It's the way BACKWARDS. It's where we came from. Templating languages are intentionally simple because you're NOT supposed to have lots of complex logic in your template. Sure, you might have a little bit of if/then/else and a bit of looping, but beyond that, if you need anything more than that, you're doing it Very Wrong. As for ending up with huge templates - again, Jeff is Doing It Wrong. To avoid having monster spaghetti templates, you're supposed to break down your templates into their elements, much like you break down your large pieces of functionality into classes and methods.

alexk 18y ago
My app evolved in the following way: templates with logic/inline JS -> templates without logic/ external js -> almost no templates/ JS + Ajax to draw the page on the fly

geebee 18y ago

I liked this post, and I think it speaks to a major problem in areas of software development that involve a lot of logic but are considered "not programming." A lot of effort is put into technologies that allow "non-programmers" to work with these tiers of app development, and I think they generally backfire. The most common one is tag libraries in place of scripting. The Java world is probably the biggest offender here. The JSTL started out as a way to create cleaner looking pages - and maybe it has - but the spec got to the point where they were recreating the entire Java language as a separate set of tags. Supposedly, these tags are easier for "non-programmers" to use, but by the time you're setting properties for objects and using conditionals and loops, you may as well admit you're a programmer. I'm no big fan of long jsp pages, but I prefer Rails's approach to scripting: if a task requires programming logic, use a programming language. Ultimately, I found the "you're doing it wrong if you include scripting in a view" to be very unconvincing, especially if the tags you replace it with end up recreating the programming language you're not supposed to be using in the first place.

jimbokun 18y ago

Scala also has in-line XML literals. Pretty much every Lisp has a way to express markup directly as S-expressions.

fortybillion 18y ago

It's amusing to watch server programmers come up with a thousand different ways to abstract away HTML. If you've ever worked with a good interaction designer, the best thing you can do is let them write views in something as close to HTML as possible. Every attempt to auto-generate sections of the view is something that will need to be worked around at some point. A lot of these frameworks seem to come from the mentality that design is just a programming problem that can be solved by pushing code out from the backend. A lightweight templating language (smarty, velocity, etc etc) should be all you really need. Poking holes in the HTML and inserting data is precisely the right way to do it.

nihilocrat 18y ago

So he wants to use PHP, then. Uh, I mean, the way PHP used to be written, with code and HTML mixed. I'm dumbfounded that he does not notice the circular nature of his proposal.

jseifer 18y ago

I really hope this doesn't start a trend of not using templates. Templates may not be perfect, but they're the best we've done so far (Seaside aside).

bad_user 18y ago

> Templating tends to break down because it forces you to treat code and markup as two different and fundamentally incompatible things. Well of course code and markup are two different things, but incompatible? Not really. We use HTML templates simply to let the designers play with the templates without our interference. It also makes changes easier to integrate. Otherwise we could use a DSL and transform the syntax tree in valid xhtml (which many people are already doing). > Rather than poking holes in HTML to insert code, we should simply treat HTML as code. Actually that means poking holes in your code to insert HTML. And it's worse IMO. While I like some of the articles Jeff has published on his blog, but I've long since deleted the blog's feed from my list because the signal to noise ration is really awful.

tjic 18y ago

I first ran into this issue several years ago, while I was using PERL (blargh). PERL has packages that allow you to put your HTML inside your code, or allow you to put your code inside templates. It soon became clear to me that neither is the win - the only real difference is "if I don't escape (via a quote character or a <? or a <%), what is a character considered - HTML or code?". The problem is that code is there are two different conceptual trees - the HTML tree with nested elements, and the code tree with nested logic, and these trees do not have a 1:1 correspondence. This is not a simple problem, and there are not simple answers. Programming in Ruby and Rails for the last few years, I've become a fan of partials, but the tradeoff that you get is that for greater ability to read one file, you lose locality of reference ( http://en.wikipedia.org/wiki/Locality_of_reference http://en.wikipedia.org/wiki/Locality_of_reference ) - you might have a table row in one file, and the data data in another file entirely. In general, I am a huge fan of straight text based editing, and always raise a dubious eyebrow at proposals for graphical editors and strange new editing tools. ...but I seriously wonder if there's some solution off in the space of a different kind of editor that lets you switch back and forth between viewing the code tree and the presentation tree...

brlewis 18y ago

He's about 1/3 of the way to reinventing BRL.