> тормозят они как раз от географического положения. Роутинг половины файлов может
> быть нормальным, а другая половина пойдёт через Новую Зеландию, и хорошо На "дальнюю связь" можно списать всё.
Но Вы пропустили, что проблема была решена, и быстро. Да и на очень медленных линиях работает доступ к прибору неплохо. И никакие многочисленные скрипты, страницы тяжелее не сделали, скорее даже наоборот.
При этом я, хоть программист, но не веб разработчик. Более того, я даже не читал ни одной книги, ни по js, ни по html. Наверное, не читатель ;)
Набросал, в виде эскизов, что вывести, записал основные получаемые данные, оченил, что будет сделано быстро, что с неизвестным мне результатом, скоректировал план.
Далее, спросил у Гугла, про темные для меня места и в js, и в html.. При весьма поверхностных знаниях большую часть выдачи по ajax я оценил как полуговнокод, и что повторяя некоторые примеры результат будет печален. Применил здравый смысл.
В итоге, оно заработало, быстро, и было потрачено мало времени.
И позже был прикол. Один человек копался в репозиториях, и у него возник вопрос. А на чём это написано? То есть, он посчитал, что код писался в чем то ином, и из него генерировался js.
Нет. Тут, как в шутке - программист на Си может писать на Си на любом языке программирования. Уж, как смог.
Итого: Разработчик не знает что дабота с данными не выполняется мгновенно? Не подозревал, что сввязь в самое неподходящее время обязательно будет медленной?
Не знал, что параллельная обработка "портянки" данных быстрее?
Написать/заимствовать простые функции, которрые отработают быстрее, чем подгрузится готовая монстр-библиотека, моветон?
А.. и так сойдёт.
На прошлой неделе, была работа на Си. В одном приборе объём базы данных увеличили, и от того поиск стал занимать до 15-20 секунд, что сильно огорчило пользователей.
После выбрасывания старого кода, и написания осмысленного, поиск стал занимать 8..120mS.
Разница в быстродействии более чем в сто раз.
