1. почему не кэшировать хэши?
2. почему не использовать для расчетов вебворкеры?
3. почему бы не использовать канвас? Сунули строку как imageData, сделали какую-то трансформацию, проверили. Я бы вообще на шейдерах попробовал это сделать для ie10+, если честно.
4. почему бы просто не использовать ленивую помодульную загрузку+async/defer? Условно, если открываем какое-то письмо — загружаем сначала код, связанный с письмом, остальное потом. Открываем общий интерфейс — загружаем сначала код, связанный с отображением общего списка писем
Ситуации разные бывают. У меня вот, например, специализация в настоящий момент — приложения для хрома, тут достаточно легко игнорировать половину ие :)
А вообще зависит от продукта. Для медийных проектов на самом деле ie 9- не нужен зачастую по ряду причин. В общем-то из-за того что доля ie9 меньше чем у ie10. В бытность мою тимлидом в «диджитал-агентстве» не раз убеждали делать ие10+, потому что прибегают все почти всегда с подпаленными волосами на пятой точке — сделать нужно было уже вчера, а флексбоксами и прочими фишками заверстать банально куда быстрее. Вот и забивали на поддержку.
Или вот проект с WebGL внутри (кстати, это было полтора года назад, а проект получил awwwards). Там вообще недолго думая на ие9 забили, потому что поддержки девятки не было и быть не могло :)
К тому же если посмотреть — на медийных проектах доля пользователей с ie 9- меньше 1.5 — 2% суммарно.
p.s. я абсолютно серьезно, это, конечно, больше для фанатов js4k и так далее, но в реальности — да, это дает ощутимое уменьшение размеров загружаемого файла. Ближе к изврату, потому что сложно дебажить и так далее, но «все ради победы».
Там действительно был старый код, который уже не модифицировался — разные либы и так далее :) С инкрементальным билдом были определенные проблемы из-за особенностей сборки, там довольно были специфичные детали типа shared-кода и кода, генерируемого и хранящегося на сервере в памяти, сейчас я вижу это решаемым, тогда — это вызывало неллюзорные проблемы. И если правильно помню, один замороченный не очень популярный плагин тек, так что сборку приходилось перезапускать регулярно.
Плюс — как выше заметили уже, тогда в gulp-watch была проблема с удалением (или переименованием) новых папок, из-за этого оно стабильно вылетало. Компонетный подход с кучей папок был, которые периодически переименовывались.
В любом случае, собрать старые либы, которые уже не изменялись, в том числе для первоначальной «раскрутки» сборщика — лишним не было.
Хм. Посмотрел — да, действительно, есть какой-то аналог пайплайна.
Из явных минусов — отсутствие подсветки путей в IDE (я в webStorm обычно набираю имя файла, жамкаю cmd-enter и там есть пункт «создать файл по заданному пути и сразу открыть его»).
Очень вряд ли — возможность создавать свой синтаксис для инклуда одних типов файлов в другие. У меня лично последние два проекта — модули для хрома, там очень много компонентов, всунутых через shadow DOM, там нужно объявлять стили внутри шаблона, соответственно их нужно как-то подключать. Вариант, когда какой-то символ просто превращается в ..." + require($1) + "… — куда удобнее.
Сомневаюсь (просто не понял, честно говоря), как там подсасывать base64, так что 50/50%, может и есть оно.
В любом случае, это выбор каждого, но я пока что продолжу доверять gulp и browserify, которые мейнтейнятся двумя жирными такими сообществами, чем вебпаку, у которого автор явно пишет «чуваки, я это делаю в свободное время». Может, когда-нибудь потом, тем более что мои задачи вполне решаемы именно так.
100кб даже на медленном интернете — это не так много ведь. Почему не сделать а-ля фейсбук с его «пустышками», которые показываются до загрузки основного контента?
Рендер на сервере все-таки тоже занимает какое-то время, а отдать статику (особенно закэшированную) можно куда быстрее.
Кстати, если не секрет — какое у вас распределение пользователей по браузерам?
да, именно, там фолбэк до канваса, если нет webgl. потому он и лучше для быстрой графики, к тому же — большое сообщество.
проблема таких велосипедов не в том что они хуже, а в том, что не поддерживаются. Я вот с vue.js мучаюсь. Он проще, быстрее и эффективнее ангуляра, но реально мешающие баги автор очень медленно исправляет.
Ээх, велосипеды.
pixi.js возьмите, там и 20 тысяч спрайтов спокойно будут тянуться :) www.goodboydigital.com/pixijs/bunnymark/ — у меня фпс начинает всаживаться (с 60 до 57 фпс, но все же) на где-то 30к, насколько помню, меньше 25 кадров в секунду — это 50к зайцев.
Да, постараюсь. Как только обновлю проект на новую версию с рекомендациями (оно пока убрано в дев-ветку по ряду причин), сразу же опубликую.
Только это не nodejs приложение, все на клиентсайде :) В Web Workers. Пересчет сети на ~600 тренировочных данных и выдача около 100 значений занимает около 0.15 секунды, что вызывает просадку по перформансу. С воркерами — все нормально работает.
На всякий случай: я использовал готовую библиотеку, но там были достаточно интересные ньюансы, связанные именно с обучением.
Я уже писал в шапке — прилетело НЛО, поэтому я почистил ссылки на проект и повторно опубликовал. Там было около 200 просмотров всего и НЛО прилетело через 15 минут после публикации, так что могли видеть, но вряд ли.
Про plumber — спасибо, гляну, я в свое время видел его, но понял, что он просто решает какую-то специфическую проблему под windows, поэтому его все пихают «на всякий случай».
libsass быстрый, но поддерживает, что пародоксально, не sass, но только scss-синтаксис (во всяком случае, так было полгода назад, насколько я помню). А у нас в той команде почему-то так завелось, что форматирование не отступами доставляло всегда кучу проблем при мердже — потому и был переход с хтмл на jade, та же самая ерунда была. Форматирование отступами позволило сливать ветки гита с куда меньшей кучей геммороя.
Про инкрементальные билды — в моем случае все решалось установкой кэша для browserify в последнее время — у меня в том числе стили подключаются через JS по ряду причин.
На самом деле куда круче было бы научить клиентов пользоваться чем-то типа rizzoma или любых других последователей wave. Но увы, приходится работать в онлайн-документах.
Все, уже есть :) К сожалению, багу не заметил. Я обычно на полной громкости слушаю, управляю системной громкостью, честно говоря, вначале вообще управление громкостью делать не хотел.
2. почему не использовать для расчетов вебворкеры?
3. почему бы не использовать канвас? Сунули строку как imageData, сделали какую-то трансформацию, проверили. Я бы вообще на шейдерах попробовал это сделать для ie10+, если честно.
4. почему бы просто не использовать ленивую помодульную загрузку+async/defer? Условно, если открываем какое-то письмо — загружаем сначала код, связанный с письмом, остальное потом. Открываем общий интерфейс — загружаем сначала код, связанный с отображением общего списка писем
медиа-запросы это тонкая настройка, а вот флексбокс — гибкая универсальная разметка. Их можно и нужно комбинировать
А вообще зависит от продукта. Для медийных проектов на самом деле ie 9- не нужен зачастую по ряду причин. В общем-то из-за того что доля ie9 меньше чем у ie10. В бытность мою тимлидом в «диджитал-агентстве» не раз убеждали делать ие10+, потому что прибегают все почти всегда с подпаленными волосами на пятой точке — сделать нужно было уже вчера, а флексбоксами и прочими фишками заверстать банально куда быстрее. Вот и забивали на поддержку.
Или вот проект с WebGL внутри (кстати, это было полтора года назад, а проект получил awwwards). Там вообще недолго думая на ие9 забили, потому что поддержки девятки не было и быть не могло :)
К тому же если посмотреть — на медийных проектах доля пользователей с ie 9- меньше 1.5 — 2% суммарно.
Про особенности работы TCP — это что-то с чем-то.
Плюс — как выше заметили уже, тогда в gulp-watch была проблема с удалением (или переименованием) новых папок, из-за этого оно стабильно вылетало. Компонетный подход с кучей папок был, которые периодически переименовывались.
В любом случае, собрать старые либы, которые уже не изменялись, в том числе для первоначальной «раскрутки» сборщика — лишним не было.
Из явных минусов — отсутствие подсветки путей в IDE (я в webStorm обычно набираю имя файла, жамкаю cmd-enter и там есть пункт «создать файл по заданному пути и сразу открыть его»).
Очень вряд ли — возможность создавать свой синтаксис для инклуда одних типов файлов в другие. У меня лично последние два проекта — модули для хрома, там очень много компонентов, всунутых через shadow DOM, там нужно объявлять стили внутри шаблона, соответственно их нужно как-то подключать. Вариант, когда какой-то символ просто превращается в ..." + require($1) + "… — куда удобнее.
Сомневаюсь (просто не понял, честно говоря), как там подсасывать base64, так что 50/50%, может и есть оно.
В любом случае, это выбор каждого, но я пока что продолжу доверять gulp и browserify, которые мейнтейнятся двумя жирными такими сообществами, чем вебпаку, у которого автор явно пишет «чуваки, я это делаю в свободное время». Может, когда-нибудь потом, тем более что мои задачи вполне решаемы именно так.
Рендер на сервере все-таки тоже занимает какое-то время, а отдать статику (особенно закэшированную) можно куда быстрее.
Кстати, если не секрет — какое у вас распределение пользователей по браузерам?
проблема таких велосипедов не в том что они хуже, а в том, что не поддерживаются. Я вот с vue.js мучаюсь. Он проще, быстрее и эффективнее ангуляра, но реально мешающие баги автор очень медленно исправляет.
pixi.js возьмите, там и 20 тысяч спрайтов спокойно будут тянуться :)
www.goodboydigital.com/pixijs/bunnymark/ — у меня фпс начинает всаживаться (с 60 до 57 фпс, но все же) на где-то 30к, насколько помню, меньше 25 кадров в секунду — это 50к зайцев.
Только это не nodejs приложение, все на клиентсайде :) В Web Workers. Пересчет сети на ~600 тренировочных данных и выдача около 100 значений занимает около 0.15 секунды, что вызывает просадку по перформансу. С воркерами — все нормально работает.
На всякий случай: я использовал готовую библиотеку, но там были достаточно интересные ньюансы, связанные именно с обучением.
Постараюсь в течении недели это все сделать.
libsass быстрый, но поддерживает, что пародоксально, не sass, но только scss-синтаксис (во всяком случае, так было полгода назад, насколько я помню). А у нас в той команде почему-то так завелось, что форматирование не отступами доставляло всегда кучу проблем при мердже — потому и был переход с хтмл на jade, та же самая ерунда была. Форматирование отступами позволило сливать ветки гита с куда меньшей кучей геммороя.
Про инкрементальные билды — в моем случае все решалось установкой кэша для browserify в последнее время — у меня в том числе стили подключаются через JS по ряду причин.