Абсолютно нелогичное сравнение. Наши «мигалки» это люди, которые ничего не делают, а скорее даже вредят городу и стране, и, в добавок к этому, получают какие-то привилегии. А программисты честно зарабатывают свои деньги и блага, платят как и все налоги, и их автобусы это равноценные участники дорожного движения, без разницы кого они возят. Владельцы автобусов платят дорожные налоги также как и все. Ваше сравнение было бы хоть немного равноценно, если бы шатлы гугла сопровождали бы полицейские машины со спецсигналами. Тогда бы это было привилегированное положение нечестное по отношению ко всем остальным. А так можно с «мигалками» сравнить любые дорогие машины — тоже типа лучшее качество.
Всегда поражали такие активисты. Жалуются, что им денег не хватает, а сами в рабочий день, когда нормальные люди зарабатывают деньги, болтаются по улицам и устраивают пикеты и мешают другим людям работать. Если у тебя есть свободное время и не хватает денег — устройся на вторую работу, а лучше работой над собой, стань профессионалом в своей области и тоже получай большие деньги.
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут
Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.
нормально работать умная IDE, подсказывая методы
умные IDE это и сейчас умеют. Для сторонних фреймворков проблема решается созданием словаря API виджетов во время сборки проекта и скармливанием его движку autocomplete-a IDE. В нашем фреймворке так и делаем.
Про импорты не понял. Например, сейчас у меня есть миксин _FormValue от которого наследуются все инпут-виджеты. Кто-то из них оставляет отнаследованный метод, кто-то его оверрайдит. Как такой же механизм может быть реализован в компонентах?
«вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша
веб постоянно меняется. Если компонент не брошен своим автором, то в нем постоянно будет что-то меняться. И жесткий кеш будет только мешать.
Спасибо за отличную статью, с ее помощью в голове все уложилось лучше чем от прошлой. Даже понял, что был не совсем корректен сравнивая Dojo Widgets и Web Components.
Но JavaScript API работы с компонентами так и не понял. Если JS внутри компонента изолирован, то как компонент общается с внешним миром? Выставляет set/get/watch? Судя по статье на html5rocks он вообще ничего не предоставляет и set/get и методы работы с дочерними компонентами нужно описывать самому. Polymer позволяет регистрировать созданные виджеты и выставлять их свойства в качестве атрибутов, но в описании Web Components я ничего такого не нашел.
Абсолютная самостоятельность компонентов может быть очень вредна. Без механизма наследования и зависимостей мы рискуем получить сайты, которые подключают десятки надерганных из разных мест компонентов, которые на 90% имеют дублирующий код. Собственно как сейчас часто происходит с JQuery плагинами.
a). Загрузить AJAX-ом
б). Найти в DOM элемент, содержащий шаблон, извлечь шаблон оттуда.
Найти в DOM тег <template> с нужным шаблоном. Его содержимое уже распаршено, с ним можно работать как с любым элементов в DOM.
А куда делся аякс во втором варианте? Если вы заранее подгружаете шаблон в виде <template>, то вы точно также можете его без аякса подгрузить сразу и сейчас. А если вы подгрузили шаблон за ранее и он представляет из себя просто HTML без специальной разметки под вставку данных (как я вижу из примеров <template> предоставляет именно такое), то вы можете сразу создать из этого documentFragment и не вставлять его в DOM. А, когда нужно, взять его и
Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.
Тогда в чем отличие? В том, что documentFragment нужно где-то хранить и он занимает память? Если вам это так критично, то не создавайте его заранее, а просто вместо
Провернуть множество операций со строками. Эскейпить данные вручную.
Вставить получившуюся строку в DOM. Браузер парсит строку, рендерит содержимое.
создавайте documentFragment и работайте с ним через DOM API. Потом его вставляйте.
Собственно виджеты, которые есть в крупных фреймворках давным-давно, например, в Dojo, так и делают. Есть template: размеченный HTML. Есть JS: логика этого виджета. Внутри логики шаблон виджета доступен через свойство domNode в котором лежит documentFragment, который потом можно вставить в нужное место. Shadow же позволяет просто отображать эту domNode в веб-инспекторе в виде одного тэга. И то пока не поставлена галочка показывать призраков.
Сейчас страницы стали сложными и все фреймворки так или иначе приходят к идеям виджетов. Ребята в W3C это поняли и решили тоже запилить. Вероятно, иметь это нативно в браузере это хорошо, но это явно не стоит всех тех восторгов, которые по этому поводу высказываются. Плюс, судя по всему ребята решили сами пройти весь путь и поэтому, пока они соберут все грабли и сделают механизм сравнимый по удобству с тем, что сейчас предоставляют фреймворки, пройдет порядочно времени.
Постоянно работать в такой позе не очень, но на конференциях иногда сижу с ноутбуком на полу вытянув ноги и привалившись спиной к стенке. При условии ковролина, конечно. Мне, правда, так удобнее. И судя по тому, что наблюдаю, не мне одному. На одном из YaC-ов в такой же позе рядом со мной дремал Илья Сегалович :)
!~, конечно, зло. Обычно такими вещами балуются люди недавно прочитавшие про них и не понимающие, что уменьшать объем кода — это работа минификатора, а человек должен писать читабельный код. Про такие вещи было хорошее обсуждение в комментариях к статье про "|0", к сожалению, не смог её сейчас найти.
Одно дело, когда пытаешься разобраться как работает работающий код и совсем другое, когда пишешь код, который вроде бы должен работать, но на некоторых данных ведёт себя не логично (исходя из здравого смысла, а не спецификаций) и точное место фэйла неизвестно.
Вот от такого меня периодическое решение примеров с wtfjs и спасает. При решении обычных рабочих задач мне в голову не придет читать спецификации. Документацию по новому или редко используемому API — да, но не спецификацию. И у многих думаю похожая ситуация. Решая задачки на неочевидные моменты языка я во-первых, проникаюсь логикой языка, во-вторых, создаю в голове некую «карту граблей». И это позволяет мне в рабочем коде намного быстрее понять причины нелогичного поведения на некоторых данных.
С разработчиками, которые пишут на JavaScript относясь к нему как к второстепенному языку, вообще печальная картина. Мало того, что в результате получается макаронное месиво на JQuery и шутки про «как мне сложить два числа на JS? используй плагин JQuery», так получившееся творение течет и тормозит. И многие считают это нормальным. Почему-то никому не придет в голову отправить JS-ника «по быстрому накидать валидацию» на C++, т.к. понимают какого качестве в большинстве случаев будет полученный код, а вот джависта отправить костылять на JavaScript — это почему-то нормально.
внимательное чтение документации от такого спасет. Хотя лучше всего увидеть такой пример в статье, обратить внимание и, если не запомнить, то в следующий раз знать куда копать.
Для тех кто не знает в чем проблема. Map передает обработчику несколько аргументов. В частности вторым передает номер элемента в массиве. У функции parseInt, есть второй, необязательный, аргумент, который указывает на систему счисления. Таким образом в указанной записи второй и третий элемент массива будут обработаны в единичной и двоичной системе счисления и parseInt от них вернет NaN.
Или вот ещё недавно всплыло в твитере:
var a,b=[1,2,3][1,2,3];
a === b;
так массивы создавать нельзя, поэтому в обоих переменных лежит undefined, который равен сам себе.
Давайте ещё функции сравним по приколу, это тоже возможно (навскидку, сравниваются их .length, которые равны арности функции)
Функции это объекты, поэтому их можно сравнивать только на больше\меньше и тогда перед сравнением они будут приводится к строке. В случае проверки на равенство все так же как для массивов в пункте 3:
В случае оператора “==”” привидение к примтивам осуществляется только если один из аргументов примитив, а во всех остальных случаях оператор “==” возвращает true только если оба аргумента ссылаются на один объект (пункт 11.9.3 “Алгоритм сравнения абстрактного равенства”).
про набили оскомину я косвенно ответил в начале комментария. Глупо отрицать, что в JS есть грабли, но по-моему лучше узнавать их месторасположения из таких статей, а не на боевом коде.
В массивах допускается завершающая запятая. Тут я могу только сослаться на Флэнагана. Раздел 7.1:
«Если литерал массива содержит несколько идущих подряд запятых без значений между ними, создается разреженный массив. Элементы, соответствующие таким пропущенным значениям, отсутствуют в массиве, но при обращении к ним возвращается значение undefined.»
«Синтаксис литералов массивов позволяет вставлять необязательную завершающую запятую.»
Зачем так сделано мне не понятно. Если учесть, что IE8 и младше падает от лишней запятой, а дефолтные настройки JSLint определяют ее как ошибку, то логично предположить, что это браузер костыль от ошибок в JS коде.
Большая часть примеров оттуда. Я этого не скрываю и даже в метках указал. В качестве цели статьи я ставил разбор логики поведения. По-моему, простой просмотр «смотри какая хрень в JavaScript» не несет пользы, полезно понять почему именно так.
У меня тоже по математике, но в правильное время заложенная в голову возможность мыслить максимально абстрактно — очень полезная в программировании штука. А про информатику в ЛНМО… Даже спустя годы после вашего выпуска я бы преподавание Штукенберга толковым не назвал. Занятным, да. Поиграться с чем-то типа OCaml бывает интересно. Но я не помню, чтобы он подводил под это какаю-то теорию, а без нее это было именно, что поиграться со странной штукой. Да даже если и была, то, на мой взгляд, во время обучения программированию элементы computer science: автоматы, графы, матлингвистика, с практической реализацией, намного полезнее функциональщины.
Уже прочитал об этом. Это круто. Единственно формат смущает. Месячная летняя школа в формате интерната это круто и сверхпродуктивно. Но семестр непрерывного Лабораторского темпа… Это может оказаться слишком жестко.
Тогда вы зря прибедняетесь. ЛНМО это один из лучших коллективов учителей в Питере. После такой подготовки говорить, что не было преподавателя — как минимум, не красиво. Может до Лаборатории вы и учили все по книжкам, но между «одной из лучших команд Питера» и вашим самообучением были три года ЛНМО, которые обычно основательно правят мозг. К ЛНМО можно относится по разному и я ни в коем случае не умаляю того с чем вы пришли в Лабораторию, но не учитывать ее существование в своей жизни, по-моему, нельзя.
И да, работу для Колмогоровских чтений и Юниора вы без руководителя писали?
Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.
умные IDE это и сейчас умеют. Для сторонних фреймворков проблема решается созданием словаря API виджетов во время сборки проекта и скармливанием его движку autocomplete-a IDE. В нашем фреймворке так и делаем.
Про импорты не понял. Например, сейчас у меня есть миксин _FormValue от которого наследуются все инпут-виджеты. Кто-то из них оставляет отнаследованный метод, кто-то его оверрайдит. Как такой же механизм может быть реализован в компонентах?
веб постоянно меняется. Если компонент не брошен своим автором, то в нем постоянно будет что-то меняться. И жесткий кеш будет только мешать.
Но JavaScript API работы с компонентами так и не понял. Если JS внутри компонента изолирован, то как компонент общается с внешним миром? Выставляет set/get/watch? Судя по статье на html5rocks он вообще ничего не предоставляет и set/get и методы работы с дочерними компонентами нужно описывать самому. Polymer позволяет регистрировать созданные виджеты и выставлять их свойства в качестве атрибутов, но в описании Web Components я ничего такого не нашел.
Абсолютная самостоятельность компонентов может быть очень вредна. Без механизма наследования и зависимостей мы рискуем получить сайты, которые подключают десятки надерганных из разных мест компонентов, которые на 90% имеют дублирующий код. Собственно как сейчас часто происходит с JQuery плагинами.
А куда делся аякс во втором варианте? Если вы заранее подгружаете шаблон в виде <template>, то вы точно также можете его без аякса подгрузить сразу и сейчас. А если вы подгрузили шаблон за ранее и он представляет из себя просто HTML без специальной разметки под вставку данных (как я вижу из примеров <template> предоставляет именно такое), то вы можете сразу создать из этого documentFragment и не вставлять его в DOM. А, когда нужно, взять его и
Тогда в чем отличие? В том, что documentFragment нужно где-то хранить и он занимает память? Если вам это так критично, то не создавайте его заранее, а просто вместо
создавайте documentFragment и работайте с ним через DOM API. Потом его вставляйте.
Собственно виджеты, которые есть в крупных фреймворках давным-давно, например, в Dojo, так и делают. Есть template: размеченный HTML. Есть JS: логика этого виджета. Внутри логики шаблон виджета доступен через свойство domNode в котором лежит documentFragment, который потом можно вставить в нужное место. Shadow же позволяет просто отображать эту domNode в веб-инспекторе в виде одного тэга. И то пока не поставлена галочка показывать призраков.
Сейчас страницы стали сложными и все фреймворки так или иначе приходят к идеям виджетов. Ребята в W3C это поняли и решили тоже запилить. Вероятно, иметь это нативно в браузере это хорошо, но это явно не стоит всех тех восторгов, которые по этому поводу высказываются. Плюс, судя по всему ребята решили сами пройти весь путь и поэтому, пока они соберут все грабли и сделают механизм сравнимый по удобству с тем, что сейчас предоставляют фреймворки, пройдет порядочно времени.
игра с приведением типов и переопределением метода прототипа
собственно в ветке обсуждения описан метод решения
можно создавать массивы? И что будет лежать в переменной а?
Дан код:
Что нужно добавить в начало программы, чтобы rx1 и rx2 стали идентичными? Сами строчки трогать нельзя.
Вот от такого меня периодическое решение примеров с wtfjs и спасает. При решении обычных рабочих задач мне в голову не придет читать спецификации. Документацию по новому или редко используемому API — да, но не спецификацию. И у многих думаю похожая ситуация. Решая задачки на неочевидные моменты языка я во-первых, проникаюсь логикой языка, во-вторых, создаю в голове некую «карту граблей». И это позволяет мне в рабочем коде намного быстрее понять причины нелогичного поведения на некоторых данных.
С разработчиками, которые пишут на JavaScript относясь к нему как к второстепенному языку, вообще печальная картина. Мало того, что в результате получается макаронное месиво на JQuery и шутки про «как мне сложить два числа на JS? используй плагин JQuery», так получившееся творение течет и тормозит. И многие считают это нормальным. Почему-то никому не придет в голову отправить JS-ника «по быстрому накидать валидацию» на C++, т.к. понимают какого качестве в большинстве случаев будет полученный код, а вот джависта отправить костылять на JavaScript — это почему-то нормально.
внимательное чтение документации от такого спасет. Хотя лучше всего увидеть такой пример в статье, обратить внимание и, если не запомнить, то в следующий раз знать куда копать.
Для тех кто не знает в чем проблема. Map передает обработчику несколько аргументов. В частности вторым передает номер элемента в массиве. У функции parseInt, есть второй, необязательный, аргумент, который указывает на систему счисления. Таким образом в указанной записи второй и третий элемент массива будут обработаны в единичной и двоичной системе счисления и parseInt от них вернет NaN.
так массивы создавать нельзя, поэтому в обоих переменных лежит undefined, который равен сам себе.
Функции это объекты, поэтому их можно сравнивать только на больше\меньше и тогда перед сравнением они будут приводится к строке. В случае проверки на равенство все так же как для массивов в пункте 3:
про набили оскомину я косвенно ответил в начале комментария. Глупо отрицать, что в JS есть грабли, но по-моему лучше узнавать их месторасположения из таких статей, а не на боевом коде.
В массивах допускается завершающая запятая. Тут я могу только сослаться на Флэнагана. Раздел 7.1:
«Если литерал массива содержит несколько идущих подряд запятых без значений между ними, создается разреженный массив. Элементы, соответствующие таким пропущенным значениям, отсутствуют в массиве, но при обращении к ним возвращается значение undefined.»
«Синтаксис литералов массивов позволяет вставлять необязательную завершающую запятую.»
Зачем так сделано мне не понятно. Если учесть, что IE8 и младше падает от лишней запятой, а дефолтные настройки JSLint определяют ее как ошибку, то логично предположить, что это браузер костыль от ошибок в JS коде.
Уже прочитал об этом. Это круто. Единственно формат смущает. Месячная летняя школа в формате интерната это круто и сверхпродуктивно. Но семестр непрерывного Лабораторского темпа… Это может оказаться слишком жестко.
И да, работу для Колмогоровских чтений и Юниора вы без руководителя писали?