Slice: A Clojure library for writing composable slices of html, css, and js | Hacker News Reader

Slice: A Clojure library for writing composable slices of html, css, and js

github.com

As cool as these sorts of libraries are (and this is a really elegant library), I think their utility is limited in the kind of development that constitutes a product.

A team can hope that they have a crack clojure developer who's also an ace designer who's also very good at handling cross-browser rendering issues... but that team could also hope for a magical site-building unicorn with about as much plausibility.

I've always felt that libraries like Slice excessively couple the application's source code with its design; even an embedded-script template like ERb or PHP is arguably better when your markup may need to be worked over with odd tweaks to get IE support.

Besides, Clojure already has a fantastic HTML rendering library in cgrand's work: Enlive. It lets you take existing, valid templates and then inject new data into them, and even compose the results. This is one of the best ways to work on projects where the folks doing the server-side work have different responsibilities than the client-side team, and is most amenable to designer talent.

This approach has started to catch on elsewhere. I think the most recent place I saw it crop up was in David Pollak's Lift project, where they're called "Designer-Friendly Templates" (and they're even more composable there than in Enlive).

For the record, I'm still undecided whether slice is a good idea. Thanks for calling it cool and elegant though :)

You can use slice for just the clojure/html/js and do the css separately. Or you can use enlive+html and slice for clojure/js. I think slice still provides a nice way to structure your code.

The site's design doesn't have to be coupled with it's logic/semantics. All the design can be in separate slices from the rest. What you gain is still composition, a full programming language, and easier testing.

Added: Originally I pitched slice as a solution for solo coders, so I agree that it has some significant weaknesses for teams, but I think it also some strengths, such as the ability to see relevant code (i.e. clojure/js/css/html) in one place, navigate code with IDE features regardless of language , abstract away details that span languages, and easier testing.

Out of curiosity, how are they more composable? I haven't used Enlive for a bit but the entire thing felt so smooth on that level (and all the others) I'm very curious to hear how it could be made better, or are they using tricks based on the type system?

The "NodeSeq -> NodeSeq" implicit construction method that DPP uses for his designer-friendly templates works so well because of the type system, yeah.

Which is not to say Enlive doesn't tackle the problem head on with a lot of solid syntax. It's just the forms like clone-for aren't everywhere, and so the second you leave the comfort zone of the syntax you lose a lot of the elegance.

This is the tradeoff between the two language approaches. The static type can carry it's DSL on its back implicitly, whereas the macro approach requires an explicit lexical tag.

Lift's templates predate Clojure, let alone Enlive.

Lift templates may predate Clojure and Enlive but the designer friendly variation are a recent development.

The designer friendly templates from still appear to need some markup added to the HTML - the lift:surround and other tags. Enlive will let you leave the HTML completely untouched - I'd prefer to use Enlive for that reason, most of my work get arranged by the customer so that I get buckets of HTML produced by external suppliers and modified throughout the project delivery.

I think that there are no longer any required non-html tags in Lift, as of 2.2's final release. The surround stuff goes in as a fake CSS class now, which is a fairly unobtrusive way to do it.

I know that Designer-Friendly Templates are new to Lift because I was the guy who told DPP about Enlive, and he said that's what inspired the new hands-off templating.

Which is not to say I don't think it's inevitable though. As Lift moves way from XHTML, it made less and less sense to shove in custom tags.

I've always felt that libraries like Slice excessively couple the application's source code with its design

Ideally, the HTML should have nothing to do with the site's design. The HTML should semantically describe the content, not govern how it is displayed.

> Ideally

and therein lies the rub. As long as we have to care about browser bugs and inconsistencies, there are going to be limits to this.

But not many limits. Modern browsers are pretty consistent in the way they render HTML/CSS, and their differences tend to be superficial. In the past you might have to deal with half a dozen browser layout bugs; now it's whether the browser supports rounded corners or drop shadows.

If you have to support IE6, you'll obviously have much more problems, but if you're supporting IE6, you're probably working on a corporate web app that has a very uniform design. In which case, there's less need for a designer to work on every single page.

It's much the way you say, save for some very peculiar rendering differences between Firefox and Webkit family.

Or it was, until Mobile became such a huge priority. As much as we wish it was otherwise, mobile is a tricky problem that often requires clever (and often painfully unobvious) workarounds for a variety of deployed browsers. The worst offender here is legacy android phones (which is to say, nearly all but the ones released last month), but iPhone deploys have problems too.

Reply on news.ycombinator.com