Несколько моментов из моего опыта с кастомными элементами:
к кастомным элементам часто называют веб-компонентами, но они являются только одной составляющей набора API веб-компонентов (другие вещи включают в себя shadow DOM, HTML templates и тд) - подробнее тут
с помощью aria- аттрибутов кастомные элементы можно наделять семантикой, для лучшей SEO и accessibility (если вы уже активно используете их или другие аттрибуты, то кастомные компоненты могут помочь вам еще больше сократить объем кода и улучшить читаемость)
среди важных проблем - server-side rendering. Кастомные элементы требуют исполнения JS кода на стороне клиента для рендера, соответственно их сложнее использовать в контексте SRR-приложений. Аспекты типа локализации, server-side авторизации, использования CMS могут усложняться, и вам придется придумать как это решать. Поэтому предпочтительно может быть использовать web-component библиотеки которые уже это делают, но в ущерб минимализма и нативности API :)
Заметил пару спорных моментов на которых базируется вся статья :)
Объем кода
Суть идеи заключается в том, что когда вы начинаете находить закономерности в своем приложении, вы можете закодировать их при помощи малого языка. Этот язык позволит вам выразить эти закономерности более компактно, чем это возможно с помощью других средств абстракции. Что позволит не только противостоять тенденции к постоянному увеличению размера приложений, но и сократить объём кода в процессе разработки!
Объем кода != когнитивная сложность. При добавлении большего числа инструментов мы усложняем поддержку приложения, поэтому очень не всегда это приведет к позитивным эффектам.
И даже если малый язык позволит реализовать тот же функционал используя более простые абстракции, это все еще может не привести к упрощению поддержки, так как она в большей упирается в количество РАЗНЫХ абстракций, а не количество из переиспользований.
Предел выразительности кода
Я лично убежден, что мы достигли предела выразительности языков общего назначения. Если есть уровень выше, то как он будет выглядеть? Возьмем, к примеру, Python — он настолько высокоуровневый, что практически выглядит как псевдокод.
Не только синтаксис влияет на выразительность языка, а его улучшение не сводится к инкрементальным изменениям. Существуют принципиально различные варианты синтаксиса и написания кода, которые обладают большей выразительностью (LISP vs C-подобные языки, декларативный vs императивный код). И это все может проявляться даже в рамках одного языка.
P.S. Приверы других вещей которые влияют на выразительность помимо синтаксиса: парадигма программирования, фреймворки, набор абстракций используемых в коде, структура файлов проекта, документация (в том числе комментарии), типизация и даже такие вещи как сообщения в коммитах в Git. Все это в совокупности постоянно используется в работе с кодом и у нас впереди еще необъятная возможность к совершенствованию :D
Несколько моментов из моего опыта с кастомными элементами:
к кастомным элементам часто называют веб-компонентами, но они являются только одной составляющей набора API веб-компонентов (другие вещи включают в себя shadow DOM, HTML templates и тд) - подробнее тут
с помощью
aria-аттрибутов кастомные элементы можно наделять семантикой, для лучшей SEO и accessibility (если вы уже активно используете их или другие аттрибуты, то кастомные компоненты могут помочь вам еще больше сократить объем кода и улучшить читаемость)среди важных проблем - server-side rendering. Кастомные элементы требуют исполнения JS кода на стороне клиента для рендера, соответственно их сложнее использовать в контексте SRR-приложений. Аспекты типа локализации, server-side авторизации, использования CMS могут усложняться, и вам придется придумать как это решать. Поэтому предпочтительно может быть использовать web-component библиотеки которые уже это делают, но в ущерб минимализма и нативности API :)
Заметил пару спорных моментов на которых базируется вся статья :)
Объем кода
Объем кода != когнитивная сложность. При добавлении большего числа инструментов мы усложняем поддержку приложения, поэтому очень не всегда это приведет к позитивным эффектам.
И даже если малый язык позволит реализовать тот же функционал используя более простые абстракции, это все еще может не привести к упрощению поддержки, так как она в большей упирается в количество РАЗНЫХ абстракций, а не количество из переиспользований.
Предел выразительности кода
Не только синтаксис влияет на выразительность языка, а его улучшение не сводится к инкрементальным изменениям. Существуют принципиально различные варианты синтаксиса и написания кода, которые обладают большей выразительностью (LISP vs C-подобные языки, декларативный vs императивный код). И это все может проявляться даже в рамках одного языка.
P.S. Приверы других вещей которые влияют на выразительность помимо синтаксиса: парадигма программирования, фреймворки, набор абстракций используемых в коде, структура файлов проекта, документация (в том числе комментарии), типизация и даже такие вещи как сообщения в коммитах в Git. Все это в совокупности постоянно используется в работе с кодом и у нас впереди еще необъятная возможность к совершенствованию :D