Павел Тысляцкий

Посмотрите следующий вопрос на стеке stackoverflow.com/q/14113278/880326.

А чем встроенная dev консоль (F12/Resources/Local Storage) не устраивает?

localstorage (ie 8+), application cache (ie 10+), indexed db (ie 10+, ff, хром), web sql (хром, опера, сафари), file writer (хром, опера, сафари)

Посмотрите www.w3schools.com/css3/css3_transitions.asp

Попробуйте для контейнера с флеш на обработчики скролла поставить event.preventDefault(); event.stopPropagation();

Wev SQL (depricated) используется в хроме, сафари, опере и их мобильных версиях caniuse.com/sql-storage
IndexedDB используется в IE10, лисе и десктопном хроме caniuse.com/#feat=indexeddb.
Те то что ниже IE10 в пролете, там только localStorage (IE8 и IE9) и Вам скорее всего прийдется комбинировать IndexedDB и Web SQL для решения этой задачи.
Суть в том что реализация их API асинхронная, в отличии от синхронного localStorage, из-за чего могут возникать проблемы в реализации вместе со сторонними библиотеками (например хранения тайлов для google maps).

Некоторые браузеры спрашивают или сразу поддерживают больше 5 мб, которые прописаны в спецификации. В любом случае для localStorage хранение данные больше 5 мб это уже плюшки браузеров.

Данные:
1. Время синхронизации брать с сервера.
2. На клиенте хранить собственно данные, последнее время синхронизиции (прислонное с сервера) и id данных, измененных после последней синхронизации. Если данные еще нет, то последнее время синхронизации принимаем за 0.
3. На сервере хранить данные с дополнительным полем last_update или журнал изменения (отдельная таблица) с временем изменения и id записи (В любом случае такой журнал можно сжать до размера самих данных, удалив старые дубликаты id).
Описание:
1. Клиент стучится на сервер отправляю последнее время синхронизации и изменненые данные после последней синхронизации.
2. Сервер сохраняет данные если не было конфликтов, и возвращает обновленные данные после последнего пользовательского обноновления (можно без пользовательских обновлений), новую дату обновления. А клиент обновляет данные и удаляет отосланные id записей после синхронизации.
3. Если были конфликты (дата последнего изменнения пользователя меньше последнего изменения на сервере и хеши данных отличаются), то можно отложить обновление и передать пользователю данные для мержа, при этом обновив last_update таких записей до даты синхронизации возвращаемой пользователю. После чего пользователь снова синхронизируется. Если опять возник конфликт, то повторять до тех пор, пока не разрешится.
Запрос:
{time: , data: []}
Ответ:
{time: , data: [], mergeData: []}
Замечания:
Те localStorage хранит до 5 метров по спецификации, то возможно не стоит заморачиваться по поводу большого объема данных. Хотя можно добавить на сервер метод, который будет возвращать количество обновлений в байтах по последнему времени изменений и завязать дополнительную логику. Если данных больше 5 мб, то стоит использовать indexed db или web sql (привет ie 8 и 9), но в браузерах реализован асинхронный API.

Не знаю насчет литературы, но можно например глянуть как ребята из jquery делают: github.com/jquery/jquery/tree/master/test или на других проектах вызывающих доверие.

По идее грузить не должно, но в любом случае можно воспользоваться профайлером. Например jsfiddle.net/k4kwP/4/, данный пример позволяет сравнить время пустой функции empty, время логики logic, время записи в dom writeDom, время записи в dom один раз вместо 4ех writeDomOnce и время которое требуется всей Вашей функции timer. Можно заметить, что основное время идет на записть в дом (возможно лучше не 4е раза писать в dom, а один). Для меня профайлеры помогают найти наиболее медленный код, для одной функции он достаточно бесполезен, можно прогнать весь Ваш код, возможно ошибка не в данной функции.

1) Вы зависите от шрифта, те для разных шрифтов текст будет разной длинны
2) Вы зависите от размера шрифта, те для разного размер шрифта будет текст разной длинны
3) Вы зависите от тегов, теги могут содержать стили с разными шрифтами, шрифты в теге h1 могут отличаться от шрифтов в теге p, к токму же падинги, маржены и др. стили
4) Вы зависите от необходимого размера разделения, те сколько пикселей по ширине и высоте примерно должно помещаться в один блок и как это должно быть на разных устройствах/размерах экрана
5) Вы не говорите как доржен вести себя html элемент не вмещающийся Ваш страничный блок

* Я бы для нескольких колонок советовал бы caniuse.com/multicolumn
* Я бы для нескольиких страниц элемент фиксированной высоты и overflow: hidden тогда количество страниц определяется Math.ceil(content.height / container.height), а очередная страница оределяется как top: container.height * (page_no - 1) и переключение на js (можно добавить градиент фон-прозрачный, чтобы обрубание текста выгладило красивее).
* Если разметка довольно простая и содержит много блоков, то $(content).children() и для каждого дочернего элемента высчитываем длинну символов и разделяем на блоки по длинне.
* Если разметка более сложная, то берем каждый элемент и высчитывем дилнну в зависимости от тега (класса, стиля) при этом запоминая в каких тегах мы находимся, когда доходим придельной длинны, то вставляем завершиющий тег дива страницы, а следующую страницу начинаем с сохраненных тегов разметки (теги inline h1, p и тд в теории должны закрываться страничным дивом).

ЗЫ. Есть всякие js плагины реализующие ... для обрезания больших блоков, то что я когда-то использовал делило текст на части и в зависимости от длинны уменьшало/увеличивало отображаемый текст до тех пор, пока элемент не будет необходимой дилнны, возможно Вам подойдут похожие плагины.

Если у Вас картинки скриптом подгружаются, то почему бы пе поставить простую проверку мобильный или десктопный браузер (window.navigator.userAgent), если просто грузить с меньшим качесвом можно смотреть на тип соединения к интернету (window.navigator.connection).
Если же через css, то нужно смотреть в сторону @media.

Большого опыта нет, так небольшое приложение на phonegap с картой и еще сейчас пишу один теманический сайт одной из основных фич которого будет карта и сейчас ищу для себя лучшее решение с картой.

По поводу API: в Вашем случае отлично подойдут яндекс карты, но как альтернативу могу предложить посмотреть на google maps api и на основе OSM: leaflet, mapbox и openlayers.

По поводу js фреймворка: выбирайте то что больше подходит Вашему сайту независимо от карты, тк карта по сути представление, такое же как, например, список или таблица. Возможно Вам хорошо подойдет какой-нибудь MVC фреймворк. По поводу JS MVC фреймфорков можно найти не одну статью на хабре.

Из замечаний, можно обратить внимание на количество маркеров на карте и их группировку (по этой теме также можно найти не одну статью на хабре, хотя с группировкой для яндекс карт решение есть из коробки), чтобы точки отдавались быстро и чтобы dom не тормозил, особенно на это стоит обратить внимание если планируете активно использовать на мобильных устройствах.
Также если основная фишка сайта карта, то давайте ее сразу на главной странице с наиболее нужными пользователю точками, но Вы и сами предложили отличные примеры сайтов.

Надеюсь мой коментарий хоть чем-то Вам помог.

В google maps api есть diresctions API. Там же можно найти примеры. Данная штука в пару строк интегрируется с гуглокартами, но вроде бы можно использовать отдельно. Поддерживаются типы: DRIVING, BICYCLING, TRANSIT, WALKING, а для авиаперелетов нет. Но для них (авиаперелетов) думаю достаточно описать прямую (дугу если учитывать что земля круглая), для этого подойдут стандартные polyline.

Сам ищу сервис который качественно предоставляет возможность строить маршрут из пункта А в пункт Б, пока остановился на предложенном мной варианте, тк больше ничего не нашел.