It’s the future

https://medium.com/@boopathi/it-s-the-future-7a4207e028c2#.17wj893dh
  • Перевод

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog


— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.


— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.


— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?


— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.


— Окей, лады. А что это?


— React это новый способ разработки веб-приложений. Оно базируется на Virtual DOM и позволяет писать JSX-код.


— Virtual-что? JSX? Что это за..?


— JSX — это HTML на стероидах. Это расширенная версия JavaScript, где вы смешиваете XML и JS в одном коде. VirtualDOM означает, что у тебя есть дерево объектов представляющих часть реального DOM, и оно дает возможность манипулировать им очень быстро без необходимости работать с DOM напрямую.


— Зачем смешивать XML и JS?


— Ну как зачем. Реакт это будущее. Он позволяет создавать переиспользуемые компоненты.


— Типа как в Backbone, да?


— Нет. Бэкбон мёртв. Щас теперь все будет на компонентах.


— Ну так мне не нужно заморачиваться про JSX или VirtualDOM?


— Неа. Но неплохо бы понимать как они работают, чтобы ты мог не думать о том, что у тебя что-то где-то тормозит, и оптимизировать код там, где это реально имеет смысл — типа состояния компонента.


— Окееей, я начинаю слегка теряться. Итак, у нас есть некая шняга для написания компонентов, называется React. Могу я использовать её с JQuery?


— Ну, ты можешь написать одну часть приложения на React, а другую на чём захочешь. Но я ж говорю тебе — JQuery мёртв. Кстати, тебе стоит обратить внимание на Webpack, чтобы склеивать компоненты вместе при сборке.


— ОК. Что это такое?


— Это бандлер модулей. Ты пишешь кучу файлов, как если бы это были модули Node — и затем комбинируешь их в один монолитный файл (или разбитый на части) для отправки клиенту. Тебе даже не понадобятся react-tools, можешь обойтись одним Babel для компиляции JSX.


— Babel?


— Ага, Babel. Это клевая хрень, которая транспилирует твой ES6+/JSX код в читабельный ES5 код, с поддержкой sourcemaps. Это широко распространено, даже в Фейсбуке это используют.


— ES6+?


— ES6/ES2015 это следующая версия ECMAScript, там очень много новых фич, типа классов, стрелочных функций, Maps, Sets и так далее… Щас почти все юзают ES6+.


— Это настолько хорошая вещь?


— Спрашиваешь! ES6+ + транспиляция это будущее.


— Ну ладно. Как мне это заюзать?


— Начни с установки Node...


— Установить Node? О, нет. Ты ведь говорил что-то про React и компоненты.


— Ну да. Дальше ты берешь Flux архитектуру и начинаешь создавать actions, stores и компоненты.


— Flux?


— Во Flux ты выстраиваешь свое приложение как набор stores, actions и view, где данные «текут» в одном направлении. Views вызывают actions, они проходят через dispatcher, а stores подписываются на события dispatcher и выдают change events, на которые подписан view.


— Ага. Как в MVC?


— Нет. MVC мёртв. Flux это будущее. Сейчас очень много реализаций flux.


— Что? Реализаций Flux?


— Да, ведь Flux это просто паттерн. Реализаций полно: Alt, Flummox, marty, fluxxor, fluxible, и т.п… И даже есть фейсбучная реализация Dispatcher.


— Мне нужно это все использовать?


— Новичку довольно сложно закодить самому весь этот шаблонный код, поэтому возьми какую-нибудь готовую реализацию.


— Ладно. Мне бы не хотелось писать эту жесть самому.


— Я ж говорю, реализаций дофига.


— А что насчёт Angular?


— Фу.


— Фу?


— Фу.


— Смотри. Мне реально не хочется возиться с установкой, настройкой и допиливанием чего-то сложного.


— Ваще-то это легко. Существуют готовые киты/репозитории для новичков, или можешь заюзать генераторы Yeoman, которые сделают это за тебя.


— Мне нужен генератор? Yeoman? Что это еще такое?


— Он может сгенерировать код за тебя, и ты можешь заюзать его для создания нескольких приложений сразу. Используй поддержку DLL в новом Webpack, и можешь компилировать каждое приложение отдельно от других.


— У меня будет только одно приложение, одна страничка, один компонент, одно что-угодно. Только одно.


— Нет. Изучи комбинируемые компоненты. Это то, как мы делаем всё сейчас. Тебе нужно разбить всё на компоненты — по одному на каждую отдельную маленькую фигню.


— Кажется, что это избыточно.


— Это единственный способ добиться аккуратности, удобства и производительности. Ты сможешь использовать штуки вроде горячей перезагрузки (hot reload)...


— Hot Reload? Типа как livereload?


— Не. Webpack поддерживает эту замечательную фичу, она называется горячей перезагрузкой модулей, и есть плагин react-hot-loader для реакта, так что ты сможешь менять код отдельного компонента без перезагрузки всей страницы. А вместе с Flux ты сможешь делать ваще башнесрывные вещи типа прокрутки истории изменений в данных туда-обратно — одновременно с горячим редактированием кода.


— Итак. Теперь у меня десятки различных инструментов и библиотек для упаковки, сборки, транспилирования и чего угодно. Еще что-то?


— Как я уже говорил, Flux дает возможность выстраивать хорошую архитектуру приложений. Но с Observables и Immutable данными всё становится намного лучше и интереснее.


— Observable? Мне нужен Immutable?


— Тебе нужны observables чтобы удобно работать с событиями и асинхронностью, а Immutable.js нужен для персистентности, эффективности и простоты. Observables это типа как массивы, только асинхронные. Они возвращают значения с помощью async-генераторов из ES2016.


— Что за async generator?


— Ну смотри, обычный генератор дает возможность функции возвращать серию значений, а с модификатором async ты можешь возвращать значения в будущее. Правда, автор этого, Джафар Хусейн, уже отозвал свой proposal и работает с Кевином Смитом над более узкоспециализированным es-observable для ES7.


— Кхм. Я просто хочу запустить простое приложение. Насколько же глубока кроличья нора?


— Ну, ты можешь использовать RxJS, который ближе к оригинальным observable. Оно широко распространено и годится для продакшена.


— RxJS? Чем же он полезен?


— Работает с твоими уже написанными promises и событиями. Ты можешь создать Observable из любого асинхронного кода, и работать с ним как с обычным значением. Но вообще-то, если ты ищешь что-то по-настоящему реактивное и интересное, позырь фреймворк Cycle.js, разработанный Andre Staltz.


— WTF. Мне всего лишь нужно написать и запустить простое приложение. Смогу я сделать уже это или нет?


— Конечно, хотя деплоинг это отдельный интересный вопрос, но мы уже почти закончили.


— Окей, «сегодня мы многое поняли». Спасибо за объяснения.


— Отлично! Нет проблем.


— Давай я повторю тогда, чтобы мы удостоверились, что я всё правильно понял. Итак, мне нужно разбить код своего приложения на actions, stores и компоненты, выстроить однонаправленный dataflow, писать ES6+ код чтобы заиметь все последние языковые фичи, позволяющие мне писать чистый код, затем использовать Babel для транспиляции этого ES6+ кода в ES5 код, пригодный для всех браузеров, использовать webpack, чтобы склеить все части моего приложения, написанные как модули node в один файл, использовать ImmutableJS для представления моих данных и подключить RxJS для описания событий и других асинхронных функций.


— Да. Разве это не восхитительно?


— И, да, я еще кажется забыл про статику и минификацию.


— Не проблема вообще. Webpack умеет это. Все что тебе нужно, это настроить несколько загрузчиков, плагинов — и вот уже почти и всё. Ты можешь импортировать CSS и картинки. Кстати, есть еще альтернативы CSS, которые позволяют описывать стили в JS...


— Я возвращаюсь к JQuery.

Поделиться публикацией
Комментарии 287
    +7
    Согласен со всем что изложено в статье, хотя новичком я не являюсь и так или иначе использую почти все что в статье упомянуто (и даже понимаю как это все работает) — просто подстраиваюсь под требования клиентов
      +3
      Если не ошибаюсь, то уже был этот перевод на хабре.
        0
        Ну ничего страшного, статья-то замечательная :) Не грех и еще раз посмеяться. Тут как раз соседний топик «Зачем нам JQuery?», так что весьма ситуативно получилось.
          +3
          когда до сих пор работаешь с adobe flex, имеешь немаленький опыт в ооп и понимаешь, что охватить это все нереально, чтобы сменить специализацию, то становится не очень смешно.
            +1
            Очень ошибаетесь. При желании это все очень быстро учится. Главное — практика.
          +7
          Не, был перевод как-раз того, по чьим мотивам это написано. Перевод
          +1
          Это можно про почти любую технологию так написать. И в конце приписать «я возвращаюсь к программированию на ассемблере».

          Факт в том, что все упомянутые в посте вещи — это IMHO необходимый для 2016 года минимум, которым каждый сильный инженер должен если и не владеть, то хотя бы иметь представление о. Это не rocket science.
            +28
            Проблема в том, что этот минимум весь разношёрстный, выпущенный разными вендорами, каждый со своими особенностями и без какой-либо стандартизации. Плюс постоянно висящий в стадии «почти готово» (это я про RC5 для Angular 2), где каждый последующий RC не обратно совместим с предыдущим. Жесть же, менять архитектуру роутера на стадии кандидата в релиз. Она по уму и на бете то уже не меняется.
            И нельзя так написать про любую технологию, в том же C# нет такой жести, новые версии обратно совместимы с предыдущими, интерфейсы официальных компонентов пишутся по одному паттерну, есть нормальная документация. И с NuGet нет такой жести, какая бывает с Npm пакетами, где выход новой минорной версии компонента может ломать всё приложение.
              –3
              Потому что молодое еще. Не успело стандартизироваться, мало серьезных научных работ, не устаканилась даже терминология. Это еще не стало частью computer science, но станет. Так всегда бывает поначалу. Например, с promises и асинхронным программированием уже меняется дело к лучшему (см. частично https://github.com/kriskowal/gtor/blob/master/README.md).
                +19
                Молодое? JS в 1995 появился, в один год с Java и на 5 лет раньше C#.
                  +6
                  Для больших и сложных приложений его стали только в последние годы использовать. Отсюда и взрыв технологий и интереса к языку, и проблем сопутствующих. В 95 году это был просто встраиваемый скриптовый язык, по типу bash. Никто не предполагал, что это будет основой будущей «операционной системы интернета».
                    +1
                    Простите заранее за возможно некорректный вопрос, но за что минусы комментарию выше? Разве это не верная точка зрения?
                      0
                      Не совсем. Доля правды есть, но… Не совсем.
                        +11
                        Да, теперь мне сразу стало всё понятно. Спасибо!
                    +1
                    Я не совсем понял, при чем тут JS и когда он появился? Речь-то не о JS, на его месте мог бы быть любой другой язык — хоть тот же Python. В JS нет ничего принципиально отличного от других языков (ну разве что event loop, встроенный в язык, в то время как в большинстве других он идет отдельной библиотекой; плюс прототипное наследование, насчет которого даже идеологи ecmascript сдались в итоге и ввели в обиход ключевое слово class, зарезервированное, впрочем, с самого 1995-го года, потому что уже тогда что-то подозревали).

                    Речь идет о стеке приемов и технологий. Этот стек я выше имел в виду, когда говорил о том, что он войдет в будущий computer science, как 40-50 лет назад (или когда там) в него вошли алгоритмы сортировки или концепции функционального программирования, например.
                      +1
                      Насчет идеологов это вы зря. Как раз-таки многие идеологи ECMAScript против классов. К примеру, Дуглас Крокфорд вообще не использует классы (btw, благодаря нему в JS появился `Object.create`).

                      Вот список статей, обосновывающих, почему классы в ES6 это кривой костыль, создающий проблемы, а не решающий их: Not Awesome: ES6 Classes

                      Или вот: How to Use Classes and Sleep at Night
                        +2
                        IMHO классы не доделали просто (еще не доделали?). Навскидку, например, автобиндинг this для «методов», объявленных в «классе», был бы весьма кстати (чтобы можно было в том же React-е писать onClick={this._myOnclick}, по аналогии с тем, как в Python автобиндится self при взятии ссылки на метод у объекта), а его нет. Ну или поддержка синтаксиса для «декораторов», как топикстартер упоминал.

                        Другой пример: в JS в catch() у try-catch нельзя фильтровать по «типу» исключения. Всегда пишется просто catch (e). Почему? Возможно, из-за того, что до появления концепции и конструкции async-await поверх промисов мало кто исключения в JS использовал широко (в силу асинхронной природы большинства операций исключение, выброшенное в одном месте, очень сложно поймать в правильном месте). Для фронтенда это и не было особо важно: во фронтенде инвертированный поток управления, но для серверного языка ИМХО исключения очень важны и удобны! К счастью, async-await вдыхает новую жизнь в исключения в JS и их поимку — она стала предсказуемой:

                        try {
                        a = await aaa();
                        B = await bbb();
                        } catch (e) {
                        Поймали!
                        }
                          –1

                          В функциональных языках и без исключений как-то живут. А серверные языки сейчас как раз в сторону функциональщины двигаются, да и не любят там исключения в общем-то, всё чаще пишут что-то подобное (если интересно) и тихо ненавидят яву за её checked-exceptions:


                          Try<MyResult> attempt = Try.of(this::doMyWork);
                          MyResult result = attempt
                              .recover(this::tryToRecover)
                              .getOrElse(myDefaultResult);

                          Или просто сразу пишут stateless и повторяют попытку в случае исключения.


                          И таки да, вроде как вот такая конструкция будет работать в JS: onClick={::this._myOnclick}

                            0
                            И таки да, вроде как вот такая конструкция будет работать в JS: onClick={::this._myOnclick}
                            Таки нет, к сожалению — убрали её из черновиков стандарта.
                              0
                              Кто вам сказал такую глупость?
                                0

                                О, прикольно, вернули в stage 0. В какой-то момент его вообще реджектили просто.

                                  0
                                  В какой момент ::this биндит себя к функции? В момент вызова или в конструктор как-то перемещается (или какой-то кэш)? Если в момент вызова, то это проблему не решает, ибо — утечка памяти потенциальная — в доках по реакту упоминается, что надо биндить один раз в конструкторе, а не каждый раз при рендеринге.
                                    0

                                    Не совсем понял вопрос, видимо. Конструкция


                                    bla(::this.bar)

                                    превращается в


                                    bla(this.bar.bind(this));

                                    Не вижу тут потенциальных утечек (во всяком случае, таких, которые не возникли бы при любом другом прокидывании this — через ту же стрелочную функцию, например). Про реакт сказать ничего не могу — не использую его.

                                      0
                                      Через стрелочную то же самое, верно. Просто метод render(), который при вызове строит представление компонента полностью (включая вложенные компоненты), будет создавать новые функции для каждого из многочисленных событий при каждой перерисовке (что при использовании bind, что при =>). А перерисовка может происходить очень часто, так что использование памяти увеличится, а сборщик мусора будет трудиться больше и дольше.

                                      Может быть, это экономия на спичках, конечно.
                                        0
                                        Чтоб не перерисовывать часто есть различные обертки, делающие проверку аргументов и пропускающие рендер, если аргументы не менялись. Бонус immutable state.
                                          0

                                          Здесь речь идёт о том, что когда вы делаете так:


                                          render() {
                                            <Component onAction={this.handleAction.bind(this)}
                                          }

                                          , то Component при каждом рендере родителя будет получать новый обработчик onAction, а значит должен перерендерится, и так далее. Хотя, на самом деле, обработчик один и тот же, просто .bind(this) на каждый вызов возвращает новую функцию. Для решения этой проблемы и предлагается биндить заранее, можно через стрелочный синтаксис:


                                          handleAction = () => {}
                                          render() {
                                            return <Component onAction={this.handleAction}
                                          }

                                          либо декоратором (как на свойство класса, так и на весь класс).

                    +2
                    Научные работы на какие именно темы здесь нужны, по-вашему?
                      0
                      Например, реактивность (в широком смысле: React, Redux — частные случаи), асинхронное программирование в новом свете (промисы, async-await, бэтчинг), новые подходы к API (GraphQL сотоварищи). Согласен, это все более высокоуровневые вещи, нежели алгоритмы на графах или сортировки, но мне так кажется, что computer science постепенно идет в сторону усложнения концепций.
                        +2
                        Если под реактивностью вы имеете в виду FRP, то есть небольшая библиография здесь.

                        Промисы и прочие async/await давно есть во всяких сишарпах. Уже даже в C++ пришли.

                        Сколько разных публикаций по асинхронному программированию — не счесть, поковыряйте arXiv.

                        Что принципиально нового в GraphQL, я при очень быстром прочтении не понял.
                  +10
                  чтобы написать todo-list?
                    –3
                    Да
                    +7
                    > это IMHO необходимый для 2016 года минимум

                    А сколько элементов этого списка войдут в необходимый для 2017 года минимум?

                    Можно оценить, например, сравнив с необходимым для 2015 года минимумом.
                    +38
                    Да, в каждой шутке есть доля шутки.
                    Использую js с 2003 года и то что происходит сейчас во многом похоже на лютый треш :(
                      0

                      Ну, как вам сказать. Как ни крути, для серьёзного проекта приходится использовать библиотеки или фреймворки. Чтобы собрать и пожать релиз — нужен какой-то бандлер. И то и другое можно написать самому, но зачем?

                        +20
                        Я это понимаю, расстраивает только, что нет стандартов на это, которым бы все старались соответствовать. Webpack замечательная штука, но одновременно с ним появилось ещё 3 аналогичных инструмента. То же самое с фреймворками, есть AngularJs, Angular2, React и 100500 других. С надстройками над js то же самое, TypeScript, CoffeeScript,…
                        В итоге отрасль дробится на условные «цеха», где все делают одно и то же, но каждый по своему. В итоге реальным профессионалом стать проблематично, появляется новая «фишка» и всех отбрасывает на нулевой уровень. Переход разработчиков с проекта на проект затруднён, вот писал ты 2 года на React, а теперь переходишь на Angular, сколько времени понадобится на адаптацию? Грустно это.
                          +47
                          А корень проблемы — сам javascript, который кривой, косой, написанный за полтора дня на коленке и с минимальной библиотекой базовых классов. Это был отличный язык для веба в 90х и начале нулевых, когда верхом искусства был DHTML (dynamic HTML), где с помощью JS можно было показывать текущее время.
                          Все эти надстройки, описанные в статье, к сожалению, лишь костыли над кривым языком. И меня реально пугает, что его пытаются тащить во всё более серьёзные вещи, типа веб-серверов и микроконтроллеров.

                          P.S. Чтобы не было недопонимания, под кривизной JS я подразумеваю то, что он изначально разрабатывался для несложных манипуляций с пользовательским интерфейсом. Он изначально не предполагал многопоточности, серьёзных возможностей для работы с исключениями, быстродействия. Он реально был написан на коленке. Как «Ока», практически. А сейчас из него пытаются Камаз сделать.
                            –2
                            Ну вы в курсе, да, что языку уже двадцать лет, и он значительно изменился за это время? Мало ли для чего он изначально создавался? Сейчас на нём можно писать приложения любой степени сложности. И не надо рассказывать про быстродействие, 20 лет производителями браузеров были потрачены не зря, интерпретаторы заоптимизированы по самое «не могу». В первую очередь это, конечно, касается es5 (банально — нативные промисы всё еще медленней полифиллов на es5), но и es6 подтягивается.

                            И отдельно хочется прокомментировать: «Это был отличный язык для веба в 90х и начале нулевых». А сейчас для веба есть еще какой-то язык?
                              +16
                              21, если быть точным. И в чём он конкретно изменился? «use strict»; появился?
                              Сейчас на нём можно писать приложения любой степени сложности используя все те костыли, которые указаны в статье. Хотя это не верно, у JS есть принципиальные ограничение, например он не работает с файловой системой, в самом языке нет такой функциональности, она реализуется за счёт внешних модулей (например в составе NodeJs) и в принципе не реализована в среде веб-браузера. То же самое относится к хранению данных, есть внешние библиотеки, реализующие доступ к LocalStorage браузера и базе данных, но это не часть языка, это именно внешняя библиотека, которая в одних браузерах реализована, а в других нет.
                              JavaScript — это костыль на костыле, пирамида костылей. Хотите что-то реализовать — не забудьте заглянуть на http://caniuse.com чтобы проверить, где эти костыли реализованы.
                                –1

                                Приложения любой степени сложности на, например, упомянутой nodejs можно писать на нативном ES6 безо всех этих костылей. JavaScript сегодня — не только браузер. Тут уже скорее вся остальная появившаяся инфраструктура приводит к появлению костылей для того чтобы в браузере работало "как там".

                                  +6
                                  он не работает с файловой системой, в самом языке нет такой функциональности

                                  Язык и не должен работать с файловой системой сам по себе. Это задача стандартных библиотек.
                                  Сравним C#:
                                  string text = System.IO.File.ReadAllText(@"path/to/file");
                                  

                                  и JS:
                                  let text = require('fs').readFileSync('path/to/file');
                                  


                                  /offtop
                                  А вам бы действительно хотелось, чтобы JS в веб-браузере мог работать с вашей файловой системой?
                                    0
                                    Странный аргумент) У C++ также нет библиотеки для работы с фс, это не мешает ему быть одним из самых популярных языков.
                                    +7
                                    Нету сейчас другого языка для веба, к сожалению, поэтому и появляются костыли. Они реально необходимы, потому что без них нормального приложения в 2016 не напишешь. Но костыли никогда не заменят живые ноги, и мне грустно от того, что и попыток создать язык с ногами не особо заметно :(
                                      –23

                                      Всяко лучше, чем дотнет.

                                        +7
                                        Обоснуйте
                                          0
                                          Он хотел сказать «всяко лучше чем совсем без ног»
                                        +4
                                        Любой язык, которому много лет — это набор костылей. С++, стандарт которого, наверное уже перевалил за 5000 страниц, PHP, создателя которого даже за программиста не считают, Java, ставшая COBOL'ом нашего времени.
                                          –8

                                          Есть. И это Dart.

                                            +2
                                            Вряд ли он в обозримом будущем будет в рантайме браузеров.
                                              0

                                              В рантайме браузеров будет WASM.

                                                –1
                                                как я надеюсь что в рантайме браузера будет LVM
                                                  +2

                                                  logical volume manager? Второй версии, надеюсь?

                                                    +2
                                                    Черт что с моими руками, могли бы и не ехидничать
                                                    LLVM конечно же
                                              +6
                                              Дарт умер, но перед этим он успел стать джавой в её худшем проявлении. Что печально.
                                                –4
                                                Он еще возродится в google fuchsia
                                                  0
                                                  Только вот при чём тут ОС, если мы о языках?
                                                    +1
                                                    Fuchsia is reportedly written in Dart
                                                    https://en.wikipedia.org/wiki/Google_Fuchsia
                                                    А на опеннете читал, что на дарт там будет UI. Ядро на Си
                                                  0
                                                  То-то по нем в октябре будет конференция. Вы прямо цитируете пост.
                                              +23
                                              Ну вы в курсе, да, что языку уже двадцать лет, и он значительно изменился за это время?

                                              Область применения языка изменилась гораздо сильнее, чем изменились возможности языка.

                                              Вот например, одна из фундаментальных особенностей языка — нестрогая динамическая типизация. Для написания DHTML, особенно в середине девяностых, это была киллер-фича: пишем пару строчек и всё волшебным образом работает. Вполне возможно, что именно низкий порог вхождения помог JS приобрести свою популярность на ранних этапах.

                                              Пока двадцать лет веб был относительно простым и дышал романтикой юношеского максимализма, противоположная сторона IT — суровый и серьезный энтерпрайз — также развивался и накапливал опыт. Умные дяди выяснили, что статическая типизация позволяет повысить качество приложений и сократить время разработки: ошибки ловятся компилятором на ранних этапах разработки, автокомплит работает лучше, появляется простор для оптимизаций. Более того, объем кода от этого не только не раздувается, а даже наоборот — современные компиляторы типа C# \ Scala \ Rust могут в большинстве случаев вывести тип самостоятельно, лишь изредка опираясь на подсказки со стороны программиста.

                                              Седые и скучные энтерпрайзеры открыли еще несколько любопытных вещей. Например, если в языке есть средство сделать поля/методы классов приватными, у новичка или невнимательного программиста сокращается шанс случайно напортачить. Если различать и грамотно использовать структуры данных, приложение будет работать быстрее и потреблять меньше ресурсов. А с помощью многопоточности можно ускорить приложение еще сильнее.

                                              Теперь, когда к веб-приложениям предъявляются требования уровня энтерпрайза, было бы вполне логичным перенять этот опыт. Но большая часть сообщества видит в этом только ущемление собственной свободы и протестует с упорством, достойным лучшего применения. Вместо этого изобретается «свой особый путь».

                                              Нужны приватные поля? Вместо этого изобрели новый базовый тип Symbol, который сложно понять и всё равно можно обойти. Вместо потоков — веб-воркеры, без примитивов синхронизации и с урезанными возможностями взаимодействия. Вместо классического наследования — прототипное. Список можно продолжать довольно долго.

                                              Парадокс ситуации в том, что в сложившуюся таким стихийно-бунтарским образом инфраструктуру вложено так много человеко-часов, что признать ее ошибки слишком досадно, а пытаться их исправить — слишком сложно. Однако жить как-то надо, поэтому народ пользуется, и сил вкладывается еще больше.

                                              Сейчас на нём можно писать приложения любой степени сложности.

                                              Можно, но при этом приходится изобретать решения для проблем, которых вообще не должно было возникнуть. Например, как сделать словарь, ключи которого являются объектами? Очевидного способа нет, можно попробовать несколько экстравагантных, каждый со своими особенностями и ограничениями? А если нужно получить слабую ссылку? Увы, никак — есть WeakMap, но он работает немного по-другому.

                                              Особенно иронично, что некоторые типично динамические трюки в JS сделать сложнее, чем в языках, обычно считающихся статически типизированными. Например, как перехватить обращение к любому полю и получить название этого поля в виде строки? В ES6 для этого будет новый класс Proxy, который пока не везде поддерживается и с горем пополам полифиллится. В это же время аналогичный функционал в C# был доступен еще в 2010 году.

                                              20 лет производителями браузеров были потрачены не зря, интерпретаторы заоптимизированы по самое «не могу»

                                              Двадцать лет были потрачены как раз-таки зря: пришлось придумывать решения для проблем, которые в статически типизированных языках вообще не существуют. Результат, безусловно, похвальный — но у пользователя по-прежнему масса возможностей написать код так, чтобы сломать оптимизации.
                                                +3
                                                Нужны приватные поля? Вместо этого изобрели новый базовый тип Symbol, который сложно понять и всё равно можно обойти. Вместо потоков — веб-воркеры, без примитивов синхронизации и с урезанными возможностями взаимодействия. Вместо классического наследования — прототипное.

                                                Тут я с вами очень сильно не соглашусь. Прототипное наследование намного мощнее вашего так называемого «классического». Классы это новая (лишняя) сущность по отношению к объектам — это blueprint'ы объектов — тогда как прототипы придерживаются самого настоящего классического ООП принципа «всё есть объект»: наши прототипы это тоже объекты. То есть, прототипное наследование на деле куда более «классическое», оно проще, оно фундаментальнее. Оно объектное.


                                                Символы точно так же куда более общая концепция, чем приватные поля. Приватные поля — это атрибут «классов», они не имеют смысла в рамках модели, в которой классов нет (в JS классы это лишь сахар для настоящих объектных прототипов — для тех несчастных, кто не освоил их — чтобы сгладить переход из других языков).


                                                Например, символы позволяют делать свойства без строкового имени вообще (анонимные), исключая конфликты с существующими полями:


                                                field = Symbol () 
                                                obj[field] = ...

                                                Что позволяет расширять объекты мета-информацией, доступной только тем, кто в ней заинтересован, не вступающей в конфликт с чем-то еще. Скажем, вместо метода .toString () у объектов, процедуры распечатки объектов могли бы экспортировать соответствующий символ. Вот как это сделано в библиотеке string.ify например:


                                                Boolean.prototype[Symbol.for ('String.ify')] = function () {
                                                                                                   return this ? 'yes' : 'no' }
                                                
                                                String.ify ({ a: { b: true }, c: false })
                                                //         '{ a: { b: yes }, c: no }'
                                                  +4
                                                  Оно-то мощное, но в нём напрочь отсутствует такая удобная штука, упрощающая понимание кода и обнаружение ошибок, как типизация.
                                                  Мы говорим «класс» — подразумеваем «тип», т.к. объявление классов и интерфейсов — это по сути объявление типа.
                                                  Когда тип объявлен, мы можем указать, что вот эти переменные содержат объекты именно данного типа. Мы можем выполнить что-то вроде isInstance(), тем самым быстро проверив, содержит ли переданный нам объект нужный набор методов и свойств. У нас упрощается генерация документации, ведь мы можем указывать тип и пользоваться инструментами вроде jsdoc.
                                                  С нашим кодом становится гораздо проще работать статическим анализаторам и IDE, тогда как в случае использования прототипов для чего-то кроме эмуляции классов даже WebStorm от JetBrains начинает путаться, выводя неверные подсказки.
                                                  В общем, для крупных проектов отсутствие простого способа указания типов очень неудобно.
                                                    –3

                                                    Посмотрите в сторону Flow.

                                                    +8
                                                    Прототипное наследование намного мощнее вашего так называемого «классического».

                                                    В этом и суть проблемы: хорошо в теории, плохо на практике. «Классическое» наследование близко к железу — можно определить адрес каждого поля на этапе компиляции и потом пользоваться очень быстрыми операциями доступа к памяти по смещению.

                                                    Прототипное же наследование предполагает, что пользователь может в любой момент творить грязные трюки, расширяя прототипы или вообще подменяя их. Несмотря на то, что большинство пользователей в здравом уме этого не делает, компилятор по стандарту все равно вынужден обмазывать всё бесконечными проверками и инлайн-кешами. Приходится делать выбор между сложностью устройства компилятора, расходом памяти и производительностью. И кому нужна эта «мощь» такой ценой?

                                                    Хорошая аналогия — рекурсия в ФП. Отличная математическая концепция, хорошо позволяющая описать любое циклическое вычисление. По факту же, в компиляторе без tail call optimization пользоваться ей опасно.

                                                    Cимволы позволяют делать свойства без строкового имени вообще (анонимные), исключая конфликты с существующими полями

                                                    Сначала поставили прототипное наследование во главу угла, а теперь героически решаем возникшие проблемы с помощью символов.

                                                    Что позволяет расширять объекты мета-информацией, доступной только тем, кто в ней заинтересован

                                                    Для собственных объектов в «классическом» наследовании то же самое можно сделать с помощью интерфейсов, и даже больше — явная реализация интерфейса позволяет объекту иметь даже несколько методов с одинаковым названием, и они не будут пересекаться. Символы же всё равно упираются в строки, и точно так же можно получить коллизии, потому что Symbol.for("a") === Symbol.for("a").

                                                    Для чужих же объектов такое вообще лучше не делать, потому что прототипы глобальны и изменение может иметь непредвиденные последствия в других модулях. Именно по этой причине prototype.js так быстро попал в ранг антипаттернов.
                                                      0
                                                      Символы же всё равно упираются в строки

                                                      Они не обязаны в них упираться. Вы можете сделать так (делая отсылку к моему предыдущему примеру):


                                                      mycoollib.ToString = Symbol ()
                                                      
                                                      ...
                                                      
                                                      Boolean.prototype[mycoollib.ToString] = function () { ... }

                                                      И никаких коллизий.

                                                    +1
                                                    >Умные дяди выяснили, что статическая типизация позволяет повысить качество приложений и сократить время разработки
                                                    Это, мягко говоря, неправда. Например, вот.

                                                    >Вместо этого
                                                    >Вместо этого
                                                    >Вместо этого
                                                    >Вместо
                                                    Парадокс ситуации в том, что вы по какой-то причине считаете, что есть только один правильный путь, в то время как это не так.

                                                    >Например, как сделать словарь, ключи которого являются объектами?
                                                    Map же.

                                                    >Увы, никак — есть WeakMap, но он работает немного по-другому.
                                                    А вы думали, что наличие «Weak» в слове «WeakMap» имеет какое-то отношение к «получению слабых ссылок»? Ведь есть же спецификация, ну.

                                                    >будет новый класс Proxy
                                                    И это нормально. Когда-то и в C# такой возможности не было — сами же это говорите. То, что сейчас происходит с JS — это восхитительно. Буквально на наших глазах язык превращается из сугубо нишевого в, так сказать, настоящий. Взрослеет, растет. Особенности его применения (многочисленные вендоры браузеров, в частности) этот рост затрудняют, и это понятно. Но растет же!

                                                    >по-прежнему масса возможностей написать код так, чтобы сломать оптимизации.
                                                    Это только в JS так?

                                                    Если позволите, я и на другой комментарий отвечу.
                                                    >хорошо в теории, плохо на практике
                                                    Почему? Кстати, вы почему-то в этом комментарии раз 5 упоминаете компиляцию. Какое она имеет отношение к JS?

                                                    > творить грязные трюки
                                                    Почему вы считаете это грязными трюками? Вот это прям особенно интересно.

                                                    >Symbol.for(«a») === Symbol.for(«a»).
                                                    Это касается только символов в глобальном реестре.
                                                      +4
                                                      Это, мягко говоря, неправда.

                                                      Соглашусь, это спорный момент. Мнения на этот счет есть разные. Однако я еще не видел, чтобы на динамически типизированных языках писали приложения, к которым предъявляются особые требования к надёжности (банковское ПО, бортовые компьютеры, и т.д.)

                                                      есть только один правильный путь, в то время как это не так.

                                                      Уже описал в предыдущем комментарии. Прототипное наследование требует либо жирной прослойки в рантайме, либо безумно сложной реализации VM. Как следствие, языков с прототипным наследованием гораздо меньше, чем с «классическим» — кроме EcmaScript, Lua и LISP я других толком не знаю.

                                                      Это только в JS так?

                                                      Статически типизированный язык имеет больше ограничений, поэтому больше гарантий. На основании них можно выполнять массу оптимизаций, недоступных динамически типизированным языкам. Запутать компилятор можно в любом случае, но для этого потребуется сильно больше кода и есть шанс, что программист подумает — «как-то слишком сложно получается, возможно я делаю что-то не так?».

                                                      Кстати, вы почему-то в этом комментарии раз 5 упоминаете компиляцию. Какое она имеет отношение к JS?

                                                      JIT.

                                                      Почему вы считаете это грязными трюками?

                                                      Расширять прототипы встроенных объектов опасно по причине возможных конфликтов. Методы-расширения решают проблему, но в JS их невозможно реализовать по причине динамической типизации. Что же касается подмены прототипа, то тут сам Брендан Эйк признается, что идея была отстойная.

                                                      Если вы делаете крупный продукт, и особенно если отвечаете головой за его качество — избегать операций с потенциально неизвестными побочными действиями вполне логично. Я знаю только два варианта, когда это может быть оправдано — дебаг и написание самомодифицирующегося кода.

                                                      Это касается только символов в глобальном реестре.

                                                      Виноват. Действительно, это верно только для символов, полученных через Symbol.for. Но тогда становится еще страннее: если Symbol придуман как раз для того, чтобы к данным мог получить доступ только тот, для кого они предназначены, зачем сразу же закладывать дыру в абстракции, создавая глобальный реестр символов и Object.getOwnPropertySymbols?
                                                        +2

                                                        Object.getOwnPropertySymbols нужен, чтобы можно было склонировать объект. Например если вы миксины делаете, без этого никак. Или для отладки, чтобы например в консоли было видно, че там за символы у объекта. Дырой было бы, если бы эту информацию нельзя было бы получить — это как раз разрушило бы консистентность.


                                                        данным мог получить доступ только тот, для кого они предназначены

                                                        Это так и есть. Ведь если у вас нет ссылки на символ (и он безымянный, не через реестр), то вы не можете никакой осмысленный доступ к свойству такому получить. Это как квантовая информация, она вроде бы есть, а вроде бы и нет. Но её можно скопировать, вот за этим и нужно.

                                                  –4

                                                  Вы из тех, кто не осилил прототипы и замыкания?

                                                    0
                                                    Вы из тех, кто не осилил строгую типизацию?

                                                    (а что, собственно, нужно «осиливать» в прототипах и замыканиях?)
                                                +8

                                                Ну да, в 2003, когда json, xhr и инлайн-блоки умели не все браузеры, трэша в js не было.


                                                  +2
                                                  Был конечно, как его могло не быть в языке, который написан за полтора дня на коленке?
                                                    0

                                                    Да не в этом дело, платформ разных сравнительно много и договориться сложно (особенно когда договариваться не хотят). Даже в одной компании это уже проблема, а тут… Язык как язык, проблема не в языке, а в способе его развития. Я уверен, был бы вместо js — python, было бы так же: у кого-то второй, у кого-то третий, у кого-то второй но кастрированный, и стандартная библиотека "почти совместимая но есть нюанс".

                                                      +9
                                                      Вот не уверен я, честно говоря. В языке программирования должна быть стройность и логичность, «внутренняя красота», если можно так сказать. Начиная использовать какую-то новую функциональность языка, в хорошем языке интуитивно понимаешь, что тебя ждёт: как примерно реализован интерфейс, какие методы потокобезопасны, какие нет, как будет проходить обработка ошибок и т.д.
                                                      В javascript этого нет и никогда не было. Те же == и ===, null и undefined, родовая травма в виде isNan. Чтобы на нём писать, его надо заучивать, реально. Нужно помнить, что при == будет приведение типов, а при === не будет. Нужно помнить, что в объекте error есть свойство message, которое хранит сообщение об ошибке. Нужно помнить, что проверять есть ли свойство нужно через if(foo.bar), потому что сравнения с null или undefined будет недостаточно. На том же хабре полно статей о подводных камнях js.
                                                        –11
                                                        Минус вам, слишком много хотите от мира.
                                                          0

                                                          Я немного не о том. Да, язык странный, но почему он такой? Потому что его нельзя нормально развивать: вот предлагаете вы фичу, гугл говорит "пшёл нафиг, у нас свой язык", ms говорит то же самое гуглу, apple тоже пилит что-то своё. Договориться в условиях жёсткой конкуренции не поулчится, поэтому мы имеем такой странный язык.
                                                          2016 год. Вендоры собрались и поняли, что договориться и развить общий язык не получится в принципе, подход "вшивать язык в бразуер" для больших приложений не работает, разработчики почему-то в экосистему пользователей загонять не хотят, а начинают писать транспайлеры, чтобы оно работало везде и у всех, хотя это и не так удобно разрабатывать.
                                                          Поэтому решили сделать webassembly (и houindi), который теоретически должен решить проблемы языка в рантайме, и это на самом деле очень круто. На чём хочешь, на том и пиши, только скомпилируй вот в этот формат. Кто первый сделает юзабельный фреймворк, работающий одинаково хорошо в браузерах и десктопе, получит конфетку. Когда это будет — интересный вопрос, наверное даже не в 2017.

                                                            +1
                                                            Скорее всего и здесь не договорятся. В итоге получится пачка принципиально разных реализаций байт-кода.
                                                            А сервер, предварительно определив user-agent, должен будет выдавать откомпилированную сборку сайта под конкретный браузер.
                                                              0

                                                              Ну, из того что есть сейчас — формат байт-кода стандартизован, спека есть, все (!) вендоры в процессе имплементации, пока хорошо.

                                                            +2
                                                            > if(foo.bar)
                                                            Нет, так нельзя проверять, есть ли свойство. Сдается мне, что не работаете вы с JS с 2003 года.
                                                              +2

                                                              Как ни странно, но в JS тоже можно найти внутреннюю красоту, особенно, если немного вникнуть в стандарт.


                                                              "== и ===" — как правило, общепринятая политика — просто не использовать "==". Резко сокращает множество проблем и даёт более читаемый код. Проверка использования легко возлагается на тот же ESLint, что ещё и облегчает аудит кода.


                                                              "null и undefined" — да, наличие двух сущностей может показаться нелогичным, но их наличие в таком виде можно считать особенностью динамической типизации. С другой стороны, ведь в тех же Java и C# есть типы java.lang.Void и System.Void, а также null как специальное значение ссылочных типов, причём точно так же "следует помнить", что int x = null — ошибка, Integer y = null — корректный код, а int x = y выбросит NullPointerException. Нелогично? Или любому новичку в C# так же следует узнать, чем отличается приведение через скобки и через as.


                                                              isNan — здесь согласен, но ни разу не довелось её видеть в реальном коде.


                                                              "Нужно помнить, что в объекте error есть свойство message" — зачем? если работал с объектом ошибки нечасто и не помнишь наверняка, то можно же просто посмотреть в документации. Или инструкции никто не читает? Единственный стандартный класс JS, который вообще неадекватен по API, по моему мнению, — Date.


                                                              Может быть просто сказывается опыт работы с другими си-подобными языками и оттого эффекты, связанные с динамической нестрогой типизацией и прототипным ООП, вызывают неожиданность?

                                                                0
                                                                Date это полный ппц.
                                                                У меня API все на питоне написано, datetime.date по стандарту как «yyyy-mm-dd» передается, приходится каждый раз на входе в ангуляр парсить строку, а, потом, на выходе собирать. Ненавижу JS.
                                                                  0
                                                                  по стандарту как «yyyy-mm-dd» передается, приходится каждый раз на входе в ангуляр парсить строку, а, потом, на выходе собирать. Ненавижу JS.
                                                                  Вы сами конвертируете в строку, а потом жалуетесь, что приходится парсить. Передавайте/получайте сразу дату, и при чем здесь JS?
                                                                    0

                                                                    Ну да, самый простой вариант — это как-то так:


                                                                    var date = new Date('2016-08-21');
                                                                    date.toISOString().substr(0, 10) // "2016-08-21"
                                                                    +1
                                                                    неадекватен по API, по моему мнению, — Date

                                                                    Эта проблема встречается в большинстве языков, к сожалению. Работа с датой и временем — сложная штука. В некоторых случаях народ успел оглянуться и посмотреть на следы от грабель на телах конкурентов ,)

                                                                      +2
                                                                      1. Следует помнить только то, что примитивный объект в java не может быть null.
                                                                      2. Void — объект-обертка над void, так же, как и Integer над int.
                                                                      3. см. п.1. и тогда всё логично.
                                                                        0

                                                                        Void — это тип, его нельзя инстанцировать в отличии от Integer и компании. Значению типа Void можно присвоить только null, что вполне логично.

                                                                      +1
                                                                      А с isNaN-то что не так? :)
                                                                        –2
                                                                        isNaN("foobar") === true
                                                                          +3

                                                                          стесняюсь спросить — а что должно быть? false?

                                                                            –2

                                                                            NaN :D А так-то false было бы логично: строка — это же не NaN.

                                                                              +4

                                                                              Вы точно понимаете что значит NaN?

                                                                          –1

                                                                          А вообще есть конечно там некая толика всеобщего JS-раздолбайства, человек просто пример неудачный привел.


                                                                          isNaN(NaN); // true - ок
                                                                          isNaN(1); //false - ок
                                                                          isNaN(undefined); // true - ну... допустим ок
                                                                          isNaN("foobar"); // true - ок
                                                                          isNaN("1"); // false - ... эээ
                                                                          isNaN(false); // false - ... нуу
                                                                          isNaN(null); // false - пожалуй с меня хватит.

                                                                          Я думаю хорошо было бы если бы оно в действительности только на NaN true возвращало, что и пытался донести staticlab

                                                                            +2

                                                                            Собственно, так и работает Number.isNaN из ES2015, который неявно не приводит типы к Number:


                                                                            Number.isNaN(NaN); // true
                                                                            Number.isNaN(1); // false
                                                                            Number.isNaN(undefined); // false
                                                                            Number.isNaN("foobar"); // false
                                                                            Number.isNaN("1"); // false
                                                                            Number.isNaN(false); // false
                                                                            Number.isNaN(null); // false

                                                                            Ну а если по логике конкретной задачи потребовалось проверить на "не число", то тут подойдёт инверсия от Number.isFinite:


                                                                            !Number.isFinite(NaN); // true
                                                                            !Number.isFinite(1); // false
                                                                            !Number.isFinite(undefined); // true
                                                                            !Number.isFinite("foobar"); // true
                                                                            !Number.isFinite("1"); // true
                                                                            !Number.isFinite(false); // true
                                                                            !Number.isFinite(null); // true
                                                                    +9
                                                                    когда человек, пришедший из других языков видит, что в javascript'e называется словом this, его волосы неизменно начинают шевелиться
                                                                      +1
                                                                      И что же в JavaScript называется словом this отчего начинают шевелиться волосы?
                                                                        –1
                                                                        какая-то хрень в нем называется этим словом. Самые близкое по смыслу наименования, которое приходит на ум мне, это, наверное caller или invoker или context, хотя и они тоже плохие. Ну уж хотя бы нет коннотаций с Java-шным this'ом.

                                                                        Ну вот куда это годится?

                                                                        var MyObj = function () {
                                                                            this.fn = function () {console.log(this)};
                                                                        }
                                                                        a = new MyObj();
                                                                        a.fn();
                                                                        // MyObj
                                                                        var b = a.fn;
                                                                        b();
                                                                        // Window 
                                                                        


                                                                          0
                                                                          Ну это документированное и ожидаемое поведение языка. Хотя вы правы — понятие «Контекст вызова» здесь больше подходит, нежели «Указатель на объект» или что-то в этом роде.
                                                                          +2

                                                                          ‘Sometimes when I'm writing Javascript I want to throw up my hands and say "this is bullshit!" but I can never remember what "this" refers to.’
                                                                          — Ben Halpern ‏@bendhalpern 20 Mar 2015

                                                                      +14

                                                                      Кормлюсь js c 2006, и то, что сейчас происходит, в последние лет 5 — во многом лютый офигенчик.


                                                                      Что у нас было тогда? Prototype c весьма странной идеей и расплывчатой ответственностью. Примерно такой же Motools. jQuery, чей подход мне не нравился вообще никогда, с его бесконечными отвратительными плагинами. Потом появился переусложненный ExtJS, императивный на всю голову qooxdoo и прочие странные порождения сумрачного корпоративного гения. Единственный приличный был y5, который умер, где и родился — в недрах яндекса. Backbone, при всех его недостатках, был лучом света в темном царстве.


                                                                      Бандлер/минификатор был либо родом из серверного фреймворка (везде со своими идиосинкразиями), либо самописный (которые моя бабушка описала бы как «мальчик-то он хороший, только дрищется»). Все они писались серверными программистами без малейшего понятия, что же все-таки нужно фронтендеру. RequireJS, опять таки при всех своих недостатках, опять же был лучом света и т.д.


                                                                      Сборка происходила в лучшем случае Makefile-ом. Это, конечно, довольно универсальная система, но на винде из коробки ее нет. grunt/gulp/webpack более кроссплатформенные решения в этом смысле, плюс не надо переключаться с JS на чей-то эзотерический синтаксис.


                                                                      Про юнит-тесты я вообще молчу. Да, был, например, QUnit, но в отсутствие нормальной модульной системы и ее поддержки, пользоваться им было довольно грустно.


                                                                      В общем, сейчас в 99% случаев можно найти «точное такое же, но с перламутровыми пуговицами». И да, никто не запрещает и сейчас писать так же, как в 2003 — все в одном-двух файлах, без сжатия и склейки, без сторонних библиотек. Просто сейчас мы делаем гораздо более сложные вещи, которые в двух файлах уже не уместить (оставим неуместное использование тяжелых фреймворков на простеньких страничках на совести тех, кто так делает).

                                                                        +2
                                                                        Это палка о двух концах, имхо. Тогда не было технологий и альтернатив и да, приходилось пользоваться кривым Prototype и тратить кучу времени на то, что сейчас можно сделать за час (та же сборка проекта).
                                                                        С другой стороны, тогда и порог вхождения был гораздо ниже, изучаешь синтаксис языка, читаешь документацию к Prototype и вперёд фигачить.
                                                                        То что происходит сейчас замечательно описано в статье, её показать человеку, который только входит во фронтэнд, он с высокими шансами станет как бабушкин мальчик. Делается то всё просто, если знаешь как, а чтобы во вё разобраться надо немеряно времени потратить. Т.е. порог вхождения вырос на порядок как минимум.
                                                                          +1

                                                                          Ну это понятно:) Но ведь и сложность задач возросла. Если надо склепать какой-нить лендинг-пейдж/визитку или там галерейку для сайта на вордпрессе — можно все так же, window.onload = function() {} и вперед, и это нормально. Я бы «удивился», если кто-то предложил использовать react + babel для этого, все либы будут весить гораздо больше пользовательского кода, а выигрыш минимален. Я же говорю, никто не запрещает сейчас делать так же, как и тогда — только если вы попробуете те подходы на сложном приложении, вам будет грустно.


                                                                          Сейчас везде так. Видели оригинал? Или вот покажи мне сейчас кто-нибудь стэк для написания десктопных приложений, я буду таким же мальчиком. Подозреваю, если бы братьям Райт показали «Конкорд», они бы тоже сказали: «ну да, круто, но у нас вот из говна и палок можно за час собрать, и летает». Сравните телефоны сейчас и во времена Белла. Да, сейчас все сложнее, зато и воможностей больше. А звонить-то можно и по-прежнему.

                                                                            0
                                                                            Я могу сказать рамках .net, котором пишу. Там такого нет. Есть основная технология, WPF (Windows Presentation Foundation), которая использует паттерн MVVM. Первая версия вышла 2006 году, в дальнейшем вносились косметические изменения. Она позволяет использовать весь функционал .net Framework. Есть библиотеки дополнительных контролов, выпускаемых различными вендорами, типа Telerik, но их использование опционально.
                                                                            Фактически, все новые приложения на платформах MS (Windows 10, Windows.Store, Windows.Phone, Silverlight) пишутся на WPF, который стандартизирован.
                                                                            При этом новые технологии, появляющиеся в рамках .net framework (async/await, EntityFramework) вплетаются в WPF без нарушения обратной совместимости.
                                                                              +1

                                                                              Спасибо. А UWP сюда каким боком относится? Я слышал, что можно что-то там делать на JS, можно ли сделать live tile и как? Пригодится ли мне WinJS или это сугубо набор контролов? Я знаю, что есть кросс-платформенное Mono и что оно в какой-то мере отстает от мейнстримного .net, оно умеет в WPF?

                                                                                +3
                                                                                Я знаю, что есть кросс-платформенное Mono и что оно в какой-то мере отстает от мейнстримного .net, оно умеет в WPF?

                                                                                В WPF не умеет ни Mono, ни .NET Core. Так что всё применение WPF ограничивается только Windows с классическим фреймворком.

                                                                                0

                                                                                Я не только из риторических целей спрашиваю, мне правда хочется сделать кое-какое приложение в виде живой плитки.

                                                                                  –3
                                                                                  Я, честно говоря, не изучал его глубоко, не приходилось сталкиваться. Но предполагаю что там идеология похожая.
                                                                                  Есть ещё Apache Cordova, там можно, насколько я понимаю на JS писать.
                                                                                  Но опять же, у .net идеология, что всё компилируется в байт-код MSIL (а-ля ассемблер), который затем, во время исполнения, компилируется в нативный код, специфичный для платформа. Скорее всего, там просто сделан компилятор, который превращает JS в MSIL (байт-код).
                                                                                    +1
                                                                                    Есть ещё Apache Cordova, там можно, насколько я понимаю на JS писать.

                                                                                    Это просто обертка над WebView (точнее, генератор таких оберток под каждую нужную платформу). В WebView показывается ваша страничка (оффлайн, она лежит в ресурсах приложения). Обертка обеспечивает проброс нативных API платформы.


                                                                                    Расскажите мне лучше то, чего я не знаю.

                                                                                      +2
                                                                                      Я, честно говоря, не изучал его глубоко, не приходилось сталкиваться.

                                                                                      Ну вот видите. Вы пишете на .net и не можете мне про него рассказать. А у JS, видите ли, сложный и запутанный стэк.

                                                                                        0
                                                                                        Я могу вам рассказать про .net, я не изучал глубоко UWP приложения, так как не было пока проектов, связанных с ним.
                                                                                        .net же огромная платформа, которая делится на множество направлений.
                                                                                        Изначально были Windows.Forms, Asp.Net Web Forms, .net CE, .net embedded. Потом появились WPF, WCF, WWF, ASP.NET MVC. Windows CE канул в Лету и на смену ему пришёл .net под Windows Phone, сейчас активно развивается UWP (в рамках мобильных платформ) и Asp.Net Web API (в рамках веба), выделившийся из ASP.NET MVC. Сейчас активно .net Core развивается. Из этого списка я вообще не трогал UWP, .net Embedded и чуть-чуть трогал .net Core. Про остальное спрашивайте, расскажу.
                                                                                    +6
                                                                                    При этом новые технологии, появляющиеся в рамках .net framework (async/await, EntityFramework) вплетаются в WPF без нарушения обратной совместимости.

                                                                                    А что из новых фич JS и DOM было добавлено с нарушением обратной совместимости?

                                                                          –4
                                                                          Интересный стек технологий сейчас используется в Web разработке.
                                                                          У нас в компании похожий стек, только про Hadoope
                                                                            –9
                                                                            Поскорее бы уже монополия инструментов от Гугла.
                                                                              +7
                                                                              Программирую уже 18 лет, из них 11 лет для WEB. Прочитал статью, понял что я почти ничего не знаю. Пора перестать быть самоучкой — велосипедостроителем, и начать изучать готовые велосипеды. И уже на них ездить…
                                                                                +3
                                                                                Вот. В этом истинная (полезная!) цель данного поста. Можно использовать как глоссарий терминов, о которых за несколько дней (хотя бы) почитать, посмотреть примеры и т.д.
                                                                                  –5

                                                                                  Потом осознать, что потратил месяц, просто чтобы начать понимать, что значат все эти термины. Прикинуть, что на освоение позволяющее использовать все это в реальной работе уйдет от года(а за это время появится еще много чего). Ну и плюнуть на все это и за выходные освоить Dart. За вторые выходные написать то самое TodoMVC которое просто будет работать.

                                                                                +11
                                                                                История о том, что кто-то не может выбрать набор инструментов соразмерно задаче. История была актуальна во все времена.
                                                                                  +4
                                                                                  ага, любят в нашей отрасли сколачивать скворечники, используя инструмент для проектирования авианосцев
                                                                                    0
                                                                                    Позвольте с Вами не согласиться. Часто начинается как скворечник, а заканчивается как Боинг. Та жа попсовая Java даёт инструменты, чтобы одинаково эффективно строить и скворечники и загоны для крупного рогатого скота.
                                                                                      +2
                                                                                      Чаще нужен именно скворечник. Разрабатывается он как авианосец и на выходе получается чёрти что за баснословные деньги и неприемлемые сроки.
                                                                                      А те редкие скворечники, которым посчастливилось показать потенциал авианосца, можно и переписать с нуля.
                                                                                  –1
                                                                                  И, кстати, вообще вся история js, экосистемы js, сообщества js как бы показывает нам очередной фильм-антиутопию про далёкое будущее. Когда на ИТ-планету упал кусок рыночного капитала, образовался неизвестной природы js-копролит чёрный и блесятщий.

                                                                                  И началось постепенное разделение ИТ-людишек на два класса — кровожадная элита, которая делает какой-либо рантайм js (неважно, браузер, нода, embed-версию) и всех остальных, которым дали js и песочницу, а постоянное нахождение в ней эволюционно отупляет даже самых способных голодранцев.

                                                                                  И это отупление относятся и к бизнесу, то есть менеджерам, владельцам бодишопов и прочим, которым надо чтобы дела делались и всё было внешне ровно и красиво, как огромный js-копролит, возвысившийся над планетой.

                                                                                  И то же самое относится к исполнителям, то есть огромной толпе буллшит-кодеров, которым просто надо жить и кушать, и плевать, что своими копытцами поддерживаешь огромный чёрный js-копролит, возвысившийся над планетой.

                                                                                  И все, вообще все понимают, насколько js унылое дерьмо, но целая планета трудится над этим дерьмом, затыкая носы ради великого доллара на вершине js-копролита.
                                                                                    +8
                                                                                    — Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.
                                                                                    — Да, я как раз занимаюсь фронтендом, юзаю пару тулз.
                                                                                    — Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?
                                                                                    — Не-не-не. Для обычного TODO-листа слишком много оверхеда. Пишешь софт на любом удобном языке, подрубаешься через telnet и юзаешь. Если хочешь секурности — используй ssh.
                                                                                      +16
                                                                                      Слишком много оверхеда. Просто возьми бумагу и карандаш.
                                                                                        +6
                                                                                        Бумага и карандаш — ненужные костыли. Лучше просто не забывать, что хотел сделать.
                                                                                          +3
                                                                                          Не забывать — лишний расход памяти. Лучше просто не хотеть делать.
                                                                                            +1

                                                                                            Лучше тогда вообще… постойте, это уже какая-то пропаганда самоубийств получается. Я слышал, это незаконно теперь!

                                                                                              +10
                                                                                              Странно, что современный фронтенд — это еще законно.
                                                                                              Пропаганда, если не самоубийств, то, как минимум, наркотиков.
                                                                                      +1
                                                                                      Для слоупоков от мира веб-разработки — написал статью, которая мб кому-то поможет разобраться лучше с проиходящим: JavaScript: где мы сейчас и куда двигаться.
                                                                                        +7
                                                                                        Читая комментарии в очередной раз подчеркнул для себя — JavaScript не оставляет равнодушным никого. Одни яростно ненавидят его, другие обожают. Видимо именно так и должно реагировать сообщество на самый популярный и в то же время противоречивый язык программирования современности. Самое время запасаться попкорном.
                                                                                          –4
                                                                                          Когда надо не трепать языком, а работать за деньги с обязательствами перед клиентами и начальством вся эта заднеприводная противоречивость встаёт на пути нормального размеренного трудового процесса. Но, опять же, власть копролита сильнее голоса разума.
                                                                                            +2
                                                                                            Это IMHO не JavaScript. Это экосистема технологий и приемов, складывающаяся вокруг JavaScript волей случая (в данном посте — даже вокруг фронтенд-разработки).
                                                                                              +1
                                                                                              На backend'е ситуация ещё хуже. Фронтенд хотя бы ограничен одним языком (js), тогда как backend — это целая пачка языков программирования, вокруг каждого из которых громоздится целая гора фреймворков.
                                                                                              При том, что выбор языков носит исключительно косметический характер (в стиле «мне не нравится синтаксис»), т.к. возможности сходны, и вряд ли можно найти такую задачу, которую легко решить к примеру на Python+Django, но невозможно на PHP.
                                                                                              0
                                                                                              Я равнодушен лет так 20. Это просто инструмент, который использую, когда считаю что лучше использовать его, а не альтернативы.
                                                                                                0
                                                                                                Проблема в том, что альтернатив-то, по сути, нет. Ненавидите джаву — пишите на шарпе (благо, уже кроссплатформенный), ненавидите ооп — пишите функционально, ненавидите жс — ууупс…
                                                                                                Да, есть дарт, есть тайп/кофе/*скрипты и на некоторых из них даже почти удобно писать, но это всё просто запихивание того же самого под ковёр. Не видно, но всё равно попахивает.

                                                                                                И да, я понимаю, почему альтернатив нет — браузеров много, и пропихнуть эту самую альтернативу почти нереально, но ситуация от этого менее плачевной не становится.
                                                                                                +1

                                                                                                Недостаточно трэша. Теперь мы хотим в качестве бэкенда использовать не какую-нибудь ноду, а ASP.NET (не Core) с бандлами. Когда для сборки React, минификации, трансляции less используются не обычные front-end инструменты, а куча разных пакетов вроде DotLess, ReactJS.NET. В Core куда удобнее, имхо — bower, grunt и прочее веселье.

                                                                                                  0
                                                                                                  Я один не понимаю, зачем для подобных действий использовать средства фреймворка (например, ассеты в RoR) вместо использования Gulp/Grunt/Bower/Webpack?
                                                                                                  Очень трудно понять, для чего нужны вот такие вещи сегодня.
                                                                                                    +1

                                                                                                    Я тоже не понимаю этого. Примерно так: ты новичок, изучаешь новую технологию, читаешь гайды, а там показан такой путь и сказано, что это труЪ и кошерно.


                                                                                                    Хотя у бандлов в асп.нет есть преимущество перед конкретно Gulp\Grunt — с помощью их и web essentials можно на лету пересобирать. Сохранил css\less, и у тебя сразу изменения в браузере, а не подождал, пока watch grunt'а увидел, пересобрал и потом обновляешь страницу.


                                                                                                    Но такую магию вроде позволяет WebPack. Я тоже за родные для фронтенда инструменты.

                                                                                                      +1

                                                                                                      Ну уж ivereload для стилей и grunt умел (точнее, grunt-livereload).

                                                                                                        0

                                                                                                        Значит я просто не разобрался.
                                                                                                        хм. Он deprecated.

                                                                                                          0
                                                                                                          У меня gulp пересобирает scss без перезагрузки страницы вот так:
                                                                                                          — в таске styles появляется строка .pipe($.if(browserSync.active, browserSync.stream({match: '**/*.css'})));
                                                                                                          — в таске browsersync остается gulp.watch, но без вызова bs.reload()
                                                                                                      0
                                                                                                      Потому что они есть из коробки, хорошо изучены и работают. Зачем отказываться от них и вводить в проект новые сущности?
                                                                                                    +16
                                                                                                    То чувство, когда освоил angular, а он умер и теперь боишься учить новую технологию, понимая что через год-два ее ждет та же участь
                                                                                                      +14
                                                                                                      Если степень фрагментации технологий продолжит возрастать теми же темпами, то ценность знаний конкретных технологий рано или поздно станет равной нулю. И хорошим программистом будет считаться человек, способный за два дня освоить конкретный набор технологий, которые он увидел впервые, быстро создать на этих технологиях проект, после чего очистить мозг от выученного, т.к. пока проект создавался, данные технологии вышли из употребления и больше никогда не понадобятся.
                                                                                                        +5
                                                                                                        На моём опыте, ваша фраза «И хорошим программистом будет считаться человек, способный за два дня освоить конкретный набор технологий» актуальная уже сейчас. С начала прошлого года мне довелось поработать над тремя frontend проектами с абсолютно разным набором технологии, начинаю со сборщика и фреймворка, заканчивая набором библиотек и плагинов, даже стиль написания кода приходилось соблюдать разный. И только за счёт способности к быстрому обучению и адаптации удалось в этом преуспеть, а не сойти с ума.
                                                                                                        +7
                                                                                                        блин, уже умер???
                                                                                                        0
                                                                                                        > И хорошим программистом будет считаться человек, способный за два дня освоить конкретный набор технологий

                                                                                                        Тогда нам срочно нужно поколение детей-индиго, способных за 2 дня освоить стэк техгологий из этой статьи
                                                                                                          +1

                                                                                                          Ну, глядя на тенденцию обучения программированию с младых ногтей, думаю что это не будет проблемой в ближайшем будущем

                                                                                                          +4
                                                                                                          Шутки шутками, а я бы с большим удовольствием прочитал подобный пост про упомянутый деплоинг. Крайне удачная подача материала дабы быстро освоиться в теме и терминологии. Год назад подобный пост сохранил бы мне неделю времени потраченную на гуглинг.
                                                                                                            0
                                                                                                            Вы хотя-бы список технологий приведите, чтобы понять, что подразумевается под делоингом веб-сайтов
                                                                                                              +3
                                                                                                              Этот пост как раз и хорош тем, что перечисляет список технологий и даёт им краткое описание, рассказывает в каком месте их можно применить.
                                                                                                            +1
                                                                                                            Что-же, если стоит задача написать todo-list — возможно тут и jquery лишний, браузерные api уже не те что раньше.
                                                                                                            Но обычно стоит задача написать реально сложное web-приложение, и вот тут все эти технологии уместны и нужны. То что их много, они сложные, и постоянно меняются — безусловно вводит в ярость человека, который привык к тому, что может написать пару сток на js в перерывах между своим .net mvc или типа того, и считать себя full-stack. Я бы посоветовал таким людям смирится, и просто сосредоточится на своей технологии, а front-end оставить тем, кого все эти слова не смущают.
                                                                                                              0
                                                                                                              Ой, еще никто не написал, что flux — прошлый век, и крутые перцы используют redux xD
                                                                                                                +2
                                                                                                                Еще и relay с graphql на подходе.
                                                                                                                  –2
                                                                                                                    +1
                                                                                                                    Крутые перцы уже используют mobx
                                                                                                                      0

                                                                                                                      Это шаг назад по сравнению с redux, потому что теряется predictability. Выглядит мощно да, но и goto в C выглядел мощно. А потом все поняли, что это верный способ себе ногу отстрелить.

                                                                                                                        +1
                                                                                                                        goto в си используется довольно часто для освобождения ресурсов в конце функции
                                                                                                                          0

                                                                                                                          Ага, как и setjmp и longjmp. Только эти вещи используются в очень частных случаях, и только когда это реально оправдано. Observables это реально интересная вещь — ложится на наши естественные ментальные модели хорошо. Как и гото, например. Он ведь тоже когда-то появился, потому что это для нашего мышления естественная штука. Проблема в том, что наши ментальные модели зачастую говно. Человеку свойственно ошибаться и нести чушь.


                                                                                                                          То есть, иногда встает выбор — либо учить что-то новое и прорывное (новую ментальную модель) — что дает принципиально новые возможности (как функциональный подход и redux) — либо заниматься луддизмом, и цепляться за mutable state, просто потому что мы уже привыкли так мыслить, а новые парадигмы мы в голове помещать не хотим. Но время все расставляет по местам, думаю что штуки типа mobx для менеджмента состояний будут оправданы только в маленьких простых приложениях, а в больших и сложных это будет шаг назад в сравнении с Redux. Это чем-то похоже на дилемму из статьи, кстати (jquery vs react).

                                                                                                                            –1
                                                                                                                            > как и setjmp и longjmp
                                                                                                                            Они как-раз специфичные. А goto — нормальная, довольно распространенная практика в Си

                                                                                                                            > либо заниматься луддизмом, и цепляться за mutable state
                                                                                                                            mutable state отличная, рабочая парадигма. Идеологи реакта прославляют иммутабельность потомучто она критична для работы реакта — это его прямое ограничение. Как только кто-то сделает «реакт без принудтельного stateless и виртуального DOMа» все забудут этот недохаскель как страшный сон.
                                                                                                                              0

                                                                                                                              В чистом C возможно. Но в C++ это не так. Я писал на C++ много лет (3D графика), и мне ни разу не пришлось использовать goto. Хотя он там есть. Я именно об этом и говорю — наличие инструмента не делает его использование оправданным.


                                                                                                                              Так же и мутабельность — это только выглядит «удобным», как гото когда-то выглядел удобным, пока не появились лучшие инструменты. И точно так же находились те, кто считал, что старый подход лучше, потому что «удобнее». Вы думаете мало было холиваров насчет гото? Вот и mutable state ждет такая же судьба. Останется уделом низкоуровневых вещей каких-то, где без этого вообще нельзя. А на макроуровне это забудут, как страшный сон.


                                                                                                                              У реакта иммутабельность это не ограничение. Это как говорить что автомобиль это ограничение, потому что он плавать не умеет, а вы умеете. Да, он не умеет плавать, зато он ездит в десять раз быстрее чем вы бегаете. И в реальности это намного важнее. Я полагаю, что вы когда рассуждаете об этом, как об ограничении — то за деревьями не видите леса, не понимая до конца преимуществ иммутабельности в макромасштабе. Я кстати об этом написал статью сегодня.

                                                                                                                                0
                                                                                                                                В плюсах для освобождения ресурсов используют деструкторы. Но даже на плюсах вы использовали goto. Switch-case не более чем легкий синтаксический сахар над goto

                                                                                                                                > не понимая до конца преимуществ иммутабельности в макромасштабе
                                                                                                                                Расскажите о преимуществах иммутабельности в макромасштабе, будте так добры
                                                                                                                                  0

                                                                                                                                  Так же можно сказать что и immutable state это легкий сахар над mutable state, ведь архитектура компов это Тьюринг-машина. Я не очень понимаю такую «логику» рассуждений. Про преимущества есть в статье.

                                                                                                                                    +2
                                                                                                                                    Switch-case строже, чем goto.

                                                                                                                                    А так-то всё — синтаксический сахар поверх машинных кодов, но это же не повод.

                                                                                                                                    Расскажите о преимуществах иммутабельности в макромасштабе, будте так добры

                                                                                                                                    Когда у вас вся логика спрятана в immutable-функции, то становится очень легко и просто рассуждать о коде (as in «reason about the code»).
                                                                                                                                    0
                                                                                                                                    Вот и mutable state ждет такая же судьба.
                                                                                                                                    Останется уделом низкоуровневых вещей каких-то, где без этого вообще нельзя.
                                                                                                                                    А на макроуровне это забудут, как страшный сон.

                                                                                                                                    Пруфлинк бы. А то каждый месяц кто-нибудь не слишком хорошо знакомый с историей развития языков открывает для себя immutable state и предрекает немедленную кончину объектов с изменяемым состоянием, а они все, гады такие, не помирают и не помирают никак.


                                                                                                                                    А не помирают они потому, что есть задачи, которые хорошо решать в парадигме чистых вычислений, а есть задачи, которые естественнее и удобнее решать в рамках ООП. Например, складской учет, оперирующий ящиками и коробками, можно, конечно, решить без изменяемых объектов — но количество костылей, которые придется нагородить вокруг, заставит глаза кровоточить гораздо раньше, чем первый пререлиз увидит свет.


                                                                                                                                    Нет серебряной пули: вот единственно верный ответ на этот вопрос. Есть масса задач, в которых давно отправленный на пенсию Backbone даст сто очков форы любому новомодному redux’у. Поэтому фанатиков технологий и недолюбливают в любом мало-мальском энтерпрайзе.

                                                                                                                                      0

                                                                                                                                      https://habrahabr.ru/post/308154/


                                                                                                                                      На высокоуровневых задачах в вебе про mutable state уже забыли. Я в прошлом году писал WYSIWYG редактор который работал с изменяемым состоянием, хранящимся напрямую в DOM. Было очень сложно добиться безглючности и понятности кода, а также работы штук типа стека undo/redo. Сейчас я смотрю на последние разработки редакторов типа Slate или Draft.js — это невероятно, насколько иммутабельность помогла им выстроить хорошую архитектуру, позволяющую в разы больше, чем возможно было до того.

                                                                                                                                        0

                                                                                                                                        Я вам говорю: «разные задачи — разные инструменты, например, забивать гвозди удобнее молотком, а закручивать шурупы — отверткой».


                                                                                                                                        Вы мне в ответ: «я и еще три крутых пацана вчера забивали гвозди, ничего круче молотка нет, вообще все все все уже давно отказались от отверток».


                                                                                                                                        Ну ок. Пруфлинк засчитан.

                                                                                                                                          0

                                                                                                                                          Так вы посмотрите с чего ветка-то началась, пример goto не просто так был приведён. Каждая новая технология не отменяет старой, но расширяет горизонт возможностей, а старая технология остается в рамках этого расширенного горизонта маленькой нишей. Сегодня люди до сих пор используют и C++, и ассемблер даже — но на прикладном уровне этого уже нет давно. Вот так же и mutable state — это старая парадигма, которая не способна решать «бытовые» задачи, с которыми люди сталкиваются сегодня. Просто это новые задачи, новые вызовы. В рамках которых люди действительно уже отказались от «отверток». А отвертки остались в своей области применимости.

                                                                                                                                            +1

                                                                                                                                            Во-первых, immutable states и чистые функции примерно настолько же «новая» парадигма, насколько и goto.


                                                                                                                                            Во-вторых, mutable states живее всех живых во многих прикладных задачах. То, что вы почему-либо с таким классом задач не сталкивались, означает только то, что ваши задачи удобнее решать с неизменяемыми объектами. Вы пока не привели ни единого аргумента, почему бы это было так, кроме «мамой клянус», «сам писал целый год целый проект» и «совершенно очевидно». Это все детский сад.


                                                                                                                                            Вот вам простой пример: я у себя в блоге накладываю на фотографии информацию о месте съемки, которую вытаскиваю сырой из EXIF и хожу из клиента в nominatim, который отвечает не всегда, поэтому я успокаиваюсь после двух отлупов. Предложите мне вариант проще, чем хранить «по этой фотографии опрос окончен» в самом объекте и рисовать общую карту с маркерами по факту «все объекты успокоились» — и я уверую.

                                                                                                                                              –1

                                                                                                                                              Задача которую вы описываете — это не высокоуровневая задача, это как раз область применимости отверток.


                                                                                                                                              > То, что вы почему-либо с таким классом задач не сталкивались


                                                                                                                                              С чего это я не сталкивался? Я с таких задач и начинал, можете резюме глянуть. В детстве 3D движки писал (DX/GL), там таких задач как раз полно. Это все лоу левел.


                                                                                                                                              Я вам привел совершенно конкретный пример весьма сложной высокоуровневой задачи (WYSIWYG редактор), где immutable state упрощает код на порядок, делая его предсказуемым, высокопроизводительным и легко расширяемым: https://github.com/ianstormtaylor/slate#principles


                                                                                                                                              А вы мне про какие-то EXIF из фоток. Детский сад...

                                                                                                                                                0
                                                                                                                                                Вот так же и mutable state — это старая парадигма, которая не способна решать «бытовые» задачи, с которыми люди сталкиваются сегодня.

                                                                                                                                                По-моему, это ваши слова, поправьте, если ошибаюсь. Теперь на сцене появляются какие-то «высокоуровневые» задачи. Ну ок, визивиг, «immutable state упрощает». И что из этого следует, кроме того, что есть пример задачи, где неизменяемое состояние — благо? С этим тезисом даже самые отъявленные оописты не спорят. Вот только он ничего не доказывает.


                                                                                                                                                Если бы вы с самого начала использовали слово «некоторые» вместо «все» (даже «большинство» можно было бы стерпеть) — я бы вообще не встрял. Каждый волен восторгаться новыми религиями, хоть каждый год.


                                                                                                                                                Напоминаю еще раз важный момент, который вы в ответах успешно игнорируете: immutable state — ровесник goto. У него было время убить вокруг вообще все живое. Но этого не случилось. Потому что не для всех задач это благо. Вот и все.


                                                                                                                                                Рано или поздно ваша высокоуровневая задача захочет восстанавливаться из локалстораджа при переоткрытии браузера (ну, если она для людей, конечно, а не для демонстрации высокоуровневости). И voilà.

                                                                                                                                                  –1

                                                                                                                                                  Вы напрасно сравниваете гото и иммутабельность, в плане их «старины», пытаясь из этого какие-то выводы сделать. Гото это чисто инженерное решение, которое было обусловлено низкоуровневой архитектурой вычислительного железа. Оно старое просто потому что компы старые.


                                                                                                                                                  Иммутабельность же появилась именно как абстрактная академическая идея, и оставалось игрушкой, пока не появились задачи, в которых это очевидно удобно. То есть миру нужно было просто дорасти до таких задач. Это сложные, высокоуровневые задачи, очень далекие от архитектуры железа и гото. Они не могли возникнуть сразу, это вопрос эволюции.


                                                                                                                                                  Точно так же как и другие вещи из функциональных языков, типа лямбд или замыканий. Представьте себе, лямбда-исчислению уже скоро будет 100 лет. И вот только-только это становится мейнстримом.


                                                                                                                                                  Вы просто путаете теплое с мягким.

                                                                                                                                                    0
                                                                                                                                                    Иммутабельность же появилась именно как абстрактная академическая идея,
                                                                                                                                                    и оставалось игрушкой, пока не появились задачи, в которых это очевидно удобно.
                                                                                                                                                    То есть миру нужно было просто дорасти до таких задач.

                                                                                                                                                    Ох. Джо Армстронг уже и так икает в безмолвном изумлении.

                                                                                                                                    0

                                                                                                                                    Я кстати уверен что в будущем люди не то что «забудут недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.

                                                                                                                                      0
                                                                                                                                      > JS все больше и больше становится похож на это
                                                                                                                                      Не было в JS ничего подобного до прихода реакта. В нем, насколько я понимаю, иммутабельность нужна чтобы реакту быстро найти изменения. То есть для того чтобы его внутренности правильно отработали. Разработчику-пользователю фреймворка она ничего кроме чувства собственной важности не дает. Поправьте, если я ошибаюсь
                                                                                                                                        +1

                                                                                                                                        Пользователю фреймворка это дает React, лол. Он был бы невозможен без этого. Я именно об этом и говорю, это не просто «быстро найти изменения», это и есть ключевой момент во всем этом. В макро масштабе.


                                                                                                                                        И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.

                                                                                                                                          +1

                                                                                                                                          Не совсем так, Реакт может работать и с изменяемым состоянием.

                                                                                                                            +13
                                                                                                                            Мне одному кажется, что мы все сейчас наблюдаем пузырь, сравнимый с доткомовским?
                                                                                                                            Все эти недавно бывшие кодерами на похапе или полгода верставшие лендинги люди раздувают ценность знаний новых технологий, и их реально нанимают работать на хорошие должности. А на деле эти люди освоили пару алгоритмов или парочку фреймворков типа Angular2 и иже с ними.
                                                                                                                            Все больше кажется, что охотнее нанимают не спецов, пусть и в драных кедах, а людей, умеющих себя подороже продать, освоивших что-то интересное, но не знающих даже основ.
                                                                                                                              +11
                                                                                                                              Backend-илита подтянулась, ну наконец-то.
                                                                                                                                –1
                                                                                                                                Я пока, по рейтингу. — в самом низу — похапешник)
                                                                                                                                Как должно быть заметно по моему первому комментарию, я не считаю себя элитой и всячески не одобряю похожего мнения от любого человека.
                                                                                                                                0
                                                                                                                                Всегда и во всех областях охотнее нанимают тех, кто умеет продать себя :)
                                                                                                                                Отовсюду слышно, что с радостью нанимают «молодых и перспективных» разработчиков, у которых горит в глазах огонь при виде новейших технологий. Люди поопытнее уже прошли эти круги ада новых и модных технологий как минимум пару раз, и подход у них более практический.
                                                                                                                                Имхо, разумеется.
                                                                                                                                +9
                                                                                                                                Я бы еще добавил:

                                                                                                                                — А как в этот Webpack'e подключить стили?
                                                                                                                                — Ну тут все просто, ставишь precss, postcss-loader, postcss-import, css-loader, style-loader, file-loader, normalizr, normalizr.css, autoprefixer
                                                                                                                                — Поставил все как вы сказали, но картинки не загружаются.
                                                                                                                                — Очевидно вы забыли установить image-webpack-loader
                                                                                                                                  0

                                                                                                                                  Перечитал статью — так и не понял над чем смеяться? С указанным стеком познакомился за месяц, за два-три месяца активной работы втянулся до уровня заглядывать в доки не больше пяти раз за день, второй год успешно на этом зарабатываю. То есть если даже оно все разом сейчас умрет — я считаю что свои инвестиции времени я отбил. Что не так?  Где можно прийти с улицы и начать грести лопатой? При чем здесь кривизна языка разработанного на коленке? Современный js от того языка довольно далеко ушел. В каком языке достаточно знать только язык что бы продуктивно работать? Java? С++? (программируем сфероиды в вакууме, ага)  Почему webpack — костыль, а make никсов — произведение исскуства? npm чем то хуже (или лучше) других менеджеров пакетов? Мужики, в любой нише придется изучать инфраструктуру, не потянули js — не расстраивайтесь. Да, сейчас порог вхождения для джисера гораздо выше чем было раньше. И уровень проектов — выше. И js давно вышел из песочницы броузера. Но это не повод расстраиваться — есть масса других ниш, другие стеки, возможно стоит начать с них )

                                                                                                                                    +11
                                                                                                                                    make не произведение искусства, make — стандартный инструмент. И будет стандартным и через 5, и через 10 лет.

                                                                                                                                    Я зарабатываю на жизнь написанием кода на C++ (в основном). Я знаю C++, и всё. Ну, и часть библиотек из Boost ещё знаю немножечко — часто использовать приходится. Из системы сборки — cmake (который, кстати, в том числе, те же мейкфайлы генерит). И у меня получается продуктивно работать.

                                                                                                                                    Надо нафигачить простейший SVM? Так, что у нас там есть… liblinear, libsvm, dlib. Мне ещё потом ручками надо будет запрогать логистическую регрессию, то есть, минимизировать функцию, в dilb это тоже есть, да ещё и в обобщённом виде, значит, выбираем его. Какой там API… За полчасика посмотрели, изучили, примеры почитали, можно писать. Ой, медленно, надо для матриц дёргать что-то этакое… О, есть же Intel MKL! А его как раз dlib тоже поддерживает! Пересобрали dlib с поддержкой MKL, вау, псевдообратная Пенроуза-Мура для матрицы 200000×200000 теперь берётся не 600 секунд, а 50!

                                                                                                                                    Надо распарсить сложный формат с исходными данными теперь — набросали на хаскеле/attoparsec прототип, убедились, что всё парсится, грамматику файла мы вывели правильно, берём Boost.Spirit, 10 минут тратим на переписывание с аттопарсековского eDSL на спиритовский, 20 — на борьбу с компилятором, попутно быстренько изучаем, как в Boost.Phoenix сделать обобщённую ленивую функцию для parser semantic action.

                                                                                                                                    Надо теперь запрогать символьную регрессию — открываем свой диплом от 2012 года, пишем прототип на хаскеле, запускаем, всё ок, переписываем, отключив мозг, на плюсах, профилируем, убеждаемся, что тормозит вычисление производных, смотрим, чем бы генерить код, ой, нет, llvm — оверкилл, пойду напишу свой компилятор в обратную польскую, оно более cache-friendly будет, и правда, теперь производительность устраивает.

                                                                                                                                    Как-то так, ага. Если стеки-библиотеки и надо изучать, то лишь для каких-то задач, специфичных для области, что, похоже, идёт совсем вразрез с посылом данного поста.

                                                                                                                                    Посмотрел я, короче, на это всё околоджаваскриптовое действо и в очередной раз порадовался, что я занимаюсь скучным, неинтересным, незрелищным вычислительным бекендом.
                                                                                                                                      0
                                                                                                                                      make — стандартный инструмент. И будет стандартным и через 5, и через 10 лет.

                                                                                                                                      webpack такой же стандартный инструмент фронтэнда (да уже и не только)


                                                                                                                                      Надо нафигачить простейший SVM? Так, что у нас там есть… liblinear, libsvm, dlib. Мне ещё потом ручками надо будет запрогать логистическую регрессию, то есть, минимизировать функцию, в dilb это тоже есть, да ещё и в обобщённом виде, значит, выбираем его. Какой там API… За полчасика посмотрели, изучили, примеры почитали, можно писать. Ой, медленно, надо для матриц дёргать что-то этакое… О, есть же Intel MKL! А его как раз dlib тоже поддерживает! Пересобрали dlib с поддержкой MKL, вау, псевдообратная Пенроуза-Мура для матрицы 200000×200000 теперь берётся не 600 секунд, а 50!

                                                                                                                                      А теперь то же самое но с гуями и что бы работало на винде, макоси, иос, андроид, зоопарке пингвинов и трех bds-дях.
                                                                                                                                      Вы теплое с мягким зачем сравниваете? Как только Вы заденете гуй и портирование — тремя либами не отделаетесь.

                                                                                                                                        0
                                                                                                                                        А теперь то же самое но с гуями и что бы работало на винде, макоси, иос, андроид, зоопарке пингвинов и трех bds-дях.

                                                                                                                                        Зачем?

                                                                                                                                        У вас был вопрос о том, где достаточно знать только язык, чтобы продуктивно работать. Вот язык, вот domain-specific-либы, которые уменьшают сложность задачи, а не языка, всё.
                                                                                                                                          +3
                                                                                                                                          > А теперь то же самое но с гуями

                                                                                                                                          Вы теплое с мяким зачем сравнваете? В браузере вы сделаете из всего перечисленного только гуй
                                                                                                                                            –2

                                                                                                                                            В КАКОМ броузере? Вы понимаете что если сравнивать разработку фронтенда с разработкой пользовательского десктопного ПО то правильнее будет брать не разработку под одну платформу а сразу под весь зоопарк. Никто же приходит со словами — а сваяй ка мне, любезный, фронт под хром 52 версии. Никаких стилей, проект развиваться не будет, вот ТЗ — оно актуально на ближайшие 10 лет. (в таком раскладе да — бабель не нужен, куфсе меняем на custom elements, на webpack забиваем — делаем сборку с npm парой самописный скриптов и радуемся жизни) Но нет такого, как правило хотят весь зоопарк за редкими исключениями (кому то старые ослы не нужны, кто то на мобильные может не заморачиваться — по разному) Тут возникает бабель, потому что фрагментация и хочется писать на прямом языке под старые броузеры.
                                                                                                                                            Далее — раз уж мы пишем приложение на все платформы, все для пользователя — давайте уже его писать так что бы пользователь (владелец сайта) мог легко менять темы (путем эксплуатации верстальщика). Ага?  Да, для фронта для этого нужны инструменты для стилей. Тут уже всякие less и иже сними с поддержкой в webpack.
                                                                                                                                            jsx (tsx) — шикарный инструмент который можно использовать и без реакта, спокойно переключаясь от верстки к коду — то есть в процессе программирования DOM елемент объявляется и используется и как верстка и как js объект. Темплейты становятся не нужны. Опять же tsx/jsx транспайлить удобено webpack-ом (просто потому что он изначально спроектирован для сборки фронтов)
                                                                                                                                            Про сборку всего этого ливера в один модуль — в статье откровенный бред, webpack легко и непринуждено позволяет собирать в несколько, группировать общеиспользуемые.
                                                                                                                                            Не хочу аппелировать к мысли о том что миллионы леммингов не ошибаются — но в этой ситуации прежде чем отмахнуться со словами "это не надо" может лучше сначала подумать — а зачем эти люди разрабатывают и использует эти инструменты? Можно спросить у самих этих людей, если сам сообразить не можешь. Но не надо натягивать свой опыт в ДРУГОЙ области к пониманию этой. Ведь по большому счету даже если взять только фронтенд — задачи которые перед ним ставятся — не ставятся в промышленных масштабах больше нигде. Никто не разрабатывет софт который ДОЛЖЕН работать на десятках платформ. Никто не разрабатывает софт который ДОЛЖЕН компилироваться десятком компиляторов. Не так часто к софту предъявляется требование легкой кастомизации интерфейса. Просто это разные области и соответсвенно разные инструменты.
                                                                                                                                            А ведь кроме фронта есть расширения для броузеров,  есть кодогенерация (swagger/raml) есть много чего чего нет в других нишах. Тут как в ресторане: не нравится — не ходи )

                                                                                                                                              +1
                                                                                                                                              > Никто не разрабатывет софт который ДОЛЖЕН работать на десятках платформ. Никто не разрабатывает софт который ДОЛЖЕН компилироваться десятком компиляторов

                                                                                                                                              Вы верстаете странички для браузера
                                                                                                                                                0

                                                                                                                                                Нет. Не просто странички и не для одного броузера.
                                                                                                                                                Так то я пишу spa, расширения для броузеров и полный фарш (фронт/бэк, кодогенерация на swagger + хранимки на plv8 вместо этих ваших orm) Это все на typescript.

                                                                                                                                                  +3
                                                                                                                                                  > Это все на typescript
                                                                                                                                                  Бедняга
                                                                                                                                                –1
                                                                                                                                                Вы понимаете что если сравнивать разработку фронтенда с разработкой пользовательского десктопного ПО то правильнее будет брать не разработку под одну платформу а сразу под весь зоопарк.

                                                                                                                                                Я не разрабатываю пользовательское десктопное ПО. Это серверное ПО.
                                                                                                                                                  0

                                                                                                                                                  А, ну это в корне меняет дело. Конечно же разработку фронта смело можно сравнивать с разработкой бэка — по сути то одно и тоже.

                                                                                                                                              +14
                                                                                                                                              > webpack такой же стандартный инструмент
                                                                                                                                              Как минимум до конца года. А там глядишь новый «стандарт» родится
                                                                                                                                                +10
                                                                                                                                                webpack такой же стандартный инструмент фронтэнда (да уже и не только)

                                                                                                                                                Для библиотеки, которой судя по ченжлогам еще трех лет нет смелое утверждение