Илья

Никак вы это на стороне сервера не сделаете.
Есть понятие клиент-серверная архитектура. Вам именно к ней, потому что фласк - это веб-фреймворк.

На клиенте (html/css/js/flash/silverlight/java-applet/schockwave/...) вы рисуете карты и ловите все эти клики, перемещения и т.д.. И в зависимости от логики вашей программы, в определенный момент формируете определенный запрос к серверу. Сервер получает данные и определенным образом их обрабатывает: пересчитывает, сверяет, заносит в базу... и выдает ответ клиенту. И так по кругу.

А зачем вы делаете jsonify? Передавайте прямо так в шаблон, списком обьектов, а в шаблоне работайте как с обьектами. user.id etc...

в курсе сюрпризов JavaScript относительно замыкание внутри closures.

Если для вас это все еще сюрпризы - рекомендую перештудировать какой-нибудь туториал или документацию. В JS все как-будто асинхронно, на самом деле там просто есть event loop.

Давайте разберемся на примере:

for(var i = 0; i < 10; i++) {
    setTimeout(function() {
        console.log(i);
    }, 1000);
}

Что у нас тут будет происходить. Мы берем цикл и 10 раз создаем отложенный вызов. Что при этом происходит... давайте представим себе что в JS все разбито на кадры. Цикл - один кадр, и пока он не отработает, какой бы он длинный не был - новый кадр так же не отработает. setTimeout не просто выполняет код с задержкой, через 1000 милисекунд в event loop будет добавлен очередной кадр. И любой "асинхронный" вызов так же просто добавляет кадр в event loop. Внутри же event loop все выполняется синхронно и по порядку.

Так вот, на момент, когда закончит выполнение кадр с циклом, значение i уже будет установлено в 9. А как мы выяснили ранее, JS ничего более не будет выполнять до этого момента. Посему отложенный код выведет нам одно и то же значение так как все они ссылаются на одну и ту же переменную.

Теперь, что происходит тут:

for(var i = 0; i < 10; i++) {
    (function(e) {
        setTimeout(function() {
            console.log(e);
        }, 1000);
    })(i);
}

Да собственно то же самое. Только за счет того что мы при публикации setTimeout используем замыкание и передаем i в качестве аргумента, срабатывает механизм называемый copy-on-write. То есть в замыкании не i а его копия (когда цикл перезаписывает значение i - все кто ссылался на это значение не по ссылке, копируют себе переменную, для простоты можно просто думать что каждый раз когда вы передаете что-то не по ссылке, происходит копирование).

Так как у каждого кадра, выполняемого в setTimeout есть своя копия i с нужным значением - все будет хорошо.

tornado.gen.coroutine + yield != асинхронность. Вызовы, которые делаются должны уметь работать асинхронно. Смотрим здесь первый пример:

class AsyncHandler(RequestHandler):
    @asynchronous
    def get(self):
        http_client = AsyncHTTPClient()
        http_client.fetch("http://example.com",
                          callback=self.on_fetch)

    def on_fetch(self, response):
        do_something_with_response(response)
        self.render("template.html")

Метод fetch объекта класса AsyncHTTPClient -- асинхронный. На это указывает аргумент callback (и название класса, конечно :)). Когда страница будет получена, вызовется _on_fetch. Как и в AJAX.
Пример ниже на этой же странице -- это переписанная версия того же самого, просто красивее, без лапши коллбеков. Для этого и нужна пара tornado.gen.coroutine + yield.

Вызов time.sleep(2) блокирует весь ioloop, вместо него можно воспользоваться чем-то типа

yield tornado.gen.Task(tornado.ioloop.IOLoop.current().add_timeout, time.time() + 2)

Но даже заменив эту строку, асинхронности не будет заметна. Это связано с ограничениями браузеров: они не умеют одновременно открывать одну и туже вкладку. Поэтому нужно открыть вкладки в разных браузерах.

Еще одно: декоратор @tornado.web.asynchronous не нужен при использовании @tornado.gen.coroutine.

Вот эту страничку нужно обязательно прочитать.

Если знания нулевые, как Вы говорите, начните с изучения базового синтаксиса. Java сегодня имеет довольно богатый, пусть и очень стандартный синтаксис: классы и интерфейсы, наследование, переменные и члены класса, методы и уровни доступа, управляющие операторы (циклы, условия), анотации, система пакетов. Вроде всё. Пусть этот список станет поводом для того, чтобы прочитать это в рамках java где угодно, будь то wikipedia, аль coursera, да хоть Шилтд. К слову, здесь не сильно важен язык программирования. Если до этого хоть что-нибудь изучали, втянете за пару дней. Иначе изучение может растянуться на пару недель.

Вот после этого уже можно копать вглубь. Здесь я бы рекомендовал вами упомянутого Кормена и Кнута. Первого нужно читать вдумчиво, выполнять все упражнения (каждое выполненое упражение это +10 к интеллекту). Кнута можно просто полистать. Оба годяться как справочники, но Кнут будто создавался таким образом. Математики у Кнута много больше и если Кормен может что-нибудь доказать "абы как", то Кнут себе такого не позволит. Из-за чего его читать долго и нудно: можете смело пропускать доказательства и возвращаться как было что-то не понятно. В любом случае, их читать действительно сложно. Осилите хотя бы Кормена - медаль Вам уготована.

Но и язык нужно знать и понимать. Поэтому здесь пора заняться и тем, для чего java предназначена - энтерпрайзом. А именно, умением не столько программировать, сколько разрабатывать продаваемые продукты. Здесь подойдёт филосифия java для начала. Когда наследование перестанет Вас пугать (или наоборот, пройдёт время чересчур увлечённого наследования всего и вся), можно приступить к банде четырёх. В то же время, умея строить сложную архитектуру, мы всё ещё смутно знаем что под капотом у java. Так что можно почитать про оптимизации в JVM (читал англ, не знаю есть ли перевод), ну и покопаться в openjdk, если будет излишняя увереность, лишнем не будет.

Собственно, это roadmap на очень долгое время. С самых начал до седой старости будете изучать java. Вполне возможно, что к тому времени, как начнёте банду четырёх (если начнёте), уже подойдёт долгожданная java 2.0 и всё нижеописанное потеряет значение, но чем чёрт не шутит? К слову, Кормен, и Кнут, и философия, и банда четырёх остануться, это скорее фундаменальные книги.

Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

UPDATE
На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,