1

This project's DOM tree is big and nodes must be created dynamically. There are 2 ways:

1) insert child element in parent as string and let the browser infer the child, i.e.

html:

<div id="parent"></div>

and javascript:

str='<input type="text" id="child" size="30">';
documen.getElementById("parent").innerHTML=str;

2) have js create the child, i.e.

parentElement=document.getElementById('parent');
childElement=document.createElement('input');
childElement.setAttribute('id','child');
parentElement.appendChild('childElement);

I've been using 1, and started getting very strange behavior when the tree got BIG and the application data got BIG. Like, e.g.

aValue="hi";
str='<input type="text" id="child" size="30" value='+aValue+'>';
documen.getElementById("parent").innerHTML=str;

The result would be a text line input element containing hi, and a few more added elements to DOM tree and data to app data, and all of a sudden the text line would read

+aValue+

And say under chrome debugger you'd see no causal relationship with said result. I tried removing previous children then inserting new children, it had no effect. Also, I get the same exact behavior in chrome, ff and opera. So it seems memory is getting corrupted in the common core browser c++ code.

So the question is: has anyone developed a stable BIG web app (order 100k lines) with BIG dynamic DOM Tree (order of 1000 nodes) and BIG app data (order of many Megs). If so, exactly what method of Dynamic DOM Node creation have you used. Any other tips with regards to memory management would be appreciated.

angrygophermusic
  • 31
  • 2
  • Whatever you do, don't do it all yourself. There are plenty of great tools out there. In fact, there are too many great tools out there. – lbstr Mar 11 '16 at 21:31

3 Answers3

0

Rather than using all these extra calls to build your DOM, you might want to investigate jQuery. It makes it pretty easy to dynamically create and manipulate DOM data and should be browser independent.

This post talks about creating new elements: The preferred way of creating a new element with jQuery

Here's a link to jQuery: https://jquery.com/

Community
  • 1
  • 1
NickT
  • 214
  • 1
  • 5
  • Do you have any performance testing to support that? Can you explain how using the jQuery library would be faster than using native javascript? – Adam Konieska Mar 11 '16 at 21:30
  • @AdamKonieska jQuery is a library written in javascript. It's become the industry standard for writing client side javascript. From the Wikipedia article: `jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML.[2] jQuery is the most popular JavaScript library in use today, with installation on 65% of the top 10 million highest-trafficked sites on the Web.[3][4][5] jQuery is free, open-source software licensed under the MIT License.[1]` You can find the answers to your questions here I think: https://en.wikipedia.org/wiki/JQuery – NickT Mar 11 '16 at 22:12
  • That's the point. jQuery is a *javascript library*. Using jQuery is going to be more computationally expensive because jQuery introduces overhead. Its faster to use native javascript than it is to call the same/similar javascript via jQuery. – Adam Konieska Mar 11 '16 at 22:20
  • @AdamKonieska Quite an unusual response, but if you want to write 4 lines of "native javascript" for every 1 line of equivalent code in jQuery be my guest. Writing clean, clear, maintainable code should be the goal. If you're doing all your computationally intensive tasks in javascript, you're doing it wrong. It's a single-threaded interpreted language. This will be my last and only response on this topic. – NickT Mar 11 '16 at 22:29
  • I guess I was being overly harsh but I felt like you didn't check out the article. Widely used libraries are pre-compiled and cached by the browser whereas user scripts (what you were calling the native code) is interpreted on the fly. I don't have any profiling data but seeing as how this is widely used by millions of sites it's probably out there. Essentially when you write script it's interpreted and compiled which creates a much larger cost than using something the browser already has cached/compiled. Plus browsers are optimized specifically for jQuery. – NickT Mar 11 '16 at 22:37
  • When you write code like `$('#myElement')`, jQuery eventually executes its own `document.getElementById()`. Its computationally faster to skip the bloat added by jQuery and use native javascript. You can see all the references to JS element selections in the unminified jQuery: http://code.jquery.com/jquery-1.12.1.js. That type overhead introduced by a library negatively impacts performance. – Adam Konieska Mar 11 '16 at 22:53
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/106060/discussion-between-nickt-and-adam-konieska). – NickT Mar 11 '16 at 23:04
0

I think my problem is that as the memory gets taxed more and more it exposes a bug of some sort in the mem<==>file_sys data swap. Say I have 8 mb ram, by the time say 6 mb is used by the web app, the underlying c+ (browser) code should io the rest of the data to some temp file(s). I exposed a bug therein. So jquery or otherwise this'll still pop up, I think. And that it pops up in multiple browsers, it reinforces this line of thought.

The approach I have now is to modularize the code. I'm building an app tree, where each node (a browser instance) contains is own functionality, and when the functionality is done, the data is passed to the parent node (then to other child nodes if need be) and the instance closes. That way 100,000 lines gets broken up to say 20 instances each with 5000 lines. And the same granularization happens with DOM tree. The other thing I'm doing is to dynamically load .js functionalities, as needed (ala c+ dll).

Then remains the app data. There I'm moving the entire platform to node.js and I'm running the web app as a peer (not client-server), i.e. all io goes like:

local app js<==ajax==>local node js <==local io ==> local app data

So the app data is localized and chunked (as much as possible) async.

angrygophermusic
  • 31
  • 2
0

This is a bit late, but you might want to investigate the react library developed by facebook.

Not sure how much 'many Megs' are in your mind, but devtools are showing me a ~35Mb heap on their site. So it's worth checking out what they're doing.

RayWiis
  • 140
  • 6