Live data from Hacker News

Better than templates, building highly dynamic web pages

blog.fastmail.fm

21–30 of 44 posts

Re: Better than templates, building highly dynamic web pages

#21
post #3

My browser does 10,000 operations / second with innerHTML, and 15,000 operations / second with DOM. In every ajax application I've ever made, this is negligible, compared to latency, server processing time, and downloading time. I guess this saves you 1ms for every 30 elements you create? I'm sure there are some cases I'm missing where this might make more of an impact, but from my understanding of the article, this…

Speed wasn't really his main selling point. He was mostly just pointing out that speed isn't a disadvantage for his method.

That being said the speed might actually make a difference with mobile browsers for some applications.

Re: Better than templates, building highly dynamic web pages

#22
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 file, is just plain ugly. Beyond that, it's a pain to manage, and totally screws up the whole "separation of duties" paradigm that the web community seems to be quickly forgetting as of late.

Keep your markup where it should be, in your HTML files, because as we all know, HTML is XML and XML is meant to give semantic meaning to data. JavaScript should be a means of transport for data to its relevant structure, not means of giving visual structure to data. Leave that to the HTML and CSS.

Even templating doesn't do it for me 100% of the time and there are better ways. I'm a heavy believer in separation of duties, and any JS programmer should be too. Every time I come across any heavy-handed DOM manipulation in JS I cringe.

As for this article, there's 523637483723526334632 other libraries/frameworks/micro-frameworks that do this same thing, and if you're going to do it, just use what you're already probably using: jQuery. You're probably already abusing it anyways.

Re: Better than templates, building highly dynamic web pages

#23
post #3

My browser does 10,000 operations / second with innerHTML, and 15,000 operations / second with DOM. In every ajax application I've ever made, this is negligible, compared to latency, server processing time, and downloading time. I guess this saves you 1ms for every 30 elements you create? I'm sure there are some cases I'm missing where this might make more of an impact, but from my understanding of the article, this…

Keep in mind, not everybody is running a desktop browser with that sort of cpu horsepower behind it.

Half of the iPhones ever sold - something like 80 million devices - are pre iPhone 4. There are a lot of low end Android devices on the market _right now_ with worse browser performance than an iPhone 3 (I've got a I had to drop an entire development branch from a project late last year due to insufficient performance of mobile device on-handset ajax. (We fell back to on-server html rendering and innerHTML updates, and even _that_ is annoyingly slow to me on low-end phones.)

And unless you have gathered data showing otherwise, this _probably_ really does apply to you. I was collecting some mobile use data last week - across ~70 websites that I've got Google Analytics access to, the average mobile visits was 14%, and the peak was just over 28%. This was across a range of markets and a variety of levels of "mobile friendliness" of the web design. (Biggest and probably most obvious takeaways from that exercise: B2B sites are a standard deviation or more below average for mobile visits, personal/leisure B2C sites up to one or two SD's above average. 80+% of mobile visits exit on a page with contact details - a phone# or address.)

Re: Better than templates, building highly dynamic web pages

#24

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.

Re: Better than templates, building highly dynamic web pages

#25
post #16

I have a library for this sort of thing (but without the HAML-style # and . niceties :-/) which can also output DOM Elements or HTML (escaped by default) from the same code by flipping its output mode: https://github.com/insin/DOMBuilder The output modes are implemented as plugins, so you can also add other sorts of things, like the template mode I'm in the progress of writing, with template inheritance and the like.…

That looks pretty cool, but I have to ask... you're using with? Really?

Re: Better than templates, building highly dynamic web pages

#26
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.

Re: Better than templates, building highly dynamic web pages

#27
post #16

I have a library for this sort of thing (but without the HAML-style # and . niceties :-/) which can also output DOM Elements or HTML (escaped by default) from the same code by flipping its output mode: https://github.com/insin/DOMBuilder The output modes are implemented as plugins, so you can also add other sorts of things, like the template mode I'm in the progress of writing, with template inheritance and the like.…

That looks pretty cool, but I have to ask... you're using with? Really?

Yes, it's perfect for building templates in code based on an object defining your templating API - code which is run once at startup with little or no assignment and no ambiguity between the contents of the context object and anything else, e.g.: https://github.com/insin/sacrum/blob/master/fragile/lib/frag...

You could easily go back and plug in use of a single-letter variable instead of the implicit context object after the fact, but it's nicer to work with while you're building stuff up.

Re: Better than templates, building highly dynamic web pages

#29

This reminds me of HAML. I've never really seen the benefit of adding a layer that doesn't really add much onto something that is well-known and thus easily maintainable. Performance benefits seem mostly irrelevant, as pointed out by others.

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.

Re: Better than templates, building highly dynamic web pages

#30
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?

I'm with you. CSS for looks, JS for logic, HTML for structure.

And the whole strategy goes down the crapper with NoScript & RequestPolicy for the most part unless I find it worth explicitly allowing them.

Post reply on HN