In my web application I would like to complately avoid html and use only javascript to create web-page's dom tree.
What is faster writing web content in the traditional way in html <div>Some text</d开发者_高级运维iv>
or using javascript dom render, like this: div.appendChild(document.createTextNode("Some text"));
?
Stick with the traditional HTML. It's not only faster than doing everything with javascript, it's much more maintainable.
Unless there is a compelling reason otherwise, stick with the straight up HTML and use javascript for the more interactive pieces of your app.
Speed is a secondary concern to correctness - that is, serve the functional requirements first, then make it fast where necessary (some places, it might already be fast enough).
In this case, the decision to use static markup versus JavaScript is a question of who is consuming your document - is it only users with JavaScript enabled? If so, it doesn't matter too much. Do you need to take search engines into consideration? Disabled users? Thin clients that don't have full JS support, or paranoid users with JS disabled? In all of these latter cases, having semantic markup, not cluttered with superfluous elements, enhanced with JavaScript, is the only correct way to go.
The traditional approach is going to be faster because the browser only has to download, interpret and display. The approach you're suggesting would cause the browser to have to download, interpret, change * n times and then display.
That's as far as rendering goes.
As far as maintainability goes, you're creating a nightmare. That's the key to development. The number of nightmares in maintainability is proportional to the "quality" of the code, IMHO. Performance and optimization should come second to maintainability. (There are exceptions, of course. Nothing is black-and-white).
HTML was created to be an expressive language. Javascript wasn't. End of story, in my opinion.
HTML is parsed and generated by the browser and then entered into the DOM. Using javascript to manipulate the dom piece by piece is more overhead.
Imagine if you had to retype an article from a magazine. Now imagine doing so if every sentence was on a new page. ALthough the end result is a copied article, you had to spend all that time flipping pages.
By far the traditional way is faster, the user downloads the file, it is there, parsed and done.
If you do the JS way the page has to be built client-side, EVERY time they load the page.
That is just a horrible way to build a page IMHO and a nightmare to manage/update/create
If you're going to be doing a lot of changes to html through javascript I'd recommend using a templating library like trimpath.
I find it interesting that you would consider creating a document purely through Javascript. It's actually faster to create elements using the DOM and document.createElement
than .innerHTML
property. This method creates the document objects directly, whereas using innerHTML
requires the parser to iterate over the HTML and create the elements.
On the other hand, using Javascript instead of writing the HTML directly would require the Javascript to be parsed and executed, creating additional overhead over the HTML parser.
HTML (templating) is generally considered to be a more intuitive, modular and maintainable approach for DOM manipulation.
A couple of places to get you started:
jQuery Templating Engines: jQuery templating engines
Google Closure Templates http://code.google.com/closure/templates/
I already tried in the past doing a 100% javascript built component for an ajax chat. It turned out, it was less maintainable, took more time to code and the advantage where very slim even tough it was probably a project that could benefit a lot from that javascript DOM approach.
Even if you think there could be advantage, there isn't. Stick to pure HTML.
2019
(Probably the correct answer is correct for 2010). Here's an answer for 2019 with benchmark.
Generating table with nested div
, total of 500 rows, 250k table cells, 10 nested divs per table cell.
<!-- Pure HTML by server -->
<html>
<head></head>
<body>
<table>
<?php
for($i = 0; $i < 500; ++$i) {
echo '<tr>';
for($j = 0; $j < 500; ++$j) {
echo '<td><div><div><div><div><div><div><div><div><div><div>' . $i . '/' . $j . '</div></div></div></div></div></div></div></div></div></div></td>';
}
echo '</tr>';
}
?>
</table>
<script>
alert('finish');
</script>
</body>
</html>
And the below HTML generated by JS:
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
</head>
<body>
<script>
$(document).ready(function() {
var html = '<table>';
for(var i = 0; i < 500; ++i) {
html += '<tr>';
for(var j = 0; j < 500; ++j) {
html += '<td><div><div><div><div><div><div><div><div><div><div>' + i + '/' + j + '</div></div></div></div></div></div></div></div></div></div></td>';
}
html += '</tr>';
}
html += '</table>';
$('body').html(html);
alert('finish');
});
</script>
</body>
</html>
Approx. Result:
| Download Size | Time 'til browser stops loading
--------------------------------------------------------------------------
HTML generated by server | 680,000 bytes | 00:01:48
HTML generated by JS | 570 bytes | 00:00:28
Tested it on Chrome v70 on Ubuntu 18. HTML generated by JS is approximately 400% faster in this test case (speed & download size will depend on how big is the HTML of course in your real case).
Conclusion
Always stick to normal HTML for many reasons (usually for readable/maintainable code), unless you're dealing with huge HTML then you may consider generating it by JS.
IMHO I think compile javascript is a good solution to create fast applications to web.
As you I was wondering the same and made a similar test as @evilReiko did:
In order to render a page containing a table with 1000000000 of records I found the following results:
- static html file : file size 32MB, page loading time 2.8 Min
- static html file with minified content: file size 12MB, page loading time 1.3 Min
- dynamic html file generated by JS: file size 612 byte (+ 713 byte of JS), page loading time 10.09 seconds...
精彩评论