На самом деле, я рассматривал подобный вариант, но его потенциальная сложность меня отпугнула. Сила Numl в том, что он в runtime анализирует атрибуты и их комбинации, выдая корректные стили, независимо от того, в какой момент и кем эти атрибуты были назначены. Это очень важная фича, которой пришлось бы пожертвовать, если бы мы обрабатывали это на сервере.
Возможно в будущем, Numl сможет переползти на сервер и даже мобильные платформы. Посмотрим :)
Всё действительно так, если вы используете кучу селекторов, которые одновременно применяются, будет падение производительности. В случае, если селекторы пассивные (не работают) их отсеивание обойдётся браузеру относительно дёшево. Мы сделали достаточно большое приложение на Numl с очень большим кол-вом элементов и всё работает достаточно быстро.
Для каждого элемента Numl предварительно генерирует много селекторов, чтобы иметь возможность использовать конкретное CSS-свойство (например, `box-shadow) в нескольких стилях: `border/shadow/inset/mark`. Я надеюсь, что в будущем удастся еще сильнее оптимизировать этот подход.
По факту, Numl совместим с чистым HTML и CSS, вы можете перемешивать их использование, хоть это и не рекомендуется. Плюс, там, где это возможно, Numl повторяет синтаксис и именование HTML/CSS/ARIA, чтобы разработчик переиспользовал свои знания (в обе стороны). Пилить радикально отличающийся язык было бы неэффективно по многим причинам. Цель Numl сделать возможности CSS более доступными для разработчиков, а не обрезать его, как ИМХО, делают большинство Дизайн-систем.
В конце статьи я привёл ряд ссылок на реальные приложения с открытым кодом. Но, чтобы понять, насколько система удобна, нужен разумеется личный опыт.
Сравнивать Numl с другими фреймворками довольно сложно. В нём много возможностей, которых нет в других фреймворках. Некоторые возможности, такие как привязка стилей к состояниям, работают эффективнее, но это может быть не так очевидно, как хотелось бы. Тем более, чтобы качественно сравнить Numl с тем же Tailwind, нужен человек, который много писал на Tailwind, чтобы мы с ним вместе сели и расписали сильные и слабые стороны и сделали понятную таблицу сравнения.
Numl не конкурент Angular, React и Vue. Он работает параллельно внутри вёрстки, а поверх вы можете использовать один из этих фреймворков (или другой, поддерживающий Web Components).
Подход Numl существенно отличается от других CSS-фреймворков и Дизайн-систем. Только время покажет, насколько людям будет удобно с ним работать в реальных проектах. Но по предварительным отзывам у людей очень приятный опыт его использования. Посмотрим, что будет дальше.
Я не скрываю и даже подробно упоминаю, что Numl поддерживается только современными вечно-зелёными браузерами, хотя при желании можно добавить поддержку и более старых браузеров вплоть до Edge15.
Конкретно для нашего проекта такой совместимости было достаточно, а поддержка более старых браузеров в любом случае сделало бы разработку значительно дороже, не оправдав кол-во привлёченных пользователей. Поэтому мы экономим свои деньги.
Всегда важно оценивать, подходит конкретный инструмент вам или не подходит. Нам данный инструмент подошел и даже полностью оправдал усилия вложенные в его разработку.
Устройства устаревают, даже без изменений охват устройств на которых работает Numl будет только расти. Его использование на различных в проектах будет становиться более оправданным.
Есть идея в будущем сделать краудфандинг переводов, чтобы люди могли сами добавлять переводы в документацию (например, на основе magic-string). Но пока проект не развился, сложно оправдать такую работу.
Я очень много сил и времени вложил в этот проект, потому что верю в него. Если появится хотя бы пара человек, которые меня в этом поддержат, то появятся и новые фичи и документация на разные языки и много чего еще :)
1. Поддержку IDE всегда можно добавить при желании и будет подсвечиваться. Хотя в данном случае я согласен, что реализовать адекватную подсветку будет сложно. В целом синтаксис достаточно понятный и без подсветки. Значения CSS свойств например почти никто не подсвечивает, а там синтаксис ну очень комплексный может быть. И вроде это не вызывает проблем.
2. Во-первых, такое название атрибута не поддерживается спецификацией Custom Elements, я даже не уверен, что ваши примеры это валидный HTML. Во-вторых, такой синтаксис менее очевидный и сложнее мапится на CSS.
Можно рассматривать Numl как библиотеку элементов, но по факту это язык описания семантики + язык описания стилей + фреймворк, который позволяет инжектировать поведения в элементы и даёт им возможность понимать свой контекст. Также тут скорее UI-библиотека, но более правильное название — HTML Framework.
По сути, это ближе к атомарный CSS-фреймворкам вроде Tailwind, только мощнее по возможностям благодаря кодогенерации.
Про кусочек кода:
Я не стал так делать, 1) потому что это обычный CSS со всеми особенностями описанными в статье. 2) это очень длинное и немасштабируемое описание стилей.
Numl не альтернатива React'у, не нужно между ними переезжать. Numl решают свою задачу связанную с созданием качественной вёрстки. Это единый инструмент для решения большого спектра задач, с которыми композиционные фреймворки не сильно дружат – доступность, управление цветам, консистентный дизайн и т.п. С другой стороны, Numl плохо работает с композицией и состоянием, поэтому не стоит с помощью него решать такие задачи.
Однако, в некоторых простых задачах Numl может заменить JS-фреймворк, если вам нужно динамически менять любые стили или атрибуты на элементах (например, показывать/прятать элемент), а также корректировать надписи.
Это не замена Angular. Это скорее UI-библиотека, которая работает параллельно вашему JS-фреймворку. Она решает задачи на уровне вёрстки, а композиционные задачи и работу с состоянием оставляет другим технологиям, которые начились это делать по-настоящему круто.
Numl можно использовать с чистым HTML или с любым популярным фреймворком — Angular, Vue, Svelte, React.
Я правильно понимаю, что, чтобы сделать хороший интерфейс, мне нужно поставить Angular, найти несколько десятков популярных библиотек под каждую мелкую задачку, разобраться как они работают и подключаются? А что если заказчик попросит переехать на React и придётся искать новый набор библиотек? Вам самому не кажется, что что-то тут не так?
Если уж искать альтернативу, то лучше что-то на Web Components.
С динамическим обновлением у Numl проблем нет.
Интересно, какие проблемы вы решаете пререндерингом?
Если есть проблемы с тем, что из коробки с включенными скриптами Numl не работает в некоторых браузерах, то буду очень благодарен за issue на гитхабе. Уверен, я смогу всё починить, получив подробную информацию.
Custom Elements не работают без скриптов в принципе. Если есть необходимость создания JS-free решения, то это возможно на базе Numl. Нужно просто все стили и вёрстку (да, там используются внутренние элементы элементы для ссылок, картинок и т.п.) предварительно пререндерить. Я делал такой эксперимент и всё работало, даже навигация. Но более сложные взаимодействия там конечно умрут, например формы.
Но можно пойти еще дальше и сделать транспиляцию Numl в HTML. Тогда будет работать вообще всё, что может работать без JS.
У меня нет ресурсов на подобные эксперименты. Но я всегда рад контрибьютерам, которые приходят с интересными идеями и помогают их реализовать.
Кажется, там кол-во операций записи на один конкретный блок. Т.е. один конкретный блок может быть переписан N раз. Так что в вашем примере разницы может и вовсе не быть, если использовалось одно и то же кол-во блоков. Причем исчерпание лимита конкретного блока ничем страшным не грозит, он просто блокируется и в дальнейшем используется «только на чтение».
Обязательно найду время почитать комментарии, но пока выскажу своё мнение.
Если допустить, что время это лишь одно из измерений пространства, которое мы воспринимаем столь интересным образом, то «изменение» свойств некоего кванта на основании его «будущего» состояния не выглядит таким уж странным, ведь некоторые свойства кванта теоретически могут быть фиксированными в этом измерении. Принцип причинности это кстати не нарушает, так как отсутствует изменение состояния.
На самом деле, я рассматривал подобный вариант, но его потенциальная сложность меня отпугнула. Сила Numl в том, что он в runtime анализирует атрибуты и их комбинации, выдая корректные стили, независимо от того, в какой момент и кем эти атрибуты были назначены. Это очень важная фича, которой пришлось бы пожертвовать, если бы мы обрабатывали это на сервере.
Возможно в будущем, Numl сможет переползти на сервер и даже мобильные платформы. Посмотрим :)
Для каждого элемента Numl предварительно генерирует много селекторов, чтобы иметь возможность использовать конкретное CSS-свойство (например, `box-shadow) в нескольких стилях: `border/shadow/inset/mark`. Я надеюсь, что в будущем удастся еще сильнее оптимизировать этот подход.
По факту, Numl совместим с чистым HTML и CSS, вы можете перемешивать их использование, хоть это и не рекомендуется. Плюс, там, где это возможно, Numl повторяет синтаксис и именование HTML/CSS/ARIA, чтобы разработчик переиспользовал свои знания (в обе стороны). Пилить радикально отличающийся язык было бы неэффективно по многим причинам. Цель Numl сделать возможности CSS более доступными для разработчиков, а не обрезать его, как ИМХО, делают большинство Дизайн-систем.
В конце статьи я привёл ряд ссылок на реальные приложения с открытым кодом. Но, чтобы понять, насколько система удобна, нужен разумеется личный опыт.
Сравнивать Numl с другими фреймворками довольно сложно. В нём много возможностей, которых нет в других фреймворках. Некоторые возможности, такие как привязка стилей к состояниям, работают эффективнее, но это может быть не так очевидно, как хотелось бы. Тем более, чтобы качественно сравнить Numl с тем же Tailwind, нужен человек, который много писал на Tailwind, чтобы мы с ним вместе сели и расписали сильные и слабые стороны и сделали понятную таблицу сравнения.
Подход Numl существенно отличается от других CSS-фреймворков и Дизайн-систем. Только время покажет, насколько людям будет удобно с ним работать в реальных проектах. Но по предварительным отзывам у людей очень приятный опыт его использования. Посмотрим, что будет дальше.
В приведённом вами примере подсветка практически ничем вам не помогает, код и без этого хорошо читается. Но, разумеется, лучше когда она есть.
Я не скрываю и даже подробно упоминаю, что Numl поддерживается только современными вечно-зелёными браузерами, хотя при желании можно добавить поддержку и более старых браузеров вплоть до Edge15.
Конкретно для нашего проекта такой совместимости было достаточно, а поддержка более старых браузеров в любом случае сделало бы разработку значительно дороже, не оправдав кол-во привлёченных пользователей. Поэтому мы экономим свои деньги.
Всегда важно оценивать, подходит конкретный инструмент вам или не подходит. Нам данный инструмент подошел и даже полностью оправдал усилия вложенные в его разработку.
Устройства устаревают, даже без изменений охват устройств на которых работает Numl будет только расти. Его использование на различных в проектах будет становиться более оправданным.
Я очень много сил и времени вложил в этот проект, потому что верю в него. Если появится хотя бы пара человек, которые меня в этом поддержат, то появятся и новые фичи и документация на разные языки и много чего еще :)
1. Поддержку IDE всегда можно добавить при желании и будет подсвечиваться. Хотя в данном случае я согласен, что реализовать адекватную подсветку будет сложно. В целом синтаксис достаточно понятный и без подсветки. Значения CSS свойств например почти никто не подсвечивает, а там синтаксис ну очень комплексный может быть. И вроде это не вызывает проблем.
2. Во-первых, такое название атрибута не поддерживается спецификацией Custom Elements, я даже не уверен, что ваши примеры это валидный HTML. Во-вторых, такой синтаксис менее очевидный и сложнее мапится на CSS.
Можно рассматривать Numl как библиотеку элементов, но по факту это язык описания семантики + язык описания стилей + фреймворк, который позволяет инжектировать поведения в элементы и даёт им возможность понимать свой контекст. Также тут скорее UI-библиотека, но более правильное название — HTML Framework.
По сути, это ближе к атомарный CSS-фреймворкам вроде Tailwind, только мощнее по возможностям благодаря кодогенерации.
Про кусочек кода:
Я не стал так делать, 1) потому что это обычный CSS со всеми особенностями описанными в статье. 2) это очень длинное и немасштабируемое описание стилей.
Однако, в некоторых простых задачах Numl может заменить JS-фреймворк, если вам нужно динамически менять любые стили или атрибуты на элементах (например, показывать/прятать элемент), а также корректировать надписи.
Numl можно использовать с чистым HTML или с любым популярным фреймворком — Angular, Vue, Svelte, React.
Если уж искать альтернативу, то лучше что-то на Web Components.
С динамическим обновлением у Numl проблем нет.
Интересно, какие проблемы вы решаете пререндерингом?
Но можно пойти еще дальше и сделать транспиляцию Numl в HTML. Тогда будет работать вообще всё, что может работать без JS.
У меня нет ресурсов на подобные эксперименты. Но я всегда рад контрибьютерам, которые приходят с интересными идеями и помогают их реализовать.
Поправьте если вдруг ошибся.
Если допустить, что время это лишь одно из измерений пространства, которое мы воспринимаем столь интересным образом, то «изменение» свойств некоего кванта на основании его «будущего» состояния не выглядит таким уж странным, ведь некоторые свойства кванта теоретически могут быть фиксированными в этом измерении. Принцип причинности это кстати не нарушает, так как отсутствует изменение состояния.
буду завтра на Южке с 6 до 8 вечера, забегай)
к сведению, зашел я в демо Select'а, что-то выбрал и получил вот такое:
yadi.sk/d/qj_qLhxhLAFNf
yadi.sk/d/RE1KJPv_LAEUp
только Safari (OSX и iOS)
IE10 в одном из проектов уходил в зацикленный refresh со сменой режима совместимости с IE-edge на старый и обратно.
Мне кажется это уже за гранью.