Да. Но заметьте, что в центре факт собственно смерти, а не «зависимости от работы». Вот если б они пахали и при этом не помирали — всё было бы идеально.
Очень серьезная. А вот если заменить слово «игра» на слово «работа», не меняя остальной текст — проблема внезапно превращается в идеальное гражданское поведение. Особенно если означенный гражданин еще и из-за «негативных последствий» до пенсии помрёт.
Ну вот и замечательно. А теперь скажите, почему тот фактик, что у нас разные игроки в страйкбол и прочая некоторая молодежь внезапно оказывается под арестом и немедленно выступает с чистосердечными признаниями во всем, в чем их обвиняют — вас совсем не беспокоит, и вы за то, чтоб еще и переписку читали, а вот что там в Штатах происходит — очень беспокоит?
Ну то есть на самом деле никакого не имеет, как правильно сказали.
Реактивное программирование можно довольно скромными усилиями хоть на голом JS поднять. Означает ли это, что JS имеет «кое-какое» отношение к реактивному программированию? Нет.
Нисколько не в защиту Яндекса, ибо сам эту контору не люблю, но…
У вас в мобильной версии
Ну вы уже должны были сами всё понять.
Мобильная версия сама по себе не взлетит. Не взлетит она и с реактами-редуксами и прочими умными словами. Мобильная версия — это по прежнему такое особое чудо, которое надо допиливать и тестировать отдельно.
И не смотря на всё это — это лучше, чем было раньше, когда мобиловерсия сайта сжирала столько же, или даже больше сил, чем обычная.
Это вы еще не слышали, на каком языке геймеры разговаривают :-)
Но да, в той статье всё хорошо написано. И, на самом деле, этот микс из фреймворков, пакетов, фич, и прочей лабуды — он не настолько страшен, как издалека кажется. Умных слов много, а принципов работы этого куда меньше. С некоторыми вещами можно разбираться и подольше, как с теми же модулями, но во многие — нет необходимости погружаться дальше одного предложения. То есть, например, «транспайлер — это то, что переделывает не работающий в браузере JS (или TS, не суть) в работающий». Всё. Научно там разжевывать можно долго, но это всё будет про шашечки, а не про ехать.
Тот, который хочет работодатель, ищущий фронтэндеров за хорошие деньги, разумеется.
Если говорить про вотпрямщас, то это скорее всего будет один из троицы Vue, Angular2 (то есть 2+), React. Но важно понимать, что через годик эта троица может уже выглядеть как-то иначе, а через пару лет — почти наверняка.
но прям чувствую боль, когда пытаюсь понять, а чем же новым пользоваться, чтобы быстрее, лучше и без рефреша
Ну, добро пожаловать в наш мир. Чувствовать боль в таких случаях — это как раз нормально.
На моей практике вообще никогда не существовало ситуаций, когда можно было откинуться в кресле, ткнуть пальцем в технологию из некоего заготовленного списка максимально подходящих, и не поиметь проблем, сразу или же (еще больнее) потом.
Это уж не говоря про то, что еще и при самом составлении списка происходит огромное количество страданий.
Пока что максимально великое откровение, которое я тут знаю — это «Никто в мире не знает, как решать конкретно твои проблемы. Даже если они довольно типичные. А уж если нетипичные, то тем более». Поэтому без боли и необходимости думать самому по каждому конкретному случаю — не выходит.
ЗЫ: Ну а если сказать более практично, то с php+jquery можно нынче куда угодно двигаться. Можно уменьшать серверную часть. Можно съехать с jquery в сторону уменьшения императивности. Можно и не делать этого (мне, например, императивный js очень нравится, и от попыток присобачить туда декларативности побольше я всегда вижу больше проблем, чем пользы). Можно смотреть в направлении модульности — даже я бы сказал нужно, если вдруг вы пока этим не озадачивались. Модульность из js уже точно никуда не денется, возможно она будет не совсем такая, как нынешние RequireJS, CommonJS, итд, но какая-то подобная будет в любом случае. Можно смотреть на разделение функциональных стилей и look&feel — этого вообще до сих пор в мире никто не смог сделать так, чтоб всем понравилось (спасибо примитивности css). Короче, тысячи путей, и это помимо предложений «изучите фреймворк Х, авось вам понравится».
Все жизненные истории по переходу с одной парадигмы кода на другую всегда такие одинаково-меланхолические :-)
Оказалось, что когда переводишь проект с одного фреймворка на другой, ты не просто переносишь код. Приходится анализировать и улучшать архитектуру приложения, выпрямлять логику, рефакторить.
Это всё не зависит от переносов между фреймворками. Разве что при переносе что-то просто таки придётся выпрямлять, в то время как без переносов оно может жить годами без модификаций (а может и не жить, если есть кому бороться за улучшение кода).
Не понимала, зачем изучать первый Angular, чтобы завтра забыть о нем и изучать второй. Не понимала, зачем менять jQuery.Ajax на Fetch, чтобы заменить потом Fetch на Axios.
И в силу вышесказанного, не понимать вот тут — это как раз нормально. Не надо изучать первый ангуляр, если переезд всё равно будет только на второй. С принципами ознакомиться — да, стоит. Изучать? Ну такое.
Переносы сами по себе имеют вполне выразимую стоимость (стоимость всех человеко-часов программистов, стоимость повторного QA, и так далее), и не всегда она как-то даже рядом стоит с выигрышами от улучшения кода, особенно с учётом того, что улучшение кода можно отлично проводить и без переносов.
Но когда потенциальные выигрыши таки значительны — там да, взяли и понесли.
И да, раз уж вы склоняетесь к тому, чтоб реагировать только на сомнительные аргументы в ваш адрес, а остальное игнорировать — распишу свою позицию поподробнее (вдруг там что-то сомнительное найдется, для обсуждения).
У проблемы терроризма есть два самых важных аспекта: экономический и социальный.
1. Экономически, потери от терроризма при наличии адекватного противодействия (без необходимости знать о вас всё и читать любую вашу переписку) эквивалентны потерям на авиатранспорте. Самолёты иногда разбиваются, террористы иногда народ убивают и собственность крушат. В пересчете на деньги — явления примерно одного порядка. Причем это даже если честно посчитать локальные экстремумы а-ля 9/11. Всё равно одного порядка.
Соответственно, нет никаких причин противодействовать терроризму как-то «более особо», чем по примерно схожим принципам, какие работают в авиации. Тут можно возразить, что авиация использует принцип выяснения происшедшего и устранения недостатков, к этому приведших, а потому если выясняется, что теракт можно было предотвратить чтением переписки — то теперь нужно читать переписку. Но не следует забывать, что «недостатки социума» (например, страшно мешающее желание людей что-нибудь да скрыть от товарища майора), точно так же, как и недостатки технические и эксплуатационные — имеют определенную исчислимую стоимость устранения. И если цена мелких доработок систем самолёта по сравнению с ценой нескольких разбившихся самолётов вместе со всем содержимым — это штуки весьма разные, то вот цена дополнительных систем для контроля и наблюдения за обществом может быть очень и очень большой. Причем, в эту цену будет входить не только стоимость самой системы, но и цена потерь от работы этой системы — и общество, и государство, и государственные институты — не идеальны и имеют системные пороки (коррупция, злоупотребление полномочиями, и так далее). И, например, возвращаясь конкретно к России, если вы вдруг решили поиграть в страйкбол или обсудить политику в кругу знакомых, а потом как-то «вдруг» случайно сидите уже какой месяц под арестом с периодическим развлечением пытками — это всё тоже относится к цене, которая была заплачена за то, что раз в N лет несколько десятков человек наверное не помрут от очередного террориста.
2. Социально, терроризм эксплуатирует общественный страх быть внезапно убитым для получения неких плюшек (привлечения внимания, и так далее). Примерно как действуют напуганные кошки — топорщат шерсть и стараются выглядеть больше и страшнее, чем на самом деле. Это декларирование действиями заявлений а-ля «посмотрите, какие мы страшные, и дайте нам что-нибудь за это». Ровно ту же самую декларацию вам приводят и службы, стремящиеся вас от этого защищать — «смотрите, какие страшные террористы, и дайте нам что-нибудь за то, что мы вас от них защитим». Слабые места у этой декларации ровно те же, что и у изначальной — это попытка раздуть проблему больше, чем она есть на самом деле.
если отказываться от всех методов, которые могут иногда помочь преступника поймать, а иногда не могут — так вообще окажется, что ничего делать не нужно
Демагогия, slippery slope, и другие прекрасности. Скажите, вы уже переехали в стеклянный дом? Почему нет? Это поможет иногда вас поймать, если вы вдруг задумаете что-то недоброе.
Как-то обновлять это — легче переписать с самого начала.
Я по долгу службы работаю с проектом, который начинался в 2002 году.
Нормально там всё обновляется. Можно даже (если б это было реально надо) поэтапно перетащить в современную среду и разбить на модули, несмотря на то, что проект сильно большой.
Ну так такова жизнь. В этом смысле никаких отличий от технологий бекэнда, где всей суммы фич вы скорее всего никогда в жизни не будете использовать, но на собеседовании может всегда попасться тот, кто считает фичу Х прекрасной и будет о ней дотошно спрашивать, а вы про фичу Х смутно читали что-то в книжке 10 лет назад, и всё.
Освоиться с промисами, с теорией и практикой — вопрос даже не одного дня, а нескольких часов. О чем и речь, мелкие надстройки — это не та штука, в которую нужно долго и последовательно вникать.
А это собственно зависит от вопроса «что вообще нужно делать при билде нашего проекта». Есть простые вещи, которые спроектированы просто и билд у них простой и очевидный. Есть же вещи, которые надо билдить долго и мучительно. И без супер-плагинов и супер-лоадеров в сложных случаях часто попросту не обойтись.
Ну и отвечая в целом на статью — даже и «взяв мир веб-фронтэнда», один из самых (хорошо если не самый-самый вообще) бурно меняющихся — не обязательно каждый день бежать за всеми уходящими поездами одновременно.
Основа этого всего не меняется уже очень много лет — стэк из HTML+CSS+JS был и остаётся тем самым, что нужно всегда, везде, и не очень-то оно меняется. Дополнительные слои, навешиваемые сверху — новые языковые фичи (которые всего лишь «сахар»), типичная экосистема нынешних фронтэнд-проектов, модульность, транспайлеры, фреймворки, итд — это с одной стороны выглядит страшно, а с другой — всего лишь надстройка над базисом. Осваивается это за куда меньшие промежутки времени, чем базовые вещи.
И просто так «чтоб было» за это всё даже и не стоит хвататься — в силу изменчивости мира фронтэнда это всё может спокойно успеть стать неактуальным еще до того, как где-либо вам понадобится. А вещей, за которыми действительно стоит всегда пристально следить — гораздо меньше: браузеры (никогда не стоит упускать из виду, как развивается то, на чем собственно вся ваша работа отображается, даже если разработка нынче идёт по пути browser-agnostic), да стандарты w3c.
В центре внимания обычно стоит то, что пострашнее, а не причина проблем. Хорошо если одно с другим совпадает, но это бывает нечасто.
Теперь только осталось понять, какое отношение разведывательная деятельность имеет к терроризму, и вообще всё хорошо будет.
Реактивное программирование можно довольно скромными усилиями хоть на голом JS поднять. Означает ли это, что JS имеет «кое-какое» отношение к реактивному программированию? Нет.
Ну вы уже должны были сами всё понять.
Мобильная версия сама по себе не взлетит. Не взлетит она и с реактами-редуксами и прочими умными словами. Мобильная версия — это по прежнему такое особое чудо, которое надо допиливать и тестировать отдельно.
И не смотря на всё это — это лучше, чем было раньше, когда мобиловерсия сайта сжирала столько же, или даже больше сил, чем обычная.
Но да, в той статье всё хорошо написано. И, на самом деле, этот микс из фреймворков, пакетов, фич, и прочей лабуды — он не настолько страшен, как издалека кажется. Умных слов много, а принципов работы этого куда меньше. С некоторыми вещами можно разбираться и подольше, как с теми же модулями, но во многие — нет необходимости погружаться дальше одного предложения. То есть, например, «транспайлер — это то, что переделывает не работающий в браузере JS (или TS, не суть) в работающий». Всё. Научно там разжевывать можно долго, но это всё будет про шашечки, а не про ехать.
Если говорить про вотпрямщас, то это скорее всего будет один из троицы Vue, Angular2 (то есть 2+), React. Но важно понимать, что через годик эта троица может уже выглядеть как-то иначе, а через пару лет — почти наверняка.
Ну, добро пожаловать в наш мир. Чувствовать боль в таких случаях — это как раз нормально.
На моей практике вообще никогда не существовало ситуаций, когда можно было откинуться в кресле, ткнуть пальцем в технологию из некоего заготовленного списка максимально подходящих, и не поиметь проблем, сразу или же (еще больнее) потом.
Это уж не говоря про то, что еще и при самом составлении списка происходит огромное количество страданий.
Пока что максимально великое откровение, которое я тут знаю — это «Никто в мире не знает, как решать конкретно твои проблемы. Даже если они довольно типичные. А уж если нетипичные, то тем более». Поэтому без боли и необходимости думать самому по каждому конкретному случаю — не выходит.
ЗЫ: Ну а если сказать более практично, то с php+jquery можно нынче куда угодно двигаться. Можно уменьшать серверную часть. Можно съехать с jquery в сторону уменьшения императивности. Можно и не делать этого (мне, например, императивный js очень нравится, и от попыток присобачить туда декларативности побольше я всегда вижу больше проблем, чем пользы). Можно смотреть в направлении модульности — даже я бы сказал нужно, если вдруг вы пока этим не озадачивались. Модульность из js уже точно никуда не денется, возможно она будет не совсем такая, как нынешние RequireJS, CommonJS, итд, но какая-то подобная будет в любом случае. Можно смотреть на разделение функциональных стилей и look&feel — этого вообще до сих пор в мире никто не смог сделать так, чтоб всем понравилось (спасибо примитивности css). Короче, тысячи путей, и это помимо предложений «изучите фреймворк Х, авось вам понравится».
Это всё не зависит от переносов между фреймворками. Разве что при переносе что-то просто таки придётся выпрямлять, в то время как без переносов оно может жить годами без модификаций (а может и не жить, если есть кому бороться за улучшение кода).
И в силу вышесказанного, не понимать вот тут — это как раз нормально. Не надо изучать первый ангуляр, если переезд всё равно будет только на второй. С принципами ознакомиться — да, стоит. Изучать? Ну такое.
Переносы сами по себе имеют вполне выразимую стоимость (стоимость всех человеко-часов программистов, стоимость повторного QA, и так далее), и не всегда она как-то даже рядом стоит с выигрышами от улучшения кода, особенно с учётом того, что улучшение кода можно отлично проводить и без переносов.
Но когда потенциальные выигрыши таки значительны — там да, взяли и понесли.
У проблемы терроризма есть два самых важных аспекта: экономический и социальный.
1. Экономически, потери от терроризма при наличии адекватного противодействия (без необходимости знать о вас всё и читать любую вашу переписку) эквивалентны потерям на авиатранспорте. Самолёты иногда разбиваются, террористы иногда народ убивают и собственность крушат. В пересчете на деньги — явления примерно одного порядка. Причем это даже если честно посчитать локальные экстремумы а-ля 9/11. Всё равно одного порядка.
Соответственно, нет никаких причин противодействовать терроризму как-то «более особо», чем по примерно схожим принципам, какие работают в авиации. Тут можно возразить, что авиация использует принцип выяснения происшедшего и устранения недостатков, к этому приведших, а потому если выясняется, что теракт можно было предотвратить чтением переписки — то теперь нужно читать переписку. Но не следует забывать, что «недостатки социума» (например, страшно мешающее желание людей что-нибудь да скрыть от товарища майора), точно так же, как и недостатки технические и эксплуатационные — имеют определенную исчислимую стоимость устранения. И если цена мелких доработок систем самолёта по сравнению с ценой нескольких разбившихся самолётов вместе со всем содержимым — это штуки весьма разные, то вот цена дополнительных систем для контроля и наблюдения за обществом может быть очень и очень большой. Причем, в эту цену будет входить не только стоимость самой системы, но и цена потерь от работы этой системы — и общество, и государство, и государственные институты — не идеальны и имеют системные пороки (коррупция, злоупотребление полномочиями, и так далее). И, например, возвращаясь конкретно к России, если вы вдруг решили поиграть в страйкбол или обсудить политику в кругу знакомых, а потом как-то «вдруг» случайно сидите уже какой месяц под арестом с периодическим развлечением пытками — это всё тоже относится к цене, которая была заплачена за то, что раз в N лет несколько десятков человек наверное не помрут от очередного террориста.
2. Социально, терроризм эксплуатирует общественный страх быть внезапно убитым для получения неких плюшек (привлечения внимания, и так далее). Примерно как действуют напуганные кошки — топорщат шерсть и стараются выглядеть больше и страшнее, чем на самом деле. Это декларирование действиями заявлений а-ля «посмотрите, какие мы страшные, и дайте нам что-нибудь за это». Ровно ту же самую декларацию вам приводят и службы, стремящиеся вас от этого защищать — «смотрите, какие страшные террористы, и дайте нам что-нибудь за то, что мы вас от них защитим». Слабые места у этой декларации ровно те же, что и у изначальной — это попытка раздуть проблему больше, чем она есть на самом деле.
Демагогия, slippery slope, и другие прекрасности. Скажите, вы уже переехали в стеклянный дом? Почему нет? Это поможет иногда вас поймать, если вы вдруг задумаете что-то недоброе.
Я по долгу службы работаю с проектом, который начинался в 2002 году.
Нормально там всё обновляется. Можно даже (если б это было реально надо) поэтапно перетащить в современную среду и разбить на модули, несмотря на то, что проект сильно большой.
Вам следовало бы уже очень давно понять, что в подобных обсуждениях и мерах слово «террористы» является не подлежащим, а предлогом ;-)
Основа этого всего не меняется уже очень много лет — стэк из HTML+CSS+JS был и остаётся тем самым, что нужно всегда, везде, и не очень-то оно меняется. Дополнительные слои, навешиваемые сверху — новые языковые фичи (которые всего лишь «сахар»), типичная экосистема нынешних фронтэнд-проектов, модульность, транспайлеры, фреймворки, итд — это с одной стороны выглядит страшно, а с другой — всего лишь надстройка над базисом. Осваивается это за куда меньшие промежутки времени, чем базовые вещи.
И просто так «чтоб было» за это всё даже и не стоит хвататься — в силу изменчивости мира фронтэнда это всё может спокойно успеть стать неактуальным еще до того, как где-либо вам понадобится. А вещей, за которыми действительно стоит всегда пристально следить — гораздо меньше: браузеры (никогда не стоит упускать из виду, как развивается то, на чем собственно вся ваша работа отображается, даже если разработка нынче идёт по пути browser-agnostic), да стандарты w3c.