Comments 123
UFO just landed and posted this here
Так о чем и речь, что все стараются зачем то навертеть себе всех возможных новых технологий, но сами не понимают зачем им они. Ну чтобы было как у всех. Хотя в 90% останься они на технологиях начала 10 года или даже 2005, то ничего бы и не изменилось в целом.
Тут зачастую может выйти так, что уменьшая время на разработку, мы воруем это время у тех, кто будет вынужден в дальнейшем такую систему поддерживать и развивать. Пример (надуманный но на основе реальных событий): пусть есть сайт на джанге, на которую для примера наверчено еще 3 библиотеки. Понадобилось обновить джангу (в старой версии нашли дыру, или нет нужной функциональности, которая понадобилась, или переносим сайт на другой хостинг, где уже предустановлена джанга но не той версии). И выясняется, что библиотека 1 не работает под новой версией. Обновляем библиотеку. А у нее изменился API и существующий код сайта не работает. Переписываем код. И тут выясняется, что библиотека 2 конфликтует с новой версией библиотеки 1. Обновляем ее. И так далее… В результате сопровождение и развитие такого продукта, в которого напихана тьма современных технологий, превращается в нетрадиционный секс, где большую часть времени не занимаешься непосредственно самим функционалом системы, а прилагаешь титанические усилия, чтобы все это нагромождение не развалилось, ваяя "стройную систему костылей и подпорок"...
А вот второй пример, тоже надуманный, но на основе реальных событий: продукт написали быстро, и использованием кучи библиотек и костылей, некоторое время развивали, получили фидбэек, вторую версию написали с нуля, выкинув часть библиотек, заменив меньшими или собственными решениями, а что-то выкинув совсем. Писали бы с нуля всё первый раз — получили бы в 3 раза бОльший срок на "боевой прототип". Но зачем?
А дает ли? Насколько мне известно, никто не делал серьезного исследования на эту тему, а самим разработчикам доверять нельзя из-за предвзятости.
Чтобы сделать первый шаг (и причем неплохой такой шаг!), достаточно убрать со страницы какую-нибудь лайкалку. Потому что за крохотной кнопкой часто спрятаны огромные скрипты. И я видел немало сайтов, где количество тех лайков измерялось единицами — то есть их можно было выбросить вообще.
Давайте я расскажу вам страшную историю. Есть такой проект, как Патреон. И предлагает он вставить на свой сайт кнопку, ведущую на страницу подписки:
<a href="https://www.patreon.com/bePatron?u=27084182" data-patreon-widget-type="become-patron-button">Become a Patron!</a>
<script async src="https://c6.patreon.com/becomePatronButton.bundle.js"></script>Что делает скрипт? Он превращает скучную ссылку в элегантную кнопку:
Скрипт весит 110кб в сжатом виде и 415кб в несжатом минифицированном. Содержит он:
- react
- styled-components
- пачка полифилов
Плюс 10кб стилей и 30кб шрифтов, но это уже сущие мелочи.
И это они ещё соптимизировали. В прошлый раз, когда я смотрел, скрипты весили около мегабайта.
Это не только с веб-страницами, а с технологиями в целом происходит. Портировал недавно одну старую MS-DOS игру для веба. Были использованы DOSbox и emscripten. То что раньше весило пару килобайт, стало весить 50 мегабайт — но зато запускается в браузере.
Процитирую себя:
Кому–то кажется, что игра выглядит несовременно? Вы сами отстали от времени: несовременной она была в 2003 году. Сегодня, чтобы просто запустить её, понадобился технологический стек настолько умопомрачительной сложности, что остается только гадать, как же это мы до такой жизни дошли. В целом, вышла неплохая иллюстрация того, как некоторые изначально простые вещи со временем становятся не проще, а сложнее.
Процитирую себя:
Кому–то кажется, что игра выглядит несовременно? Вы сами отстали от времени: несовременной она была в 2003 году. Сегодня, чтобы просто запустить её, понадобился технологический стек настолько умопомрачительной сложности, что остается только гадать, как же это мы до такой жизни дошли. В целом, вышла неплохая иллюстрация того, как некоторые изначально простые вещи со временем становятся не проще, а сложнее.
сегодня вам понадобился стек чтобы запустить эту игру где она не была предназначена запускаться. Игра запускалась только на определенной архитектуре под определенной ос. Игра была просто заточена на очень конкретное окружение.
Теперь, вы запустили ее в браузере, технически позволив запустить игру на целой куче платформ, используя технологический стек с открытыми стандартами, а значит завтра разработчик собственного браузера тоже сможет запустить игру у себя.
Теперь вопрос, что быстрее, написать один раз эмулятор под DOS игры, или переписать тысячу игр? Сегодня эта игра должна работать не под DOS, а под windows 7, 8, 10, android, ios, при этом желательно не писать каждую версию с нуля. Потому и раздувается стэк, потому что это сокращает время разработки.
Теперь, вы запустили ее в браузере, технически позволив запустить игру на целой куче платформ, используя технологический стек с открытыми стандартами, а значит завтра разработчик собственного браузера тоже сможет запустить игру у себя.
Теперь вопрос, что быстрее, написать один раз эмулятор под DOS игры, или переписать тысячу игр? Сегодня эта игра должна работать не под DOS, а под windows 7, 8, 10, android, ios, при этом желательно не писать каждую версию с нуля. Потому и раздувается стэк, потому что это сокращает время разработки.
Хорошо что я обновил комментарии перед тем как написать всё тоже самое.
Не понимаю, как можно говорить о "простые вещи становятся сложнее" в контексте — стало хуже. Нет, хуже не стало. Да, технологии стали сложнее. Но и возможности которые они дают — несравнимы с тем что было.
alex_blank вы не портировал игру, а эмулировал ее окружение! Уверен, порт игры был бы простым, примитивным, весил бы десятки килобайт и не требовал бы мощную машину. Но нет, надо полностью сэмулировать окружение для игры и заявить, что все непомерно усложнилось… Так усложнилось, потому что решаете задачи "в лоб". Вторая фишка усложнившегося стэка технологий — это как раз возможность решать задачи просто. Вы не тратили месяцы чтобы разобрать игру и написать ее заново под современные технологии. Вы взяли готовый эмулятор и запустили на нем игру… Именно Вы. Лично ВЫ — виновник того что эта игра требует кучу современных технологий и весит 50 мегабайт. Лично Вы являетесь потребителем и главной ЦА этих "сложных вещей, которые раньше были проще"
Не понимаю, как можно говорить о "простые вещи становятся сложнее" в контексте — стало хуже. Нет, хуже не стало. Да, технологии стали сложнее. Но и возможности которые они дают — несравнимы с тем что было.
alex_blank вы не портировал игру, а эмулировал ее окружение! Уверен, порт игры был бы простым, примитивным, весил бы десятки килобайт и не требовал бы мощную машину. Но нет, надо полностью сэмулировать окружение для игры и заявить, что все непомерно усложнилось… Так усложнилось, потому что решаете задачи "в лоб". Вторая фишка усложнившегося стэка технологий — это как раз возможность решать задачи просто. Вы не тратили месяцы чтобы разобрать игру и написать ее заново под современные технологии. Вы взяли готовый эмулятор и запустили на нем игру… Именно Вы. Лично ВЫ — виновник того что эта игра требует кучу современных технологий и весит 50 мегабайт. Лично Вы являетесь потребителем и главной ЦА этих "сложных вещей, которые раньше были проще"
Уверен, порт игры был бы простым, примитивным
Это не так. Если под портом вы понимаете переписывание исходника вручную на JS — то это архисложная задача в сравнении с тем что было проделано. Хотя бы потому что исходника попросту нет, а если бы и был — никто бы не захотел возиться с его переписыванием. Ведь возни много, а результат тот же самый для пользователя. Конечно, за счет усложнения run-time стека.
То есть мы наблюдаем экспорт сложности из одного domain'а в другой.
Программа от апполона писалась специально под апполон и специально под одну конкретную задачу. Эта игра писалась специально под конкретное окружение и больше ничего не поддерживает. Написать сегодня 2D игру под windows проще чем раньше под msdos, достаточно взять например SDL и вы приблизительно за тоже время что и автор игры напишете порт, это в случае если бы у вас было полное ТЗ на игру, при этом вы с нулевым оверхедом сможете себе позволить графику получше. Стек у вас получился бы больше, но он стал бы более "общим", api стаал бы общим, вы не затачиваете свою игру под узкое, конкретное окружение. И больше авторов смогло бы работать над игрой, потому что использовалась популярная известная библиотека, а не какой то узкий самописный код с собственными решениями.
Раздутие стэка? да. Зато проще портировать на те платформы где этот стэк присутствует (в моем примере C + SDL)
Однако портирование игры с одной платформы на другую ВСЕГДА было сложной задачей. Взять хотя бы какой нибудь допустим apple ||, как просто было бы вам портировать DOS игру на подобный компьютер? думаю это было бы архисложной задачей, ничуть не проще чем написание эмулятора. Помимо этого у JS совершенно другая парадигма программирования (асинхронные события) которой в MSDOS нет, там код однопоточен и синхронен (образно).
Выводы: раздутие стэка увеличивает скорость разработки, позволяет запустить нечто на нескольких платформах обхватив большую аудиторию, зачастую позволяет привлекать новых программистов в проект многократно быстрее чем если писать собственное решение.
Портирование с одного "domain" на другой, как было сложным так таким и осталось. Если не стало проще.
Раздутие стэка? да. Зато проще портировать на те платформы где этот стэк присутствует (в моем примере C + SDL)
Однако портирование игры с одной платформы на другую ВСЕГДА было сложной задачей. Взять хотя бы какой нибудь допустим apple ||, как просто было бы вам портировать DOS игру на подобный компьютер? думаю это было бы архисложной задачей, ничуть не проще чем написание эмулятора. Помимо этого у JS совершенно другая парадигма программирования (асинхронные события) которой в MSDOS нет, там код однопоточен и синхронен (образно).
Выводы: раздутие стэка увеличивает скорость разработки, позволяет запустить нечто на нескольких платформах обхватив большую аудиторию, зачастую позволяет привлекать новых программистов в проект многократно быстрее чем если писать собственное решение.
Портирование с одного "domain" на другой, как было сложным так таким и осталось. Если не стало проще.
Лично для меня всегда при разработке проблемой становятся нестандартные шрифты: они должны включать все необходимые символы, все необходимые варианты начертания и при этом не выходить за рамки допустимого размера, прилично выглядеть и быть легальными. Получить всё это сразу иногда бывает столь сложно, что проще отказаться от нестандартных шрифтов вообще.
пользуй гугл-шрифты
А почему не дефолтные?
Не почему, а когда дефолтные не подходят или хочется разнообразия.
Не все дефолтные шрифты кросс-платформенны (могут попросту отсутствовать). Иногда даже шрифт с одним и тем же названием на Винде и Маке выглядит по-разному
Нет никакого «дефолтного шрифта». А те, кто считает, что Arial, Helvetica и Times New Roman есть везде — очень нехорошие люди.
> Нет никакого «дефолтного шрифта».
Да неужели?
Откройте для себя serif и san-serif там где не везде есть Arial, Helvetica и Times New Roman.
Кстати, в отличие от кастомных, дефолтные системные шрифты значительно лучше вылизаны для дисплеев. На малых кеглях и дешевых это особенно заметно.
> очень нехорошие люди.
очень нехорошие люди заставляют юзеров качать лишние мегабайты. И в статье это очень подробно описано.
Да неужели?
Откройте для себя serif и san-serif там где не везде есть Arial, Helvetica и Times New Roman.
Кстати, в отличие от кастомных, дефолтные системные шрифты значительно лучше вылизаны для дисплеев. На малых кеглях и дешевых это особенно заметно.
> очень нехорошие люди.
очень нехорошие люди заставляют юзеров качать лишние мегабайты. И в статье это очень подробно описано.
А в итоге http://i.imgur.com/94T4uKc.png.
Подискутировали с Pu4u на тему этой статьи. Но он ридонли, так что от его имени:
высказывание спорное
а еще например, я сохранил эту страницу на диск
и она весит 243 КБ
а картинки + js (т.е. всё прочее) еще 3,2МБ
интересно как автор замерил размер той страницы
но это бред, из 900 кб(html+css) сам html только 25%
css нормально кэшируется, даже если бы его было суммарно на несколько мегабайт — ничего в этом страшного не было бы
поэтому тема спорная, кэш никто не отменял
250 КБ для 2016 — мелочь.
Если поднапрячь память, то еще когда я учился в школе началось нытьё, что некоторые веб-страницы весят около мегабайта
но если мегабайт в 2005 было овердофига, то 3 мегабайта в 2016 — ерунда.
скорости выросли в десятки раз
специально порылся, нашел мастера и маргариту
ansi — размер 850КБ
utf-8 — размер 1,4МБ
сайты-то сейчас на utf-8 делают, опять же сравнение с другйо кодировкой некорректно
- Первую загрузку тоже никто не отменял. Вот вы ходите с поисковика на сайты, каждый из них открываете первый раз, в итоге все работает медленно. Оправдания типа второй раз быстрее тут не работают.
- Картинки и js+css это совершенно разные вещи. Картинки могут грузится после отображения страницы параллельно, загрузка css и некоторого js блокирует отображение страницы вообще. Так что не надо сравнивать мегабайт картинки с мегабайтом css, пожалуйста. К тому же, css и js нужно ещё проинтерпритировать, это особенно сказывается при открытии сайтов на мобильном.
Это почти на 100 КБ больше, чем полный текст «Мастера и Маргариты», наполненного мистикой и комедией романа Булгакова о Дьяволе, который наведывается в Москву со своей свитой (включая огромного кота!) во время Большого террора 1937 года.
Действие «Мастера и Маргариты» разворачивается в 1936 г.
https://otvet.mail.ru/question/7584044
Развелось, блин, специалистов во всех областях знания.
Тут говорят иначе.
Вообще, думаю, человек, который выбрал в университете специализацию по русской культуре (double major in Russian and Studio Art), хотя бы приблизительно знает, что он говорит.
Особо стоит отметить и появление двух «новеньких» гостей на балу у сатаны, имен которых Коровьев якобы не знает. Один из них – автор плана убийства человека, «разоблачений которого он чрезвычайно опасался» (с. 686), с помощью яда, которым обрызгали стены кабинета. Второй – исполнитель. Этот изысканный способ убийства и анонимность гостей на балу ассоциируются с попыткой Ягоды отравить Ежова, стены и шторы кабинета которого были, по его приказанию, обрызганы ртутью (ртуть добавили и в побелку). Правда, желаемого результата Ягода не добился. Но присутствие Ягоды на балу у Воланда связано уже с концом 30-х годов – он мог там появиться только после смерти в 1937 году.http://www.e-reading.club/chapter.php/82995/6/Pozdnyaeva_-_Voland_i_Margarita.html
Из реалий 1930-х годов Б. Гаспаров отмечает неоднократное упоминание в романе имени А. С. Пушкина в связи со столетием гибели поэта в 1937 году. В торжествах по этому поводу активное участие принял Булгаков (пьеса «Последние дни»).
Вообще, думаю, человек, который выбрал в университете специализацию по русской культуре (double major in Russian and Studio Art), хотя бы приблизительно знает, что он говорит.
Интересно, про Prodigy — это он на "The fat of the land" намекает?
Нет, это американский провайдер услуг связи. Пик пришёлся на девяностые.
Я думаю 90% не осилили прочитать эту статью полностью, такой же процент мусора находится на современных сайтах.
P.S. А теперь выдохнули) Эта аналогия не говорит о том, что кто-то из нас мусор, просто ее реально стоит прочитать полностью, от и до. В ней описывается куча проблем современного веба, не только на стороне клиентского кода, но и на стороне дизайна, рекламы и многого другого.
P.S. А теперь выдохнули) Эта аналогия не говорит о том, что кто-то из нас мусор, просто ее реально стоит прочитать полностью, от и до. В ней описывается куча проблем современного веба, не только на стороне клиентского кода, но и на стороне дизайна, рекламы и многого другого.
Нужно быть специалистом очень высокого уровня, обладающим очень весомым (жирным?) авторитетом, чтобы рискнуть высказать такое мнение. И автор перевода должен обладать всеми этими качествами, чтобы рискнуть запостить это на хабре. Потому что в статье покушение на святое — смысл развития технологий.
Нет, в ней на примере веба описывается проблема всего современного мира технологий — мощность без смысла, сложность без нужды, дизайн без идеи, существование без цели. Все, рассчитанное на обычного "потребителя" таково, без исключений (разве что скотч не такой).
В ней описывается куча проблем современного веба, не только на стороне клиентского кода, но и на стороне дизайна, рекламы и многого другого.
Нет, в ней на примере веба описывается проблема всего современного мира технологий — мощность без смысла, сложность без нужды, дизайн без идеи, существование без цели. Все, рассчитанное на обычного "потребителя" таково, без исключений (разве что скотч не такой).
А проблема кстати на поверхности, мы все хотим быстрый веб, который «всё умеет», но барузеры не дают нам нужного и/или быстрого API. Началось с мелочей, всякие анимашки, балуны, календарики, алерты, лаеры, Drag'n'Drop и т.п., а браузеры все разные и пришлось изобрести сначала Prototype + script.aculo.us, а потом jQuery + jQuery UI (40KB + 78KB min + gzip).
И вот прошли года, в этом jQuery будет праздновать юбилей, как ни как, 10 лет уже и за все эти года даже в самых современных браузерах не появилось api, которое позволило бы избавиться от него (тут можно возразить, а как же http://youmightnotneedjquery.com/ и т.п., это не альтернатива, даже для современных браузеров, слишком упрощено).
Скажу больше, за эти 10 лет, всё стало только веселей, кроме абстракций над DOM/Ajax/Animation/Events, появились над массивами и объектами в виде Lodash/Underscore и не потому, что они дают новые возможности, хотя и это тоже, а потому что Lodash просто быстрей чем Native код 0_o (ситуация конечно меняется, но флагман v8, до сих пор позади).
Несколько лет назад появился React, который реализовал Virtual DOM, чтобы полностью избавиться от взаимодействия с реальным DOM, и тут дело не в том, что он по умному обновляет только нужные узлы, как многие думают, проблемы глубже, любое взаимодействие с реальной нодой (вызов геттеров
Итого мы и имеем около мегабайта кода (несжатого ;]), который нужен только для того, чтобы быстро работать с DOM, массивами/объектами и т.п. и т.д. А ведь ещё нужно само приложение написать, да побороть кроссбраузерность и это не IE7/8/9.
Так и живем.
И вот прошли года, в этом jQuery будет праздновать юбилей, как ни как, 10 лет уже и за все эти года даже в самых современных браузерах не появилось api, которое позволило бы избавиться от него (тут можно возразить, а как же http://youmightnotneedjquery.com/ и т.п., это не альтернатива, даже для современных браузеров, слишком упрощено).
Скажу больше, за эти 10 лет, всё стало только веселей, кроме абстракций над DOM/Ajax/Animation/Events, появились над массивами и объектами в виде Lodash/Underscore и не потому, что они дают новые возможности, хотя и это тоже, а потому что Lodash просто быстрей чем Native код 0_o (ситуация конечно меняется, но флагман v8, до сих пор позади).
Несколько лет назад появился React, который реализовал Virtual DOM, чтобы полностью избавиться от взаимодействия с реальным DOM, и тут дело не в том, что он по умному обновляет только нужные узлы, как многие думают, проблемы глубже, любое взаимодействие с реальной нодой (вызов геттеров
firstChild/nextSibling/children/childNodes и т.п.) приводи к неминуемым провалам в производительности, даже элементарное element.myProp = 123 — проблема. Именно поэтому, самые быстрые реализации VDOM использую максимум createElement/insertBefore/replaceChild/removeChild и только в случае крайней необходимости, некоторые даже пытаются переиспользовать ранее удаленные элементы, чтобы лишний раз не вызывать createElement.Итого мы и имеем около мегабайта кода (несжатого ;]), который нужен только для того, чтобы быстро работать с DOM, массивами/объектами и т.п. и т.д. А ведь ещё нужно само приложение написать, да побороть кроссбраузерность и это не IE7/8/9.
Так и живем.
Всё станет лучше с приходом WebAssembley. Все эти jQuery\jQuery UI\React станут нативным кодом, который будет компилироваться\кэшироваться\векторизироваться\параллелиться (и все прочие умные слова из мира С++), а сайты смогут этим пользоваться уже воспринимая их как часть API браузера, а не JS-библиотеки.
Ох, сколько этих разговоров было, тот же NaCL, но вериться в это с трудом, да и сколько ждать? По самым оптимистичным заявлениям, как минимум год, потом обкатка, появление первых инструментов, вопрос кроссбраузерности, поддержка мобильными браузерами, вот этих но-но-но слишком много, слишком.
тот же NaCL
Совершенно не "тот же NaCL". Никому в здравом уме не могло прийти в голову делать общедоступный сайт широкого профиля на NaCL, поскольку у половины домохозяек в их левых и старых браузерах он бы не запустился. В то же время делать сайт на привычных jQuery\jQuery UI\React, который будет работать чуть медленнее на старой JS-библиотеке и чуть быстрее на современном браузере с WebAssembley — вполне себе нормальный вариант.
На счёт "минимум год" — это верно, даже скорее минимум полтора-два года. Но это единственный путь, по которому вообще можно эволюционировать, потому что альтернативы вроде "выбрасываем вообще весь HTML\DOM\JS и городим что-то кардинально новое" обречены на провал сразу.
Совершенно не "тот же NaCL".
Вы меня неправильно поняли, это в качестве примера «Всё станет лучше с приходом ХХХ», тогда писали ровно тоже самое и вы можете его уже много лет использовать в приложениях, но больше никто это не подержал.
Но кроме NaCL/PNaCl, ещё есть asm.js, заходы были, но не нашли хоть какого-то распространения. Так что говорить, что в ближайшие 3-4 года что-то измениться я бы не стал.
А в промежутке компания Google хотела втюхать Dart, как решение всех проблем с производительностью JavaScript/DOM/CSS и т.п.
Свой комментарий я писал к тому, что в рамках существующий браузеров, за эти 10 лет jQuery/GWT/knockout/React/Angular/XXX, можно было решить кучу проблем с производительностью, но этого не происходит.
Все предыдущие подходы (NaCL, asm.js, Dart) предлагали писать другой клиентский код, поверив на слово, что технология будет жить\поддерживаться\станет популярной. Люди не верили и правильно делали. Подход WebAssembley предлагает конечному веб-разработчику писать то же самое, что он и до этого писал, и лишь разработчикам библиотек и фреймворков — возможность ускорить их код в N раз. При этом даже и разработчикам библиотек не обязательно верить в успех WebAssembley — если не взлетит, то всегда есть привычная JS-версия библиотеки.
asm.js собственно это подмножество js же? В худшем случае ничего не теряется. Про него можно сказать всё то же самое, что и про WebAssembly.
О различиях asm.js и WebAssembly много где писали (вот, например) и нет, про него нельзя "сказать всё то же самое". Это разные технологии.
> Про него можно сказать всё то же самое, что и про WebAssembly.
Я имел в виду следующее:
>Подход WebAssembley предлагает конечному веб-разработчику писать то же самое, что он и до этого писал, и лишь >разработчикам библиотек и фреймворков — возможность ускорить их код в N раз. При этом даже и разработчикам >библиотек не обязательно верить в успех WebAssembley — если не взлетит, то всегда есть привычная JS-версия >библиотеки.
Меняем WebAssembly на asm.js в этом фрагменте — что становится не верным? Прирост поменьше вероятно, но принципиально всё вами сказанное про WebAssembly применимо и для asm.js. Аргументация выглядит весьма неубедительно.
И да, я знаю, что это разные технологии и в чем их ключевые отличия.
Я имел в виду следующее:
>Подход WebAssembley предлагает конечному веб-разработчику писать то же самое, что он и до этого писал, и лишь >разработчикам библиотек и фреймворков — возможность ускорить их код в N раз. При этом даже и разработчикам >библиотек не обязательно верить в успех WebAssembley — если не взлетит, то всегда есть привычная JS-версия >библиотеки.
Меняем WebAssembly на asm.js в этом фрагменте — что становится не верным? Прирост поменьше вероятно, но принципиально всё вами сказанное про WebAssembly применимо и для asm.js. Аргументация выглядит весьма неубедительно.
И да, я знаю, что это разные технологии и в чем их ключевые отличия.
принципиально всё вами сказанное про WebAssembly применимо и для asm.js
да, я знаю, что это разные технологии и в чем их ключевые отличия
То есть ключевые отличия всё-же имеются, но тем ни менее, всё сказанное про WebAssembly применимо и для asm.js? Как же так? В чём же тогда ключевые отличия?
Я вам привёл пример вашей фразы, где всё вами сказанное в поддержку webassembly справедливо и для asm.js.
Вы апеллировали к тому, что что другие, в отличии от webassembly, заставляют писать другой клиентский код. Так вот никто не заставляет. Можно писать только библиотеки на том же asm.js.
Ключевые отличия — бинарность и отсутствие груза совместимости с обычным js. Но это дает и плюсы и минусы. Быстрее разбирается, теоретически лучше оптимизируется jit-компилятором. Но надо переписывать(заново генерировать/компилировать в). Библиотеки никто не мешал писать с использованием asm.js и не ждать поддержки движков. Есть поддержка — чуть быстрее, нет — всё равно работает.
Аргументация при сравнении с NaCl верна — поддержка ограничена, перспективы туманны. А при сравнении с asm.js ваша предыдущая аргументация, на мой взгляд, в корне не верна. Если вы всё еще этого не понимаете — или я сам дурак, или объяснять не умею. В любом случае не вижу смысла обсуждать именно этот пункт дальше.
Вы апеллировали к тому, что что другие, в отличии от webassembly, заставляют писать другой клиентский код. Так вот никто не заставляет. Можно писать только библиотеки на том же asm.js.
Ключевые отличия — бинарность и отсутствие груза совместимости с обычным js. Но это дает и плюсы и минусы. Быстрее разбирается, теоретически лучше оптимизируется jit-компилятором. Но надо переписывать(заново генерировать/компилировать в). Библиотеки никто не мешал писать с использованием asm.js и не ждать поддержки движков. Есть поддержка — чуть быстрее, нет — всё равно работает.
Аргументация при сравнении с NaCl верна — поддержка ограничена, перспективы туманны. А при сравнении с asm.js ваша предыдущая аргументация, на мой взгляд, в корне не верна. Если вы всё еще этого не понимаете — или я сам дурак, или объяснять не умею. В любом случае не вижу смысла обсуждать именно этот пункт дальше.
Писать библиотеки на asm.js было мало толку, потому что это хоть и "asm", но всё-же "js". Браузеру всё-равно приходилось его качать\парсить\строить AST\запускать и из этих 4-ех шагов asm.js давал выигрыш только на последнем, при том что на первых трёх мог дать даже проигрыш (если у нас нет всех возможностей JS- код иногда получается больше, парсить\оптимизировать его тоже надо хитрее). WebAssembly даёт бинарный код (меньшего размера), уже скомпилированный и оптимизированный и в том числе быстрее работающий — выходит быстрее на всех четырёх этапах. Где же здесь "всё сказанное про WebAssembly применимо и для asm.js"? Принципиально же разная механика, нет?
Бинарное AST — это не «уже скомпилированный и оптимизированный и в том числе быстрее работающий» код. Это AST, которое потом компилируется оптимизирующим компилятором в байткод. Скорость первоначальной загрузки конечно у asm.js ниже, но это не всегда определяющий фактор. «Парсить\оптимизировать его тоже надо хитрее» — это не так. asm.js для того и был придуман что его парсить и оптимизировать проще, но да, это надо делать, в отличии от WebAssembly.
Еще раз, 3-ий вроде уже, говорю: в контексте вашего первого комментария, на который я отвечал, про asm.js можно сказать то же самое, что вы в том комментарии сказали по WebAssembly.
asm.js давал преимущество для библиотек относительно стандартного подхода по производительности. Этого оказалось недостаточно для авторов библиотек. Окажется ли выигрыша от WebAssembly достаточно — покажет время. Но, в отличии от asm.js, WebAssemble требует практически полного переписывания.
Лично мне кажется, что WebAssembly приживется только как формат, в который будут компилироваться другие языки: тот же Dart, TypeScrypt, C и C++ через что-то подобное emscripten.
Еще раз, 3-ий вроде уже, говорю: в контексте вашего первого комментария, на который я отвечал, про asm.js можно сказать то же самое, что вы в том комментарии сказали по WebAssembly.
asm.js давал преимущество для библиотек относительно стандартного подхода по производительности. Этого оказалось недостаточно для авторов библиотек. Окажется ли выигрыша от WebAssembly достаточно — покажет время. Но, в отличии от asm.js, WebAssemble требует практически полного переписывания.
Лично мне кажется, что WebAssembly приживется только как формат, в который будут компилироваться другие языки: тот же Dart, TypeScrypt, C и C++ через что-то подобное emscripten.
И здесь мы возвращаемся к теме статьи — "жирности" сайтов. Не за горами тот момент, когда для показа 140 символов твиттерного коммента нам нужно будет мегабайт 20 Javascript-кода. Ну или раз в 5 меньше кода в формате WebAssembly. Компилировать в него будут не от хорошей жизни, а потому что "менеджеры сказали что нам нужно вот эти 80 фич на странице, а на Javascript это будет открываться три минуты".
>любое взаимодействие с реальной нодой (вызов геттеров firstChild/nextSibling/children/childNodes и т.п.) приводи к неминуемым провалам в производительности, даже элементарное element.myProp = 123 — проблема.
не приводит, и присваивание кастомных дом свойств — не проблема на webkit/blink(тормозные андроиды).
>Именно поэтому, самые быстрые реализации VDOM использую максимум createElement/insertBefore/replaceChild/removeChild и только в случае крайней необходимости, некоторые даже пытаются переиспользовать ранее удаленные элементы, чтобы лишний раз не вызывать createElement.
Эти функции используются каждый раз когда нужно добавить/удалить/переставить ноду, что как бы очевидно :) Не понимаю что такое «используют максимум ...», используются только в тех случаях когда иначе никак не сделать и делается почти всегда минимальное кол-во вызовов.
не приводит, и присваивание кастомных дом свойств — не проблема на webkit/blink(тормозные андроиды).
>Именно поэтому, самые быстрые реализации VDOM использую максимум createElement/insertBefore/replaceChild/removeChild и только в случае крайней необходимости, некоторые даже пытаются переиспользовать ранее удаленные элементы, чтобы лишний раз не вызывать createElement.
Эти функции используются каждый раз когда нужно добавить/удалить/переставить ноду, что как бы очевидно :) Не понимаю что такое «используют максимум ...», используются только в тех случаях когда иначе никак не сделать и делается почти всегда минимальное кол-во вызовов.
не приводит, и присваивание кастомных дом свойств — не проблема
Уверены? https://dl.dropboxusercontent.com/s/d5jtfjpaho6plxx/Screenshot%202016-03-09%2018.05.41.png?dl=0
Даже если сравнивать
childNodes vs. firstChild + nextSibling, второй будет быстрей.>Уверены?
И зачем замерять разницу между жс объектом и дом объектом? Если вам понадобится присваивать свойство дом объекту, то у вас не будет выбора, вот и всё, и это не приведёт к катастрофическим последствиям.
И зачем замерять разницу между жс объектом и дом объектом? Если вам понадобится присваивать свойство дом объекту, то у вас не будет выбора, вот и всё, и это не приведёт к катастрофическим последствиям.
Мы про VDOM говорим и почему он быстрей или нет? Если об этом, то его сила как раз в том, что он сводит взаимодействие с DOM к минимум, тем самым достигая выигрыша.
Проверти это ещё не самое плохое, геттеры — вот где основной профит.
Проверти это ещё не самое плохое, геттеры — вот где основной профит.
В чём смысл замерять скорость присваивания оычному жс объекту и дом ноду, если в итоге всё равно нужно будет присвоить это свойство реальному дом ноду?
>Если об этом, то его сила как раз в том, что он сводит взаимодействие с DOM к минимум, тем самым достигая выигрыша.
можно делать минимум взаимодействий с DOM и без виртуального дома.
>Если об этом, то его сила как раз в том, что он сводит взаимодействие с DOM к минимум, тем самым достигая выигрыша.
можно делать минимум взаимодействий с DOM и без виртуального дома.
можно делать минимум взаимодействий с DOM и без виртуального дома.
Например параллельно хранить где-то актуальные состояния, на основе которых построен DOM или что вы предлагаете?
Например kvo датабайндинг.
Понятно, «те же яйца, только в профиль». Только я не видел быстрого kvo, а вот быстрый vdom использую.
А какие кво вы пробовали?
Vue или Angular считается? PS: Ооочень давно пробовал KO, профита не обнаружил.
То есть атомы не пробовали?
Слишком сложно, чтобы даже попробовать, но я уверен, сам принцип проигрывает нормальной реализации vdom.
Собственно о чем я и говорил https://habrahabr.ru/post/276747/#comment_8809715
Атомы использовать очень просто:
Ну а сравниваете вы тёплое с мягким. $mol_view — не просто рендерер, он ещё контролирует время жизни объектов, позволяет кастомизировать вёрстку извне, генерирует BEM-аттрибуты, защищает от падений, инкапсулирует асинхронность.
var greeting = new $jin2_atom( 'Hello' )
var bodyRenderer = new $jin2_atom( () => {
document.body.innerText = greeting.get()
} )
bodyRenderer.pull()
setTimeout( () => { greeting.set( 'Hello, world' ) } , 1000 )Ну а сравниваете вы тёплое с мягким. $mol_view — не просто рендерер, он ещё контролирует время жизни объектов, позволяет кастомизировать вёрстку извне, генерирует BEM-аттрибуты, защищает от падений, инкапсулирует асинхронность.
Вы ошибайтесь. Мы говорим о kvo vs. vdom, мой пример только доказывает, что есть vdom-движки которые с легкостью уделаю любой kvo просто перерисовывая «всё». Дальше поверх накручиваем компоненты (можно даже React использовать) и готово. BEM атрибуты, защита от падения, это не задача vdom-движка. Я например использую xml-подобный синтаксис, который потом на этапе компиляции транслирую в vdom, а там и BEM и защита.
Повторюсь, я пока не видел kvo, которое могло бы сравниться по скорости и гибкости с нормальным vdom, которые от разработчика не требует создания обсерверов или реактивных контейнеров. Мой пример как раз и показывает, что для того, чтобы создать TodoMVC, мне достаточно пары строчек на js и простой перендер на любые события.
P.S. По поводы атомы использовать просто, не согласен, вы написали 6 строчек кода и с использование библиотеки, там, где она не нужна. Но об это мы уже говорили, так что я пас повторять этот опыт.
Повторюсь, я пока не видел kvo, которое могло бы сравниться по скорости и гибкости с нормальным vdom, которые от разработчика не требует создания обсерверов или реактивных контейнеров. Мой пример как раз и показывает, что для того, чтобы создать TodoMVC, мне достаточно пары строчек на js и простой перендер на любые события.
P.S. По поводы атомы использовать просто, не согласен, вы написали 6 строчек кода и с использование библиотеки, там, где она не нужна. Но об это мы уже говорили, так что я пас повторять этот опыт.
Вы в подтверждение своих слов привели ссылку, где сравнивается:
При этом атомы можно использовать как в модели, так и во вьюшке. А для полного перерендеринга вам приходится на каждый чих полностью перегенерировать данные или опять же добавлять промежуточные состояния с обсерверами. В простейших случаях типа ToDoMVC это не так фатально. Сможете столь же эффективно реализовать, например, табличный процессор?
Через vdom это займёт меньше 6 строчек и не потребует библиотеку?
- жёсткая реализация на коленке с рендерингом через vdom, которая по мере усложнения приложения будет всё больше тормозить и течь
- гибкая реализация с атомами, с меньшей алгоритмической сложностью.
При этом атомы можно использовать как в модели, так и во вьюшке. А для полного перерендеринга вам приходится на каждый чих полностью перегенерировать данные или опять же добавлять промежуточные состояния с обсерверами. В простейших случаях типа ToDoMVC это не так фатально. Сможете столь же эффективно реализовать, например, табличный процессор?
Через vdom это займёт меньше 6 строчек и не потребует библиотеку?
>Даже если сравнивать childNodes vs. firstChild + nextSibling, второй будет быстрей.
Что будет быстрее чего? Они делают совершенно разные вещи, зачем их сравнивать, сравнивайте скорость того что вы пытаетесь сделать с помощью этих вызовов.
Что будет быстрее чего? Они делают совершенно разные вещи, зачем их сравнивать, сравнивайте скорость того что вы пытаетесь сделать с помощью этих вызовов.
Какую разную? Всё тужу, обход дерева элементов, но если мы продолжаем говорить про VDOM, хотя уже понял, что нет, но если всё же говорить про него, то он с этой операцией справиться ещё быстрей, потому что вместо HTMLCollection, он пробежится по обычному массиву из обычный объектов.
Ну так зачем обходить дерево, используя childNodes, который возвращает динамический(лайв) массив, используйте для этого nextSibling, оно как раз для этого и сделано, но зачем сравнивать разные инструменты мне так и непонятно.
А про vdom — зависит от того какую реализацию vdom возьмём, не все хранят ссылки на дом ноды в vnode'ах, кому-то ещё важны immutable vnode'ы.
А про vdom — зависит от того какую реализацию vdom возьмём, не все хранят ссылки на дом ноды в vnode'ах, кому-то ещё важны immutable vnode'ы.
Ок, тут ваша правда, сравнивать их и в правду некорректно.
Я ещё раз говорю, вся это карусель с vdom, только ради уменьшения взаимодействия с реальным DOM.
А про vdom — зависит от того какую реализацию vdom возьмём
Я ещё раз говорю, вся это карусель с vdom, только ради уменьшения взаимодействия с реальным DOM.
>Я ещё раз говорю, вся это карусель с vdom, только ради уменьшения взаимодействия с реальным DOM.
Ну, являясь автором одной из самых быстрых вдом либ, и общаясь с большинством разработчиков остальных вдом либ, мне всё же кажется что я имею небольшое представление о том ради чего весь этот vdom :) И для меня это в первую очередь очень удобный api для работы с домом.
Ну, являясь автором одной из самых быстрых вдом либ, и общаясь с большинством разработчиков остальных вдом либ, мне всё же кажется что я имею небольшое представление о том ради чего весь этот vdom :) И для меня это в первую очередь очень удобный api для работы с домом.
Ну так и о чем тогда разговор? Где я был неправ, говоря, что за последние 10 лет так и не появилось быстрого и/или удобного api?
P.S. Что именно за либа, если не секрет?
P.S. Что именно за либа, если не секрет?
>Ну так и о чем тогда разговор?
>любое взаимодействие с реальной нодой (вызов геттеров firstChild/nextSibling/children/childNodes и т.п.) приводи к неминуемым провалам в производительности, даже элементарное element.myProp = 123 — проблема.
не приводит, не проблема :)
>P.S. Что именно за либа, если не секрет?
https://github.com/localvoid/kivi
https://github.com/localvoid/uix
>любое взаимодействие с реальной нодой (вызов геттеров firstChild/nextSibling/children/childNodes и т.п.) приводи к неминуемым провалам в производительности, даже элементарное element.myProp = 123 — проблема.
не приводит, не проблема :)
>P.S. Что именно за либа, если не секрет?
https://github.com/localvoid/kivi
https://github.com/localvoid/uix
не приводит, не проблема :)
Я же говорю про полную абстракцию над DOM, а это значит, что «свои» или «data» свойство, двигло может держать в объекте vnode.
firstChild/nextSibling/parentNode всё равно медленней, чем не вызывать их вовсе, а ходить по vtree, вы же сами это прекрасно знаете.https://github.com/localvoid/kivi
https://github.com/localvoid/uix
Знакомые названия, как и vdom-benchmark, который ой как путает людей, да и померли многие либы (не запускаются бенчмарки).
>firstChild/nextSibling/parentNode всё равно медленней, чем не вызывать их вовсе, а ходить по vtree, вы же сами это прекрасно знаете.
Да, бегать с использованием nextSibling будет медленнее, но относительно всего остального оверхэда в конечном приложении — это будет не так сильно заметно. virtual-dom либа вроде до сих пор использует childNodes во время patch'а и ничего, куча приложений нормально работают :)
>как и vdom-benchmark, который ой как путает людей
Я бы давно прикрыл этот бэнчмарк, но некоторые разработчики до сих пор используют его для тестирования своих либ :)
Да, бегать с использованием nextSibling будет медленнее, но относительно всего остального оверхэда в конечном приложении — это будет не так сильно заметно. virtual-dom либа вроде до сих пор использует childNodes во время patch'а и ничего, куча приложений нормально работают :)
>как и vdom-benchmark, который ой как путает людей
Я бы давно прикрыл этот бэнчмарк, но некоторые разработчики до сих пор используют его для тестирования своих либ :)
но относительно всего остального оверхэда в конечном приложении — это будет не так сильно заметно
увы, не соглашусь, вот например мои данные:
- холодный старт: fragment: 68.370ms, vdom.append: 30.960ms
- последующие (с полным обновлением): fragment: 15.290ms, vdom.update: 32.505ms
Но, работу с данными тоже можно ускорить, пишем своим
forEach/map/etc, bind, EventEmitter и так далее. Очень многое можно реально убыстрить, но этим должен браузер делать, а не библиотека Х.для тестирования своих либ
Так в этом и проблема, оно же не тестирует ;] Надо бы результат проверять после либы, да и дерево очень простое, многие на это затачивают.
Я бы должен поддержать статью и ратовать за облегчение сайтов, так как живу в пригороде в частном доме, беспроводная сеть 1-2 мегабита днем и пинг 100 мс. Но нет. Основная проблема сейчас, вообще, единственный момент, по которому заметно ограничение скорости канала — видео потоки. Делаешь качество фильма 360p идет хорошо, выше, уже надо покурить/попить чаю, пока загрузится предварительный кэш. Домашние всё смотрят через интернет, телевизор оказался не нужен. Даже торренты как-то ушли в прошлое, иногда проще найти фильм в онлайн кинотеатре, чем скаченный на своем диске.
На фоне мультимедиа контента, 5 мегабайт странички вообще исчезающе малая величина. Статья, возможно, актуальна для стран, где очень дорогой интернет, у нас как-бы один из самых быстрых и дешевых на планете (второе место), хотя бы по данным замечательной статьи на Хабре
https://habrahabr.ru/post/268175/
Да и сложно представить, кто-то нашел нужную ему статью, и размер в 5 мегабайт стал препятствием для получения информации. Ну только, если это не проявление специфического перфекционизма, я его понимаю, так как когда-то был обладателем модема на 2400 бит/с в сети FIDO, там да, каждый байт был на счету :)
По аналогии, как автор статьи приводил лаконичность классиков, отмечу, что сайты текстовые весом даже в 5 мегабайт, так же лаконичны, по сравнению с той же информацией в форме видеороликов от стримеров. Сайт — 5 мегабайт, ролик на youtube в HD качестве может весить 5 гигабайт, а смысловое содержание примерно такое же (а иногда просто нулевое). Вот там да, глядя как стримеры некоторые забивают место на youtube терабайтами, и потом грузят этим хламом каналы беспроводного интернета, где частоты ограниченны весьма, и возникает вопрос о том, насколько эта информация нужна, целесообразна, оптимальна.
Ну и еще один момент "ожирения", высокие требования к количеству памяти на компьютере. Только по этой причине невозможно пользоваться интернетом на старых ноутбуках, где менее 1 гигабайта памяти. Браузеры под современные сайты просят памяти больше, чем есть в системе. Вот тут, наблюдаю реальные потери денег, нужно обновлять оборудование.
На фоне мультимедиа контента, 5 мегабайт странички вообще исчезающе малая величина. Статья, возможно, актуальна для стран, где очень дорогой интернет, у нас как-бы один из самых быстрых и дешевых на планете (второе место), хотя бы по данным замечательной статьи на Хабре
https://habrahabr.ru/post/268175/
Да и сложно представить, кто-то нашел нужную ему статью, и размер в 5 мегабайт стал препятствием для получения информации. Ну только, если это не проявление специфического перфекционизма, я его понимаю, так как когда-то был обладателем модема на 2400 бит/с в сети FIDO, там да, каждый байт был на счету :)
По аналогии, как автор статьи приводил лаконичность классиков, отмечу, что сайты текстовые весом даже в 5 мегабайт, так же лаконичны, по сравнению с той же информацией в форме видеороликов от стримеров. Сайт — 5 мегабайт, ролик на youtube в HD качестве может весить 5 гигабайт, а смысловое содержание примерно такое же (а иногда просто нулевое). Вот там да, глядя как стримеры некоторые забивают место на youtube терабайтами, и потом грузят этим хламом каналы беспроводного интернета, где частоты ограниченны весьма, и возникает вопрос о том, насколько эта информация нужна, целесообразна, оптимальна.
Ну и еще один момент "ожирения", высокие требования к количеству памяти на компьютере. Только по этой причине невозможно пользоваться интернетом на старых ноутбуках, где менее 1 гигабайта памяти. Браузеры под современные сайты просят памяти больше, чем есть в системе. Вот тут, наблюдаю реальные потери денег, нужно обновлять оборудование.
В стране есть ещё некоторое количество суровых мест, где Интернет (если он вообще есть) идёт, разве что, через спутник по космическим ценам. И там это весьма актуально, особенно если речь идёт о бизнес-приложениях.
Я пользуюсь интернетом в телефоне в основном в транспорте. С учетом плохого покрытия 3g во многих городах миллионниках, больше половины сайтов, которые я обычно просматриваю не могут открыться — где-нибудь проскакивает 2g, подвисает загрузка какого-нибудь скрипта и все, привет, сайт не загружается. Так что проблема во многом актуальна, на мой взгляд.
Если проскакивает 2G, то это беда, может прерваться TCP сессия по таймауту и далее множество сложностей. Как браузер, так и сервер в противоречии, рвать сессию или подождать? Для беспроводной мобильной связи лучше было бы использовать UDP протокол и разбирать пакеты более тщательно, с использованием приоритетов с учетом контекста ситуации.
15 секунд keep alive (значение по умолчанию) даже на 3G может далеко не всегда хватить на тяжелую 5 МБ страничку. Особенно замечательно, если при закрытии соединения происходит принудительная деавторизация (привет веб-банкинг, я говорю о тебе). А теперь берем страну с дорогим и медленным интернетом, спутник или заграницу — и начинаем посылать лучи «добра» разработчикам и системным администраторам.
Кстати, насчет страны с дорогим интернетом — мне как-то довелось общаться с «коренным» жителем Сахалина, вот он был весьма скептически настроен, насчет того, что интернет в России — быстрый и дешевый, причем по обоим тезисам. Кроме того, предполагаю, что почти весь ДВ и часть Сибири живут в подобных условиях.
Microsoft Edge в Windows 10 не прожорлив, на том же нетбуке тут же запускаешь Firefox и пр. и система ложится из-за нехватки памяти.
Ох, это все настолько точно и актуально, хочется соглашаться и соглашаться с автором под каждым абзацем!
Спасибо за перевод столь объемной (по нынешним меркам, когда принято вешать 2-3 мб картинок на строку текста) статьи.
Спасибо за перевод столь объемной (по нынешним меркам, когда принято вешать 2-3 мб картинок на строку текста) статьи.
Версия статьи на Хабре заняла больше 10 Мб против 1 Мб в оригинале :)
В последнее время "компьютер для интернета" имеет совсем другое значение, нежели 10 лет назад.
Целое счастье, что поисковики пока не "ожирели" до невозможности. С каким же удовольствием я пользуюсь ежедневно такими страничками, как ya.ru, gmail.com. Радует, что там нет ничего лишнего, только то, зачем я туда зашел.
Пользователь 100Мбит/с сети в мегаполисе:
Пользователь мобильного интернета на 128кбит/с в поселке.
Директор хостинга:
Менеджер по хостингу:
Менеджер разработки проекта:
Менеджер по рекламе:
- Меня это не касается, лучше фейсбук полистаю.
Пользователь мобильного интернета на 128кбит/с в поселке.
- А куда деваться (. Может, в следующем году оборудование новое поставят, будет быстрее, вроде ж обещали..
Директор хостинга:
- Большие странички? Ну хоть как-то компенсирует падение цены на бендвич, а то скоро доплачивать придется за трафик, чтобы брали хостинг у нас, а не конкурентов.
Менеджер по хостингу:
- Да кого волнует размер страницы, вы цены на бендвич видели? И так полностью укладываемся в тарифный пакет.
Менеджер разработки проекта:
- Оптимизировать размер? Нам что, время больше некуда девать. А тот единственный специалист, у которого есть опыт и знания, чтобы вручную оптимизировать html — да Вы хоть представляете, сколько стоит его время?
Менеджер по рекламе:
- Рекламная вставка тормозит? Так другая дохода такого не дает… А у тех, кто кликает по рекламе, каналы быстрые, у них не тормозит, вот замеры даже есть.
Я пользователь беспроводного (безлимитного) интернета в поселке, 6 км от черты города. Скорость не 128 кбит, больше в 10 раз, но и не 100 мегабит. Вообще без разницы сколько весит страничка. Уже отписывался, что основной трафик это видео файлы, да и там со сжатием и предварительным кэшированием всё хорошо.
Подождать 5 секунд на открытие странички, которую потом будешь изучать 10 минут, вообще не проблема (зачем странички кликать каждую секунду?). Тем более что загрузка в основном динамическая, пока знакомишься с текстом, подгружаются картинки.
Канал в 128 кбит/с (почему не 2400 бит/с, будем под такой канал подстраиваться?) это из области предельных режимов доступа к интернету, для этого есть мобильные версии сайтов и разнообразные технические ухищрения.
Именно мобильный интернет, больше напрягает высочайшим пингом и разрывом TCP сессии, когда соединение вроде бы есть, но данные уже никогда не придут. Больше UDP подойдет для таких случаев. Сам думаю переписать специфическое ПО для GSM модемов, собирающее телеметрические данные, при пинге 2000 мс, TCP соединение ведет себя как-то странно, с UDP проще.
Вторая проблема пользователя, то что тяжелые странички напрягают процессор телефона или планшета, по моим наблюдениям это больше раздражает, чем медленный канал связи (главное чтобы он стабильный был).
Подождать 5 секунд на открытие странички, которую потом будешь изучать 10 минут, вообще не проблема (зачем странички кликать каждую секунду?). Тем более что загрузка в основном динамическая, пока знакомишься с текстом, подгружаются картинки.
Канал в 128 кбит/с (почему не 2400 бит/с, будем под такой канал подстраиваться?) это из области предельных режимов доступа к интернету, для этого есть мобильные версии сайтов и разнообразные технические ухищрения.
Именно мобильный интернет, больше напрягает высочайшим пингом и разрывом TCP сессии, когда соединение вроде бы есть, но данные уже никогда не придут. Больше UDP подойдет для таких случаев. Сам думаю переписать специфическое ПО для GSM модемов, собирающее телеметрические данные, при пинге 2000 мс, TCP соединение ведет себя как-то странно, с UDP проще.
Вторая проблема пользователя, то что тяжелые странички напрягают процессор телефона или планшета, по моим наблюдениям это больше раздражает, чем медленный канал связи (главное чтобы он стабильный был).
У моих родителей беспроводный интернет (не мобильный, используется антенна) такой, что скайпом можно только аудио пользоваться.
Так что не сказал бы, что это предельная редкость.
Так что не сказал бы, что это предельная редкость.
Скайп не может кэшировать ведеопоток на час вперед. Когда смотришь фильм с youtube, не проблема даже пропадание интернета на 10 минут, скорость может замедляться, расти, дискомфорта это не вызывает. Тем более что нет цели сидеть у экрана от начала до конца трансляции, дома полно дел что могут отвлечь от фильма, в это время идет загрузка информации. У беспроводного интернета проблема не столько скорость, сколько высокий пинг и замирания потоков информации, к которым многие программы часто не готовы. Youtube тоже не восстанавливает связь после полного разрыва связи с получением нового динамического IP (но это и редкость, при перезагрузке модема возможно такое).
Страничку весом в 10МБ теоретически можно загрузить на dialup-е, отвлекшись на обед, тут не поспоришь.
Но смысл?
Если скайп не может нормально играть видео, то можете себе представить, как выглядит браузинг на таких скоростях — унылое зрелище. В то время как адекватный размер страниц решил бы эту проблему.
Но смысл?
Если скайп не может нормально играть видео, то можете себе представить, как выглядит браузинг на таких скоростях — унылое зрелище. В то время как адекватный размер страниц решил бы эту проблему.
Обед за 78.1 секунды? :) Вот эта страничка занимает 10 мегабайт. Только фотка с собакой весит 0.48 мегабайта. Куда деть графическую информацию, шрифты? Тут еще видео нет, а ко многим статьям прикреплено видео до 1000 мегабайт весом. Ява скрипт тоже множество функций выполняет, легкий переход в избранное и свои комментарии. Отказаться ради всего этого и оставить только текст?
Это всё было в 90е годы, вот вся страничка, ничего лишнего:
Это всё было в 90е годы, вот вся страничка, ничего лишнего:
Но только теоретически. На практике сервер рвёт соединение по таймауту секунд через 10-15, в зависимости от настроек. В итоге при достаточно медленной связи половину ресурсов вообще невозможно открыть, т.к. они тупо не успевают догрузиться, а докачки не предусмотрено. Несколько помогают технологии вроде Opera Turbo, без них за городом было бы совсем печально.
"бенд"-что?
Оптимизировать размер? Нам что, время больше некуда девать.
А может, просто его не раздувать?
https://stallman.org/
Нашел интересное расширение для FF по этой теме, https://addons.mozilla.org/ru/firefox/addon/tab-memory-usage/, отображает потребление памяти на каждой вкладке, удобно знать, какой сайт потребляет больше всего ресурсов, ведь весь мусор кроме того как нагружает интернет канал, еще и лежит в памяти.
Классное расширение. Только вот в тему статьи: официальная страничка этого приложения — 17МБ. На страничке, где все полезное — в виде текста.
И еще немного про это приложение. Ниже в комментариях приводят ссылку на идельно легкий сайт. Так вот, сравните две картинки:
Раз
Два
И все же это не совсем то. Расширение меряет количество оперативной памяти, отводимое компьютером под отображение конкретной вкладки. Это имеет лишь относительную корреляцию с весом самой страницы.
Выкиньте из отличной статьи "Кризис ожирения сайтов" все про ожирение сайтов, и она не станет хуже! Никогда бы не подумал, что напишу подобное без сарказма. Интересно, автор просто увлекся, или это осознанный прием?
Увы, простыми призывами "перестать так делать" проблему не решить. Потому что у тех, кто выделяют деньги на создание сайтов, никакой проблемы как раз нет.
Поэтому просто не остаётся иного выхода, кроме как решать проблему там, где она мешает — в браузере пользователя.
К счастью, пока ещё пользователь может контролировать как содержимое, так и работу веб-странички, а весь "жир" и все тормоза сосредоточены в картинках и скриптах, которые можно избирательно резать. Тяжёлая артиллерия Adblock + uMatrix + NoScript + imgLikeOpera посадит любой сайт на диету. Достаточно, в принципе, даже AdBlock+uMatrix, остальное уже на любителя.
А для тех ресурсов, которые вы посещаете регулярно, можно написать юзерскрипт (или даже найти готовый), который отформатирует страничку так, как надо вам, а не дизайнеру.
Конечно, рано или поздно под давлением рекламщиков разработают DRM для сайтов, разумеется исключительно для безопасности пользователя (ну чтоб дополнения не занимались фишингом и не крали приватную информацию). Но пока такого нет, ещё лет 5-7 можно наслаждаться нормальным вебом, пусть и с костылями в виде пачки дополнений.
Поэтому просто не остаётся иного выхода, кроме как решать проблему там, где она мешает — в браузере пользователя.
К счастью, пока ещё пользователь может контролировать как содержимое, так и работу веб-странички, а весь "жир" и все тормоза сосредоточены в картинках и скриптах, которые можно избирательно резать. Тяжёлая артиллерия Adblock + uMatrix + NoScript + imgLikeOpera посадит любой сайт на диету. Достаточно, в принципе, даже AdBlock+uMatrix, остальное уже на любителя.
А для тех ресурсов, которые вы посещаете регулярно, можно написать юзерскрипт (или даже найти готовый), который отформатирует страничку так, как надо вам, а не дизайнеру.
Конечно, рано или поздно под давлением рекламщиков разработают DRM для сайтов, разумеется исключительно для безопасности пользователя (ну чтоб дополнения не занимались фишингом и не крали приватную информацию). Но пока такого нет, ещё лет 5-7 можно наслаждаться нормальным вебом, пусть и с костылями в виде пачки дополнений.
/хмуро/
Отдельный железнодорожный костыль надо забить в голову тем дезигнерам которые вкрячивают видео на первую же страничку загрузки сайта.
Это доставляет неимоверную массу ощущений когда работаешь удаленно.
Отдельный железнодорожный костыль надо забить в голову тем дезигнерам которые вкрячивают видео на первую же страничку загрузки сайта.
Это доставляет неимоверную массу ощущений когда работаешь удаленно.
Чувак, ты нихрена не понимаешь в рекламе… прости.
Interstitial переводитса на русскии обђчно как межстраничнаја
Ох уж эти манипуляторы.
Берем файл книжки в цифровом виде и говорим, что она весит около мегабайта.
Берем страницу с твитом и говорим, что она весит около мегабайта.
Сравнимаем 140 символов с целой книгой.
Ох, ужас, мы все умрем!
При этом сайт мы берем со всеми библиотеками, которые лишь дают возможность его правильно отобразить. Самой разметки там кот наплакал. А книжку мы берем безо всего — только контент, только буквы. PDF с обложкой, разметкой и прочим, весил бы 5-8 мб. А если еще и картинки будут в тексте, можно и в 20-25мб раздуться.
И что вообще за идея сравнивать сайт с книгой?
Иногда хочется, чтобы такие приёмы приравнивали к мошенничеству и наказывали за них соответственно.
Берем файл книжки в цифровом виде и говорим, что она весит около мегабайта.
Берем страницу с твитом и говорим, что она весит около мегабайта.
Сравнимаем 140 символов с целой книгой.
Ох, ужас, мы все умрем!
При этом сайт мы берем со всеми библиотеками, которые лишь дают возможность его правильно отобразить. Самой разметки там кот наплакал. А книжку мы берем безо всего — только контент, только буквы. PDF с обложкой, разметкой и прочим, весил бы 5-8 мб. А если еще и картинки будут в тексте, можно и в 20-25мб раздуться.
И что вообще за идея сравнивать сайт с книгой?
Иногда хочется, чтобы такие приёмы приравнивали к мошенничеству и наказывали за них соответственно.
Автор совершенно правильно сравнивает текстовую составляющую книги и твита. Это сравнение не работает с веб-приложениями типа гугл.докс или страничек поиска авиабилетов, но абсолютно корректно для сайтов с текстовой информацией, и твиттер — один из них. В этом-то и дело, что конечному пользователю нет никакого дела до разметки, картинок и скриптов-шпионов, в твиттер он заходит за текстовой информацией. И художественную книгу он открывает за этим же.
Книжку можно читать и из txt. Максимум — fb2/epub, читать художественную литературу в pdf — мазохизм.
Автор — взрослый чувак, и в его юности солнце светило ярче, а женщины были более мохнатыми. Сравнение размера чистого текста и размера веб-статьи в корне неверно. Взять книжку Агнии Барто — там короткие стишки и большие картинки для детей. Но именно картинки заставляют малышей листать страницы (во всяком случае, я был таким малышом).
Фотография стоит тысячи слов. А видео — тысячи фотографий. Конечно, надо оптимизировать контент (хотя 20 лет назад экран был 1024х768 и модем 28800, а сейчас Ретина и выделенный канал).
Фотография стоит тысячи слов. А видео — тысячи фотографий. Конечно, надо оптимизировать контент (хотя 20 лет назад экран был 1024х768 и модем 28800, а сейчас Ретина и выделенный канал).
Я не особо взрослый, и солнце для меня всё еще светит ярко, но я тоже поддерживаю автора. Где-то до 2000 года я сёрфил интернеты с компьютера уровня современной микроволновки. Никаких проблем не было; ну, приходилось иногда отключать картинки, но не более того. Да, рекламы тогда было побольше, чем сейчас, но она легко резалась отключением картинок. Касательно наполнения — я изучал свою профессию по тем сайтам.
Потом что-то резко произошло, и моя Opera 9.63 вдруг перестала отображать все мои любимые сайты (либо crash, либо пустая страница, либо полторы кнопки с надписью «hidden»), а Firefox вдруг начал улетать в своп на каждом втором сайте. Сами сайты тоже изменились: первое время я на сайтах с «современным» дизайном просто играл в «пятнашки» — нажимал на плиточки и смотрел, как полстраницы куда-то плавно отъезжает; или играл в «бесконечный скроллинг», пытаясь найти конец страницы. Ну, потом наигрался и поставил NoScript.
Касательно наполнения: словосочетание «современный сайт» у меня ассоциируется с сине-белым фоном и огромной, потной надписью посреди экрана (при этом не всегда понятно, есть ли у сайта еще содержимое, кроме этой надписи).
Я не знаю, что произошло. Наверно, кто-то обнаружил, что JavaScript полон по Тьюрингу.
Потом что-то резко произошло, и моя Opera 9.63 вдруг перестала отображать все мои любимые сайты (либо crash, либо пустая страница, либо полторы кнопки с надписью «hidden»), а Firefox вдруг начал улетать в своп на каждом втором сайте. Сами сайты тоже изменились: первое время я на сайтах с «современным» дизайном просто играл в «пятнашки» — нажимал на плиточки и смотрел, как полстраницы куда-то плавно отъезжает; или играл в «бесконечный скроллинг», пытаясь найти конец страницы. Ну, потом наигрался и поставил NoScript.
Касательно наполнения: словосочетание «современный сайт» у меня ассоциируется с сине-белым фоном и огромной, потной надписью посреди экрана (при этом не всегда понятно, есть ли у сайта еще содержимое, кроме этой надписи).
Я не знаю, что произошло. Наверно, кто-то обнаружил, что JavaScript полон по Тьюрингу.
Вот плохой пример с книжкой на компьютере — тогда нужно учитывать весь стек. Браузер, движок рендеринга, шрифты, библиотеки отрисовки шрифтов, графическая подсистема ОС, графический драйвер, сама ОС… итого, получаются десятки мегабайт "лишнего" кода просто чтобы прочитать книжку. А уж если учесть прошивки "железной" части и вообще весь железный стек…
И чтобы прочитать анекдот про Штирлица, понадобится вот такая куча технологий.
И чтобы прочитать анекдот про Штирлица, понадобится вот такая куча технологий.
Sign up to leave a comment.
Кризис ожирения сайтов