Develop Reference

Callback in Dart when the page is fully loaded

You may know that I totally fell in love with Dart and Polymer and once again, I have a question addressing those two technologies.
My application is a fairly compex polymer app written in Dart. There are some sort of "pages" whereas a page is shown once the user performed an action. The pages contain various types of content and the number of items can reach from zero to a few hundreds.
To enhance the user experience I've build a loader which you can register elements at and once all registered elements loaded, the page is shown. This works and feels pretty amazing but it's way to complicated to make sure to react on all the different states which can occur and overall I am not that happy with the loader thingy.
Thus I wanted to ask if there is anything in Dart or Polymer which helps me to show a loading indicator as long as not everything is fully loaded and once it is done, it hides the loader?

Use an HTML/CSS-only loading indicator and style it so that it becomes hidden when the unresolved attribute is removed from the body. See https://www.polymer-project.org/0.5/articles/styling-elements.html#preventing-fouc

How many tags is too many for Google Tag Manager?

I want to set up a number of tags within GTM (at the most 25) and noticed in the support section Google states too many can affect the size of the container as well as how much data the browser has to download. As a general rule of thumb is anyone able to tell me how many is too many?

This isn't really a question about GTM so much as content you put on your page in general. And in general, the more stuff you have on your page, the longer the page will take to load, and the longer things take to load, the longer the visitor has to wait for your site to be fully displayed and working.
So basically "too many" can loosely be equated with overall page load being "too long". You could have 100 tags that on average take a total of half a second to load (e.g. perhaps most of your tags just (potentially) execute 1 line of code like setting a variable), or you could have 1 tag that takes a minute+ to load (e.g. perhaps some code block for some 3rd party script hosted on a bad server that takes forever to respond and maybe also loads lots of other scripts and images and stuff).
So how long is "too long"? There's no "general rule of thumb" here, because it's highly subjective and based on what's in those tags, what your site is (the "theme"/purpose) and who your target audience is.
In fact, I'd say if we're going for "general rule of thumb" instead of "evaluate my specific circumstance", the only truly accurate answer here is to always be of the opinion that your site is taking too long to load, so that you always strive to make it load faster, or failing that, make it load in such a way that the visitor doesn't notice or have to wait before interacting with your site.
In any case, I guess the tl;dr of this is GTM is basically telling you it's not some magic box that gets delivered in the same amount of time regardless of what you put into it because that's not how the internet works.

All events in Backbone app fire twice. Occurs randomly

First, some background. I'm fairly certain this is not because of zombie views. I use requireJS and I have only one instance of main views at any given time.
Also, this behavior is random, I haven't been able to reproduce it even once, but several of my users have pointed it out and shown me a video where every click on the app seems to trigger the handler twice. The clicks happen very very fast. It can't be mechanical failure of the mouse because the problem has been reported on multiple machines. The reports are from people with fast Internet connections, for what it's worth.
Is it possible that two instances of the app are running at the same time? Are there any steps I can take to isolate a problem of this kind in backbone?
Apologies for the wall of text, please let me know if I can put up any extra information or relevant pieces of source.
Edit : I've managed to recreate this in Opera. After stepping through part of the code that fires twice (I was inspecting code that opens a modal), I was able to look at the view that triggers the event. Both views have the same CID, so this cannot be attributed to Zombie views right?

In my experience, this is almost always related to zombie views, or other DOM leaks. My best friend in this case if the Web Inspector Profiles -> Take Heap Snapshot and look for detached DOM tree (type "detached" in the search field).
It can occur in tricky cases, even if you think you're only instanciating views once.
Beyond that, you'll have to show us some code ;)

The problem here was that I was running a third party library that reports JS errors. Due to a n error on their part, event bindings on page were affected and this caused the confusion inside the application.
Moral of the story - Whenever you hit an error you feel is impossible, remove your third party dependencies one by one and confirm the problem is your fault to begin with.

Will infinite scroll cause browser crashes?

I implemented infinite scroll like so:
new_page_value = 1;
$(window).scroll(function() {
if($(window).scrollTop() >= $(document).height() - $(window).height() - 200) {
new_page_value = parseInt(new_page_value) + 1;
get_page(new_page_value);
}
});
When the user almost reaches the bottom of the page (200px left) the function get_page() is called. This contains an ajax call that gets all the contents of the new page and appends it to the <body> of the document.
Now I just realized if my site gets big and instead of having 10 small pages I have a gazillion giant pages then the user's browser might crash if they are persistent enough to keep infinite scrolling for long time.
Would this be a possible solution to this problem:
I will keep appending the new pages to the document <body> until the 10th page, after that I will be replacing the <body> content entirely instead of appending. So using html() rather than append().
I just don't know if this will actually work to prevent crashes. Will .html() clear the "memory" of prior html that was brought in via ajax?

I really think this is a common issue for many sites with AJAX list content. So let's take an example at some of the most popular ( think of scale = experience ) websites and their solutions :
Google Images
If you check out images.google.com and you search for whatever, for e.g. "guiness", you will see a page full of results (actually the images are ajax loaded, not the html-code, so the page is with fixed height) and when you scroll at the bottom there is a button "Show more results". This might be solution one of your problem, but is it really necessary to place a button at the bottom after, for e.g. the 10-th page? I really think it is generally a good solution for page usability and memory leaks, but it is really not a necessary option as we can see in :
Facebook
Facebook Newsfeed is another story. There is a button "Show more posts", but I really don't know when exactly it is displayed rather than loading the next page of posts. It happened to me once to load 10-15 pages of posts, only by scrolling. And you know Facebook posts include videos, photos, AJAX comments and a lot of more Javascript fancy stuff, which take a lot of memory. I think they've managed to do this after a lot of research, how much of the users scroll to the bottom.
Youtube
Youtube has "Load more videos" at every page, so the solution is basically similar to Google, except that Google renders the whole html of the page and on scrolling just loads the images.
Twitter
Twitter supports infinite scrolling. Yep, they do it may be because tweet is 140 characters and they don't need to worry about memory so much. After all who is willing to read more than 1000 pages of tweets at one page load. So they don't have a button for "load more" and they don't need one.
So there are two solutions :
Use infinite scrolling ( you should consider how much content you load and how rich it is )
Use button : "Load More"
Most of all, you should not delete already loaded content of a list.
Nowadays everything is Javascript and Javascript has garbage collection, so it is very hard to unload the DOM ( if it has Javascript, not plain text ) and manage to remove the Garbage from Javascript. Which means that you won't free the whole allocated memory of the unloaded content from the browser.
Also think about of your requests, why would you need to load again something, that you have already loaded at first place. It costs another server request, meaning another database request and so on.

I have worked with this before and here are some of my thoughts:
a) If you are appending data to the memory page(s) at a time then it is not an issue, some browsers might not respond well but most of the lastest browsers will render without any problem so long as there is enough memory on the target machine, you could probably see how the ram usage increases as you append pages. Use chrome for this as each page is a separate process and it has an inbuilt task manager
b) regarding usage of html(), it indeed removes the markup but it does so at a heavy cost as it tries to take care of special conditions and has an overhead and accesses all the controls nested within the container that you are replacing (not sure about the last pat), but it has a cost. A simpler way to clear the DOM would be to use the innerHTML property and set it to empty, jquery does this but it is at a later point in the html() api. open up the api and look at the method.
using innerHTML
$("<selector>")[0].innerHTML=""
Also deletion of pages sounds weird to me as a user, what if I want to go back to the initial comments and please dont think about making it an infinite scroller too.. I have tried and given up after the number of bugs raised but we had a genuine use case for it and I had to stick a button up there, but this wasnt when the user scrolled away from the first page, this is when the user landed on a 3rd page but now needs to see the results above it.
Hope that answers your question and btw infinte scrolling is your friend use it, dont over engineer a case which will probably only be tested by your QA team. Its better to spend your effort somewhere else.

Yes it will, if i may suggest an idea after let's say 5 pages just delete the first page and append the new one instead of deleted all of the previous pages. good luck :)

DOM memory and CPU management

I am creating a progressively built single-page (if Javascript is enabled) "blog" which uses AJAX to request HTML for new pages the user is navigating to.
When the user navigates to new pages they will be added one after another into the DOM in a small window with "overflow: hidden;":
<div id="foo" style="width:200px; height:100px;">
<div id="bar" style="width:999999px">
</div>
</div>
When an AJAX call returns success a div will be appended into #bar.
How will it affect the browser when there are a lot of hidden pages outside the #foo width?
Do I need to remove the divs from the DOM as the user navigates away from them? Then I will need to make a new AJAX request if the user chooses to navigate to them again. :(
Thanks
Willem

No matter what people say GC will do for you, whether in JavaScript or C# or Java, watch out and forget the silly promise of automatic management. Clean it up explicitly and sleep well.
Very simple reason: closures leak and leak pretty bad the moment you move out of most simplistic scenarios (the case both for brower's JavaScript as well as C#/java).

Modern browser layout engines are generally smart enough to not process elements that are hidden, so it won't take much CPU power. However, adding large numbers of nodes with highly complex object graphs can be expensive in some browsers, so I'd be careful with this. Also note that even if they're not laid out, they're still there as part of the DOM, and memory usage could conceivably become a concern if these nodes are large.