С JS, как ни странно, MS — молодцы.
В ie11 они внедрили самые нужные вещи, которые нереально сделать Traceur или чем-либо аналогичным.
Arrow function транслитерировать в обычную — как нехрен делать.
А вот поддержку let и const внедрить, или ввести дополнительные структуры в память — типизированные массивы, Map, Set, WeakMap, __proto__ — черта с два какой-нибудь там traceur сможет поддержать такую низкоуровневую работу с языком.
Да одно только то, что они в ie10 ввели поддержку WebGL — уже говорит о том, что они пашут как кони проклятые там.
Я считаю, что в Редмонде с осликом нынче делают реально хорошую работу, подходят с умом, а 9-11 версии делались с оглядкой на то, что энтерпрайз их будет держать у себя годами, и хотели помочь разработчикам обеспечить приличное быстродействие и возможности, а не максимум сахара.
Эмм, нет.
Полимер работает поверх «честных» компонентов, это что-то типа lodash для компонентов — удобная обертка, дата-биндинг и еще пара прелестей жизни.
И еще полифиллы.
Так у таких функций есть ограниченная область применения, там явно видно, нахрена они нужны.
Они не создают новый this, они красивее всего выглядят с одним аргументом и одним действием… В общем-то придумали их, как я понимаю, чтобы чейнинг делать там красивый, ну например
arr
.map( entry => entry.length)
.filter( len => len > 10)
.sort()
Это все вкусовщина.
Как человек, который пишет на руби и es6 — es6 ощущается более структурированным. Я уже давно с трудом читаю чужой код на кофе, руби и питоне — он выглядит для меня слишком «плотным», а подсвеченные в IDE фигурные скобки и точки с запятой позволяют увидеть, где заканчивается чейнинг команды.
Есть буквально пара вещей, которые действительно хотелось бы перетащить из руби — пара особенностей синтаксиса для большей выразительности и читаемости (def вместо function, do ...end в дополнение к обычным стрелочным функциям), честные геттеры и сеттеры (да, они только в паре могут обновляться, а это свинство — мне порой надо только сеттер, например, обновить, а есть только Object.defineProperty) и что-то еще, примерно такого же уровня, вот только что из головы вылетело, к сожалению.
Но в качестве «преимущественно функционального» языка — JS (окей, JS в ближайшем будущем) делает руби. Да, в руби есть Lambda и block, но в реальности ими не так удобно пользоваться, если ты сторонник именно функциональной парадигмы, а не объектной. Напишите простенький пример на руби, который будет делать примерно то же самое:
а речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то
За гарантиями в проект v8. Думаете, он рискнет обновиться так что что-нибудь отвалится?
Я лично очень в этом сомневаюсь
io.js — это же по сути «обвес».
HTML как он сложился — увы, именно про «семантику-шмемантику для хомячков»
Дело не в этом, дело в том, что он (как и любой другой язык разметки, т.е. семантичного структурирования данных) позволяет на базе себя, как абстрактного языка, не имеющего дела с реальными понятиями, реализовывать структуры конкретных данных.
Условно, если HTML служит для описания деревьев (живых таких, зеленых) как абстрактного понятия — с листочками, веточками и так далее, то OpenGraph уже позволяет указывать точную породу древесины и ее возраст, а HTML предоставляет еще и табличку перед деревом, на котором можно написать в том числе это. Так понятнее?
Не маскировка, а честное авторедактирование.
Да, возможно, имелось ввиду указание для мобильных, нужно ли делать автокапитализацию каждого слова. С этим — ок, согласен, возможно, автор криво написал просто идею.
Да, можно, всякие schema.org и т.п. тоже этим занимаются. Но если семантика выносится в отдельный слой, что остается на основном уровне? Мне кажется, то, что в нашу соцсетевую эру в HTML нет стандартной штуки для указания на человека (которая «из коробки» могла бы интегрироваться с приложениями для контактов и т.п.) — это всё-таки недоработка языка. Не фатальная, конечно, но лишней такая штука бы точно не была)
Я еще раз говорю — HTML и OpenGraph это несколько уровней одной модели, как в OSI. HTML — структурирует, оперируя абстрактной информацией. OpenGraph — оперирует конкретными понятиями и сущностями. Я говорю об этой семантике, а не о истерии хомячков на тему того, что правильнее — section или article
Как это нет? А проложить/рассчитать маршрут до искомого места, а найти ближайшие к месту стоянку/гостиницу/кафешку, а в недалекой перспективе — указать пункт назначения для роботакси? По-моему, в нынешнем вебе, особенно мобильном, к геоданным что только ни привязывается…
Опять вспоминаем про уровни использования.
Время нужно, чтобы на уровне представления браузер мог показать актуальное для пользователя время. Координаты достаточно вынести в очередной метатэг.
Проблем куча:
На сервере будут некорректные данные, но юзер этого не поймет;
Когда юзер попытается зайти со старого компа, не понимающиего text-transform для textarea, и введет визуально тот же текст, сервер скажет ему «ты кто такой, давай до свидания», что будет для юзера выглядеть необъяснимой ошибкой;
Нельзя ввести фамилию «ван Бетховен», которая совсем не то же самое, что «Ван Бетховен» (CSS-отображение вручную никак не перебить, а от поля с автокапитализацией лично я жду поведения нынешней клавиатуры iOS после точки — по умолчанию большая буква, но это можно явно отменить);
Путаница из-за одинакового отображения разных (в т.ч. по смыслу) входных данных.
эмм. нет.
1. Ну, на сервере хранятся данные для машин. Время там тоже не в особо человеческом формате.
2. Насколько помню — text-transform — одно из самых первых свойств.
3. А в предложенном решении с принудительной трансформацией как это решается?
4. Где?
Я лично так не буду делать никогда в основном из-за третьего пункта. Но для тех, кто хочет вот так автоматически все превращать — лучше править на уровне отображения, чем принудительно что-то слать в базу.
Потребность у многих есть уже сейчас. И вполне нормально, имхо, прощупывать разные подходы — чтобы в итоге консорциуму было из чего выбрать лучший и довести до ума окончательно, и сделать это до 2022-го года:)
Еще раз: если работает в полифилле — это можно использовать. Консорциум будет смотреть, изучать, вносить правки, а когда уже отлежится и все поймут, что им реально надо — примут.
много синтаксического сахара
И разве это плохо? :)
И да и нет. Причем в основном нет. С одной стороны — классы — это хорошо для быстродействия. С другой — дело в том, что язык должен будет поддерживаться по сути бесконечноhttp://habrahabr.ru/post/249207/# долго (самые первые сайты до сих пор должны корректно отображаться). Из-за этого фичи и возможности продумываются достаточно долго, на это тратятся напряженные часы споров, тестов, изучения и проб. Для такого большого изменения, как классы — это сожрало туеву кучу времени. По факту из-за того, что куча набежавших хомячков затребовала классы, как у нормальных посонов на серверсайде, а то чо мы как лохи — меньше времени ушло на обсуждение тех фич, которые нельзя было бы реализовать без трансляторов на уровень JS. А классы — это реально огромное количество проделанной работы.
В итоге — из-за того, что пахали над классами — до сих пор, например, в фазе обсуждения находятся async/await functions.
Это абстрактный пример, я не слежу за происходящем в сообществе, но тем не менее.
Просто чтобы понимать уровень сложности принятия решений однозначности ради — объясню на примере arrow functions и destructing assignment.
У них вот такой синтаксис:
То есть скобки не обязательны, если есть один аргумент. Если выполняется одна операция и нет фигурных скобок — ее результат возвращается.
Вопрос на засыпку: во что должен превратиться и должен ли во что-то превратиться вот такой код?
Читал и нежно вспоминал, как годами бережно холил и лелеял музыкальную библиотеку в гигабайт в 60 из mp3 с MediaMonkey (кстати, изумительное по мощи решение было).
А потом случайно удалил, забыв скопировать на внешний жесткий диск перед форматированием. И сразу так легко стало без кучи треков, которые так давно уже не слушал.
Хорошая статья. Спасибо.
Дело в том, что HTML, CSS, JS — служат разным целям.
И их основная задача исконно выступать в качестве «платформы».
В случае с JS, например, наиболее корректно воспринимать вкладку-сайт как виртуальную машину. Если вспомнить, что JS в рамках этой виртуальной машины может быть достаточно низкоуровневым, аналогия становится еще более понятной. Соответственно, при загрузке подключаются какие-то модули ядра и какие-то клиентские модули.
Модули ядра служат для выполнения задач, которые сделать НЕЛЬЗЯ (например, Function.prototype.call) или делать СЛИШКОМ ДОЛГО(Function.prototype.bind — он дает прирост скорости) для клиентского кода.
HTML служит языком СЕМАНТИЧЕСКОЙ разметки. Он описывает разбивание данных на семантические (ну, если проще — логические) составляющие.
Поверх него можно строить языки-указатели (типа OpenGraph), служащие для как раз указания на авторов в том числе. Для этого есть специальный тэг meta.
А гугловские/яндексовые карты и GPS в телефонах учитывают эти штуки? Насколько я понимаю, сейчас почти все используют WGS 84 + EGM96, полагаю, для типовых веб-задач этого хватит…
Все несколько сложнее, просто поверьте. Я устану это объяснять, с навигацией всегда было очень много тонкостей. WGS-84 дает в некоторых точках земного шара (если не путаю, в Японии максимум) расхождение с геоидом 186, что ли, метров, что для многих ситуаций неоправданно. Более того — какое будет применение у этого тэга?
Тэг для времени ввели для того, чтобы не происходило расхождение: если где-то пишут «встреча произойдет ...15 января в 15:00...», такой элемент теоретически сможет автоматически ввести поправку на часовой пояс пользователя и автора и показать дополнительно скорректированное время. А у координат такой смысловой нагрузки нет.
Вот это работает:… text-transform: capitalize
Но на сервер данные полетят с маленькими буквами. Что может дважды расстроить юзера — неуважением к его фамилии и фактом обмана. Не надо так:)
При отображении имени и фамилии на клиенте тоже показывать через text-transform, какие проблемы.
какое быстродействие будет у этой балалайки
По-моему, при хорошей реализации — не особо меньшее, чем у стандартных интерактивных элементов типа details (не считая разовых затрат на инициализацию). registerElement решает всё-таки немного другую задачу, определение совсем новых элементов и расширение поведения нескольких старых — разные вещи, но они могут неплохо друг друга дополнять.
Угу, только с нынешними селекторами и будущими можно будет нагородить конструкцию типа
main.formatted > .container:not(:last-child):not(:first-child) + *:has(section:not(:only-child)) > section
и при добавлении класса .formatted для main нужно будет это пересчитывать, например. Какова перспектива.
Да, нужно не уметь себе стрелять в ногу, но лучше помочь не делать этого.
document.createElement ввели потому что конструктор для неизменного тэга — это несложно и вообще весело, это в рамках выделения вообще всех элементов в потомки HTMLElement произошло.
Ну почему, HTML-импорты ведь появились. Правда, будущее у них несколько туманно. Возможно, новому предложению повезет больше, кто знает?..
Опять же возвращаемся к вопросу про полифиллы. С импортами очень много сложных вопросов (например, про контекст исполнения) есть, поэтому пока что их лучше не трогать, пусть отлежатся, тогда консорциум их и согласует, когда потребность будет.
Это вопрос скорее к авторам ES6, где как минимум классы уже ввели. Правда, тут уже я удивляюсь, как это относится к HTML:)
Там много синтаксического сахара, не более. Компилируются примерно так же как классы в кофе или тайпскрипте. «Честные» классы на JS фундаментально нереально сделать.
Спасибо :)
На самом деле я верю в проект, просто не выходит вторая версия, а без нее продолжать продвижение смысла не так много (там уже есть ускорение загрузки до ~2секунд с нынешних 15, куда большее быстродействие, необязательная авторизация в вк — уже понятно, что это даст прирост в конверсии в несколько раз, привлекать пользователей на нынешнюю версию пока что банально неоправданно)
В любом случае, даже если будет только возможность получить советы по нескольким вопросам — я был бы очень благодарен, для меня некоторые вещи с небольшим ломанием текущих сценариев использования онлайн-плееров (вроде объяснения того, что на паузу ставить не нужно, достаточно выключить громкость) по-прежнему загадка, покрытая мраком.
Преимущества такого подхода: доступ браузера к файлам из ZIP, снижение требований к пропускной способности (что особенно важно для мобильных платформ).
Давно уже решили это все через Keep-Alive. К сожалению, маленькие файлы продолжают лететь с заголовками, но в целом gzip+keepAlive дают примерно тот же результат.
Забыли указать геоид, например (а он отличается от страны к стране). Очень много вещей нужно будет учесть для географических штук, просто поверьте человеку, у которого диплом инженера-судоводителя на полочке лежит.
tеaser
Не понял зачем. Тэга section мало?
Автоматическое написание с заглавных букв в полях формы
Только что проверил на поле ввода хабра. Вот это работает:
<textarea style="text-transform: capitalize">
Полноэкранный режим и скриншоты
Через webGL можно делать скриншоты в хроме, как бы смешно не звучало.
Элемент editоr
Есть для этого на js уже решения. persistent.js называется, кажется
tеxtarea type=”wysiwyg”
ContentEditable
«behaviors» или динамические подклассы DOM-элементов
Только не в мозг.
Мееедленно задумайтесь все разом, какое быстродействие будет у этой балалайки.
И как это отлаживать.
document.registerElement достаточно сильная штука, надо ее использовать, если прям хочется.
include(‘url’);
Это как бы вообще к HTML не относится ни разу, даже комментировать не буду (хотя есть что сказать)
JavaScript: пространство имён и классы
Уберите свои грязные руки от моей функциональщины, пожалуйста.
Если человек не умеет готовить — это его проблема, нехрен жаловаться, что получилась гадость на выходе.
Это перевод, я понимаю, потому и не пытаюсь как-то оскорбить или унизить переводчика. Но вот автору хочется сломать пальцы, чтобы он не нес такую вот доброту в массы.
Это музыкальный проект, некоммерческий, что-то на стыке между pandora (персональные музыкальные радиостанции) и stereomood.com (заготовленные станции). Работает просто: для пользователя персонально подбираются музыкальные сообщества из ВК, из них генерируется поток музыки.
Мне хочется верить, что получилось придумать что-то действительно новое: я не встречал еще платформы для «авторских» рекомендаций музыки. Другие проекты дают рекомендации от умных машин, а тут — живой человеческий рандом :)
Это куда ближе к реальным музыкальным станциям, которые выбирают именно за конкретных диджеев и даже узнают их вкус. Находки обычно куда более неожиданны, чем в системах рекомендаций. Естественно, сами станции рекомендуют такие же бездушные алгоритмы, но что поделать.
В приложении есть специфическая бессмысленная изюминка — это полностью фронтэнд-приложение.
Если что — в новой версии (которая еще не на сайте) — 6000 «станций».
Польза:
-Что last.fm, spotify, grooveshark etc пользуются популярностью не буду долго болтать. Почему — опять же, это все понятно.
-Сейчас идет тренд (не «модно», а «удобно» и «полезно») не на доступ к музыке, а на системы рекомендаций-радиостанций. Grooveshark в эту схему ушел, например.
-Рекомендации действительно отрабатывают уникальным путем, обычные сервисы вряд ли подскажут по своим алгоритмам треки, которые появляются в проекте
Я понимаю, что у радио масштаб не тот, чтобы тягаться со всеми этими акулами, но в нем есть определенный потенциал, новизна, челлендж для меня лично, и что-то, что цепляет.
Почему мне надо попасть на курс?
Ну, я не знаю зачем я вам, но я знаю, зачем он мне.
Я один черт буду дальше возиться и развивать радио. Во-первых из принципа, во-вторых это действительно хороший проект, и хочется сделать так, чтобы им пользовались и это причиняло людям удовольствие. А то уже два месяца переделываю дизайн и интерфейс из раза в раз и все не то, хотя надеялся еще в том году выкатить полноценную новую версию.
Вся проблема в том, как бы не перегрузить интеллект, и как убедить пользователей довериться «бездушной машине». Например, люди очень просят в обратной связи возможность прощелкивать треки вперед. А я не знаю, как объяснить, что нужно искать из сотен (а скоро тысяч), из которых предлагаются те, которые почти наверняка понравятся, станцию, треки в которой не захочется переключать, а не воспринимать это как просто очередной плеер. И таких проблем десятки.
И в целом я хочу больше понимать пользователей. Устал делать интерфейсы, которые в итоге оказываются нелогичными. Я фронтэнд-разработчик, который потихоньку уходит в технический менеджмент, но от интерфейсов я все равно вряд ли отойду, так что это мне дико пригодится.
А, ну и еще я потом обязательно напишу еще несколько статей на хабр о том, как делал это приложение (там очень много о чем можно рассказать с технической стороны) и, конечно, если поучаствую на курсе — обязательно напишу что-нибудь об этом в этих статьях. Ну это так, к слову :)
В ie11 они внедрили самые нужные вещи, которые нереально сделать Traceur или чем-либо аналогичным.
Arrow function транслитерировать в обычную — как нехрен делать.
А вот поддержку let и const внедрить, или ввести дополнительные структуры в память — типизированные массивы, Map, Set, WeakMap, __proto__ — черта с два какой-нибудь там traceur сможет поддержать такую низкоуровневую работу с языком.
Да одно только то, что они в ie10 ввели поддержку WebGL — уже говорит о том, что они пашут как кони проклятые там.
Я считаю, что в Редмонде с осликом нынче делают реально хорошую работу, подходят с умом, а 9-11 версии делались с оглядкой на то, что энтерпрайз их будет держать у себя годами, и хотели помочь разработчикам обеспечить приличное быстродействие и возможности, а не максимум сахара.
Полимер работает поверх «честных» компонентов, это что-то типа lodash для компонентов — удобная обертка, дата-биндинг и еще пара прелестей жизни.
И еще полифиллы.
Неет. Звонить покупателям через полгода и предлагать им аудиосистему к телевизору — это не добро.
Они не создают новый this, они красивее всего выглядят с одним аргументом и одним действием… В общем-то придумали их, как я понимаю, чтобы чейнинг делать там красивый, ну например
Как человек, который пишет на руби и es6 — es6 ощущается более структурированным. Я уже давно с трудом читаю чужой код на кофе, руби и питоне — он выглядит для меня слишком «плотным», а подсвеченные в IDE фигурные скобки и точки с запятой позволяют увидеть, где заканчивается чейнинг команды.
Есть буквально пара вещей, которые действительно хотелось бы перетащить из руби — пара особенностей синтаксиса для большей выразительности и читаемости (def вместо function, do ...end в дополнение к обычным стрелочным функциям), честные геттеры и сеттеры (да, они только в паре могут обновляться, а это свинство — мне порой надо только сеттер, например, обновить, а есть только Object.defineProperty) и что-то еще, примерно такого же уровня, вот только что из головы вылетело, к сожалению.
Но в качестве «преимущественно функционального» языка — JS (окей, JS в ближайшем будущем) делает руби. Да, в руби есть Lambda и block, но в реальности ими не так удобно пользоваться, если ты сторонник именно функциональной парадигмы, а не объектной. Напишите простенький пример на руби, который будет делать примерно то же самое:
Да, в ES6 можно абсолютно спокойно писать именно так.
А классы в руби крутые, даже очень. С этим не поспоришь.
За гарантиями в проект v8. Думаете, он рискнет обновиться так что что-нибудь отвалится?
Я лично очень в этом сомневаюсь
io.js — это же по сути «обвес».
Ребята на hexlet.io/ с этого и начали. А потом уже начали продумывать.
Дело не в этом, дело в том, что он (как и любой другой язык разметки, т.е. семантичного структурирования данных) позволяет на базе себя, как абстрактного языка, не имеющего дела с реальными понятиями, реализовывать структуры конкретных данных.
Условно, если HTML служит для описания деревьев (живых таких, зеленых) как абстрактного понятия — с листочками, веточками и так далее, то OpenGraph уже позволяет указывать точную породу древесины и ее возраст, а HTML предоставляет еще и табличку перед деревом, на котором можно написать в том числе это. Так понятнее?
Да, возможно, имелось ввиду указание для мобильных, нужно ли делать автокапитализацию каждого слова. С этим — ок, согласен, возможно, автор криво написал просто идею.
Я еще раз говорю — HTML и OpenGraph это несколько уровней одной модели, как в OSI. HTML — структурирует, оперируя абстрактной информацией. OpenGraph — оперирует конкретными понятиями и сущностями. Я говорю об этой семантике, а не о истерии хомячков на тему того, что правильнее — section или article
Опять вспоминаем про уровни использования.
Время нужно, чтобы на уровне представления браузер мог показать актуальное для пользователя время. Координаты достаточно вынести в очередной метатэг.
эмм. нет.
1. Ну, на сервере хранятся данные для машин. Время там тоже не в особо человеческом формате.
2. Насколько помню — text-transform — одно из самых первых свойств.
3. А в предложенном решении с принудительной трансформацией как это решается?
4. Где?
Я лично так не буду делать никогда в основном из-за третьего пункта. Но для тех, кто хочет вот так автоматически все превращать — лучше править на уровне отображения, чем принудительно что-то слать в базу.
Еще раз: если работает в полифилле — это можно использовать. Консорциум будет смотреть, изучать, вносить правки, а когда уже отлежится и все поймут, что им реально надо — примут.
И да и нет. Причем в основном нет. С одной стороны — классы — это хорошо для быстродействия. С другой — дело в том, что язык должен будет поддерживаться по сути бесконечноhttp://habrahabr.ru/post/249207/# долго (самые первые сайты до сих пор должны корректно отображаться). Из-за этого фичи и возможности продумываются достаточно долго, на это тратятся напряженные часы споров, тестов, изучения и проб. Для такого большого изменения, как классы — это сожрало туеву кучу времени. По факту из-за того, что куча набежавших хомячков затребовала классы, как у нормальных посонов на серверсайде, а то чо мы как лохи — меньше времени ушло на обсуждение тех фич, которые нельзя было бы реализовать без трансляторов на уровень JS. А классы — это реально огромное количество проделанной работы.
В итоге — из-за того, что пахали над классами — до сих пор, например, в фазе обсуждения находятся async/await functions.
Это абстрактный пример, я не слежу за происходящем в сообществе, но тем не менее.
Просто чтобы понимать уровень сложности принятия решений однозначности ради — объясню на примере arrow functions и destructing assignment.
У них вот такой синтаксис:
Это эквивалентно
То есть скобки не обязательны, если есть один аргумент. Если выполняется одна операция и нет фигурных скобок — ее результат возвращается.
Вопрос на засыпку: во что должен превратиться и должен ли во что-то превратиться вот такой код?
А потом случайно удалил, забыв скопировать на внешний жесткий диск перед форматированием. И сразу так легко стало без кучи треков, которые так давно уже не слушал.
Хорошая статья. Спасибо.
И их основная задача исконно выступать в качестве «платформы».
В случае с JS, например, наиболее корректно воспринимать вкладку-сайт как виртуальную машину. Если вспомнить, что JS в рамках этой виртуальной машины может быть достаточно низкоуровневым, аналогия становится еще более понятной. Соответственно, при загрузке подключаются какие-то модули ядра и какие-то клиентские модули.
Модули ядра служат для выполнения задач, которые сделать НЕЛЬЗЯ (например, Function.prototype.call) или делать СЛИШКОМ ДОЛГО(Function.prototype.bind — он дает прирост скорости) для клиентского кода.
HTML служит языком СЕМАНТИЧЕСКОЙ разметки. Он описывает разбивание данных на семантические (ну, если проще — логические) составляющие.
Поверх него можно строить языки-указатели (типа OpenGraph), служащие для как раз указания на авторов в том числе. Для этого есть специальный тэг meta.
Все несколько сложнее, просто поверьте. Я устану это объяснять, с навигацией всегда было очень много тонкостей. WGS-84 дает в некоторых точках земного шара (если не путаю, в Японии максимум) расхождение с геоидом 186, что ли, метров, что для многих ситуаций неоправданно. Более того — какое будет применение у этого тэга?
Тэг для времени ввели для того, чтобы не происходило расхождение: если где-то пишут «встреча произойдет ...15 января в 15:00...», такой элемент теоретически сможет автоматически ввести поправку на часовой пояс пользователя и автора и показать дополнительно скорректированное время. А у координат такой смысловой нагрузки нет.
При отображении имени и фамилии на клиенте тоже показывать через text-transform, какие проблемы.
Угу, только с нынешними селекторами и будущими можно будет нагородить конструкцию типа
main.formatted > .container:not(:last-child):not(:first-child) + *:has(section:not(:only-child)) > section
и при добавлении класса .formatted для main нужно будет это пересчитывать, например. Какова перспектива.
Да, нужно не уметь себе стрелять в ногу, но лучше помочь не делать этого.
document.createElement ввели потому что конструктор для неизменного тэга — это несложно и вообще весело, это в рамках выделения вообще всех элементов в потомки HTMLElement произошло.
Опять же возвращаемся к вопросу про полифиллы. С импортами очень много сложных вопросов (например, про контекст исполнения) есть, поэтому пока что их лучше не трогать, пусть отлежатся, тогда консорциум их и согласует, когда потребность будет.
Там много синтаксического сахара, не более. Компилируются примерно так же как классы в кофе или тайпскрипте. «Честные» классы на JS фундаментально нереально сделать.
На самом деле я верю в проект, просто не выходит вторая версия, а без нее продолжать продвижение смысла не так много (там уже есть ускорение загрузки до ~2секунд с нынешних 15, куда большее быстродействие, необязательная авторизация в вк — уже понятно, что это даст прирост в конверсии в несколько раз, привлекать пользователей на нынешнюю версию пока что банально неоправданно)
В любом случае, даже если будет только возможность получить советы по нескольким вопросам — я был бы очень благодарен, для меня некоторые вещи с небольшим ломанием текущих сценариев использования онлайн-плееров (вроде объяснения того, что на паузу ставить не нужно, достаточно выключить громкость) по-прежнему загадка, покрытая мраком.
Давно уже решили это все через Keep-Alive. К сожалению, маленькие файлы продолжают лететь с заголовками, но в целом gzip+keepAlive дают примерно тот же результат.
Есть уже семантика для указания авторов
Забыли указать геоид, например (а он отличается от страны к стране). Очень много вещей нужно будет учесть для географических штук, просто поверьте человеку, у которого диплом инженера-судоводителя на полочке лежит.
Не понял зачем. Тэга section мало?
Только что проверил на поле ввода хабра. Вот это работает:
Через webGL можно делать скриншоты в хроме, как бы смешно не звучало.
Есть для этого на js уже решения. persistent.js называется, кажется
ContentEditable
Только не в мозг.
Мееедленно задумайтесь все разом, какое быстродействие будет у этой балалайки.
И как это отлаживать.
document.registerElement достаточно сильная штука, надо ее использовать, если прям хочется.
Это как бы вообще к HTML не относится ни разу, даже комментировать не буду (хотя есть что сказать)
Уберите свои грязные руки от моей функциональщины, пожалуйста.
Если человек не умеет готовить — это его проблема, нехрен жаловаться, что получилась гадость на выходе.
Это перевод, я понимаю, потому и не пытаюсь как-то оскорбить или унизить переводчика. Но вот автору хочется сломать пальцы, чтобы он не нес такую вот доброту в массы.
Public Radio
publicradio.io
Это музыкальный проект, некоммерческий, что-то на стыке между pandora (персональные музыкальные радиостанции) и stereomood.com (заготовленные станции). Работает просто: для пользователя персонально подбираются музыкальные сообщества из ВК, из них генерируется поток музыки.
Мне хочется верить, что получилось придумать что-то действительно новое: я не встречал еще платформы для «авторских» рекомендаций музыки. Другие проекты дают рекомендации от умных машин, а тут — живой человеческий рандом :)
Это куда ближе к реальным музыкальным станциям, которые выбирают именно за конкретных диджеев и даже узнают их вкус. Находки обычно куда более неожиданны, чем в системах рекомендаций. Естественно, сами станции рекомендуют такие же бездушные алгоритмы, но что поделать.
В приложении есть специфическая бессмысленная изюминка — это полностью фронтэнд-приложение.
Если что — в новой версии (которая еще не на сайте) — 6000 «станций».
Польза:
-Что last.fm, spotify, grooveshark etc пользуются популярностью не буду долго болтать. Почему — опять же, это все понятно.
-Сейчас идет тренд (не «модно», а «удобно» и «полезно») не на доступ к музыке, а на системы рекомендаций-радиостанций. Grooveshark в эту схему ушел, например.
-Рекомендации действительно отрабатывают уникальным путем, обычные сервисы вряд ли подскажут по своим алгоритмам треки, которые появляются в проекте
Я понимаю, что у радио масштаб не тот, чтобы тягаться со всеми этими акулами, но в нем есть определенный потенциал, новизна, челлендж для меня лично, и что-то, что цепляет.
Почему мне надо попасть на курс?
Ну, я не знаю зачем я вам, но я знаю, зачем он мне.
Я один черт буду дальше возиться и развивать радио. Во-первых из принципа, во-вторых это действительно хороший проект, и хочется сделать так, чтобы им пользовались и это причиняло людям удовольствие. А то уже два месяца переделываю дизайн и интерфейс из раза в раз и все не то, хотя надеялся еще в том году выкатить полноценную новую версию.
Вся проблема в том, как бы не перегрузить интеллект, и как убедить пользователей довериться «бездушной машине». Например, люди очень просят в обратной связи возможность прощелкивать треки вперед. А я не знаю, как объяснить, что нужно искать из сотен (а скоро тысяч), из которых предлагаются те, которые почти наверняка понравятся, станцию, треки в которой не захочется переключать, а не воспринимать это как просто очередной плеер. И таких проблем десятки.
И в целом я хочу больше понимать пользователей. Устал делать интерфейсы, которые в итоге оказываются нелогичными. Я фронтэнд-разработчик, который потихоньку уходит в технический менеджмент, но от интерфейсов я все равно вряд ли отойду, так что это мне дико пригодится.
А, ну и еще я потом обязательно напишу еще несколько статей на хабр о том, как делал это приложение (там очень много о чем можно рассказать с технической стороны) и, конечно, если поучаствую на курсе — обязательно напишу что-нибудь об этом в этих статьях. Ну это так, к слову :)
Атаки на стороне клиента, не отказываясь от DOM, вы избежать не сможете.
Да и не факт, что в вашем клиенте дыры не вскроются внезапно.