Pull to refresh

Comments 26

Даёшь браузер вместо ОС!
Спасибо за статью, Вы подпитали мои надежды. Как же я жду возможности менять значения кастомных переменных в CSS…

Разве есть проблема сделать это сейчас в браузерах, поддерживающих эти самые кастомные переменные пользовательские свойства?

Конечно такой проблемы нет. Но в живом проекте, даже с узким охватом аудитории, использовать их нерационально. И вот почему: http://caniuse.com/#search=Custom%20Properties. Я же жду, когда смогу использовать все их преимущества именно в живом проекте.
UFO just landed and posted this here
Интересно, как это всё скажется на быстродействии?
Уверен, что разработчики браузера будут ограничивать полёт фантазии в угоду производительности. Здесь важно найти правильный компромисс.
До сих пор ни авторы браузеров, ни авторы сайтов как-то о каком-то ограничении особо не задумывались. Т.е. я, конечно, понимаю, что гигабайт памяти для открытия пяти страничек и 64-битные бинарники — это прямо must-have для самых мелких задач, но, простите, не так давно еще 64 Мб ОЗУ было очень крутой набивкой компа, а качество жизни не то чтобы было сильно хуже… Так что зажирание наблюдается, и об экономии особо никто никогда не думает, к сожалению.
Вы забыли упомянуть о среднем размере страницы, сравнявшемуся с размером инсталлятора Doom)

Одна из самых крутых вещей за последнее время, а я о ней впервые слышу…


Огромное спасибо за перевод, голова кругом от открывающихся возможностей, реализуй они задуманное.

Я смотрю на «инновации» в мире Web и грусть заполняет сердце моё. Всё потому, что Я вспоминаю славные деньки с Adobe Flex 3/4, где любой программист мог создавать собственные CSS свойста и привязывать их к ActionScript коду через [Style] метатег. Старый, добрый, всеми покинутый Flex не ограничивал моей фантазии. Я не зависел от бюрократии рабочих групп. Базовый функционал, предоставляемый Flash Player-ом, был минималистичным, как микроядро OS. А Open Source фреймворк Flex позволял переопределить львиную долю используемых фишек. Нужен свой тег? Легко. Хочешь добавить CSS свойство? Флаг тебе в руки. Нужно своё значение для свойства «position» (отличное от relative, absolute и прочих) с хитрой логикой? Нет проблем. И всё это со статической типизацией, поддержкой в IDE и отличной документацией.

К сожалению современные HTML/JS/CSS мне напоминают монолитное ядро, закрытое для изменения, в которое медленно добавляют возможности для расширения той или иной функциональности.

Эта была минутка ностальгии. А Flash, конечно же, обречён.
Вот только контролирует этот flash player только один вендор. Если бы все пользователи сидели под хромом, то flexbox пользовались чуть ли не сразу, ни о каких годах речи не идёт. Но в чём минус единого вендора все знают (вспоминаем мороки с IE6 с 90% аудиторией). В общем, получается палка о двух концах. Много движков — много различий в реализации. Движок один — проблема в том что он один.
Вопрос Монополизм vs. Конкуренция слишком обширен, чтобы его здесь поднимать. И на мой взгляд закат Flash Player связан скорее с качеством его реализации. Множество опасных уязвимостей, медленная работа плохо оптимизированных Flash роликов (как будто на JS/CSS нельзя написал тормозной баннер), плохая работа плагина в Linux. Компания Adobe слишком поздно поняла, что трон Flash плагина пошатнулся. Они открыли спецификацию формата SWF, открыли спецификацию ActionScript 3, сделали компилятор ActionScript открытым, перевели фреймворк Flex в OpenSource. Но было уже поздно. Никто не хочет создать альтернативный Flash плагин. И попытка передать виртуальную машину Tamarin на попечение Mozilla Foundation не увенчалась успехом.

Я не хотел бы здесь развивать дискуссию вокруг Flash плеера. Меня больше беспокоит противостояние Микроядро vs. Макроядро. Как Я упоминал ранее, сам по себе Flash Player реализует только базовую функциональность: векторная графика, сетевой API, аудио, видео, текст и типографика, 3DScene, event loop, доступ к камере, микрофону, акселерометру и др. А уже потом с помощью большого количество AS3 кода поверх этих API создаётся фреймворк: визуальные компоненты и контейнеры (кнопки, выпадающие списки, табы, таблицы, списки, диаграммы, календарь, date-time picker, др), поддержка скинов, data binding, анимация, даже soap rpc есть из коробки.

На другом конце спектра открытые стандарты и движок браузера, который реализован на С/С++ с набором вшитых визуальных компонентов, имеющих фиксированное поведение, многие особенности которых берут своё начало в браузере Mosaic. И если вам вдруг станет интересно, как размер шрифта, значение «padding» и «border» влияют на ширину кнопки, то придётся либо поверить спецификации W3C, либо изучать дебри C++ кода Blink-а или Gecko. И уж точно, вы не сможете добавить иконку слева от текста, или сделать первую букву другого шрифта. Вам придётся создавать <div/> который выглядит как кнопка и ведёт себя как кнопка. Аналогично Date Picker, выпадающий список, диалоговое окно и другие возможности современных JavaScript фреймворков — это костыли поверх div-ов.

Я надеюсь, что со временем Web технологии возьмут лучшее из мира Java, .Net, Android и сделают спецификацию на виртуальную машину (а не на язык JavaScript), сделают минималистичный набор встроенного API вместе со стандартным (но не обязательным) фреймворком и дадут программистам полную свободу действий. Эх, мечты :)
Если я правильно понял, они разрабатывают не конкретные решения, а спецификации на апи, которые предлагается реализовывать производителям браузеров?
Звучит всё это круто, конечно, но я очень сомневаюсь, что взлетит. По целому ряду причин.
Каких, если не секрет?
1. Очевидно, что это должно повлечь огромные изменения в коде браузеров, как архитектурно, так и в деталях. Кто и за какие деньги должен делать всю эту работу?

2. Нужно, чтобы эту технологию внедрили все основные движки (как минимум WebKit/Blink, Gecko, Trident/EdgeHTML). Если технологию игнорит хотя бы один крупный игрок — она становится почти бесполезна. Причем тут может получиться как обычно: её раньше внедрят самые передовые браузеры, с которыми как раз и так меньше всего проблем, а легаси-аутсайдеры будут продолжать курить бамбук. И будет она напоминать мертворожденную фичу supports, где поддержка функции проверки зачастую меньше, чем поддержка тех свойств, которые она должна проверять.

3. Получается, что мир веб-стандартов раскалывается на 2 большие части, со своими законодательными органами, усилия в которых прилагаются в ортогональных направлениях.

4. Очевидно, что порог вхождения в эти технологии окажется относительно высоким, их сможет использовать меньшая часть разработчиков. И готовые библиотеки эту проблему не всегда способны решить, как показывает пример WebGL.

5. А кто вообще сказал, что реализация этих самых API окажется во всех браузерах полностью идентична? Ведь в CSS-свойствах разночтения делаются не специально всем на зло, а потому что… ну так вот получилось. И тут может получиться, что технология устранения проблем кроссбраузерности окажется сама не совсем кроссбраузерна. И выйдет такой мега-костыль, всем костылям костыль.

Ну то есть в теории-то возможно, что все гиганты соберутся, обо всем договорятся и годика за 3 запилят всю эту красоту. Но сомнительно. Логичнее потратить эти усилия непосредственно на доведение до ума существующих/планируемых спецификаций.

Причины примерно те же самые, по которым flexbox был предложен в 2009-м, а 2016-м его до сих пор многие избегают. Это очередная невменяемо сложная вещь, которая должна пройти через все стандартизации, реализоваться во всех браузерах, несколько раз эволюционировать до неузнавания, а потом всё упрётся в старые браузеры у юзеров.


Кроме того, у меня ощущение, что эта штука лезет глубоко в архитектуру браузеров. Как бы боком потом не вышло.

body {
  display: layout('masonry');
}

А работать подобное будет быстрее, чем при обычном подключении js либы?
Думаю будет работать быстрее хотя бы потому, что это будет крутиться в отдельном воркере и не будет блокироваться вывод всяким другим явасриптом.
Но ведь и это не будет поддерживаться всеми браузерами…
После прочтения восторженных комментариев решил перечитать статью, вдруг что-то упустил. Но это вновь что-то придуманное сегодня, что можно будет использовать через несколько лет или нельзя.
Изучая новые инструменты и библиотеки, кажется что делают так: «Мы не можем rocketsince, поэтому давайте усложним то с чем работаем!» 

Ну и конечно http://xkcd.ru/927/
Честно говоря, мне кажется давно пора все современные браузеры выкинуть на свалку, а оставить что-то реализующее подобный механизм… Для ВСЕХ современных параметров CSS. Т.о. современный стандарт получается нечто вроде «стандартной библиотеки», но которую можно расширять всякими своими примочками.
На бумаге всё это выглядит очень круто.
На практике, к сожалению, Houdini не работает. Не в смысле подход не работает, а сама рабочая группа, гордо названная «объединенной силой TAG и Houdini» не работает.

Называть Houdini «новой» группой — выдавать желаемое за действительное. Неформально группа была образована больше двух лет назад (ваш покорный слуга при этом присутствовал; изначально рассылку назвали «public-wtf», но, как оказалось, такая уже была). За два года сделано примерно ничего, спецификации даже не начаты, в вики из полезной информации фотографии досок со встреч.

Я далёк от того, чтобы винить в этом членов группы — Питер действительно очень круто пушит css в светлое будущее, но один в поле не воин. Вопросы API-зации CSS и rendering engine, к сожалению, совершенно не находят поддержки в кругах веб-разработчиков. Пока не начнётся какого-то массового движения вокруг этой темы, все эти красивые диаграммки останутся утопией.

Да даже черт с ним, с rendering engine. Возьмём тривиальную вещь — Font Metrics API. Это просто маленький API для того, чтобы измерить точный размер текста без необходимости отрендерить его в браузере. Каждый веб-разработчик сталкивается с этой проблемой, и у каждого в загашнике есть свой костыль для решения этой задачи. Увы, даже здесь за два года прогресс нулевой.
Sign up to leave a comment.