В данный момент вся сложность в том, что бэмисты гордятся своими bemhtml и bemjson, а реальное преимущество в них ощущается не сильно. А они уже привыкли так.
А семантики своим jade|haml|slim + less|sass|stylus, которые тоже очень удобны. И они не видят смысла делать двух-трех уровневую структуру блоков.
Я просто по своему опыту знаю что библиотеки от полимера всегда стоит принимать во внимание. И самому проверять, в каких браузерах они поддерживаются, тот же самый MutationObserver полифилл не работал в ie8 и андроиде 2.3 только, во всех остальных хоть сколько-то актуальных ощущался практически как нативный, несмотря на их «мы поддерживаем только последние версии браузеров».
вы бы хоть комментарий прочли. Конкретно с этим полифиллом я не работал, но имел дело с пятью полифиллами: weakmap, mutationobserver, observe-js, html imports, custom elements из полимера, все из них, несмотря на декларирование ie10+ only, вполне неплохо работали с ie9+.
На weakmap+mutationObserver работает моя собственная библиотека, и я ее долго и упорно тестировал под ie9+, чтобы убедиться в стабильности; mozilla X-tags опираются на custom elements и HTML Imports, и декларируют ie9+.
Полимеры — известные перестраховщики, у них есть на то право. Они делают будущее веба, на настоящее веба они имеют право не оглядываться, веб компонентов будет актуален только года через два-три, а пока они делают proof of concept и фрейморк-для-фреймворков.
Я практически уверен, что pointer events спокойно заведутся в ie9+(в ie8 не заведутся только из-за отсутствия addEventListener), в куче мобильных браузеров и так далее.
И да, Pointer Events by Polymer — это не библиотека, это полифилл (polyfill / shim). Библиотеки добавляют функционал на основе дополнительной спецификации, например, jQuery работает в соответствии с собственной документацией. Полифиллы предоставляют стандартный функционал на устаревших платформах, следуя публично доступной спецификации, утвержденной сообществом или вендором. Разница заключается в том, что полифиллы обеспечивают следование стандартам там, где это было не предусмотрено, и в вебе, например, могут со временем безболезненно убираться из кода. В 2015 году вы не сможете выдрать из старого сайта жквери, а вот полифилл для pointer events — спокойно сможете.
По браузерам точно не укажу, но гарантированно ie10+, safari 6, safari mobile, последние версии хрома и фф. По опыту работы с другими полифиллами полимера. скорее всего поддерживается на самом деле ie9+, и хром и лиса где-то с двадцатых версий.
да, там несколько баг по этому поводу, просто это всего второй случай на моей памяти, когда уже давно и стабильно работающая, а значит — допустимая к использованию и вполне активно использующаяся в продакшне фича падает из-за обновления автообновляющегося браузера. До этого было только раз, когда mozilla убрала из открытого доступа классы списков нод(HTMLNodeMap, кажется). Но их в общем-то пользовать и не стоило, а тут вполне устоявшийся css3 псевдокласс. Решил, что предупредить сообщество стоит, потому что у меня лично было минут пять-семь паники из-за этого.
зато в канарейке месяц назад попытка проскроллить заканчивалась крэшем на некоторых сайтах. Меня это (и то что он два месяца назад зависал при попытке открыть консоль разработчика) убедило перейти на просто хром все-таки.
А смысл в этом советчике? В море по сути практически нет реально сложных задач, все можно решать и самостоятельно.
Суда с минимальным экипажем в шесть человек и так есть: капитан+старпом поочередно стоят по 6 часов на вахте(разделение ответственности), стармех(опять же тупо ответственность) следит за состоянием машины, 2 моториста, которые при необходимости встают на руль(требование конвенции) и повар.
Вопрос в том, как убрать этот минимальный экипаж.
В отличии от автомобилей полная автоматизация грузовых судов могла бы дать куда большие преимущества: если убрать жилые помещения надстройки и требования безопасности для людей, можно увеличить диапазон нагрузок, в том числе максимальные углы крена при штормовых условиях, то есть при сильном волнении там, где экипаж с людьми будет вынужден снизить скорость хода и изменить курс, роботизированное судно сможет двигаться вперед без значительного снижения скорости. Плюс нет проблем с обледенением корпуса — ну обледенеет палуба и хрен с ним, там никому ходить не надо. В общем из объекта, который рассчитан на то, что по нему будут ходить, роботизация делает судно консервой с пропеллером, которой вообще плевать что с ней творится, она идет себе и идет. Но это уже мои рассуждения личные.
Самолеты-самолетами, а я вам расскажу байку, которую мне рассказал побитый жизнью старпом, когда я четыре месяца работал на танкере. Ну, было дело. Если что-то переврано — за что купил, за то и продаю, никаких претензий на абсолютную историческую точность.
В Японии в восемьдесятчетвертом, кажется, году были испытания полностью автоматического танкера. Присутствие людей ограничивалось тем, что на буксире забрасывали швартовную команду, она швартовалась и сходила. То же самое на отход. Все остальное время консерва болталась в море сама по себе и шла себе на дизельном моторчике спокойно. Ну, так предполагалось.
После первых ходовых испытаний, когда умный робот идеально вывел судно в море, судовладельцам прошел звонок сидеть на месте и не дергаться, после чего на судно высадился отряд с вертолета, и полностью уничтожил все оборудование. С тех пор попытки создать робота-судоводителя не предпринимались.
Звучит как полная ахинея, но после того, как попадаешь в эту среду, и видишь, как машинное отделение может спокойно полностью управляться с пульта (что и происходит каждую ночь на танкерах), после того как узнаешь про суда с пятью-шестью людьми экипажа (это минимальный набор по конвенциям), про полный автопилот — когда есть возможность проложить курс от начала и до конца, и он сам будет поворачивать, ускоряться и замедляться — в море под автопилотом обычно подразумевается система удержания на курсе, т.н. авторулевой — начинаешь вспоминать понятие из mass effect, «виртуальный интеллект». Это искуственный интеллект с намеренно ограниченными возможностями. Тут то же самое, машины могут делать все, но им не дают.
Теперь самый главный вопрос: почему?
Мне это объяснили очень просто. Стоимость экипажа на фоне всего чартера — цифра незначительная. Аренда судна — условно 50 тысяч долларов в день, где-то больше, где-то меньше. Весь экипаж — с учетом еды и всего остального — может укладываться в 50 тысяч долларов в месяц и даже меньше. 3% от стоимости аренды — это весьма незначительная цифра.
Еще один постулат: производство подобного ИИ — штука дорогая, и этим занималось бы всего несколько агентств по миру, так что один и тот же ИИ был бы на сотнях, а то и тысячах судов по миру, по крайней мере вначале.
И мы подходим к самому интересному. Даже если предположить, что ИИ подключался бы исключительно на время морского перехода, оставался бы риск аварий.
Морское ПДД — т.н. МППСС — и еще куча регламентов созданы со следующей целью: даже в случае, если их соблюдает только один из участников движения, все равно аварии не должно произойти. Там реально просто блок-схема, «если то — делай одно, иначе — делай другое». Соответственно, если происходит авария в случае, если ИИ полностью следовал МППСС — то все-таки ИИ некорректно откалиброван, и необходимо будет полностью остановить до окончания отладки все суда с этим ИИ по миру. И тут мы вспоминаем историю про фикс бизнес-джета, и умножаем 30 дней на пусть 100 кораблей на 50 тысяч в день, которые предъявят разработчику. При этом количество исков к судовладельцам за несвоевременную доставку грузов увеличится в разы. В среднем судно может перевозить товар на несколько миллионов долларов, и это могут быть, например, бананы, которые нужно довезти как можно быстрее. При этом p&i клубы(страховщики) почти наверняка не будут готовы покрыть ущерб из-за ИИ.
Это финансовые риски от одной аварии. В случае, если авария произошла с человеком на вахте — останавливается одно судно, и сажается один человек, который был на вахте (условно).
И, наконец, самое главное. В случае человеческих жертв опять же сажают капитана и вахтенного офицера. Но в случае с аварией с участием ИИ кого сажать?
Повторяю, это не мое личное мнение даже, это рассуждения человека, который больше десяти лет работает в море, и просто рассказал мне, почему до сих пор мы делаем все то, что могут делать роботы.
А с самолетами рисков еще больше, они могут и на город упасть, например. И даже если риск — тысячная доля процента, все равно нужно чтобы было кого обвинить. И желательно, чтобы при этом не пострадал чужой бизнес.
Это реализация на уровне библиотеки все же, и скорее всего вы ее довольно долго писали, и выявили кучу интересных особенностей поведения. Я говорил про конечных разработчиков, которые не хотят писать нужные вызовы на внесения правок в верстку, и вместо этого пользуют мутейшнобсервер.
Пожалуйста, не надо использовать mutationObserver в продакшне, не в рамках библиотек. Он реально очень низкоуровневый.
В чем, собственно, дело: по сути единственный способ изменить дом-дерево это код. Код, который написал разработчик.
Если разработчик не способен архитектурно построить код так, чтобы реагировать на внесенные этим же кодом изменения в дом-дерево — я бы не назвал разработчика грамотным.
Пользователь максимум может взаимодействовать с value инпутов и :checked у чекбокса — это из изменений структуры. Ну ладно, сейчас появились drag-n-drop события, но они тоже обрабатываются на жс, нельзя просто так все править, без создания базы для кода. Так что на исключение не тянет. Ладно, если говорить совсем откровенно — есть и contenteditable, но он до сих пор не кроссплатформенный, да и я честно еще не встречал его нигде, и, подозреваю, нескоро встречу.
Mutation events необходимы для веб-компонентов, без них невозможно построить триггеры на добавление кастомного элемента в дом-дерево, что лишает их большинства преимуществ. Mozilla и Google вместе разрабатывали этот стандарт, и, конечно же, им хотелось сделать для себя разумные и простые решения. Кроме этого единственное, где реально имеет смысл использовать MutationObserver не в качестве очень грязного хака — это библиотеки, переводящие большую часть кода в декларативное состояние, например, Angular и ему подобные с директивами.
А так — не надо пользовать. Не только даже потому что это почти невозможно отлаживать, но еще и потому что у MutationObserver до конца не выясненные глюки. Например, мало кому известно, что в хроме(во всяком случае раньше было так) на четвертом или пятом колбэке подряд, когда в самом колбеке редактируется содержимое элемента, иногда обсервер захлебывается и начинает пропускать события. При этом этот эффект наблюдается только на ванилле, jquery как-то его обходит.
я не знаю что думать, потому что у меня полифилл для mutationObserver, который поддерживал в том числе вендорные префиксы, появившиеся в хроме в 14-й версии. Так что подцеплялся нормально.
А в яндекс-браузере он тупо фейлил базовые тесты для mutationObserver. Если бы не видел своими глазами — не поверил. Три из пяти событий не отстреливались. Переключил форсированно на DOM Mutation Events, потому что настолько испохабленный мутейшнобсервер за api считать нельзя. Но и там куча всего ломалась.
Добавился Яндекс.Браузер, который внутре тот же Хромиум, хоть и обновляется реже.
Даааа. Конеечно.
Мне только одно интересно. А нахрена они выпилили mutationObserver из хромиума? Да еще и испоганили DOM mutation events. В итоге полифилл отрабатывал от силы раз из трех.
а стилизовать отца как-то тоже зло очень.
В данный момент вся сложность в том, что бэмисты гордятся своими bemhtml и bemjson, а реальное преимущество в них ощущается не сильно. А они уже привыкли так.
А семантики своим jade|haml|slim + less|sass|stylus, которые тоже очень удобны. И они не видят смысла делать двух-трех уровневую структуру блоков.
На weakmap+mutationObserver работает моя собственная библиотека, и я ее долго и упорно тестировал под ie9+, чтобы убедиться в стабильности; mozilla X-tags опираются на custom elements и HTML Imports, и декларируют ie9+.
Полимеры — известные перестраховщики, у них есть на то право. Они делают будущее веба, на настоящее веба они имеют право не оглядываться, веб компонентов будет актуален только года через два-три, а пока они делают proof of concept и фрейморк-для-фреймворков.
Я практически уверен, что pointer events спокойно заведутся в ie9+(в ie8 не заведутся только из-за отсутствия addEventListener), в куче мобильных браузеров и так далее.
И да, Pointer Events by Polymer — это не библиотека, это полифилл (polyfill / shim). Библиотеки добавляют функционал на основе дополнительной спецификации, например, jQuery работает в соответствии с собственной документацией. Полифиллы предоставляют стандартный функционал на устаревших платформах, следуя публично доступной спецификации, утвержденной сообществом или вендором. Разница заключается в том, что полифиллы обеспечивают следование стандартам там, где это было не предусмотрено, и в вебе, например, могут со временем безболезненно убираться из кода. В 2015 году вы не сможете выдрать из старого сайта жквери, а вот полифилл для pointer events — спокойно сможете.
www.polymer-project.org/platform/pointer-events.html
По браузерам точно не укажу, но гарантированно ie10+, safari 6, safari mobile, последние версии хрома и фф. По опыту работы с другими полифиллами полимера. скорее всего поддерживается на самом деле ie9+, и хром и лиса где-то с двадцатых версий.
зато в канарейке месяц назад попытка проскроллить заканчивалась крэшем на некоторых сайтах. Меня это (и то что он два месяца назад зависал при попытке открыть консоль разработчика) убедило перейти на просто хром все-таки.
Суда с минимальным экипажем в шесть человек и так есть: капитан+старпом поочередно стоят по 6 часов на вахте(разделение ответственности), стармех(опять же тупо ответственность) следит за состоянием машины, 2 моториста, которые при необходимости встают на руль(требование конвенции) и повар.
Вопрос в том, как убрать этот минимальный экипаж.
В отличии от автомобилей полная автоматизация грузовых судов могла бы дать куда большие преимущества: если убрать жилые помещения надстройки и требования безопасности для людей, можно увеличить диапазон нагрузок, в том числе максимальные углы крена при штормовых условиях, то есть при сильном волнении там, где экипаж с людьми будет вынужден снизить скорость хода и изменить курс, роботизированное судно сможет двигаться вперед без значительного снижения скорости. Плюс нет проблем с обледенением корпуса — ну обледенеет палуба и хрен с ним, там никому ходить не надо. В общем из объекта, который рассчитан на то, что по нему будут ходить, роботизация делает судно консервой с пропеллером, которой вообще плевать что с ней творится, она идет себе и идет. Но это уже мои рассуждения личные.
В Японии в восемьдесятчетвертом, кажется, году были испытания полностью автоматического танкера. Присутствие людей ограничивалось тем, что на буксире забрасывали швартовную команду, она швартовалась и сходила. То же самое на отход. Все остальное время консерва болталась в море сама по себе и шла себе на дизельном моторчике спокойно. Ну, так предполагалось.
После первых ходовых испытаний, когда умный робот идеально вывел судно в море, судовладельцам прошел звонок сидеть на месте и не дергаться, после чего на судно высадился отряд с вертолета, и полностью уничтожил все оборудование. С тех пор попытки создать робота-судоводителя не предпринимались.
Звучит как полная ахинея, но после того, как попадаешь в эту среду, и видишь, как машинное отделение может спокойно полностью управляться с пульта (что и происходит каждую ночь на танкерах), после того как узнаешь про суда с пятью-шестью людьми экипажа (это минимальный набор по конвенциям), про полный автопилот — когда есть возможность проложить курс от начала и до конца, и он сам будет поворачивать, ускоряться и замедляться — в море под автопилотом обычно подразумевается система удержания на курсе, т.н. авторулевой — начинаешь вспоминать понятие из mass effect, «виртуальный интеллект». Это искуственный интеллект с намеренно ограниченными возможностями. Тут то же самое, машины могут делать все, но им не дают.
Теперь самый главный вопрос: почему?
Мне это объяснили очень просто. Стоимость экипажа на фоне всего чартера — цифра незначительная. Аренда судна — условно 50 тысяч долларов в день, где-то больше, где-то меньше. Весь экипаж — с учетом еды и всего остального — может укладываться в 50 тысяч долларов в месяц и даже меньше. 3% от стоимости аренды — это весьма незначительная цифра.
Еще один постулат: производство подобного ИИ — штука дорогая, и этим занималось бы всего несколько агентств по миру, так что один и тот же ИИ был бы на сотнях, а то и тысячах судов по миру, по крайней мере вначале.
И мы подходим к самому интересному. Даже если предположить, что ИИ подключался бы исключительно на время морского перехода, оставался бы риск аварий.
Морское ПДД — т.н. МППСС — и еще куча регламентов созданы со следующей целью: даже в случае, если их соблюдает только один из участников движения, все равно аварии не должно произойти. Там реально просто блок-схема, «если то — делай одно, иначе — делай другое». Соответственно, если происходит авария в случае, если ИИ полностью следовал МППСС — то все-таки ИИ некорректно откалиброван, и необходимо будет полностью остановить до окончания отладки все суда с этим ИИ по миру. И тут мы вспоминаем историю про фикс бизнес-джета, и умножаем 30 дней на пусть 100 кораблей на 50 тысяч в день, которые предъявят разработчику. При этом количество исков к судовладельцам за несвоевременную доставку грузов увеличится в разы. В среднем судно может перевозить товар на несколько миллионов долларов, и это могут быть, например, бананы, которые нужно довезти как можно быстрее. При этом p&i клубы(страховщики) почти наверняка не будут готовы покрыть ущерб из-за ИИ.
Это финансовые риски от одной аварии. В случае, если авария произошла с человеком на вахте — останавливается одно судно, и сажается один человек, который был на вахте (условно).
И, наконец, самое главное. В случае человеческих жертв опять же сажают капитана и вахтенного офицера. Но в случае с аварией с участием ИИ кого сажать?
Повторяю, это не мое личное мнение даже, это рассуждения человека, который больше десяти лет работает в море, и просто рассказал мне, почему до сих пор мы делаем все то, что могут делать роботы.
А с самолетами рисков еще больше, они могут и на город упасть, например. И даже если риск — тысячная доля процента, все равно нужно чтобы было кого обвинить. И желательно, чтобы при этом не пострадал чужой бизнес.
В чем, собственно, дело: по сути единственный способ изменить дом-дерево это код. Код, который написал разработчик.
Если разработчик не способен архитектурно построить код так, чтобы реагировать на внесенные этим же кодом изменения в дом-дерево — я бы не назвал разработчика грамотным.
Пользователь максимум может взаимодействовать с value инпутов и :checked у чекбокса — это из изменений структуры. Ну ладно, сейчас появились drag-n-drop события, но они тоже обрабатываются на жс, нельзя просто так все править, без создания базы для кода. Так что на исключение не тянет. Ладно, если говорить совсем откровенно — есть и contenteditable, но он до сих пор не кроссплатформенный, да и я честно еще не встречал его нигде, и, подозреваю, нескоро встречу.
Mutation events необходимы для веб-компонентов, без них невозможно построить триггеры на добавление кастомного элемента в дом-дерево, что лишает их большинства преимуществ. Mozilla и Google вместе разрабатывали этот стандарт, и, конечно же, им хотелось сделать для себя разумные и простые решения. Кроме этого единственное, где реально имеет смысл использовать MutationObserver не в качестве очень грязного хака — это библиотеки, переводящие большую часть кода в декларативное состояние, например, Angular и ему подобные с директивами.
А так — не надо пользовать. Не только даже потому что это почти невозможно отлаживать, но еще и потому что у MutationObserver до конца не выясненные глюки. Например, мало кому известно, что в хроме(во всяком случае раньше было так) на четвертом или пятом колбэке подряд, когда в самом колбеке редактируется содержимое элемента, иногда обсервер захлебывается и начинает пропускать события. При этом этот эффект наблюдается только на ванилле, jquery как-то его обходит.
А в яндекс-браузере он тупо фейлил базовые тесты для mutationObserver. Если бы не видел своими глазами — не поверил. Три из пяти событий не отстреливались. Переключил форсированно на DOM Mutation Events, потому что настолько испохабленный мутейшнобсервер за api считать нельзя. Но и там куча всего ломалась.
Даааа. Конеечно.
Мне только одно интересно. А нахрена они выпилили mutationObserver из хромиума? Да еще и испоганили DOM mutation events. В итоге полифилл отрабатывал от силы раз из трех.