Live data from Hacker News

Better than templates, building highly dynamic web pages

blog.fastmail.fm

31–40 of 44 posts

Re: Better than templates, building highly dynamic web pages

#31

This is, in my opinion, even worse than writing straight HTML in JavaScript. Before I get into anything, I just want to point out that with jQuery, you can do the same thing: $(' bar ').appendTo('.baz'); I'm not one to condone the over-use of the bloated jQuery, but in this case I sure would. Anyways, my biggest gripe with this whole thing is the fact that writing any markup in your JS, or anywhere other than an HTML…

That jQuery snippet is the best possible way to make your site sluggish.

http://jsperf.com/tmandersondomtest

The best possible way? Well, that's not true at all. In fact, that was even faster* than whatever method this article was talking about (genDom).

Either way, my point wasn't to say 'just toss it all over to jQuery!' My point was, if you think this technique is cool, you're probably using jQuery and you could've been doing this for years. Years!

Anyhow, this is a huge deflection from what I was really trying to convey. Basically, I don't think this (the 'sugared dom' method from the article) is solving anything. HTML should define your markup and JS should just be filling in the blanks (and not creating them).

*Please note that I do realize my DOM creation was particularly minimal (however, hardly differing from the 'sugared dom' test mentioned in the article) and is hardly a sufficient test. Really, I just wanted to show that you'd have to be doing a ridiculous amount of DOM manipulation to see any significant drop in performance.

Re: Better than templates, building highly dynamic web pages

#32
post #15

The DOM is a live object while a string can be sliced and compiled in a function. If you run a template once, either to generate a form or a simple list, the DOM is faster than innerHTML. But if you need to repeat a template(loop), use partials or recurse, interpreted DOM manipulations will become a degree of magnitude slower than a compiled function concatenating strings. Quickly slow enough to loose the snappy effe…

A compiled function only gives you a really fast string creator. It doesn't make the innerHTML call any faster than it is (which is really fast, but slower than the DOM). You can also use cloneNode to cache frequently reused DOM snippets.

The creation of a complex DOM tree(nested loop, partials, recursion) is what is slow compared to string concatenation. The injection time of the string need parsing, and will take a bit longer. But in total less time than DOM manipulations.

I'm trying for a few months now to remove the last innerHTML bits of pure.js and haven't figured out a way yet to make it as fast.

Re: Better than templates, building highly dynamic web pages

#33

This is, in my opinion, even worse than writing straight HTML in JavaScript. Before I get into anything, I just want to point out that with jQuery, you can do the same thing: $(' bar ').appendTo('.baz'); I'm not one to condone the over-use of the bloated jQuery, but in this case I sure would. Anyways, my biggest gripe with this whole thing is the fact that writing any markup in your JS, or anywhere other than an HTML…

Constructing DOM with javascript doesn't preclude the separation of duties. Nothing stops you from separating the presentation logic and the business logic into separate javascript files. In fact I believe this article describes a very viable approach. Especially if one is building a complex highly interactive web-app (as oppose to web-site). The term "presentation logic" has the word "logic" in it. And the best way to handle logic is with a proper programming language.

P.s. Didn't they mention XSS

Re: Better than templates, building highly dynamic web pages

#34

This is an interesting approach. One downside is that it's much less readable than the Handlebars template. Using Coffeescript for the "templating" functions would actually clean it up a lot.

Would you mind posting a Coffeescript snippet to demonstrate that?

Re: Better than templates, building highly dynamic web pages

#35

This is an interesting approach. One downside is that it's much less readable than the Handlebars template. Using Coffeescript for the "templating" functions would actually clean it up a lot.

Would you mind posting a Coffeescript snippet to demonstrate that?

http://coffeekup.org/

Re: Better than templates, building highly dynamic web pages

#36

This is an interesting approach. One downside is that it's much less readable than the Handlebars template. Using Coffeescript for the "templating" functions would actually clean it up a lot.

Would you mind posting a Coffeescript snippet to demonstrate that?

  items = [ 1, 2, 3, 4 ]
  el 'div#message', [
    el 'a.biglink', href: 'http://www.google.com', [ 'A link to Google' ]
    el 'ul',
      el 'li.item', [ "#{item}. Item" ] for item in items
    'There are lots of items'.localise() + '. ' if items.length > 1
    'This is just plain text. I have no effect' ]

Re: Better than templates, building highly dynamic web pages

#37

Earlier quoted context omitted.

I didn't see the point of HAML - until I used it. I'm a complete convert now: the syntax is just so superior to being productive in markup for me. In my current app I'm including a small ember app, having to write straight markup for handlebars (hamlbars is a bit awkward) is painful compared to how quickly you can produce markup with HAML. Personal preference of course, but to me the difference is night and day in te…

I guess the thing for me is that my HTML is usually simple enough that there isn't significant time spent writing it. So I can see there could be productivity gains, but I don't see they would be sufficient to justify the technical debt in introducing a new syntax.

I seriously think you're overstating the technical debt incurred by HAML. The docs aren't the best - they cover stuff, but are hard to navigate sometimes - but the actual language has a very shallow learning curve in my experience picking it up myself and bringing front-enders up to speed with it when I work with them on projects.

Re: Better than templates, building highly dynamic web pages

#38
post #5

I have a problem with this, as it appears to break the separation of concerns. Don't the programing guru's tell us over and over NOT to mix markup into code and vice-versa?

Try for yourself. What the guru's tell you is a heuristic.

When this heuristic fails, you waste lots of time mangling data to fit it into dumb markup instead of writing a simple loop with a couple of ifs.

Re: Better than templates, building highly dynamic web pages

#39

The idea that CSS selectors could be used for element creation is awesome. It would be so convenient to write: var link = el("a#top.link[src='http://google.com'][data-external='true']") Instead of: var link = document.createElement('a'); link.setAttribute('id', 'top'); link.setAttribute('class', 'link'); link.setAttribute('src', 'http://google.com'); link.dataset.external = 'true' Someone needs to bring it to W3C for…

I get that what you're trying to do is keep it syntactically correct javascript, but just in case, have you looked at HAML [1] and/or Jade[2]? Both templating languages that allow you to write HTML in that kind of way. Even less syntax than what you're writing there.

I guess you have the overhead of the template language and rendering them though still.

[1] http://haml-lang.com/

[2] http://jade-lang.com/

EDIT: Added links.

Post reply on HN