First of all, am I the only person using JSONML? And second of all, would you recommend using JSONML for inserting dynamic HTML or is InnerHTML more efficient?
Bare in mind that (in IE) not every innerHTML is writable (innerHTML isn't standar compilant anyway). So closer you come to appending nodes rather then inserting html, better you are. As far as I can see, jsonml thingie creates DOM elements whch is nice. I can only sugest you to make some huge dataset, insert it in two different ways and mesure performance yourself.
While superficially used to perform similar tasks, JsonML and innerHTML are quite different beasts.
innerHTML requires you to have all the markup exactly as you want it ready to go, meaning that either the server is rendering the markup, or you are performing expensive string concatenations in JavaScript.
JsonML opens the door to client-side templating through JBST which means that your template is converted from HTML markup into a JavaScript template at build time. At runtime, you simply supply the data and you end up with DOM elements to be inserted or to replace an existing element (something innerHTML cannot easily do without extra DOM creation). Rebinding only requires requesting additional data, not the entire re-rendered markup. This is where large performance gains can be made as the markup can be requested/cached separately from the data.
For simplicity, innerHTML has been the preferred method for the HTML-Message pattern style of Ajax. But tool-sets like JsonFx can make using JsonML and JBST just as easy while delivering a full browser-side templating Ajax pattern.
JsonML and the connected libraries (templating, etc.) seem to offer an efficient way of generating dynamic HTML on the client side.
When I say efficient I mean, I mean that the programmer does not waste time or effort while completing his task. But I am not sure if you meant to ask whether using innerHTML is faster and requires less resources on the client side.
Related
Right now I have a hard-ish to read HTML page composed of ~300 lines of code. Most of the code however comes from the same form repeated multiple times, with no changes whatsoever except for the id (which differs by a number). Would it be an acceptable or even encouraged practice to use Javascript to attach the same piece of HTML code to the DOM as many times as I need it? I'm a beginner to JS, so I don't have any clue about any performance impact that this could cause, and I can't see anything bad coming from this approach.
In my opinion, semantic HTML that is verbose and not rendered through JavaScript is the way to go. The only reason you wouldn't want to do this is if your application could scale and more forms would be rendered in the future. If there are a set amount of forms, debugging and handling data will be easiest by simply hardcoding all of the HTML.
I know in dojo we can create any widgets in two ways,
programmatically
declaratively
To create widgets programmatically we'll use JavaScript, whereas for declaratively we'll use dojo attributes in HTML tags.
Can someone explain me what are the differences between them?
which one is mostly preferred and why?
Difference
Well, there are certain differences between both ways. In the declarative way, all configuration is based upon HTML attributes like dojo-data-props but also some other attributes like the value, title, ... . So the DOM node you create actually serves as some kind of placeholder.
When you create widgets by writing JavaScript code, you will have to provide the DOM node you will attach it too, but the biggest difference is that it will not copy the HTML attributes from that DOM node. The DOM node here only serves as a container, not a placeholder.
Preferred
There is no solution that is mostly preferred and it usually depends on the requirements of your application and what you think is the cleanest way of developing.
Personally I like the declarative markup because in the end it's a part of the user interface. However, you can go as far as you want. I've seen people creating stores and widget event handlers in a declarative way too, but I personally prefer to write them in JavaScript since they're not a part of the user interface.
There are also other reasons that might change the way you would create widgets. For example, one of the biggest drawbacks of declarative markup is that you need to parse the page (for example with parseOnLoad). This usually is slower than creating the widgets programmatically. You can improve it by only parsing certain DOM nodes, but then you have to write additional code (and it still isn't faster).
Just a small note; this doesn't mean that the declarative way is slow. It's just an extra operation that should be executed and thus, it's a bit slower but chances are that the end user will not even see the difference.
An advantage of the declarative way however is that, when loading the page, the end user is able to see the placeholder. If you pick the right placeholder (for example, a <select> for dijit/form/FilteringSelect and dijit/form/ComboBox), the end user will at least see something. If you create everything programmatically, the end user will see a blank page until the JavaScript code is executed.
So if performance is one of the requirements, then you could choose creating them programatically. If you like to have seperation of code where the presentation layer is seperated from the business logic, then I would recommend using the declarative way.
But in the end, both solutions are good.
I am a newbie to html/css/javascript and code like this really scares me:
http://code.google.com/apis/maps/documentation/javascript/overlays.html#InfoWindows
Is assigning html to javascript variable a good practice? or I hope there is a substitute.
There is nothing wrong with it. After all, it is really no different then typing the same thing outside of the javascript block.
I do however find, that the formatting and the likes can be annoying. On use JQuery a fair bit, and depending on what I might be doing I might use a .html() or .clone() method to create html form another element.
JQuery also has a template plugin which when used does allow for you to get slightly better formatting, and you can also specify dynamic values. Which is great for creating dynamic tables that update with Ajax for example.
Another side note, the fact that example you gave was on a Google site, would usually be enough to convince me it is OK to do ;)
There's nothing bad in it. People have been doing this since there was a thing called DHTML :-)
AFAIK, this is one of the most performant ways to build a part of document (later to be inserted to DOM or whatever).
In this case you have to, since google Maps API requires explicitly to pass a HTML content (and not a reference to some hidden element in page or loaded via ajax).
This don't mean it's a bad practice: for example, I always use a HTML string along with some custom template system, so that I can pass infowindow HTML in a loop, changing dynamically some chunks of markup with data retrieved by a JSON.
Anyway you can still use an element into the DOM and then pass its outerHTML string to the API if this makes your application more performant with an improved maintainability
When generating dynamic content, which way is better to simply create the HTML and insert it into a .innerHTML or to create elements in the DOM directly?
I'm not concerned with complexity or other. Just processing time on the client.
Which is quicker?
If I had to guess in order of efficiency (low processing time) this would be:
DOM Creation
.innerHTML property insertion
direct writing
This would be inversely related to the complexity of implmenting:
direct writing
.innerHTML property insertion
DOM Creation
This is a validatin question? Can someone validate that this is the trade-offs for determining how to update the client (i.e. javascript) when considering complexity and speed?
Research:
I'm not concerned with security like they are here->
InnerHTML vs. DOM - Security
InnerHTML vs. DOM
This is not a duplicate as it covers only part of my question.
In my experience they are basically comparable in performance. However if you use the DOM approach you get better accessibility to the power of closures so you can bind data and functions to the individual DOM elements directly.
For performance, the main thing, regardless of approach, is to hide or remove the part of the DOM you want to modified, make all you alterations outside the DOM, then put it back into the DOM as one single operation to avoid unnecessary reflows (repaints) in the browser.
From my own personal tests they're all fast enough for most needs. But if you're doing something crazy like creating thousands of elements to a page the fastest way is to use document fragments. John Resig wrote a good blog post about it. http://ejohn.org/blog/dom-documentfragments/
It is not necessarily true that DOM insertion is faster than updating innerHTML, see benchmarks at http://segdeha.com/experiments/innerhtml/ and http://www.quirksmode.org/dom/innerhtml.html, for example. Implementing the innerHTML solution might be quicker, just note that it is not available when using XHTML.
Lots of jsPerf benchmarks cover this topic; try searching the web for "jsperf innerhtml domelement" or other meaningful combinations of your search.
I have a unique situation where I'm building a site that will call data via AJAX and load it into "containers" (basically just divs styled and arranged according to elements retrieved from the AJAX callback).
I'm not sure how many of these unique container types will be created (styled and rendered) when all is said and done, so I'm looking for a solution that will allow me to store containers in a separate file(s), load them dynamically as they are needed, populate the content, and rendered them on page.
I'm not sure if I should write my own loading/template solution or use an existing JavaScript template engine (e.g.: Pure).
The reason I'm hesitant to use an existing JavaScript template solution is they all seem focused on binding and looping on existing page elements, whereas I'm more concerned with the ability to load-up and binding to dynamic content.
You might want to give jQote a try, it's the most powerful jQuery templating engine as it let's you use scripting inside your templates.
Go check it out, it'll suit your needs, I promise.
http://aefxx.com/jquery-plugins/jqote
After starting with JST, we moved to EJS:
http://embeddedjs.com/
It's more powerful, syntactically simpler, and you can put your templates in different files.
The website is pretty nice too.
I found http://code.google.com/p/trimpath/wiki/JavaScriptTemplates pretty useful for this.
I am planning to use jTemplates for a future project that will need to do something like this, it is very fast and has a nice jQuery plugin