Clever Geek Handbook

Angularjs effect on creating dom elements, pure js vs jqlite

I have a directive in Angularjs that will have a table with a lot of rows (over 1000), so my boss said that I shouldn't use anchor to create the grid content (due to the angular ~ 2000 limitation in anchor), and instead i have to create dom elements on the fly.

And I did it with angular.element(...)

and it works. BUT now I am wondering if there could be a performance improvement if I use native js document.createElement

?

So jqlite is slower than pure js? how much will it affect when generating over 1000 lines of html?

jquery faster? slower or equal to jqlite?

UPDATE:

@Joe Enzminger +1 for binding one time would be nice for a report / print viewable view. BUT the grid has inline editing, so it needs two-way snapping. it has 19 columns with an input and two buttons and a save button in the last column. each button has ng-show

, and the save button has ng-class

to change the icon based on the state of the rows. so (19 * 3) +1 two-way bindings.

this grid is a data entry form of some kin: D, and all lines should be visible and not paginated.

UPDATE2:

I forgot to mention that right now I have an empty element tbody

in my template and all of its content is generated as a simple dom and injected into it without any data bindings of any type. all interactions are handled with good JS ability manually: D.

+3


source to share


2 answers


I'm sure one of them is "faster". However, perhaps only marginally - I don't think there is much of a chance that you will be using it over others.



However, from a maintainability standpoint, I would suggest using Angular's one-time binding. The mythical "~ 2000" peg limit really refers to watches, not pegs, and is not really a limit, not a benchmark. By using {{:: var}} inside ng-repeat you will get much more user-friendly code with comparable performance than creating custom DOM on the fly, and it won't create hours that could impact performance.

+2


source


There are two things here: DOM rendering performance and angular $ watch ($ digest) performance. In both cases, trying to optimize document.createElement

vs is angular.element

not worth it.

For DOM rendering, the bottleneck is not JavaScript execution speed, but browser view (see: html5rocks ) and recalculations (see: Google Developers ). Whether you use it document.createElement

or angular.element

lightly, because performance hit and UI blocking occurs when you add or modify elements on the page, not when you create DOM elements in memory. This is why most modern Batch DOM UIs update rather than making many tiny updates (e.g. ReactJS, Meteor, EmberJS).



For performance $ watch and $ digest defeat the performance depends on the number and complexity of the anchor expressions (e.g., {{things}}

, ng-bind

, ng-show

, ng-class

etc.), which should evaluate angular each cycle $ digest. If you remember that in most cases a simple action like a click will cause a $ digest loop, thousands of bindings can be evaluated with each click. It is recommended to use one-time bindings to minimize the number of hours and keep the watch as simple as possible.

In the default directive ng-repeat

(presumably what you are using to generate the mesh), you really have no fine control over these two considerations, other than preferring as much as possible to one-off bindings or to split your data model. This is why developers with a high degree of sensitivity completely bypass ng-repeat

and create their own directives . If performance is key to you, you should look into something like this.

+2


source






More articles:


All Articles