5 ms·
Your templating engine sucks and everything you've ever written is spaghetti
- eob 15y agoBeen working on something like this for a while and nearing a big push of version 1 to github. Glad others feel the same way!
- dools 15y agoMake sure and post about it when you do - I definitely want to see more momentum around this and was pleasantly surprised when I saw that solutions already existed. My favourite thing about it is that it transcends "technology". The fact that you've been working on this is no loss to someone else who's been working on something similar as the cost of changing from one solution to another is so dramatically low when all the value is retained within the templates themselves.
- eob 15y agoLikewise. Two other template engines you might be interested in are Knockout.js (http://knockoutjs.com/ http://knockoutjs.com/) and the template engine from the Lift web framework. Both play relatively well within HTML. And Stanford has done some nice work on segmenting the DOM into semantic chunks. The site appears to be down now, but it's usually hosted at http://bricolage.stanford.edu/ http://bricolage.stanford.edu/. Check out their paper on the "Bento" algorithm.
- sorenbs 15y agoThe lift book is worth a quick look if you are interested in templating engines. In short, instead of logic in the view, css selectors are used on the server side to transform small chunks of the website in a statically typed and safe (the dom structure is carried around as xml instead of a string which makes it possible to prevent most of the common security problems on the web) way http://simply.liftweb.net/ http://simply.liftweb.net/
- llimllib 15y agoYeah, well, your website sucks and doesn't load.
- dools 15y agoIt seems to be serving that page in around 5 - 7 seconds but it's pretty heavily loaded. Yes I wish I'd gotten around to doing all that stuff that I know I should do in order to make it load faster than it does right now. PS: If the site didn't load, how do you know it sucks?
- ichc-werker 15y agoHey dools, these two images are broken for me: Instead of splitting up the task of templating in the following, arbitrary fashion: [broken] We can create a non-arbitrary, completely objective separation where the view/template layer truly contains no logic what so ever: [broken] Cool article; made me think about how I've been handling views. I think I agree with you, but I'll need to mull it over for a while. Thanks!
- jamesaguilar 15y agoSolely with respect to your post script: a website that doesn't work pretty much always sucks.
- thurn 15y agoWhat he's describing is best realized in the Enlive templating library for Clojure. You perform a suite of transformations on regular html files.
- draegtun 15y agoPush style template is a phrase I've seen used to describe these kind of templating systems: http://news.ycombinator.com/item?id=2238885 http://news.ycombinator.com/item?id=2238885
- gnorsot 15y agoI hate templating. There are just so many engines to choose from and you end up writing your own because none of them can do what you really need.
- ronreiter 15y agoWhat are you building there? A nuclear reactor?
- peteforde 15y agoIt's a drag when what you're working on is such a unique snowflake that nothing really smart teams have worked on for years is able to help you. I'm going to abuse a Bruce Schneier quote and suggest that if you're trying to get a job done and you start by writing a template interpreter, you're doing it wrong.
- einhverfr 15y agoDude.... I get laughed at for the things I do with templates (html page with 20k input elements) until people realize what I am doing with them (a bulk payment interface for paying 5000 invoices in a compact workflow). I have found that any complete templating system has sufficient flexibility and extensibility to do what you want. Though I use Perl's Template Toolkit.
- jeremymcanally 15y agoSounds like he wants Pakyow: http://pakyow.com http://pakyow.com
- dools 15y agoHmm not really. I mean, what I want is HTML/JavaScript/CSS and then absolutely anything I choose on the backend. The framework is completely irrelevant. The fact that there is an "itemprop" attribute in the Pakyow view construction already invalidates it as an option for achieving what I'm putting forward here.
- peteforde 15y agoEvery programmer is on a long, cyclical journey where every stepping stone feels like a new kind of enlightenment. Blogging allows them to share their brilliance with the world, showing how they are surely amongst the first to attain their new level of purity and zen. The funny thing about this post is that the author tells us to get off our high horses and come down from our ivory towers... and then proceeds to make a series of highly conjecturable claims presented with no factual evidence beyond his own confident assertion that he's in the know. There's like, no chance that in two years he'll be advocating for his new new philosophy. In the meantime, I'm left to wonder "Iain Dooley who?" and be glad that I'm confident enough not to read an opinion-as-fact article and assign it significant credibility. PS: A good first editing step is to ask "does my opinion-as-fact blog post question the capacity and potential of a professional web designer to understand simple concepts like string interpolation, and could they find this insulting?" before assuming that you've got it all figured out.
- crikli 15y agoPosts like this are little snapshots of a programmer's development during which he really thinks he has this shit figured out.
- dools 15y agoWhilst this article is indeed an opinion piece and strongly hyperbolic (and perhaps even didactic), I'm not sure why that offends you. I don't have any statistics about large or small organisations putting this into practice so I'm not sure what other facts I could have included apart from the examples I provided. The capacity of designers to understand anything isn't the subject of the post, so I'm not sure why anyone would be offended by that. The idea is that it's easier to find someone to work on HTML/JavaScript/CSS in a static HTML context than it is to find someone familiar with whatever frameworks you're using and it's templating language, then to have that installed locally (especially when you're not working with a long term in-house team of designer/developers and don't have lots of time to spend on training people). I also personally find it far easier and quicker to iterate and test new interface ideas quickly when working with static HTML so I like to be able to view my templates outside of the context of my application/framework etc. and then iterate without having to re-apply a bunch of templating code.
- luigi 15y agoI was inspired by this project for Node: https://github.com/hij1nx/weld https://github.com/hij1nx/weld And I tried the concept using Nokogiri in Ruby. I found that in practice it gets really tedious. I had to make sure that every single element I wanted to manipulate had a unique id. Then I had to account for updating the content of an element versus an arbitrary attribute for that element. Or adding an attribute, like some data-* attribute. I realized why string interpolation is just so much easier. There's also the problem where the DOM parser changes the original HTML in some way. How will it deal with conditional comments for IE? Or slightly malformed HTML that you want to keep that way? I ended up going back to Handlebars.
- barumrho 15y agoBut now aren't you putting design into logic?
- saurik 15y agoAt first I thought this (and even typed out a long explanation of "the reason why you cannot make the assumption that your resulting document will be manipulated with DOM" involving "what if you want to change the presentation layer to PDF"), but then I realized that nowhere did he advocate mixing the DOM manipulation into his other logic; it could just as easily be a completely separate pile of "presentation to HTML" code that was entirely unrelated to the "generate content to present" layer.
- dools 15y agoPrecisely - in fact, if you want to change the output to JSON, you don't need the HTML templates at all. You just use the same code you were going to use to extract the data from your persistence layer and then output it however you want.
- barumrho 15y agoHmm. I do understand what you are saying, but in most cases where you are outputting HTML, how is this really different from using templates? I see templates as a way to reduce redundant code. The examples on the blog post are simple (e.g. removing a node, which is easier with 'if' statement), but it will probably be messier. Regarding alternative formats like JSON or PDF, I guess you can add a layer there.
- saurik 15y agoFirst off, let me be clear (as I'm concerned that your bringing up this unrelated "messier" argument is the beginning of me being used as a proxy for the author): I am not generally arguing in favor, I was simply countering that specific argument against. I will now describe why they are different, but I do not want this to be taken as a defense of the method. The way it is different is that it is an inversion of control inside the template, not that it is changing up the layering. You still have a "construct data" layer and a "present data" later, and you can still swap out the "present data" layer with something unrelated, such as a normal template engine or whatever else you wish to use to generate JSON or PDF. However, inside the "template", rather than having HTML with embedded logic (where you can almost envision the HTML calling into the logic to insert text or execute flow control at specific points), you instead have logic that manipulates the HTML via DOM, modifying the HTML to contain text at specific points. You could probably even make a compelling argument that these are duals of each other.
- ronreiter 15y agoYou are plain simply wrong. First of all, logic in templates is something which is OK to have. Different templates display information in different manners. Second thing, I don't think you've seen how awful and unmaintained code which manipulates DOM instead of templating looks like.
- dools 15y agoThe point I'm making, though, is that the challenge of solving "maintainability of DOM manipulation code" is a simpler problem to solve than the creation of the perfect templating language. What's more, a good DOM manipulation strategy and library can be really easily ported to any language, freeing up your templates to go wherever you may feel is appropriate in the future.
- Harkins 15y agoInstead of including if/then/else logic in the template, templates are duplicated for each branch and the logic is pushed up to the controller. This takes on hand-managing duplicate code (because there will discrepancies between the "logged in" and "logged out" version every time someone forgets they need to change two files, or doesn't notice there is a second version to touch) to avoid having any code in templates (which it labels as technical debt without support). This does not seem like a worthwhile tradeoff to me. And the author doesn't address loops, which often want to have special treatment of first or last elements, even/odd rows, and other small bits of logic. When you combine these things, you're going to have a combinatorial problem, I can just imagine a shopping cart table with templates like shopping_cart_item_list__table_row__last_item__logged_in__even_row__multiple_quantities__discounted_item.html And what's with the really confrontational tone? This article would've been improved by spending a couple hundred fewer words putting words in the reader's mouth and insulting their tools/code. There's a chance this could be useful in some situations, but I sure don't want to spend any time talking to this guy.
- dools 15y agoLoops with special treatment for first and last items is quite simply dealt with by including a list of items (for example) in the static HTML mockup, the first and last of which is different from the middle one. EDIT: Also in response to the issue of double handling, I did mention this in the article: In that second example of course, we've got a bunch of duplicate markup, but that's not our problem. That is the job of whatever system you're using to fragmentify your templates and re-use common assets
- deleted 15y ago[deleted]
- X-Istence 15y agoI've been waiting about 4 minutes for his web server to send me down the bits for the site. --- Your hotlinks to ditaa.org seem to be down because the server on the other end is serving stack traces ...
- pyre 15y ago> As soon as I'm looking at more than one programming or > markup language in the same file, I'm looking at > spaghetti code. By this definition the following is 'spaghetti code': $dbh->do("delete from my_table"); Following his logic: 1. Realize there's SQL and Perl in the same line. 2. STOP EVERYTHING 3. Start attempting to fully abstract SQL into Perl so that no one will ever need to write a line of SQL again. 4. Die an old man, never having accomplished this task.
- notaddicted 15y agoI've actually seriously considered keeping all my SQL queries in their own files, and reading them into local variables on load. It would allow them to be tracked and edited individually... but I now use an ORM.
- pyre 15y agoThe point being that ORMs have limitations. Advocating that something is 'one-size-fits-all' is foolish (not claiming that that's what you're doing).
- einhverfr 15y agoI do keep the SQL queries in their own files. The only difference is that they get loaded into the db (as stored procs) at first and then called by name. Works well.
- draegtun 15y agoThis is called the Phrasebook pattern and was probably being pushed as best practise until ORM's took hold. * http://ootips.org/yonat/patterns/phrasebook.html http://ootips.org/yonat/patterns/phrasebook.html * http://www.perl.com/pub/2002/10/22/phrasebook.html http://www.perl.com/pub/2002/10/22/phrasebook.html * https://metacpan.org/module/Data::Phrasebook::SQL https://metacpan.org/module/Data::Phrasebook::SQL
- ExpiredLink 15y ago> .. but I now use an ORM. "ORM is an anti-pattern": http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern
- DarkMeld 15y agoHaving to loop through arrays to translate data into html elements is the majority of the problem. I'd be happy with just a solution to that.
- einhverfr 15y agoWell, the only time I have ever said exactly this was about SQL-Ledger which used a home-brewed template system (which sucks big time) and which is mostly spaghetti code (in the true sense, of logic wandering aimlessly between modules in ways difficult to understand and predict. Of course the fact that the template system sucked and the code was spaghetti were unrelated except the fact that they were authored by the same (IMHO inept) developer. On to the article though.... I think that what the individual is discussing in fact is something different, which is the need for stable API's between layers of the application. I am very skeptical of his idea that all projects can benefit from his proposed solution. Indeed in areas like complex reporting, a template is conceptually simpler than HTML mockups that have to be populated by Javascript. At that point XSLT on the client starts making a lot of sense.... However, not at all sure that's always a win compared to templates. But then XSL files pose all the issues he is complaining about! The beauty of templates on the other hand is the ability to create diverse output. XSL is no different there. One can create a LaTeX file, an HTML file, a CSV. Anything else. For systems that need that diversity, going with HTML and Javascript is a net loss.
- snprbob86 15y agoFunny, we've been doing this with a modified-Backbone.js site and have found it requires tedious, manual management of an excess of IDs and classes, plus an error-prone mountain of jQuery expressions. What I'd really like to do is go 100% the other way: all functions, all the time. A view could just be a named function, accepting the object(s) to be rendered as arguments, define some closures for callbacks/event handlers, then return a DOM structure.
- Animus7 15y agoI've been doing exactly that in my more recent projects, and it works extremely well for simpler views/shallow DOMS. But it turns into write-only code pretty fast when you have tons of callbacks flying around for highly interactive elements.
- snprbob86 15y agoFor one-off actions, like the "save" and "cancel" buttons, callbacks don't descend into madness. Most UIs have very few commands which need true event handling. And the ones that do, the commands are often pretty simple one-button -> one-command. Sometimes many-buttons -> parameterized-command. For everything else, you can use data-binding. If you're already writing lexically scoped render functions, you can trivially create a data-bindable local object in a variable to eliminate the event management process. Instead of an onclick event for a checkbox, you can trivially set the checked property to be equal to an observable value box containing a boolean. With the right abstractions, callback spaghetti is not an issue.
- wwweston 15y agoI've been thinking about some of the ideas in this rant for a while now. I might not have put it in quite such an opinionated manner (templating systems aren't usually my biggest problem), but I pretty much agree with a few things: 1) Fragmentation is a problem, particularly with some templating systems. Layouts should almost always be a single file. Things going inside the layout should probably be single files. 2) As long as templating means sprinkling extra tokens to process throughout a document, there's going to be some coupling problems. Transforming a document based on some external criteria is an interesting alternative. There's certainly a number of transformation based solutions out there, some of them pretty powerful. But as I was thinking about this a few years ago, it occurred to me that maybe I don't want a powerful uber-transform set so much as I want a simple descriptive set of semantics for addressing content into nodes of a document. Then I thought about where I'd seen this kind of thing come up before in the realm of document styling: DSSSL and XSLT vs CSS. The simple descriptive CSS won out and has worked out more or less well. So... I came up with something I called `CAST` (Content-addressed Style Templating): http://weston.canncentral.org/web_lab/CAST/about.html http://weston.canncentral.org/web_lab/CAST/about.html Basically, you use a subset of CSS selectors (or XPath queries) to pick out a node of a document, then you specify a content rule, and the engine drops a content string into the document node. I ended up writing my blog around the idea. I ended up being pretty happy with a very simple set of rules, despite the fact that there's not much too the system beyond that -- for example, there are no rules for conditionally hiding a node based on whether or not it's needed, no rules for repeating certain nodes. I think those things might be nice, but it turned out if I was willing to push a little bit of the view down into model layer, I didn't need them at all, and I was (I kindof tend to think that any application is going to have a bit of model-view bleed-across anyway, you just have to figure out how you'd like to manage it). If anybody's curious, this post made me get off my behind and put the code up on GitHub: https://github.com/westonc/CAST/ https://github.com/westonc/CAST/ But it's in PHP, which I suppose will probably turn off a lot of the cool kids, so I should probably write a Ruby or Clojure version. :)
- dools 15y agoYep this is pretty much the idea. The key thing is, though: however you do it on the backend, that's entirely a coding problem. DOM manipulation sucks? Well, solve that problem, which is where something like your CAST library comes in. It's easier to solve the problem of making a nice, easy way to "address" content (I used "animate" but basically they're the same thing :) than it is to solve the multitude of problems caused by choosing a technology stack and creating templates in it for your application.
- generators 15y agopoor guy haven't heard about jinja2.
- zobzu 15y agoits a little more like native software's gui. that is, with website templating, its, well, template driven. pieces of codes are here and there in the template, following template's will. with software, your app is code driven. the gui follows what the code tells, instead. even if in both cases you have a mvc these days.
- djbender 15y agoThis is so confrontational, I couldn't even read it. Stop putting words in my mouth.
- cheeaun 15y agoThis approach reminds me of hquery (for Ruby on Rails) by choonkeat: http://blog.choonkeat.com/weblog/2008/10/hquery-an-unobtrusive-server-script-implementation.html http://blog.choonkeat.com/weblog/2008/10/hquery-an-unobtrusi... https://github.com/choonkeat/hquery https://github.com/choonkeat/hquery
- dools 15y agoYes! In fact, in the Q&A he even says this: Nope. "hquery" is just a library I wrote to do USS in Rails. I believe any language / framework can have its own USS renderer. I'm totally in agreement on this. Any language or framework can address this very simply - we don't need "one to rule them all".
- CyruzDraxs 15y agoThe moment a programmer thinks they know the ultimate solution to a problem is the moment they understand the problem the least. No, templating is not perfect. Nothing a programmer does is perfect. Our job, as programmers, is to make stuff suck less. We break stuff until it works. We squash bugs until we can't find any more. That doesn't mean what we've built is perfect. It means what we've built is the best we could build with our current understanding of the problem. I don't think of spaghetti code as the presence of logic in presentation code, I think of it as a lack of separation of what SHOULD logically be abstracted. I find the code it labels evolves over time as the common abstraction level of things increases and we move closer and closer to fully isolating concerns.
- voidr 15y ago> A typical example written in PHP would look like this: That's not how templating works, that's just some messed up code. I totally disagree with the idea that having static HTML as templates and transforming them with DOM manipulation is better then templating. When you do DOM manipulations you make assumptions about the structure, if that structure is changed by somebody, you are screwed. The less assumptions you make the better. Also last time I checked DOM parsing was a relatively slow process, even if it would be better than templating it still has to justify the performance overhead. Also let's not forget that writing if's are easier than writing DOM queries. Templating allows separation of view logic and business logic, I find it much cleaner to have the view logic in the templates, this is in fact what the author complains about, but how is having both database calls and layout logic in the same place cleaner?
- rickmb 15y agoThe main problem isn't templating engines. And although a better solution is always welcome, a bit of procedural code inside a template is not a big problem either. The real problem is that so many projects and frameworks don't have a powerful enough View layer that is separate from the (preferably optional) templating engine. In many cases it's even worse, and the templating engine is the entire implementation of the view layer. This pushes a lot of view logic into the templates, where it quickly degenerates into spaghetti. (In even worse cases, any logic the templating engine can't handle gets coded inside the controllers, and view logic starts leaking through the layers.) Fragmentation into purely static templates is only a solution if you've dealt with with all the other view-related issues, and still end up with too much logic in your templates. And by "too much" I mean that it results in errors and maintenance overhead, not just that it looks ugly. Intensive use of logic inside templates is definitely a code smell, but you have to be careful not to address the wrong problem. The templating method itself is rarely the root cause.
- buster 15y agoIsn't this 2011 where web pages use Ajax and contain a lot of logic, because.. well.. Javascript and stuff?
- Alexandervn 15y agoIsn't this all the same? <span><?=$salary?></span> <span>{{ salary }}</span> <span id="salary"></span>
- bergie 15y agoThere is one important difference: the server-side templating engine will probably retain the id attribute in the last case, meaning that the templating information remains usable also on client-side. We use RDFa for somewhat similar purposes.
- judofyr 15y agoI've talked about "template animation" (or "mockup-driven development" as I've called it) before, but focused mostly on how to achieve static files that can easily be opened in the browser (without any server components) and still be modular (layouts/partials): http://timelessrepo.com/mockup-driven-development http://timelessrepo.com/mockup-driven-development This article seems to solve modularity by splitting it out into different files. On the same page you can have dozens of modules that can have several different states;how are you supposed to combine them all? How do you say "this page contains a sidebar, a blog post, comment section" and that there should be a "new comment"-form if the user is logged in and "delete"-links if the user is a moderator? In the example in the article, it seems that would be solved by having blog_post.html, blog_post_logged_in.html and blog_post_moderator.html, where 90% of the content in the files are duplicated. Beside, in the example templates you can't actually open the templates in a browser (because it only contains the content, not the stylesheets, script-tags etc. that you need). So if the designer wants to see how it actually looks, he still needs a server that can wrap the layout around it. Okay, but maybe you don't need the "view this template without running the server"-requirement. I'd still argue that dools' current approach is brittle. The reason is that he's now tying together two layers (the template layer and the animation layer) and there's no easy way to see what the animation layer will actually do. This means that small changes in the template might invalidate the animation. You really don't want to re-write the animation just because the designer switched from <h3> to <h2>. This problem is easily solvable though: Use custom attributes which doesn't conflict with HTML/CSS: <form> <dl class="error" id="whatevsError" animate="error"> <dt>You have to do something about this</dt> <dd>The reason we ask you do do this is so that we can laugh all the way to the bank</dd> </dl> <dl> <dt><label for="whatevs">Whatevs:</label></dt> <dd><input type="text" name="whatevs" id="whatevs" /></dd> </dl> </form> However, as you're adding more features to these attributes, you'll actually end up with another template language; it just happens to be encoded in HTML/XML. From here on we might wondering, why should we "hide" the logic inside attributes (where it can be easy to miss) when we can use a more distinctive and effective syntax? To summarize: - If you want to separate the template and the animation (so that you can easily change the template without updating the animation) you need to stay away from HTML/CSS-semantics and use custom attributes/tags that you know won't conflict. - If you use custom attributes/tags you've essentially created another language which deals with the logic for you. - If you don't care about the "view the templates without running a server", you might as well use a completely different syntax (which probably is going to be easier to understand than the "hide everything in the DOM"-approach).
- yycom 15y agoAn article without a byline has zero credibility.
- simonw 15y agoTemplating by manipulating the DOM is one of those bad ideas that just keeps on turning up. At first glance it seems like a eureka-moment flash of purity, but the practical realities of it are pretty horrible. For any change to the page more complex than tweaking copy or maybe changing an element (a ul to an ol for example) you'll have to update both the HTML and the DOM manipulation code - killing your separation of concerns. Even worse, you have to have a complete understanding of how what the DOM manipulation code does before you can edit any of the HTML at all - otherwise you might accidentally kill the page by changing the order of two seemingly unimportant elements, or deleting an unused div. You'll also be forced to make all sorts of compromises in your markup to accommodate the templating layer, which will drive your front-end engineers crazy. Finally, there are extremely useful aspects of regular template languages (like template inheritance and includes) which don't map at all neatly to a DOM manipulation engine - so you'll probably have to compromise on those and end up inventing your own weird attribute-driven template engine. I'd suggest approaching this idea with caution. There's a reason most popular template engines are designed the way they are: practicality beats purity.
- dools 15y agoActually, my suggestions is just to encourage template implementation and refactoring with impugnity. There are perhaps ways of refining workflow to ensure that ids and classes are perhaps changed less than other aspects of the markup and used as hooks to "animate" the templates, but any time lost fixing broken templates as a result of an incompatible change pales in comparison to the time spent going back and forth between designers and developers to fix a problem where the scope happens to fall in between 2 skillsets (particularly when dealing with people in different timezones).
- dendory 15y agoI always get entertained reading the latest stories about templates and the latest innovations on how to make web sites work, and how (language x) is so old now, and everyone should use (language y) because it's more logical. I built my own custom CMS in 2008 and have been slowly improving it, and to this day I have a full dynamic site working on less than 600 lines of PHP, HTML and JavaScript. No JQuery, no need for a dozen includes, or keeping up to date on the latest patches of 12 different code bases. Yet the site keeps chugging along, even got to the front page of HN without any issue handling the load, while some sites mysteriously go down, but it's never the developer's fault, they just had a problem with their backend db server, or forgot a critical patch, or ne of their libraries didn't behave well with another library under heavy load... Not sure what my point is, I guess that there's something to be said for keeping it simple, and not chasing new technologies without reason..
- dools 15y agoGlad I could entertain :)
- extension 15y agoViews have logic, sometimes very complex logic. If views are not allowed to have "code" in them, or are functionally crippled in some way, then presentation logic is probably going to get mixed in with the domain model, because there won't be any other place to put it. The programmer needs to have complete discretion in where they draw the line between domain and presentation. This codeless view mythos arose because HTML includes a lot of rich interactive capabilities, and it's tempting to declare that these capabilities are all you will ever need in your presentation layer, but that is arbitrary and false. In most other contexts, e.g. GUI programming, a codeless view is nonsensical. Code is everywhere. And if it's difficult to write nice view code, that's likely a problem with your programming language and/or your APIs. Also, don't conflate model/presentation separation with server/client separation. Ideally, they are orthogonal concerns. To create the best UX, your views, and possibly your models, will have to straddle the network. In short, don't let your technology stack dictate how you modularize your application.
- antirez 15y agoSolution: don't use templates, generate HTML from code with a DSL that makes HTML and code the same thing. There is no longer the designer/programmer separation, now with CSS designers can do everything if your HTML layout makes a bit of sense. Also there is no need to generate complex HTML as it was the case N years ago, it is mainly a semantical affair, and fits perfectly inside the code. Templates suck, they fake an abstraction layer that actually does not exist since the code and the template are strictly connected in all the non trivial cases. It's just a lame substitution layer forcing you to switch from one file to the other while coding.
- dools 15y agoI think that having a separate DSL that abstracts HTML/CSS/JS is not the answer. When you abstract HTML (or SQL or whatever) you find that eventually your abstraction basically has to do everything that the thing you were abstracting needed to do in the first place. I think the "just use CSS" or "we can boil HTML/CSS/JS down to a subset of reusable chunks" doesn't work. It's simpler to just let these technologies be what they are, and remove the need to care!
- antirez 15y agoYou are right, I don't mean "abstract HTML", I just mean to provide a way to generate it from code using the same syntax of your code. This is what I use: https://github.com/antirez/lamernews/blob/master/app.rb#L1388 https://github.com/antirez/lamernews/blob/master/app.rb#L138... For instance to write <foo> <bar id="4">content</bar> </foo> You write: H.foo { H.bar(:id => 4) {"content} } So everything you can write in HTML you can write in this DSL, there is no real abstraction, but it is Ruby code like in all the rest of the application.
- dools 15y agoOkay so now here is my problem with this: I can't just find whoever knows HTML/JS/CSS and get them to work on this by sending them a ZIP file with the interfaces in it. They have to install the environment and application and then iterate using this DSL, refreshing the page to see it in the browser. It is far easier to find a really good designer, who knows HTML/CSS and a bit of JS (probably jQuery) than it is to find a really good designer, who knows HTML/CSS and a bit of JS (probably jQuery) and then is also comfortable configuring a Rails environment and also proficient enough with coding Ruby to learn quickly and without support or input, this custom DSL. There are already so many people that have the skills you need, why force the issue? Let the technologies be what they are. In my experience, communication between team members is the single highest cost in building software. Unless you're a designer/developer or you're working with a small team on your startup and you happen to have all the skills you need right there in one office and timezone, you'll need to confront the issues of resourcing, iteration and staff changeovers - what I'm advocating is that we play to the prevailing skill separations and reduce the communication overhead.
- jasonlotito 15y agoSo, he's trying to rewrite XSLT. Gotcha.
- cousin_it 15y agoI agree that putting code in templates can lead to spaghetti. But the OP's proposed solution seems suboptimal because loosely coupling the template to the application code via "template animation" will lead to convoluted code with lots of hardcoded IDs on the application side, and brittleness on the template side because there's no way to see which IDs are used by the application. A less extreme but more practical solution would be to disallow code in templates by making templates accept a data structure, like JSON, and giving them the bare minimum of capabilities to render it. So looping over an array is okay, checking for the existence of a property is okay, but querying the database from the template is impossible by construction. This way you also get language independence because many languages can generate JSON. Also, you can have compile time error detection (for both the template and the application code) if you use some sort of schema for the data structure, like Thrift or Protocol Buffers.
- rimantas 15y agoThey guy is wrong thinking that business logic does not exist. Then it all goes downhill from there. Extremely narrow view of the world he does not even try to uderstand.
- carsongross 15y agoThe idea of templating as a separate activity from coding is what, in my opinion, is wrong. It comes from the days when "front end" guys didn't want javascript or "back end" logic in their files. Personally, I would just prefer that the code for a button be located with that button. Crazy, I know. Back in the day (2001) I didn't understand the separation of logic and presentation, although I grudgingly admitted that the front end guys had a lot of stuff to worry about that I didn't understand (cross browser issues, rendering issues). These days, with jquery and widely available standards compliant browsers, plus all the design resources available on the web, we should all be both front end and back end developers, to a greater or lesser extent. So we should strive to have clean code, but that, IMO, doesn't have nearly as much to do with separating concerns like templating and application logic as the "pure-templates" guys think. I disagree with the "pure-model" and "pure-controller" guys on the back end for the same reasons. They fall into the same platonic manichaeism: the world is a mess and if only The One Pure Way were followed, we'd be good. Instead, grouping things logically as best we can and trying to minimize spooky action at a distance ("where the hell is the code associated with this button coming from?!?!") should be the goal.