В 2018 году количество вакансий с упоминанием специальности data scientist выросло в семь раз по сравнению с 2015 годом, а вакансий с ключевыми словами machine learning — в пять раз.
Именно разработка фронтенда упростилась в разы. Мы получили абстракции и готовые решения над всеми основными болями фронтенда за последние несколько лет: сеть, синхронизация состония и представления, управление состоянием, инкапсуляция стилей, асинхронность, модульность и так далее. Только посмотрите как далеко ушли инструменты разработки в браузере! С точки зрения Developer Experience фронтенд развился очень сильно: от alert() и console.log до дебагера который умеет отлаживать асинхронные вызовы сохраняя весь стек. От script.js со всеми скриптами в одной куче до асинхронной подгрузки модулей по мере надобности. Современному фронтендеру нужно держать минимум информации в голове при разработке, за него это уже всё делают автоматизированные системы (линтеры, тесты, сборка, CI) и инкапсуляция. С этой точки зрения разработка стала даже проще.
А вот что усложнилось так это инструменты под капотом. Ты можешь поставить Parcel, собрать проект в одну команду и вообще не задумываться о том как оно работает. А если захочешь разобраться как работает каждый этап то увидишь насколько там всё сложно и тяжело для понимания.
Выше правильно отметили об избытке инструментов в современном фронтенде, даже был в своё время такой термин как Javascript Fatigue. Но этот период уже скорее прошёл, среди всех инструментов появились явные лидеры и выбирать приходится не из 10-25 вариантов, а из 3-4. При этом у вас всегда есть возможность попробовать что-то новое, даже если не на проекте, то для личного развития.
Так же сильно повысились требования к фронтенду, а соответственно и к фронтенд-разработчикам. Недостаточно просто знать HTML, CSS и JS, нужно разбираться в смежных областях, в инструментах, уметь писать тесты. Это новые ответственности фронтендера, про которые можно сказать что они усложнили саму сферу фронтенда. Но абсолютно такие же процессы происходят и в других областях, так что это вполне закономерно.
Различие продакшн кода и исходников это самая меньшая боль во фронтенде, особенно учитывая сколько задач она решает такой малой кровью.
А вот из действительно больших нерешённых болей фронтенда я бы отметил кроссбраузерность. И это не про поддержку фичей, а про поведение браузеров. До сих пор в 2019 году вам придётся городить велосипеды для исправления поведения браузеров. Может показаться что со смертью IE и Edge эта проблема решилась, но на самом деле нет потому что появились различные мобильные браузеры которые в некоторых аспектах работают совсем иначе чем десктопные. И далеко не факт что под ваш конкретный баг есть готовое решение.
В чём проблема с тем чтобы привязать модальное окно к модулю Vuex и использовать middleware роутера?
Вешать логику роутера на модальное окно — это грубое наршение SRP. Появилась ненужная связь модального окна и роутера, такой код будет невозможно поддерживать.
Использование Vuex избавит вас от глобальных переменных и позволит более гибко контролировать поведение модального окна.
Вам правильно подсказали что такой подход будет перезагружать страницу. У вас на начальной странице ничего нет. Попробуйте добавить туда что-нибудь и увидите как при каждом закрытии окна весь контент рендрится заново. (пример: https://jsfiddle.net/uyqmL7ro/)
Только не Ростелеком закупил, а абоненты Ростелекома проспонсировали покупку оборудования. Был тариф 330 рублей, стал 450. При чём повышают тихо, о повышениях можно узнать только в дебрях новостей регионального сайта.
С ужасом обнаружил что вы тот же самый автор что год назад писал крутые статьи про фронт в Яндекс.Деньгах. Эх, грёбаный фронтенд, что ж ты с людьми-то творишь!
То что у Babel есть preset-env совершенно не означает что он делает тоже самое что postcss-preset-env. Как раз в бабеле полифилятся полностью готовые спецификации, см. https://new.babeljs.io/docs/en/next/babel-preset-env.html
Это похоже скорее на autoprefixer, чем на preset-env.
И бабель уже проходил путь preset-stage-0, что-то похожее на то что в PostCSS, только в postcss-preset-env ситуация ещё хуже потому что смешались все стейджи: 0, 1, 2, 3. И вот к чему это привело у бабеля: https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
А если наборы разные, то очень велика вероятность прийти, написать что-то и только потом при тестировании в разных браузерах обнаружить, что какой-то трансформации нет и все сломалось.
А каким образом postcss-preset-env решает эту проблему? Какая разница как подключен плагин который не полифилится в конкретном браузере? Вы и в сборке и по отдельности получите эту проблему.
Эти плагины решают конкретные задачи, их нет смысла постоянно обновлять.
Здесь нет логической связи, если плагин работает некорректно его нужно починить, а наличие этих плагинов в одном пакете усложняет этот процесс. Допустим нужно откатиться на старую версию плагина которая работала корректно, при этом остальные плагины должны быть на последней версии потому что там добавились какие-то фишки или фиксы, и это превращается в очень нетривиальную задачу.
Если на проектах каждый добавляет что-то от себя вы в любом случае придёте к ситуации когда объём зависимостей будет выглядеть как зоопарк. Только на одной чаше весов у вас контролируемый и чёткий список зависимостей, а на другой чёрная коробка, в которой может быть что угодно. По-моему между очевидным и неочевидным выбора не стоит. Я не очень понимаю аргумент с «каждый раз вникать», ведь чтобы работать с post-css-env вам нужно сначала вникнуть во все плагины которые там есть, что по мыслительной нагрузке будет всегда больше чем разбираться в отдельных плагинах.
Представьте что человек написал код на stage 0 и ни кому об этом не сказал (а код-ревью вёрстки это скорее исключение чем правило), вы это никак не проконтролируете с таким плагином и люди будут так писать потому что это просто. Всё-таки когда вам нужно приложить некоторые усилия чтобы писать на stage 0 это очень мотивирует несколько раз подумать а нужно ли оно вообще и можно ли решить эту проблему как-то иначе. Если мы говорим про хорошие практики то все они строятся именно на том чтобы максимально уменьшить возможность сделать плохо для проекта\команды. И в данном случае post-css-env является очень плохой практикой, которая по факту развязывает руки для давнокода.
Так же стоит отметить что post-css-env всего лишь агрегатор плагинов. Если у вас поломался какой-то из этих плагинов вам придётся ждать когда фикс добавят в post-css-env (или форкать и фиксить самому), вместо того чтобы обновить плагин отдельно.
Пожалуйста, прежде чем добавлять к себе Postcss-preset-env прочитайте что именно он за собой тянет. Вашему проекту совсем не обязательно нужно применять столько трансформаций при каждой сборке. Вполне возможно что будет достаточно взять 1-2 плагина из этой сборки и подключить их отдельно. Это будет так же наглядно отражать какие конкретно зависимости есть в вашем проекте, вместо одной зависимости на всё.
Первый совет не просто самый сложный, но ещё и самый вредный, потому что добавление ключевого слова functional в ваш шаблон несёт за собой очень много побочных эффектов, о которых вы можете даже и не догадываться.
Например, вы полностью лишаетесь автоматического пробрасывания атрибутов в рутовый элемент и эту логику вам придётся реализовывать самому. Простого v-bind="$attrs" здесь не хватит, потому что у Vue есть два типа классов в data: class и staticClass, оба из которых нужно прокидывать. Так же вы лишены возможности использовать другие компоненты внутри функционального компонента как раньше, для этого вам придётся использовать пропы или inject с дефолтными значениями.
Для таких компонентов как в первом примере, который просто отображает данные из пропов я бы посоветовал использовать v-once, если вы на все 100% уверены что этот компонент не будет изменяться.
С приходом Vue 3 нам обещают оверхед stateful компонентов на уровне функциональных, а писать функциональные компоненты, чтобы потом от них избавляться это очень дорого. Поэтому применяйте их только в тех случаях когда у вас рендерятся сотни и тысячи таких компонентов, в таком случае выигрыш по производительности обоснует поддержку этого кода.
Какая знакомая риторика. «Вы что, хотите как в Китае?» Чья бы корова мычала, Марк.
Решает не только ставка, есть ещё доверие к защите частного капитала и верховенство права. В России пока с этим не всё хорошо.
Это может быть запросто вызвано эффектом базы.
It should be illegal to compare Javascript runtime (Node), frontend libraries (React), frontend frameworks (Vue) and full stack frameworks (Rails).
Некорректен сам тезис статьи.
Именно разработка фронтенда упростилась в разы. Мы получили абстракции и готовые решения над всеми основными болями фронтенда за последние несколько лет: сеть, синхронизация состония и представления, управление состоянием, инкапсуляция стилей, асинхронность, модульность и так далее. Только посмотрите как далеко ушли инструменты разработки в браузере! С точки зрения Developer Experience фронтенд развился очень сильно: от alert() и console.log до дебагера который умеет отлаживать асинхронные вызовы сохраняя весь стек. От script.js со всеми скриптами в одной куче до асинхронной подгрузки модулей по мере надобности. Современному фронтендеру нужно держать минимум информации в голове при разработке, за него это уже всё делают автоматизированные системы (линтеры, тесты, сборка, CI) и инкапсуляция. С этой точки зрения разработка стала даже проще.
А вот что усложнилось так это инструменты под капотом. Ты можешь поставить Parcel, собрать проект в одну команду и вообще не задумываться о том как оно работает. А если захочешь разобраться как работает каждый этап то увидишь насколько там всё сложно и тяжело для понимания.
Выше правильно отметили об избытке инструментов в современном фронтенде, даже был в своё время такой термин как Javascript Fatigue. Но этот период уже скорее прошёл, среди всех инструментов появились явные лидеры и выбирать приходится не из 10-25 вариантов, а из 3-4. При этом у вас всегда есть возможность попробовать что-то новое, даже если не на проекте, то для личного развития.
Так же сильно повысились требования к фронтенду, а соответственно и к фронтенд-разработчикам. Недостаточно просто знать HTML, CSS и JS, нужно разбираться в смежных областях, в инструментах, уметь писать тесты. Это новые ответственности фронтендера, про которые можно сказать что они усложнили саму сферу фронтенда. Но абсолютно такие же процессы происходят и в других областях, так что это вполне закономерно.
Различие продакшн кода и исходников это самая меньшая боль во фронтенде, особенно учитывая сколько задач она решает такой малой кровью.
А вот из действительно больших нерешённых болей фронтенда я бы отметил кроссбраузерность. И это не про поддержку фичей, а про поведение браузеров. До сих пор в 2019 году вам придётся городить велосипеды для исправления поведения браузеров. Может показаться что со смертью IE и Edge эта проблема решилась, но на самом деле нет потому что появились различные мобильные браузеры которые в некоторых аспектах работают совсем иначе чем десктопные. И далеко не факт что под ваш конкретный баг есть готовое решение.
В чём проблема с тем чтобы привязать модальное окно к модулю Vuex и использовать middleware роутера?
Вешать логику роутера на модальное окно — это грубое наршение SRP. Появилась ненужная связь модального окна и роутера, такой код будет невозможно поддерживать.
Использование Vuex избавит вас от глобальных переменных и позволит более гибко контролировать поведение модального окна.
Вам правильно подсказали что такой подход будет перезагружать страницу. У вас на начальной странице ничего нет. Попробуйте добавить туда что-нибудь и увидите как при каждом закрытии окна весь контент рендрится заново. (пример: https://jsfiddle.net/uyqmL7ro/)
Только не Ростелеком закупил, а абоненты Ростелекома проспонсировали покупку оборудования. Был тариф 330 рублей, стал 450. При чём повышают тихо, о повышениях можно узнать только в дебрях новостей регионального сайта.
С ужасом обнаружил что вы тот же самый автор что год назад писал крутые статьи про фронт в Яндекс.Деньгах. Эх, грёбаный фронтенд, что ж ты с людьми-то творишь!
То что у Babel есть preset-env совершенно не означает что он делает тоже самое что postcss-preset-env. Как раз в бабеле полифилятся полностью готовые спецификации, см. https://new.babeljs.io/docs/en/next/babel-preset-env.html
Это похоже скорее на autoprefixer, чем на preset-env.
И бабель уже проходил путь preset-stage-0, что-то похожее на то что в PostCSS, только в postcss-preset-env ситуация ещё хуже потому что смешались все стейджи: 0, 1, 2, 3. И вот к чему это привело у бабеля: https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
А каким образом postcss-preset-env решает эту проблему? Какая разница как подключен плагин который не полифилится в конкретном браузере? Вы и в сборке и по отдельности получите эту проблему.
Здесь нет логической связи, если плагин работает некорректно его нужно починить, а наличие этих плагинов в одном пакете усложняет этот процесс. Допустим нужно откатиться на старую версию плагина которая работала корректно, при этом остальные плагины должны быть на последней версии потому что там добавились какие-то фишки или фиксы, и это превращается в очень нетривиальную задачу.
Если на проектах каждый добавляет что-то от себя вы в любом случае придёте к ситуации когда объём зависимостей будет выглядеть как зоопарк. Только на одной чаше весов у вас контролируемый и чёткий список зависимостей, а на другой чёрная коробка, в которой может быть что угодно. По-моему между очевидным и неочевидным выбора не стоит. Я не очень понимаю аргумент с «каждый раз вникать», ведь чтобы работать с post-css-env вам нужно сначала вникнуть во все плагины которые там есть, что по мыслительной нагрузке будет всегда больше чем разбираться в отдельных плагинах.
Представьте что человек написал код на stage 0 и ни кому об этом не сказал (а код-ревью вёрстки это скорее исключение чем правило), вы это никак не проконтролируете с таким плагином и люди будут так писать потому что это просто. Всё-таки когда вам нужно приложить некоторые усилия чтобы писать на stage 0 это очень мотивирует несколько раз подумать а нужно ли оно вообще и можно ли решить эту проблему как-то иначе. Если мы говорим про хорошие практики то все они строятся именно на том чтобы максимально уменьшить возможность сделать плохо для проекта\команды. И в данном случае post-css-env является очень плохой практикой, которая по факту развязывает руки для давнокода.
Так же стоит отметить что post-css-env всего лишь агрегатор плагинов. Если у вас поломался какой-то из этих плагинов вам придётся ждать когда фикс добавят в post-css-env (или форкать и фиксить самому), вместо того чтобы обновить плагин отдельно.
Пожалуйста, прежде чем добавлять к себе Postcss-preset-env прочитайте что именно он за собой тянет. Вашему проекту совсем не обязательно нужно применять столько трансформаций при каждой сборке. Вполне возможно что будет достаточно взять 1-2 плагина из этой сборки и подключить их отдельно. Это будет так же наглядно отражать какие конкретно зависимости есть в вашем проекте, вместо одной зависимости на всё.
Первый совет не просто самый сложный, но ещё и самый вредный, потому что добавление ключевого слова functional в ваш шаблон несёт за собой очень много побочных эффектов, о которых вы можете даже и не догадываться.
Например, вы полностью лишаетесь автоматического пробрасывания атрибутов в рутовый элемент и эту логику вам придётся реализовывать самому. Простого
v-bind="$attrs"здесь не хватит, потому что у Vue есть два типа классов в data:classиstaticClass, оба из которых нужно прокидывать. Так же вы лишены возможности использовать другие компоненты внутри функционального компонента как раньше, для этого вам придётся использовать пропы или inject с дефолтными значениями.Для таких компонентов как в первом примере, который просто отображает данные из пропов я бы посоветовал использовать
v-once, если вы на все 100% уверены что этот компонент не будет изменяться.С приходом Vue 3 нам обещают оверхед stateful компонентов на уровне функциональных, а писать функциональные компоненты, чтобы потом от них избавляться это очень дорого. Поэтому применяйте их только в тех случаях когда у вас рендерятся сотни и тысячи таких компонентов, в таком случае выигрыш по производительности обоснует поддержку этого кода.
Вот сейчас обидно было
...
Зато можно будет посмотреть на работу машины времени и пожить в России 90-х годов!
www.izotope.com/en/products/repair-and-edit/rx/features-and-comparison/music-rebalance.html.html