а, да, микрософт тоже переключился на мобильную версию после обновления страницы. И тем не менее интерфейс Google Translate не требует обновления страницы, т.е. представляет собой одну базу кода, хорошо масштабирующуюся под любой экран. Если это не актуально, то почему такое есть только у гугла?
я как разработчик сталкивался с разными взглядами на проблему масштабируемости веб-интерфейса, а тут невольно испытал их на себе как пользователь. Мне показался интересным примером тот факт, что идентичные по функциональности конкурирующие продукты показывают полную выборку решений.
касательно именно импортов, возможно некоторым потребовался удар масштабными граблями. Сейчас много отрицателей ООП, MVC и прочих полезных паттернов, произошел видимо разрыв поколений из-за ухода разработки в аутсорс и дрейфа технологий, да и есть лобби с евангелистами которые постоянно призывают от чего-нибудь отказаться или наоборот что-то поставить во главу угла и как-будто обеспечить этим узко-специализированную эффективность.
вряд ли в гугле все считали HTML импорты дичью, кроме того, я читал что в развитии стандартов для веб компонентов активно участвовали и Microsoft и в эдже все относительно быстро реализовывали.
да, существенная разница как раз в том что не надо бустрапить и транспилять, что-бы заиметь некоторый минимум и точку входа, это дает более простую реализацию динамически добавляемых компонентов и вообще взаимодействия на странице. Веб компоненты достаточно органичны и при том мощны, раньше была такая технология Flesh/Flex и многие делали на нее ставку из-за всяких удобных и крутых возможностей и производительности, но она была блобом закрывающим приложения в свой черный ящик, таким же как популярные фреймворки сейчас. Тогда вы писали на флеше и только на нем используя эту технологию, сейчас точно также закрываетесь во внутреннем джаваскрипт рантайме приложения на фреймворке. Да, можно все таки делать мостики, но будет ли это эффективнее использования фреймворков на веб компонентах и нативном джаваскрипте (с модулями и пр.) — большой вопрос.
возможно это было у меня только в отдельных легаси браузерах, но факт в том что кастомные элементы у меня то ли не раздиспатчивались совсем, то ли как-то не совсем корректно при использовании innerHTML, в тоже время через другие перечисленные методы все работало
кстати именно с Custom Elements гораздо более доступным оказывается прямое взаимодействие с элементами дерева, вот в реакте у вас обязательно такие приколы будут сбоить от перерендеров, а тут перерендер это дело «добровольное», осмысленное, сопровождаемое вызовом колбеков с разбиндивающим кодом
веб компоненты не заставляют вас все задачи решать сугубо программно и каждый раз низкоуровнево. Если вам кажется разумным сделать адаптивную иконку стилями, то вероятно нет смысла делать это как-то еще.
При декларативном подходе это реализуется на раз-два. Я не рассматриваю всерьёз реализацию декларативности через innerHTML
innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml, и если от конечного разработчика какую-то магию спрятали за подсистемами это не значит, что такого же нельзя реализовать для веб-компонентов. Даже я бы сказал наоборот: в популярных фреймворках делают специальные погремушки для live биндинга и шаблонизации, которые в компонентах просто работают из коробки или после некоторых изящных доработок, например с attributeChangedCallback не нужны специальные обзерверы и реакторы потоков данных.
полностью может и нет, но фреймворк использующий веб компоненты заменит. Насчёт декларативности можете привести пример чего нельзя сделать с ними? Я вот прикручивал инжектор от ангуляра и это было декларативно вполне. Слоты и гетеры тоже позволяют это все обеспечивать. Ну а теневое дерево как раз призвано решать проблемы со стилями.
развитие веб компонентов проходило не безболезненно, однако нынешняя реальность из засилия совершенно несовместимых между собой и порой противоречащих инженерной науке фреймворков реакт, вуе и ангуляр гораздо хуже
главное в нем было — это легкость и скорость интерфейса и загрузки страниц. Такого не было ни у мозиллы ни у «облегченного» фаерфокса из-за собственного тормозного тулкита XUL и тяжести самого движка netscape. В то же время опера, которая в тогда была прибежищем альтернативщиков выпустила тяжелую перегруженную версию, ну и вообще она всегда была варезная. Поэтому все перфекционисты быстренько переехали на хром.
зависит не только, но тем не менее этого не отменишь, например синтаксис джавы многим сторонникам скриптовых языков кажется не таким элегантным, даже учитывая субъективность этого впечатление оно вполне имеет реальные основания, а раньше так и вообще было злободневным
коренных носителей английского среди разработчиков как раз не так то много, гораздо больше каких-нибудь филипинцев или индусов с китайцами, этот факт только подчеркивает значимость английского в коде, т.к. даже программируя в узкой нише не использовать их наработки будет только сложнее
эсперанто — элегантный язык с ложкой дегтя, т.е. крыжиков в этом он оказался привязан к восточно-европейской культуре создателя (хотя говорят, что есть версии без них), и я не уверен, что эти символы есть в ASCII:)
конечно, последнее предложение в заметке как раз об этом, если вы придерживаетесь некоторых рекомендаций к которым относится использование латиницы и английского, то некоторый шанс получить объективно элегантный код есть, а иначе вряд ли
ну код это как раз об прекрасном, точнее есть понятие элегантный код и есть противоположные ему. Вот немецкий в вашем примере как раз совсем не подходит под понятие элегантность. Понятно, что практические соображения можно какие-то придумать, но исходить только из удобства это недальновидно когда речь идет о разработке ПО, именно сиюминутное удобство (быстрота решения задачи) часто становится причиной плохо читаемого и также плохо работающего кода, который может еще обрасти костылями и стать пугалом на проекте, даже если тот восновном ничего.
// ваш кэп;)
innerHTML это вообще не про веб компоненты, потому что customElements работает только с appendChild и insertAdjacentHtml, и если от конечного разработчика какую-то магию спрятали за подсистемами это не значит, что такого же нельзя реализовать для веб-компонентов. Даже я бы сказал наоборот: в популярных фреймворках делают специальные погремушки для live биндинга и шаблонизации, которые в компонентах просто работают из коробки или после некоторых изящных доработок, например с attributeChangedCallback не нужны специальные обзерверы и реакторы потоков данных.
полностью может и нет, но фреймворк использующий веб компоненты заменит. Насчёт декларативности можете привести пример чего нельзя сделать с ними? Я вот прикручивал инжектор от ангуляра и это было декларативно вполне. Слоты и гетеры тоже позволяют это все обеспечивать. Ну а теневое дерево как раз призвано решать проблемы со стилями.
развитие веб компонентов проходило не безболезненно, однако нынешняя реальность из засилия совершенно несовместимых между собой и порой противоречащих инженерной науке фреймворков реакт, вуе и ангуляр гораздо хуже