я мог бы даже написать «для матана» на самом деле, потому что он стал основой для языков программирования (когда «процедура» называется «функцией»), это как обобщение для совокупности околоайтишных сфер
ну есть термин «говнокод» и я просто хотел его даже сгладить, пожалуй поправлю.
Насчет языка, разработка ПО штука очень международная, а языков национальных очень много и проще всем выучить какой-то один дополнительный язык хотя бы до уровня со словарем (вот я учу китайский еще полгода и пока не достиг такого и близко), и так исторически сложилось, что это английский, но это оказалось правильным потому что английский подходит для записи кода.
в том как кодируются символы в кодировках, для латиницы в UTF-8 как и доюникодных кодировках используется первый байт поэтому они всегда выглядят хорошо, а национальные при ошибочном указании всегда выглядят корявками
английский стал латынью для электроники, любое сообщение закодированные в ASCII или английской части UTF-8 будет корректно отображаться практически в любых условиях, а вот с другими языками такого нет. Поэтому он на особом положении, а почему это так я как раз и попытался сформулировать в заметке.
сокращения вообще не рекомендуют использовать, только когда без них совсем длинно выходит, предполагается, как я понимаю, что если вы хорошо попилили предметку на сущности, то и имена методов и классов будут короткими
коммерческий уникс всегда был привязан к большим дорогим железякам, это они сейчас умирают. Из-за того что юникс не запускался на процессорах 386х и слабже, которые из-за своей доступности получили широкое распространение среди обычных пользователей, появились такие «необычные» операционные системы как dos и windows. Они работали на массово завозимых из японии (в сша) персональных компьютерах, а юникс — нет. Линукс был разработан как доступный на этих десктопных компьютерах и обычных писи серверах аналог юникса, который мог развернуть любой провайдер или даже энтузиаст. Популярность он обрел как платформа для такого же доступного каждому веб-сервера apache.
грузить шаблоны можно и фронтенд кодом, а их нахождение в дереве является отличным механизмом кеширования, т.к. когда вы кешируете строку или функцию ее генерации, вы все равно эту строку потом рендерите в дерево, а иначе рендера не происходит, что оптимальнее
>> С ленивой загрузкой компонентов тоже непонятно как быть
с ленивой загрузкой в веб-компонентах ситуация лучше всех, т.к. для браузера динамически дорендеренный <my-custom-element> преобразуется в ваш кастомный компонент без особенных препятствий и с выполнением полагающихся хуков
>> Свойства обновляются поштучно, и изнутри компонента вы не можете предугадать
можно передавать джейсон или не использовать атрибуты, а использовать эвенты или прямое связывание
чаще есть возможность поменять конфигурацию, чем код, а системы которые позволяют своими изменениями переопределить базовые вообще представляют исключительные примеры хорошего проектирования. В вашем примере вы определяете новый элемент-тег. То есть вы сможете использовать его только для своих кнопок, а все остальные кнопки абстрактной многомодульной системы этими изменениями затронуты не будут, а часто именно это и требуется.
отдельно загружать придется потому что они структурированы отдельно, потому что все вместе их будет неудобно поддерживать даже может более неудобно, чем если они захардкожены в джаваскрипте. Можно конечно склеить, но тогда либо опять же все придется загружать и разбирать, а их может быть очень много либо полагаясь на запрашиваемый роут, но и в этом случае при переходе на другой, надо будет загрузить шаблоны для добавляемых элементов. Переопределить что-то и встроить в инфраструктуру можно восновном когда разработчики фреймворка и решения на нем об этом как-то подумали, но на деле я такой уровень видел только в ангуляре и то вот у него конфигурирующие директивы вынесены в аннотации, что осложняет решение задачи переопределения, т.е. вы можете у своего наследника сделать другой темплейт, но переконфигурировать имеющийся компонент на использование вашего темплейта задача уже нетривиальная.
если у вас шаблоны отдельно, то их надо загружать, загружать их надо будет по сети, особенно если вы имеете дело с SPA и некоторой модульной архитектурой на приличном размере, а по сети значить асинхронный запрос с отложенным результатом, т.е. это надо будет делать либо до инициализации/рендера самих компонентов, либо как-то хитрить. Видимо так же нетривиально, как и в случае если вам пейджер с контролами < — -> надо будет перескинить на пейджер с пейджанацией 1 2 3 используя только css. Насчет наследования я не уверен, тут штука в том, что компоненты могут находится в тесном взаимодействии друг с другом которое будет полагаться на конкретные класс, а не их даже наследники. Например у вас есть такой лейаут:
если разработчик реализовал прямое связывывание всех этих компонентов (хардкод) без возможности подменить скажем pager, своей реализацией, с доработкой такого кода могут быть проблемы, в то же время если он разрабатывал уважая необходимость выносить верстку-лейаут в отдельные шаблоны, эти шаблоны вы переопределить скорее всего сможете.
как я понимаю, из источников не получится подгрузить асинхронно, т.е. по сети (динамически), только если предзагрузить шаблоны до инициализации самих компонентов и в этом случае конвертация обратно в строку тоже будет лишней. Единственный вариант тут будет дорендеривать шаблоны в какие-нибудь слоты, но это все будет запутаннее чем даже продолжать наворачивать html-строки в коде, поэтому никто в сторону шаблонов отделенных от кода и не посмотрит.
отдельные браузерные вендоры от импортов отказались «на отрез», поэтому в стандарты W3C они не пошли, а команда полимера на тот момент уже вовсю готовила 3ю версию фреймворка серьезно базировавшуюся на механизме импортов и все дальнейшее развитие тоже пришлось отменить в пользу LitElement
у меня был кейс angular material/cdk, когда мне надо было сделать другой пейджер и свой фильтр, легко переопределял классы и использовал свои шаблоны, менял на совершенно иной принцип работы и заодно локализовал, не уверен, что такое было бы возможно с фреймворком предполагающим прямую линковку и хардкод верстки
на мой взгляд это скорее поветрие, они обожглись с Polymer, когда все вроде было сделано не плохо, но за счет HTML Imports получался код в верстке и маятник качнуло в другую крайность, уже утвержденную популярностью реакта.
атрибуты это строки, да, и в DOM вы можете зарендерить строку, но это не означает, что браузер хранит все в виде текстового файла. Для создания можно использовать document.createElement или просто конструкторы и аттрибуты. В дереве есть и индексация, по айди выборка быстрее, чем селектором или даже элемент можно сразу получить из глобального пространства, есть и типизация самих элементов за счет того, что за каждым элементом вы можете закрепить свой тип-класс, и это все позволит просто и изящно структурировать код, так что-бы не было огромных портянок с вермишелями.
в LitElement вертска пишется прямо в джаваскрипт код, что нарушает инженерный принцип разделения ответственностей и лишает разработчика гибкости получаемой от использования нативных шаблонов. Например, с помощью веб-компонентов я легко могу сделать систему, которая будет поддерживать скины и кастомизацию не только за счет изменения стилей, но и самого лейаута.
Насчет языка, разработка ПО штука очень международная, а языков национальных очень много и проще всем выучить какой-то один дополнительный язык хотя бы до уровня со словарем (вот я учу китайский еще полгода и пока не достиг такого и близко), и так исторически сложилось, что это английский, но это оказалось правильным потому что английский подходит для записи кода.
грузить шаблоны можно и фронтенд кодом, а их нахождение в дереве является отличным механизмом кеширования, т.к. когда вы кешируете строку или функцию ее генерации, вы все равно эту строку потом рендерите в дерево, а иначе рендера не происходит, что оптимальнее
>> С ленивой загрузкой компонентов тоже непонятно как быть
с ленивой загрузкой в веб-компонентах ситуация лучше всех, т.к. для браузера динамически дорендеренный <my-custom-element> преобразуется в ваш кастомный компонент без особенных препятствий и с выполнением полагающихся хуков
>> Свойства обновляются поштучно, и изнутри компонента вы не можете предугадать
можно передавать джейсон или не использовать атрибуты, а использовать эвенты или прямое связывание
если разработчик реализовал прямое связывывание всех этих компонентов (хардкод) без возможности подменить скажем pager, своей реализацией, с доработкой такого кода могут быть проблемы, в то же время если он разрабатывал уважая необходимость выносить верстку-лейаут в отдельные шаблоны, эти шаблоны вы переопределить скорее всего сможете.
или так:
но когда пишешь в html как в статье, то среда подсвечивает если ошибся, а addEventLiseter это динамический несвязный биндинг со всеми вытекающими