Про то что Flow не умеет в типизацию destructuring-выражений это, конечно, печально — но думаю это всего лишь временная неувязка. По поводу ваших сетований об алгоритмической сложности «хипстерского» (wtf) кода — вы же должны понимать, что это лишь специфика вашей работы (игры?), связанной с повышенными требованиями к производительности.
В достаточно сложном проекте (ERP предприятия), работающем с кучей данных (сотни тысяч записей в таблицах, обрабатываемых на client-side) мне пришлось всего пару раз вручную написать цикл — это собственно, табличный контрол который осуществлял виртуализацию рендеринга и фильтрацию/сортировку датасетов. Во всем остальном, «прикладом» коде я с радостью использовал все прелести функциональных выражений, вообще не думая о том, насколько быстро они работают (покуда это не начинало тормозить).
Premature optimization is the root of all evil, как говорится. Я в JS пришел из C++ и дико рад, что мне в моих повседневных задачах больше не надо думать о таких вещах, как ручной менеджмент памяти или там, упаси боже, какие-нибудь cache misses. Я хочу забыть про это, как про страшный сон, и заниматься вещами поинтереснее, чем бессонными ночами думать о «протекающих абстракциях» в моем коде. Покуда он работает и работает приемлемо — я не хочу об этом думать.
Да, это все становится оправдано когда кол-во файлов переваливает за несколько десятков. Для проектов из трех-четырех файлов смысла в вебпаке, мб, никакого и нет. По крайней мере все эти проблемы я начал неиллюзорно ощущать только когда проект порядком разросся.
Но при этом мне проще мейнтейнить свой проект, т.к. каждый модуль знает только то, от чего он зависит. И плоский список всех зависимостей получается как производное от этого.
А у вас получается делокализация — скажем, я поменял модуль A так, что он теперь зависит от модуля B. И эту информацию мне нужно добавить в какое-то совершенно третье место («главный заголовочный файл», со плоским списокм всех зависимостей), в котором никак не отражена связь между модулями. Это значит, что если модуль A перестанет зависеть от B, то «мусорная» зависимость с высокой вероятностью останется в том третьем файле, потому что вы забудете про неё. Или кто-нибудь еще забудет. В общем, у меня был опыт разработки проекта где именно таким образом все делалось — я не юзал import/require для декларирования межмодульных зависимостей, и поимел все возможные связанные с этим проблемы. Самая жесть началась, когда я попытался сделать свой код re-usable, расшарив его между многими проектами. Сразу же возникает такого рода проблема, что вам нужно во всех этих проектах менять список зависимостей, когда в каком-то модуле что-то меняется. Это приводило к труднообнаружимым багам, к избыточности кода, и так далее.
Если бы я с самого начала использовал import/require и автоматическое разрешение зависимостей (webpack), то сэкономил бы кучу времени...
Ну склеивать удобно хотя бы потому, что браузер не поддерживает директивы import и require. А любой более-менее сложный проект это сотни файлов, связанных такими зависимостями.
Каким образом вы это на HTML страничку доставите? Будете вручную script теги прописывать для каждого, еще и вручную нужный порядок подключения высчитывая?
Конечно же, вы возьмете webpack, укажете ему «точку входа» (js-файл), и он разрешит все дерево зависимостей, высрав это в один файл, который вы можете банальным script тегом подключить. Как бонус — вебпак поддерживает горячую перезагрузку модулей.
Я вот буквально прямо щас настраиваю у нас в сервере Webpack HMR (hot module replacement) + React HotReload. Очень удобная вещь — я жму Ctrl-S в редактируемом модуле, и моментально получаю в браузере обновленный код, без перезагрузки страницы. А поскольку архитектура React/Redux предполагает разделение кода и данных, то при такой замене кода «на горячую», даже не теряется состояние моих компонентов. Это очень круто и дает 100% буста продуктивности.
О, замечательная штука. Меня правда больше заинтересовал Draft.js сейчас фейсбучный — т.к. он куда более примитивный, для образовательных целей больше подходит. В общем, щас буду думать, как такую механику взаимодействия реализовать для React-based редакторов, может это не так уж и сложно, как кажется. Потому что очень хочется перейти на VirtualDOM и иммутабельность состояния — плюсы от этого перевешивают все минусы, когда речь заходит о такой сложной вещи, как современные контент-редакторы.
Насчет телефонов я с вами согласен. Я вообще телефон не использую уже пару лет как — не хочу кормить зажравшихся операторов связи, которые отчаянно не хотят быть просто «трубой для данных», и ведут себя как цыгане на рынке, пытаясь обобрать пользователя до последней копейки. Это не партнерство, это не сотрудничество — это воровство… И бороться с этим можно только прекратив эти «отношения». Но это так, оффтоп :)
Но если вы думаете, что концепция «функций как объектов первого класса (first class citizen)» и замыканий вам подобным образом чем-то навредит, обокрав ваше внимание и время — то это вы зря. Мне вот есть с чем сравнивать, могу вас уверить, что это вас только обогатит, сократив ваши трудозатраты. Ну это конечно, если вы собираетесь зарабатывать написанием кода. В ином случае вам это, действительно, не нужно...
По сравнению с реактом — это голый дом, т.к. к нему прямой доступ, оно работает напрямую с его узлами (без виртуальной прослойки). На реакте я такое не знаю как сделать, мне кажется это просто невозможно на данный момент. По поводу эксепшенов я хз, я это вообще не планировал публиковать пока что, пока не отвяжу это от проприетарных библиотек. Зря я ссылку выложил.
Это просто SerafimArts панику наводит. На самом деле это не депрекейт, а просто обновляют черновик стандарта, и пока апдейт идет, из Babel временно убрали текущую реализацию (она доступна в виде внешнего плагина). Это нормальный процесс работы, и декораторы еще вернутся. Их уже юзают многие технологии популярные — например ангуляр2, mobx.
Я хаскеллом не обмазываюсь уже лет восемь, поэтому совершенно выпал из контекста — про ghcjs и purescript впервые слышу. Я про Elm-то узнал буквально на днях, когда узнавал откуда у React/Redux ноги растут. Даже не успел его попробовать толком.
И одновременно стало проще — но на другом уровне. Такой стек технологий ведь не просто так возник, это именно ответ на вызовы современности, это реакция на необходимость делать вещи, которые лет 5 назад были просто немыслимы из-за сложности реализации.
То есть оно «все усложнилось» разве что только в какой-то статичной системе отсчета… ну типа, если вы в 2016 все еще ориентируетесь на проекты уровня 2008 года, то это действительно кажется чем-то безумным. Я занимаюсь веб-фронтендом примерно с того года как раз, и прекрасно помню, как я тогда несколько недель (на голом DOM / HTML / CSS) возился с проектом, на который сегодня у меня ушел бы один рабочий день. Тогда просто не было таких инструментов.
На самом деле, код на jQuery намного дороже. Это примерно как лечить зубы у плохого стоматолога. Вроде бы дешевле, но выходит что дороже. И потерянное время вам никто не вернет.
И оправдано это именно в мегапроектах типа Фейсбука. У них тысячи компонентов, миллионы строк кода. Для маленьких же сайтов-визиток, конечно же, лучше использовать jQuery. Или вообще голый DOM (в jQuery смысла не очень много с появлением нативных селекторов).
Если это троллинг, то я на него почти повёлся. В ином случае вам стоит изучить Haskell (или его браузерную инкарнацию Elm), иначе ну нельзя же таким быть! Особенно вот это понравилось:
питон пробовал — синтаксис не понравился, скобочек нет
Я кстати уверен что в будущем люди не то что «забудут этот недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.
[...]
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Согласен, я погорячился с выводами. Просто я часто замечаю, что люди пытаются сделать из JS какой-то Java, хотя куда правильнее было бы двигаться в сторону функциональных вещей — и таким образом достигать статической верифицируемости. Собственно, я в этой статье и изложил видение того, как этого можно было бы достичь. А прототипы и динамичность языка мне нравятся именно возможностями метапрограммирования (embedded DSL), и это не очень пока совместимо с Java-подходом. Java это такой энтерпрайз-фашизм, а в JS есть дух хардкора, молодости и эксперимента. И вот это я и называю «фишкой».
Пользователю фреймворка это дает React, лол. Он был бы невозможен без этого. Я именно об этом и говорю, это не просто «быстро найти изменения», это и есть ключевой момент во всем этом. В макро масштабе.
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Ну это меня не печалит, потому что у меня свои «декораторы», которые вообще даже в ES5 работают. Я просто прикидывал, как их можно было бы реализовать, будь у нас нативный синтаксис. Хотя по мне, лучше бы они классы депрекейтнули, ха-ха.
Какие чужие? Это мои слова, и это основано на моём опыте. Я как раз делал систему классов и декораторов для ES5, и вижу какие напряги возникают с попытками перенести это на нативные ES6 классы. Я не готов отказываться от этого только для статического анализа типов, это совершенно неразумный tradeoff в моем случае.
Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.
Про то что Flow не умеет в типизацию destructuring-выражений это, конечно, печально — но думаю это всего лишь временная неувязка. По поводу ваших сетований об алгоритмической сложности «хипстерского» (wtf) кода — вы же должны понимать, что это лишь специфика вашей работы (игры?), связанной с повышенными требованиями к производительности.
В достаточно сложном проекте (ERP предприятия), работающем с кучей данных (сотни тысяч записей в таблицах, обрабатываемых на client-side) мне пришлось всего пару раз вручную написать цикл — это собственно, табличный контрол который осуществлял виртуализацию рендеринга и фильтрацию/сортировку датасетов. Во всем остальном, «прикладом» коде я с радостью использовал все прелести функциональных выражений, вообще не думая о том, насколько быстро они работают (покуда это не начинало тормозить).
Premature optimization is the root of all evil, как говорится. Я в JS пришел из C++ и дико рад, что мне в моих повседневных задачах больше не надо думать о таких вещах, как ручной менеджмент памяти или там, упаси боже, какие-нибудь cache misses. Я хочу забыть про это, как про страшный сон, и заниматься вещами поинтереснее, чем бессонными ночами думать о «протекающих абстракциях» в моем коде. Покуда он работает и работает приемлемо — я не хочу об этом думать.
Да, это все становится оправдано когда кол-во файлов переваливает за несколько десятков. Для проектов из трех-четырех файлов смысла в вебпаке, мб, никакого и нет. По крайней мере все эти проблемы я начал неиллюзорно ощущать только когда проект порядком разросся.
Но при этом мне проще мейнтейнить свой проект, т.к. каждый модуль знает только то, от чего он зависит. И плоский список всех зависимостей получается как производное от этого.
А у вас получается делокализация — скажем, я поменял модуль A так, что он теперь зависит от модуля B. И эту информацию мне нужно добавить в какое-то совершенно третье место («главный заголовочный файл», со плоским списокм всех зависимостей), в котором никак не отражена связь между модулями. Это значит, что если модуль A перестанет зависеть от B, то «мусорная» зависимость с высокой вероятностью останется в том третьем файле, потому что вы забудете про неё. Или кто-нибудь еще забудет. В общем, у меня был опыт разработки проекта где именно таким образом все делалось — я не юзал import/require для декларирования межмодульных зависимостей, и поимел все возможные связанные с этим проблемы. Самая жесть началась, когда я попытался сделать свой код re-usable, расшарив его между многими проектами. Сразу же возникает такого рода проблема, что вам нужно во всех этих проектах менять список зависимостей, когда в каком-то модуле что-то меняется. Это приводило к труднообнаружимым багам, к избыточности кода, и так далее.
Если бы я с самого начала использовал import/require и автоматическое разрешение зависимостей (webpack), то сэкономил бы кучу времени...
Ну склеивать удобно хотя бы потому, что браузер не поддерживает директивы
importиrequire. А любой более-менее сложный проект это сотни файлов, связанных такими зависимостями.Каким образом вы это на HTML страничку доставите? Будете вручную
scriptтеги прописывать для каждого, еще и вручную нужный порядок подключения высчитывая?Конечно же, вы возьмете
webpack, укажете ему «точку входа» (js-файл), и он разрешит все дерево зависимостей, высрав это в один файл, который вы можете банальнымscriptтегом подключить. Как бонус — вебпак поддерживает горячую перезагрузку модулей.Я вот буквально прямо щас настраиваю у нас в сервере Webpack HMR (hot module replacement) + React HotReload. Очень удобная вещь — я жму Ctrl-S в редактируемом модуле, и моментально получаю в браузере обновленный код, без перезагрузки страницы. А поскольку архитектура React/Redux предполагает разделение кода и данных, то при такой замене кода «на горячую», даже не теряется состояние моих компонентов. Это очень круто и дает 100% буста продуктивности.
О, замечательная штука. Меня правда больше заинтересовал Draft.js сейчас фейсбучный — т.к. он куда более примитивный, для образовательных целей больше подходит. В общем, щас буду думать, как такую механику взаимодействия реализовать для React-based редакторов, может это не так уж и сложно, как кажется. Потому что очень хочется перейти на VirtualDOM и иммутабельность состояния — плюсы от этого перевешивают все минусы, когда речь заходит о такой сложной вещи, как современные контент-редакторы.
Насчет телефонов я с вами согласен. Я вообще телефон не использую уже пару лет как — не хочу кормить зажравшихся операторов связи, которые отчаянно не хотят быть просто «трубой для данных», и ведут себя как цыгане на рынке, пытаясь обобрать пользователя до последней копейки. Это не партнерство, это не сотрудничество — это воровство… И бороться с этим можно только прекратив эти «отношения». Но это так, оффтоп :)
Но если вы думаете, что концепция «функций как объектов первого класса (first class citizen)» и замыканий вам подобным образом чем-то навредит, обокрав ваше внимание и время — то это вы зря. Мне вот есть с чем сравнивать, могу вас уверить, что это вас только обогатит, сократив ваши трудозатраты. Ну это конечно, если вы собираетесь зарабатывать написанием кода. В ином случае вам это, действительно, не нужно...
По сравнению с реактом — это голый дом, т.к. к нему прямой доступ, оно работает напрямую с его узлами (без виртуальной прослойки). На реакте я такое не знаю как сделать, мне кажется это просто невозможно на данный момент. По поводу эксепшенов я хз, я это вообще не планировал публиковать пока что, пока не отвяжу это от проприетарных библиотек. Зря я ссылку выложил.
Practice makes perfect… Или «дорогу осилит идущий». Вы же просто не хотите идти.
Смешно как раз то, что от скобочек-то кровь из глаз и течет, а вы это «приятным синтаксисом» называете. Вспоминается автомобиль Гомера Симпсона сразу.
Это просто SerafimArts панику наводит. На самом деле это не депрекейт, а просто обновляют черновик стандарта, и пока апдейт идет, из Babel временно убрали текущую реализацию (она доступна в виде внешнего плагина). Это нормальный процесс работы, и декораторы еще вернутся. Их уже юзают многие технологии популярные — например ангуляр2, mobx.
Я хаскеллом не обмазываюсь уже лет восемь, поэтому совершенно выпал из контекста — про ghcjs и purescript впервые слышу. Я про Elm-то узнал буквально на днях, когда узнавал откуда у React/Redux ноги растут. Даже не успел его попробовать толком.
И одновременно стало проще — но на другом уровне. Такой стек технологий ведь не просто так возник, это именно ответ на вызовы современности, это реакция на необходимость делать вещи, которые лет 5 назад были просто немыслимы из-за сложности реализации.
То есть оно «все усложнилось» разве что только в какой-то статичной системе отсчета… ну типа, если вы в 2016 все еще ориентируетесь на проекты уровня 2008 года, то это действительно кажется чем-то безумным. Я занимаюсь веб-фронтендом примерно с того года как раз, и прекрасно помню, как я тогда несколько недель (на голом DOM / HTML / CSS) возился с проектом, на который сегодня у меня ушел бы один рабочий день. Тогда просто не было таких инструментов.
На самом деле, код на jQuery намного дороже. Это примерно как лечить зубы у плохого стоматолога. Вроде бы дешевле, но выходит что дороже. И потерянное время вам никто не вернет.
И оправдано это именно в мегапроектах типа Фейсбука. У них тысячи компонентов, миллионы строк кода. Для маленьких же сайтов-визиток, конечно же, лучше использовать jQuery. Или вообще голый DOM (в jQuery смысла не очень много с появлением нативных селекторов).
Спросонья показалось, что это какая-то операционка сделанная на ReactJS, лол. Надо меньше упарываться фронтендом...
Если это троллинг, то я на него почти повёлся. В ином случае вам стоит изучить Haskell (или его браузерную инкарнацию Elm), иначе ну нельзя же таким быть! Особенно вот это понравилось:
Согласен, я погорячился с выводами. Просто я часто замечаю, что люди пытаются сделать из JS какой-то Java, хотя куда правильнее было бы двигаться в сторону функциональных вещей — и таким образом достигать статической верифицируемости. Собственно, я в этой статье и изложил видение того, как этого можно было бы достичь. А прототипы и динамичность языка мне нравятся именно возможностями метапрограммирования (embedded DSL), и это не очень пока совместимо с Java-подходом. Java это такой энтерпрайз-фашизм, а в JS есть дух хардкора, молодости и эксперимента. И вот это я и называю «фишкой».
Пользователю фреймворка это дает React, лол. Он был бы невозможен без этого. Я именно об этом и говорю, это не просто «быстро найти изменения», это и есть ключевой момент во всем этом. В макро масштабе.
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Ну это меня не печалит, потому что у меня свои «декораторы», которые вообще даже в ES5 работают. Я просто прикидывал, как их можно было бы реализовать, будь у нас нативный синтаксис. Хотя по мне, лучше бы они классы депрекейтнули, ха-ха.
Какие чужие? Это мои слова, и это основано на моём опыте. Я как раз делал систему классов и декораторов для ES5, и вижу какие напряги возникают с попытками перенести это на нативные ES6 классы. Я не готов отказываться от этого только для статического анализа типов, это совершенно неразумный tradeoff в моем случае.
Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.