в общем-то это даже и не вопрос, это его цель.
если кратко, то все зае...мучились с бесконечными фронт-энд фреймворками, и решили запилить все это на нативном браузерном уровне (с блекджеком и плюшками, все как обычно)
то есть теперь браузер может использовать кастомные компоненты как нативные элементы, сам связывает данные и вью и прочее. На стороне частной реализации остаются только некоторые вещи, например, как эти данные приходят в браузер и безопасность.
то есть браузер сам стал фронт-энд фреймворком
к чему это приведет:
(1) фактически неизбежное вымерание JS фронт-энд фреймворков, так как JS фронт-энд фреймворков - это все же костыль, заплатка, глобальный "полифил" для несуществовавшего ранее браузерного функционала. Старый Лайтнинг фреймворк теперь уже легаси Аура велосипедо-изобретательский проектик. RIP.
(2) Унификация фронтэнд девелопских скилсов: СФ пишет, что теперь любой фронт-энд разработчик может легко запилить СПА програмулину под СФ. А я вот думаю об обратном:
(3) Теперь любой, кто разобрался в Web Component может относительно легко пилить на любой платформе. Вот это действительно важно. Это свобода.
А не приведет ли это к третьему сдвигу:
(4) если все работу можно организовать в браузере на нативном уровне, не снизится ли зависимость проектов от дорогих и сложных платформ. Может и значение платформы выродится просто в функционал БД и обеспечение безопасности? Вот где начинается настоящая свобода и шанс для новый прорывных стартапов.
Что думаете?!
в общем-то это даже и не вопрос, это его цель. если кратко, то все зае...мучились с бесконечными фронт-энд фреймворками, и решили запилить все это на нативном браузерном уровне (с блекджеком и плюшками, все как обычно) то есть теперь браузер может использовать кастомные компоненты как нативные элементы, сам связывает данные и вью и прочее. На стороне частной реализации остаются только некоторые вещи, например, как эти данные приходят в браузер и безопасность. то есть браузер сам стал фронт-энд фреймворком к чему это приведет: (1) фактически неизбежное вымерание JS фронт-энд фреймворков, так как JS фронт-энд фреймворков - это все же костыль, заплатка, глобальный "полифил" для несуществовавшего ранее браузерного функционала. Старый Лайтнинг фреймворк теперь уже легаси Аура велосипедо-изобретательский проектик. RIP. (2) Унификация фронтэнд девелопских скилсов: СФ пишет, что теперь любой фронт-энд разработчик может легко запилить СПА програмулину под СФ. А я вот думаю об обратном: (3) Теперь любой, кто разобрался в Web Component может относительно легко пилить на любой платформе. Вот это действительно важно. Это свобода. А не приведет ли это к третьему сдвигу: (4) если все работу можно организовать в браузере на нативном уровне, не снизится ли зависимость проектов от дорогих и сложных платформ. Может и значение платформы выродится просто в функционал БД и обеспечение безопасности? Вот где начинается настоящая свобода и шанс для новый прорывных стартапов. Что думаете?!
Одна из реализаций называется Material Design. Прикольная штука
[quote="Den Brown"]3) Теперь любой, кто разобрался в Web Component может относительно легко пилить на любой платформе. Вот это действительно важно. Это свобода.[/quote] Одна из реализаций называется Material Design. Прикольная штука
Давно слежу за Web Components. Штука прикольная, но еще крайне сырая и не все поддерживается современными браузерами. Хотя последнее время прогресс пошел.
Что станет киллер фичей для сегодняшних фреймворков это врядли. Это всего лишь низкоуровневый слой для инкапсуляции html/js. Всю сложную логику по взаимодействию, биндингу, сервисы и прочей js фигню придется писать самому. Преимущество лишь в том что если использовать WebComponents чистыми, то не нужны будут никаких многотонные библиотеки и компиляция. Бери и пили прям внутри страницы - как в старые добрые времена с JQuery. Но кто активно практикует фронтенд знают сколько плюшек есть еще до того как код дойдет до браузера. Плюс куча готовых решений из коробки современных фреймворков сильно облегчают жизнь и спасают от изобретения очередного велосипеда.
WebComponents это всего лишь основа и многие фреймворки просто начинают их использовать как фундамент, а переход для разработчиков абсолютно незаметен (вчера компоненты просто компилились в кусок html, завтра будут собираться в нативные web компоненты).
Конечно можно будет использовать их напрямую, но это будет сравни разработке на голом JS (поклонников данного подхода тоже хватает).
Давно слежу за Web Components. Штука прикольная, но еще крайне сырая и не все поддерживается современными браузерами. Хотя последнее время прогресс пошел. Что станет киллер фичей для сегодняшних фреймворков это врядли. Это всего лишь низкоуровневый слой для инкапсуляции html/js. Всю сложную логику по взаимодействию, биндингу, сервисы и прочей js фигню придется писать самому. Преимущество лишь в том что если использовать WebComponents чистыми, то не нужны будут никаких многотонные библиотеки и компиляция. Бери и пили прям внутри страницы - как в старые добрые времена с JQuery. Но кто активно практикует фронтенд знают сколько плюшек есть еще до того как код дойдет до браузера. Плюс куча готовых решений из коробки современных фреймворков сильно облегчают жизнь и спасают от изобретения очередного велосипеда. WebComponents это всего лишь основа и многие фреймворки просто начинают их использовать как фундамент, а переход для разработчиков абсолютно незаметен (вчера компоненты просто компилились в кусок html, завтра будут собираться в нативные web компоненты). Конечно можно будет использовать их напрямую, но это будет сравни разработке на голом JS (поклонников данного подхода тоже хватает).
Если не ошибаюсь Material Design это всего лишь концепция дизайна
https://ru.wikipedia.org/wiki/Material_Design
и она не имеет никакого отношения к Web Components. Вариантов ее реализации куча.
https://material.angular.io/
https://material-ui.com/
https://materializecss.com/
В том числе и на Web Components
https://material-components.github.io/material-components-web-catalog/#/
Но что-то набор сильно скудненький.
[quote="wilder"]Одна из реализаций называется Material Design. Прикольная штука[/quote] Если не ошибаюсь Material Design это всего лишь концепция дизайна https://ru.wikipedia.org/wiki/Material_Design и она не имеет никакого отношения к Web Components. Вариантов ее реализации куча. https://material.angular.io/ https://material-ui.com/ https://materializecss.com/ В том числе и на Web Components https://material-components.github.io/material-components-web-catalog/#/ Но что-то набор сильно скудненький.
Но если честно так и не проникся экой концепцией. Походу это сильно выше моего понимания. Хотя пробовал использовать на уровне css в своих проектах. ИМХО сложилось впечатление что это все вылезло и заточено скорее под мобильную платформу чем под web.
[quote="Dmitry Shnyrev"]Если не ошибаюсь Material Design это всего лишь концепция дизайна https://ru.wikipedia.org/wiki/Material_Design [/quote] Но если честно так и не проникся экой концепцией. Походу это сильно выше моего понимания. Хотя пробовал использовать на уровне css в своих проектах. ИМХО сложилось впечатление что это все вылезло и заточено скорее под мобильную платформу чем под web.
Вот кстати и интересная статейка подоспела на Хабре.
Когда исчезнут JavaScript-фреймворки?
Конечно ничего выдающегося в ней нет, но как всегда соль в самих комментах. Позволю себе наглость и процитирую популярный коммент
К сожалению, приведённый пример с веб-компонентами не учитывает тот факт, что уже в небольшом приложении сразу же встанет вопрос об управлении состоянием, асинхронных операциях и т.п. Здесь нужны вспомогательные технологии, подобные redux, rxjs, mobx, vuex. В итоге получится некоторый глубоко кастомный фреймворк, для которого не будут существовать готовые рецепты и библиотеки (например, для обработки форм), а порог входа для новичков будет существенно выше, чем при разработке на популярном фреймворке. Придётся тратить дополнительное время на объяснение всех принципов, особенностей, best practices и соглашений. То есть собственно того, что делает фреймворк фреймворком.
И это чертовски правильное утверждение - современные фреймворки являются полноценными инструментами с хорошо документированными стандартами. За годы развития они впитали в себя все основные элементы для создания приложения. Разработка с нуля на тех же веб компонентах сведется к разработке собственного фреймворка-франкенштейна. Ладно еще простительно если сам будешь работать, но если на такой проект придут люди, то как быстро они проникнутся вашей структурой проекта. В то время как с тем же Ангуляром инструктаж новых разработчиков будет сводиться к редиректу на официальную документацию. Кстати, из опыта скажу, еще не разу мне не объясняли новый проект на Ангуляр - весь процесс входа сводился к получению ссылки на git репозиторий. И это очень правильно. Свобода действий это ЗЛО! Чем больше фреймворк ограничивает в возможностях разработки, тем сложнее выстрелить себе в ногу.
Вот кстати и интересная статейка подоспела на Хабре. [url=https://habr.com/ru/company/ruvds/blog/439824/]Когда исчезнут JavaScript-фреймворки?[/url] Конечно ничего выдающегося в ней нет, но как всегда соль в самих комментах. Позволю себе наглость и процитирую популярный коммент [i]К сожалению, приведённый пример с веб-компонентами не учитывает тот факт, что уже в небольшом приложении сразу же встанет вопрос об управлении состоянием, асинхронных операциях и т.п. Здесь нужны вспомогательные технологии, подобные redux, rxjs, mobx, vuex. В итоге получится некоторый глубоко кастомный фреймворк, для которого не будут существовать готовые рецепты и библиотеки (например, для обработки форм), а порог входа для новичков будет существенно выше, чем при разработке на популярном фреймворке. Придётся тратить дополнительное время на объяснение всех принципов, особенностей, best practices и соглашений. То есть собственно того, что делает фреймворк фреймворком.[/i] И это чертовски правильное утверждение - современные фреймворки являются полноценными инструментами с хорошо документированными стандартами. За годы развития они впитали в себя все основные элементы для создания приложения. Разработка с нуля на тех же веб компонентах сведется к разработке собственного фреймворка-франкенштейна. Ладно еще простительно если сам будешь работать, но если на такой проект придут люди, то как быстро они проникнутся вашей структурой проекта. В то время как с тем же Ангуляром инструктаж новых разработчиков будет сводиться к редиректу на официальную документацию. Кстати, из опыта скажу, еще не разу мне не объясняли новый проект на Ангуляр - весь процесс входа сводился к получению ссылки на git репозиторий. И это очень правильно. Свобода действий это ЗЛО! Чем больше фреймворк ограничивает в возможностях разработки, тем сложнее выстрелить себе в ногу.
И обратная сторона этого - сложнее сделать что-то нестандартное. Написать слово мел *уем.
[quote="Dmitry Shnyrev"]Чем больше фреймворк ограничивает в возможностях разработки, тем сложнее выстрелить себе в ногу.[/quote] И обратная сторона этого - сложнее сделать что-то нестандартное. Написать слово мел *уем.
В небольших масштабах возможно, но я бы к примеру лучше бы жил в городе построенном из железа и бетона по законам архитектуры, чем в городе где каждый строит из говна и палок как умеет.
Помнится мне один проект где один программист нагородил всяких одному ему известных паттернов программирования, натянул кучу сторонних либ и сказал работать с этим всем. А пришли потом более опытные разрабы и ужаснулись. А со временем все эти паттерны ушли в историю и все кодят кто во что горазд.
Я против любого вида самодеятельности!
[quote="Maxim Elets"]И обратная сторона этого - сложнее сделать что-то нестандартное.[/quote] В небольших масштабах возможно, но я бы к примеру лучше бы жил в городе построенном из железа и бетона по законам архитектуры, чем в городе где каждый строит из говна и палок как умеет. Помнится мне один проект где один программист нагородил всяких одному ему известных паттернов программирования, натянул кучу сторонних либ и сказал работать с этим всем. А пришли потом более опытные разрабы и ужаснулись. А со временем все эти паттерны ушли в историю и все кодят кто во что горазд. :) Я против любого вида самодеятельности!
Классика что бы никто кроме тебя не разобрался и поддерживать не смог,но на это история с этим программистом не закочилась, он тут нафигачил одной конторе проект и потом свалил.... Но не переживай потом пришел добрый молодец и достал свой проект из коробки и все решил,вот и сказки конец.
[quote="Dmitry Shnyrev"]Помнится мне один проект где один программист нагородил всяких одному ему известных паттернов программирования, натянул кучу сторонних либ и сказал работать с этим всем[/quote] Классика что бы никто кроме тебя не разобрался и поддерживать не смог,но на это история с этим программистом не закочилась, он тут нафигачил одной конторе проект и потом свалил.... Но не переживай потом пришел добрый молодец и достал свой проект из коробки и все решил,вот и сказки конец.
Не думаю что все настолько низко. Скорее всего делается все из лучших побуждений. Программисты имеют разный опыт и свои наработки. И конечно считают их лучшим решением которому должны следовать все остальные. Но приходит на проект другой программист с не меньшим опытом и наработками и начинается война!
Хахаха. Про что я и написал
А что будет когда придет третий?
[quote="Sergey Prishchepa"]Классика что бы никто кроме тебя не разобрался и поддерживать не смог[/quote] Не думаю что все настолько низко. Скорее всего делается все из лучших побуждений. Программисты имеют разный опыт и свои наработки. И конечно считают их лучшим решением которому должны следовать все остальные. Но приходит на проект другой программист с не меньшим опытом и наработками и начинается война! [quote="Sergey Prishchepa"]Но не переживай потом пришел добрый молодец и достал свой проект [/quote] Хахаха. Про что я и написал :D А что будет когда придет третий? :D
Ну, конкретно Web Component не разбирал, но то что JS пытаются с Олимпа свалить - это факт. И пытаются не только "мелкие" конторки. Тот же Мелкософт где-то в августе сделает релиз Core 3.0, а там нормально достаточно плюшек чтобы работать front-end без JS, теоретически. Практически - JS для них параллельная технология, которой можно и нужно продолжать пользоваться.
И пока что они пытаются двигаться в двух направлениях:
1. Blazor - технология работающая через WebAsebly и теоретически позволяет задеплоить все возможности платформы Net в браузер. Попробовал - понравилось. Работает быстрее JS и меньше скрипта на подгрузке.
2. Razor Components - та же самая ерунда, но позволяет вынести часть работы клиента на сервер. Хорошо подойдет для легких мобильных приложений с минимумом расхода траффика.
Пока, из того, что сделали выглядит очень достойно. Думаю, с релизом, выставят баннер "your move JS?"
Ну, конкретно Web Component не разбирал, но то что JS пытаются с Олимпа свалить - это факт. И пытаются не только "мелкие" конторки. Тот же Мелкософт где-то в августе сделает релиз Core 3.0, а там нормально достаточно плюшек чтобы работать front-end без JS, теоретически. Практически - JS для них параллельная технология, которой можно и нужно продолжать пользоваться. И пока что они пытаются двигаться в двух направлениях: 1. Blazor - технология работающая через WebAsebly и теоретически позволяет задеплоить все возможности платформы Net в браузер. Попробовал - понравилось. Работает быстрее JS и меньше скрипта на подгрузке. 2. Razor Components - та же самая ерунда, но позволяет вынести часть работы клиента на сервер. Хорошо подойдет для легких мобильных приложений с минимумом расхода траффика. Пока, из того, что сделали выглядит очень достойно. Думаю, с релизом, выставят баннер "your move JS?"
Так мегафреймворки работали испокон веков. Не уверен что они ставят целью изжить JS, они просто продолжают пилит свои шаблонизаторы чтобы быть в тренде. Еще пять лет назад помню RoR внедрял технологию для рендеринга своих Views аля SPA (валидиция на лету, сабмит форм без перезагрузки, рендеринг patrial views без перезагрузки). То же пришло и в Django. Так же мог поступить и SF со своим Visualforce, но пошел другим путем с Lightning. Уверен тоже самое делают и другие монстры Web на .net/java/... . Они просто развивают то что есть у них, то что используют разработчики. Только все эти шаблонизаторы всего лишь новый уровень абстракции над JS, который как Assembler для железа, только в браузере.
На счет WebAssembly вот это уже интереснее будет! это уже действительно не JS и вполне возможно будущий JS-киллер. Но чет я не слышал до сих пор чтобы его начали поддерживать и использовать. Возможно у меня устаревшие данные. Надо будет поковыряться! (за эту тему спасибо )
Так мегафреймворки работали испокон веков. Не уверен что они ставят целью изжить JS, они просто продолжают пилит свои шаблонизаторы чтобы быть в тренде. Еще пять лет назад помню RoR внедрял технологию для рендеринга своих Views аля SPA (валидиция на лету, сабмит форм без перезагрузки, рендеринг patrial views без перезагрузки). То же пришло и в Django. Так же мог поступить и SF со своим Visualforce, но пошел другим путем с Lightning. Уверен тоже самое делают и другие монстры Web на .net/java/... . Они просто развивают то что есть у них, то что используют разработчики. Только все эти шаблонизаторы всего лишь новый уровень абстракции над JS, который как Assembler для железа, только в браузере. На счет [url=https://webassembly.org/]WebAssembly[/url] вот это уже интереснее будет! это уже действительно не JS и вполне возможно будущий JS-киллер. Но чет я не слышал до сих пор чтобы его начали поддерживать и использовать. Возможно у меня устаревшие данные. Надо будет поковыряться! (за эту тему спасибо :) )
Да, как и думал они еще в глубокой бете.
https://webassembly.org/roadmap/
Можно только пробовать. Production увидит решения на WebAssembly еще не скоро.
Да и к тому же предназначение WebAssembly немного другое - это скорее ускорение а не замена JS.
Пилить всякие интерактивные формочки на WebAssembly будет таким же приятным занятием как заниматься рендерингом html на чистом C. Крупные фреймворки начнут использовать WebAssembly потихоньку, чисто для оптимизации тяжелых компонентов но для конечного потребителя (разработчиков) это будет скрыто
Да, как и думал они еще в глубокой бете. https://webassembly.org/roadmap/ Можно только пробовать. Production увидит решения на WebAssembly еще не скоро. Да и к тому же предназначение WebAssembly немного другое - это скорее ускорение а не замена JS. Пилить всякие интерактивные формочки на WebAssembly будет таким же приятным занятием как заниматься рендерингом html на чистом C. Крупные фреймворки начнут использовать WebAssembly потихоньку, чисто для оптимизации тяжелых компонентов но для конечного потребителя (разработчиков) это будет скрыто :D
Про изжить JS никто из них не думает, но мне кажется большие папы пытаются привести разработку frontend к какому-то общему знаменателю. Так будет проще и для разрабов и для самих больших пап. А то сейчас часто так получается, разработчик хороший, много знает. Работаешь с Vue? Нет, с Angular работаю. Извините, Вы нам не подходите. По сути, какая разница с каким фреймом ты работаешь? Нету проблемы перейти с одного на другой. Но HR этого не понимает.
Про изжить JS никто из них не думает, но мне кажется большие папы пытаются привести разработку frontend к какому-то общему знаменателю. Так будет проще и для разрабов и для самих больших пап. А то сейчас часто так получается, разработчик хороший, много знает. Работаешь с Vue? Нет, с Angular работаю. Извините, Вы нам не подходите. По сути, какая разница с каким фреймом ты работаешь? Нету проблемы перейти с одного на другой. Но HR этого не понимает.
Тут даже возражать не хочется
Вот простая картинка о том как оно на самом деле будет!
ну и вот так
[quote="yurick"]пытаются привести разработку frontend к какому-то общему знаменателю[/quote] Тут даже возражать не хочется :D Вот простая картинка о том как оно на самом деле будет! [img]https://xkcd.ru/i/927_v4.png[/img] ну и вот так :D [img]https://i.paste.pics/34a5f8194b2fad2e4361d2517d6c0888.png[/img]