Comments 505
При этом удивительно что достаточно полного es6 до сих пор нет даже в Firefox / Chrome. В IE нет даже arrow functions! Это при всей продвинутости их виртуальных машин, большом количестве ресурсов, контрибьюторов — казалось бы дело нескольких месяцев. Такое ощущение что Javascript специально искусственно загоняют в рамки убогой кросс-трансляции, вынуждая программиста использвать огромный tool chain.
Скажи какому разработчику Python / Java / PHP что для использования последней версии языка ему нужны кросс-трансляторы вместо нормального интерпретатора с байт-кодом, удивятся. А в мире Javascript это "норма" и даже пишутся статьи в защиту такого подхода.
Слава Богу можно разрабатывать большие приложения в обычном ES5 без кросс-трансляции, используя Knockout.js или Backbone, да и в React тоже (хоть и сложнее).
Разработчику на той же Java, вообще-то, нужен целый компилятор чтобы его код можно было запустить...
Что ж в этом хорошего?
Ничего. Как и плохого. Просто особенность языка, делающая "кросс-трансляторы" с одной версии языка на другую принципиально ненужными: программист может поставить себе нужную версию компилятора и использовать ее, ему не нужно подстраиваться под зоопарк возможных устаревших клиентских интерпретаторов.
Хотя я не удивлюсь если в удивительном мире Java для Android однажды кросс-транслятор таки появится.
Хотя я не удивлюсь если в удивительном мире Java для Android однажды кросс-транслятор таки появится.
Уже есть, вроде: https://github.com/orfjackal/retrolambda
UPD. Ого, там кроме retrolambda есть целый зоопарк для перекомпиляции в более старые версии Java.
В node.js поспевает.
В браузерах уже.
Поэтому и ждать уже особо и нечего :)
Присоединяюсь. Для тех, кто просто интересуется трендами в разработке, очень полезно оказалось. Я не профессиональный JS разработчик, знаю язык, но кухни последних лет совсем не знал, благо теперь яснее стало!
Через 20 минут ковыряний у меня были установлены node.js, npm, webpack, bower (зачем-то), гит показывал 300+ добавленных файлов, а я не понимал, нафига мне всё это — ведь я хотел только bootstrap.min.js
гит показывал 300+ добавленных файлов
А в .gitignore вы их добавить не пробовали? :-)
Но до того, как я это сделал я был удивлен количеством файлов, которые были добавлены ради bootstrap.min.js, который был мне нужен.
А мне, к примеру, эти файлы очень даже пригодились. Когда меня не устроили стандартные отступы в бутстрапе — я просто создал свой less-файл, подключил туда bootstrap.less и переопределил несколько переменных.
Если бы bootstrap поставлялся без исходников — этот сценарий был бы невозможен.
Хотя я бы на их месте просто предоставлял два пакета вместо одного (bootstrap и bootstrap-source к примеру).
Я не критикую существующие методы и не говорю, что те 300 файлов были бесполезны. Просто я пропустил мимо себя новинки последних 5ти лет разработки на фронтенде и для меня переход от старой парадигмы с включением кучи своих файлов и локальных библиотек к сборке файлов при помощи бандлера и диспетчера пакетов был слишком резким — я слишком удивился количеству файлов в node_modules и не очень понимал их назначение.
Ваш же пример раньше решался тем, что программист сначала включал some_framework.css, а после него включал my_own_styles.css, в котором переопределял все интересующие его классы. А о такой штуке как less и переменные в css я до недавнего времени не слышал =)
Уж простите нас — динозавров =)
Так я потому и рассказываю...
Ваш же пример раньше решался тем, что программист сначала включал some_framework.css, а после него включал my_own_styles.css, в котором переопределял все интересующие его классы.
Этот подход плох тем что надо много писать руками. А еще в результате много правил будет в разных файлах дублироваться. В моем же варианте достаточно было десятка строчек.
Пардон, а нет ли тут опечаток и смысловых ошибок?
Понятно, что это только инструмент для разработки, но что же там такого «нужного» на 3 гигабайта? Хотелось бы иметь более изящное решение.
не знаю что у вас там за пакеты, у меня любой крупный проект тянет за собой около 100мб node_modules модулей
{
"name": ".....",
"version": "0.0.1",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-sourcemaps": "^2.5.0",
"gulp-stylus": "^2.6.0",
"gulp-util": "^3.0.8",
"jeet": "^7.1.0",
"nib": "^1.1.2"
}
}
В git не уходит, конечно же.
но что же там такого «нужного» на 3 гигабайта?
ну так package.json в студию, мы вам расскажем ))
Попробуйте свежую ноду поставить. Или возьмите вместо npm использовать yarn.
Меня вот что удивляет: все эти пакеты в обязательном порядке тащат тесты. Зачем оно нужно конечному пользователю?
Вот к примеру, пакет es5-ext. 787 файлов, 500 Кб. Подкаталог tests 380 файлов, 113 кб.
Нет, я понимаю пользу тестов при разработке. Но в "дистрибутиве" пакета на продакшене какой в этом смысл?
У нас в одном из проектов сборка CSS (stylus + autoprefixed) и JS (babel + rollup) через gulp. Папка node_modules весит 20,7МБ (40,1МБ на диске). Что может занимать 3ГБ, я даже не представляю.
необходимость искать и скачивать новые версии библиотек при каждом их обновлении
ЩИТО? Переход на новую версию библиотеки — это отдельная процедура. Прежде чем переходить — нужно быть уверенным в совместимости старого кода с новой библиотекой.
Автоматическое обновление всего, что поддаётся обновлению — весьма вероятно сломает проект. Только отдельные особо доверенные библиотеки от авторитетных команд разработчиков достойны того, чтобы мониторить их обновление и систематически переходить на новую версию.
npm up lib@42 С этим — согласен. Однако скачивание — меньшая из проблем при переходе на новую версию библиотеки.
А большая из проблем — локальные изменения в коде библиотеки. Подход с автоматическим скачиванием библиотеки гарантирует что локальных изменений в ней не будет (и обратное тоже верно — если 3 библиотеки установлены через npm, а четвертая лежит просто файлом — значит, в ней точно есть местные доработки).
1) не заливать все сторонние библиотеки в репозиторий проекта,
2) чтобы установить все и разом командой `npm i`, а не заходить на сайт каждой и искать где там кнопка скачать.
Когда необходимо обновить конкретную библиотеку, после обновления проводится тестирование перед выкатыванием на продакшн. Зарплаты считаются сперва в старой работающей версии, а потом в новой проверенной работающей версии.
Прекрасный пример — питоновый PyPI, в котором лежат заранее собранные пакеты для всех архитектур для всех ОС (если об этом позаботились разработчики пакета, конечно); таким образом для установки каких-нибудь lxml или Pillow, написанных на чистой сишечке, ставить gcc не придётся. В итоге всё, что чаще всего делает pip install — качает whl-пакет и распаковывает куда надо. Каким бы сложным пакет ни был. Ничего никуда собирать не надо — всё сразу готово хоть для продакшена.
Не знаю, есть ли что-то аналогичное для жс (может и есть, однако на сайте npmjs.org я заранее собранных пакетов не нашёл), но то, что все ставят исходники пакетов через npm i и потом сами собирают всё бабелем вместо скачивания заранее собранного — явно ошибка эволюции жс :) (Но если я не прав и такое есть — просьба ткнуть меня носом, возможно я стану использовать такое в своих проектах)
Пакеты, готовые для исполнения на сервере через node.js, или пакеты для использования на клиенте?
И те, и другие. Если продолжать аналогию с питоном, то там все пакеты и так только для «сервера», и многие из них заранее собраны, чтобы не требовать установки местных аналогов бабелей (gcc, cython и прочий dev-хлам. При желании можно их поставить и собрать пакет самостоятельно через pip install --no-binary, но зачем, если всё уже собрано для нас?).
бабелем
А должно быть без бабеля! Я вот набрал, к примеру, «npm install jquery» и появился каталог node_modules, в котором несколько мегабайт нахрен не нужного хлама. Единственный нужный здесь файл — node_modules/jquery/dist/jquery.min.js 85КБ — вот только он и должен был скачаться (ну, может, плюс минимально необходимая мета-информация). В PyPI с pip дело обстоит именно так (с поправкой на питон). Я буду очень рад, если найдётся общепринятый аналог такого «минимализма» для жс (bower и yarn по умолчанию так же качают несколько мегабайт хлама, предположу что потому что сайт npmjs, в отличие от PyPI, собранные пакеты просто не хранит)
node_modules бабелем не обрабатывают
И не надо обрабатывать node_modules бабелем! Надо скачивать заранее обработанное. В node_modules исходников библиотек вообще не должно быть ни в каком виде. А сейчас они есть. И это отвратительно.
(Вообще у меня есть сомнения в правдивости высказывания «node_modules бабелем не обрабатывают», но для проверить не хватает соответствующих знаний)
И никто не мешает вообще не пользоваться бабелем и не подключать его в проект.
Не мешает, я и не подключаю. Только вот получается две крайности: или подлючать несколько гигабайт nodejs-окружения со всеми исходниками всех зависимостей, или скачивать jquery.min.js вручную и класть его в репозиторий. Промежуточного варианта — скачивать только jquery.min.js автоматически с репозитория с плюшками типа автоматического обновления — нету, и это отвратительно.
Я вот набрал, к примеру, «npm install jquery» и появился каталог node_modules, в котором несколько мегабайт нахрен не нужного хлама. Единственный нужный здесь файл — node_modules/jquery/dist/jquery.min.js 85КБ — вот только он и должен был скачаться (ну, может, плюс минимально необходимая мета-информация).
Это особенность jquery, где решили включить исходники в пакет тоже.
пакеты npm никогда не были нацелены и оптимизированы под использование вне экосистемы commonjs
Ну и зря
cdnjs
О, круть) Но, я так так понимаю, общепринятых аналогов npm install и package.json с описанием зависимостей для cdnjs нету? Или плохо искал?
Попробуйте unpkg. Этот сервис дает доступ к файлам из npm-модулей.
https://unpkg.com/jquery выдаст вам искомый jquery.js файл.
Хотя с другой стороны можно указать точный путь к файлу, но, во-первых, есть сомнения в стабильности такого решения, во-вторых, тогда я уж сам могу скачать архив и распаковать оттуда только то, что мне надо)
Значит авторы React и boostrap не удосужились прописать нормальные метаданные, где у них находится упакованный бандл. Прямые линки для react и bootstrap работают:
https://unpkg.com/react@16.0.0/umd/react.production.min.js
https://unpkg.com/bootstrap@3.3.7/dist/js/bootstrap.min.js
Еще про unpkg: если добавить слеш в конец url, то вместо файла он вернет листинг директории: https://unpkg.com/react/ Таким образом я и нашел где в пакетах бандлы лежат.
Тут дело не в npm/yarn, а в авторах конкретного пакета, которые в пакет включают и исходники, и тесты, и документацию с примерами — проще говоря включают весь репозиторий проекта, вместо его папочки dist/build.
Не заливать сторонние библиотеки — это мегакосяк ) Когда в ваш проект через 10 лет понадобиться внести минимальное изменение, вы не найдете процентов 50 библиотек, а те которые найдете сменят уже три-четыре мажорных релиза и не будут работать в нужном вам окружении 10 летней давности. Желание взять все и переписать оно похвальное, но денег почему-то на это не дают )
Ну и про расчет зарплаты у вас сказочные представления ) Ситуация выглядит так: сегодня нужно сдать отчет, 1с выкатывает релиз с "последними" исправлениями, релиз ставится.
"Проверить" релиз сил не хватает даже у 1с, поэтому косяки там встречаются. Отчет — это условный мегабайт кода нетривиального, делать его своими силами может себе позволить мало лишь кто. Откатиться на предыдущий релиз может быть очень сложно, потому что при повышении релиза добавляются/удаляются поля базы данных, для заполнения которых при повышении 1с пишет скрипты, для понижения релиза скрипты не пишет никто, поэтому база может вообще перестать работать. Обновить копию, проверить, заменить рабочую — это остановить работу бухгалтерии и кадров на день, т.к. перенести данные которые они введут, исправят, удалят за рабочий день пока мы будем упражняться с копией может опять же мало лишь кто, ну и отчет горит
Когда в ваш проект через 10 лет понадобиться внести минимальное изменение, вы не найдете процентов 50 библиотек, а те которые найдете сменят уже три-четыре мажорных релиза и не будут работать в нужном вам окружении 10 летней давности.
Это как раз ситуация без использования пакетного менеджера. Потому что пакетный менеджер как раз позволяет зафиксировать зависимости и выкачать через 10 лет ту самую версию с которой код раньше работал.
Ну а если боитесь реформ на стороне центрального репозитория — всегда можно завести свой репозиторий пакетов.
Для решения этой проблемы есть стандарт semver. При подключении библиотек менеджеры пакетов ставят в файле-списке пакетов символ ^ перед версией пакета, что означает «подойдёт любая версия, совместимая с указанной». Так при обновлении библиотек через менеджер пакетов не произойдут обновления, ломающие обратную совместимость. Но всё это работает, если авторы библиотек достаточно ответственно следуют semver.
(если вам вдруг нужен mvc на фронтэнде — вы что-то делаете не так)
А на диск пишет именно хром. И я уже выяснил, что ледо в web-версии телеграмма.
Так это узнать не проблема. Процесс браузера пишет какие-то данные в файл с ничего не говорящим названием в скрытой папке temporary internet files. Проблема в том, что я не понимаю, какой из десяти открытых сайтов и что там хранит.
Что не так конкретно?
попробовал«А включать-то пробовали?» :D
Нет, ну ладно, примем, что для вебсофта 100 мб это «идеально»… Но в реальности это достижимо только при условии «не включать». %) То есть практически не пользоваться по назначению. Как в случае с браузерами — открывать две-три вкладки за сессию.
f6.s.qip.ru/etSMzb2V.png
Это тоже самое если я сейчас топовую игру запущу и буду жаловаться что она требует 8 ГБ оперативки.
У вас всегда есть выбор, взять десктопную версию приложения.
Если вы открываете 100 вкладок за сессию, то это ваша проблема, я же не открывать 100 фотошопов.
Я о «десктопе» и говорил, но, на самом деле-то нет никакой «десктоп версии», в этом и прикол! :D Это ровно тот же сайт, только крутится в электроне. Нет никакого выбора! %)
Не «если» открываю 100 вкладок, а «когда», потому что чатик — это не то же самое, что браузер (хотя и со страницами та же история, но это более общая тема), и у меня может быть сколько угодно контактов там, и их число не уменьшается. И проблема совсем не на моей стороне, я могу (и открываю) 100 вкладок в чем-то, отличном от электронных поделок и мне норм. :) А про 100 фотошопов — ооо, не надо так опрометчиво зарекаться-то, придет время и пооткрываете «фотошопы» во вкладках, уже вон в веб-версии переезжает все. ;)
Меня все устраивает, мне не западло потратить 150 Мб оперативки и 200 мб памяти на жестом диске.
Я вот недавно какой-то софт устанавливал ан комп, весил он 20 метров
. только вот он меня попросил скачать NET framework в 200 метров, по сути все тоже самое выходит, километровый софт ради простой задачи!
Мобильная разработка вас устаривает в 2017 году?
Я скачивал приложуху дял финансов весит она 200 метров.
Скачивал игрушку, весит 1 гб.
Меня все устраиваетВот в этом и проблема. :) Люди такие люди, к достатку привыкают быстро…
И опять же, 150 метров — меня бы тоже устроило (в десктопном софте на кутях это типа норма), но речь-то идет о гиг-полтора! :)
С дотнетом отдельная беседа. И я их тоже стараюсь не трогать, но дотнет уже с виндой идет, выбора особо нет. С жабой примерно так же получается, хотя ее уже чаще таскают с собой, но еще не так часто, как электрон.
Меня — не устраивает, но я ее и не трогаю, мне нравится десятилетней выдержки. %)
Игрушку могу понять на гиг, там грофоний (2017 год опять же), а мобилы это как компы старые, когда как раз на гиг игры уже были. А приложуха, почти уверен, слабана на электроне или типа того, шоб сразу на все платформы деплоить.
Но что, Вас и это тоже устраивает?
— Самое интересное, что я не могу пока понять, откуда такое желание защищать текущее положение дел, особенно учитывая вот это коммент по которому видно, что автор полностью осознает причины происходящего. :)
Экономия на сотрудниках.
Позволительно когда проекты не сложные и высокие знания особо не нужны.
Не знаю какой привести пример, но если вы делаете что-то типа: «Показать записи, сгруппировать, вывести комментарии, показать среднее число постов в сутки, отправить данных на клиента, добавить, отредактировать», то вам не нужен крутой бекендер, там особо много ума не нужно, подойдет и фронтендер со знаниями бека.
Если это что-то реально серьезное нужно сделать на беке, то такой разработчик уже будет плох.
chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg
Расход оперативки снизится на 90%.
Теперь вместо 40 вкладок у вас будет висеть только 1 вкалдка в оперативной памяти.
Это одна из альтернатив, уверен что существуют браузеры которые делают так по умолчанию.
Это на случай если вы не современный человек и у вас старое железо и 1ГБ оперативки.
Что касается электрона, я тоже хочу что бы все приложения в мире занимали по 5МБ памяти, вместо 300 мб.
Только вот софт такой стоить будет не 50 баксов, а 1000 баксов.
Потому что цена разработки повысится, а нафиг это нужно? я лучше уж оперативку куплю за 1000 рублей, чем буду вечно переплачивать гуру программистам.
но почему меня это не тревожит? А потому что оперативная память стоит очень дешево, я покупал 5 лет назад 2 планки по 4гб за 3500 рублей и мне это хватает по сей день, даже с избытком Вот если бы планки стоили по 30 000 рублей, тут бы я был зол. таких людей как я еще 95% на всей планете и всех всё устаревает.
Цена на софт раньше почему-то не была выше, не надо вот. :3 Не цена разработки повысится, а скорость понизится, ну и снизится возможность использования веб-макак, само собой. Переплачивать приходится именно сейчас, тем, что покупать железо ТОЛЬКО ради ТЕХ ЖЕ задач, которые были решены уже пять-десять лет назад. %)
Именно так, 95% и всем норм. -_-
Тут конечно зависит от много факторов, например от уровня компании, маркетинга, спроса и так далее, давайте рассмотрим фрилансера.
Я не хочу платить 10000 баксов гению низкоуровневого программирования фрилансеру, который будет пилить свой софт 2 года под все платформы.
Я лучше заплачу 100 баксов макаке (как вы выражаетесь) который быстро решит мою задачу и решит ее не хуже.
Мне проще докупить оперативную память за 1000 рублей, что я кстати сделал еще 6 лет назад и вам советую сделать тоже самое. :)
Можете рассказать какое у вас железо стоит?
Я покупал свой комп около 5-6 лет назад и он до сих пор тянет весь софт, сайты и прочую фигню,
Вот игры перестал тянуть, но там видюха слабая просто :)
А вот я — хочу! Разумеется, 10 тыщ бачей не в одну каску, а вскладчину (и получается %кикстартер%), и опять же ошибка — платит разрабу не пользователь, а босс. Фрилансер тоже работает на босса — заказчика, кстати.
Так я не понял… ДЛЯ ЧЕГО память покупать? %) Если все и так тянет?
У меня примерно такая же жестянка, но сейчас я сижу на еще более старом ноуте.
Кстати да, тут уже давно должны были набежать с факелами и вилами владельцы модных ноутов, где память распаяна… %)
Срок — 1 сутки.
Приложение простое, нужно разбивать загруженный текст на слова и делать по ним перевод через Yandex api + из полученных слов формировать цепочку карточек и показывать их в очереди.
Около 50-100 строчек кода на JS не считая визуализацию блока.
А вот хрен вы сделаете, вы запросите 500 баксов) потому что вам надо будет подключить к проекту еще 3 программиста и сроки увеличатся до недели.
Вот о чем речь.
Цену устанавливаете вы, но и конкурентов у вас много на такую легкую задачу.
А деньги работодателю приносят конечно не пользователи, а дедушка мороз.
таких людей как я еще 95% на всей планете и всех всё устаревает.
Б#$, да откуда же вы такие берётесь-то?
60% на всей планете не выходили в интернет ни разу в жизни
Половина всех детей на планете страдает от голода.
я покупал 5 лет назад 2 планки по 4гб за 3500 рублей
Для одной пятой населения планеты это 4 месяца работать и ничего не есть.
Какие к чёрту 95%?
Десктопная версия слаки или дискорда — это ровно то же самое "веб-приложение", просто в другой обёртке. Как следствие — те же самые (+на обёртку) проблемы с памятью и всем прочим.
P.S. Я уж не говорю о том, что дискорд просто обожает коллекционировать устаревшие копии себя, а каждая такая копия по 120 мегов. И лежат они разумеется где попало, а не в ProgramFiles.
Сейчас веб-версию слака сильно переписали в лучшую сторону. Десктопная версия пока что ужас-ужас. =(
Vue хорош всем, кроме того, что нужно дважды описывать модель во фронтенде и бекенде. Моя мечта написать backend defined frontend. Раз делал с jquery такое, но не до конца.
Наиболее очевидный путь — это ORM на JS, умеющая фронтенд. Но не все хотят JS на бэкенде…
А еще есть PouchDB, которая синхронизируется непосредственно с CouchDB. Но вот CouchDB использовать не очень хочется, да и не всегда нужно тащить данные на клиент.
К сожалению, не правильно поняли. Самое близкое это JamPy. Но оно больше всего подходит для работ с БД. Я говорю про следующую систему:
У Вас есть готовый макро/микро-сервис. Вы просто направляете скрипт на описательный запрос и singleapp интерфейс генерерируется автоматически с socketio соединением и со всеми ограничениями и какими-то дефолтными настройками для этого. Все работает с серверной части для защиты endpointа ну и реалтаймовости интерфейса. Было бы круто сделать что-то вроде:
route(endpoint_uri, endpoint_custom_name or domain_name, timeout, schema_uri or custom_schema)Я делал подобную систему, но надо было делать быстро, поэтому пришлось все выкинуть и спуститься на землю и описать клиентскую часть, серверную часть и еще и микросервис.
У меня еще этот говнокодец для mongoengine 0.8 ORM сохранился где-то. Конвертировало поля в list/dict и можно было работать и с референсами тоже. Только фронтенд я писал очень криво, шло определение по датаатрибутам, что делать и куда вставлять данные
Прелесть такой системы, в том что неважно, что в бекенде. Фронтенд прелоадит отображение и цсс согласно темплейтам, а функционал работает в серверсайде, преобразуется любой апи в соответствующие команды этой системы.
Допустим у нас апи клиентского раздела. Клиенту выдается сначала темплейт логин, после логина выдается темплейт интерфейса, если len(route) == 1 то сразу интерфейс апи, если len(route) > 1 то интерфейс каждого апи скрыт под submenu.
Рут получает на входе credentials которые либо пересылаются в endpoint, либо обрабатываются декоратором и накладывают лимиты (апи фаерволл), согласно настройкам.
В дефолте, сделали API для почтового сервера и сервера хостинга например. Запустили такую программу и все — кормите пользователей. Либо напрямую, либо пишите фаерволл на апи, для допустим ограничения имени пользователя для endpoint...
@authorize(user)
route('wss://mailserver', 'Mail', 10, 'wss://mailserver/api_help')
@authorize(user,firewall_schema)
route('https://rest.cpanel.lan/', 'Web', 10, 'https://rest.cpanel.org/schema')Я примерно описываю. Моя слабость фронтенд написать. Например пока не знаю, как заставить vue динамически получать и обрабатывать темплейты и экстенжны через socketio
Я уверен это бы ускорило бы создание стартапов и сервисов на очень много.
Ну, если Вы пишете сайты, то, вероятно такой подход годится. Я лично пишу не их, мне mvc на клиенте необходим.
Т.е. удобство бандлинга действительно перекрывает тот факт, что клиенты в каждого приложения таскают одно и то же в составе различных многомегабайтных плюх?
Библиотек становится больше, новые версии выходят чаще — и вот уже вероятность что все это у клиента есть в кеше околонулевая. А если в кеше нет хотя бы одного модуля — то его загрузка по времени сравняется со временем загрузки всего бандла.
Плюс любой CDN — это риски: он может перестать отдавать файл или начать тормозить и вы об этом никак не узнаете. Причем в последние годы на территории РФ эти риски многократно возросли.
Даже не "в РФ в последнее время" а в мире вообще.
И не только по причине политических причин.
Со своим сайтом я столкнулся с одной политической и двумя техническими проблемами (кривая маршрутизация у отдельных провайдеров).
Второе даже неприятнее — ибо хрен вычислишь если проблема только в отдельных городах.
Наш мир становится все более зависимым от интернета. И лучше, имхо, по возможности иметь большее влияние на используемые сервера.
Да, большие видео и много фото — есть смысл в CDN.
Но для обсуждаемых здесь файлов JS — напротив — CDN это дополнительное слабое звено, согласен с вами
Библиотек становится больше
Ну так не надо лепить все эти тысячи популярных библиотек в свой проект ради мелких финтифлюшек и кусочков сахара, которые они дают. Если мы будем на каждый чих тащить пакет — так и будет эта проблема вечной.
Во-вторых, можно указать какие вендоры будут резолвится с сдна.
Каждый решает сам что ему важнее.
А еще ломается вот такая офигенная (к сожалению, в прошлом) штука: https://addons.mozilla.org/ru/firefox/addon/decentraleyes/
После того как я столкнулся с тем, что мой сайт, хостящийся у Google в GAE, не видим для Крыма. А после переезда на сервера в РФ — не видим как минимум в двух немелких городах (проблемы маршрутизации местных хостеров). После третьего переезда — не видим в других трех крупных городах....
После чего я стараюсь минимизировать зависимость сайтов от внешних серверов.
Свои ты хоть как то контролируешь и можешь вовремя заметить и принять меры
с решением проблем использования возможностей ES6 в старых браузерах, с минификацией и с бандлингом?
Справедливости ради, стоит сказать, что проблем с использованием ES6 в старых браузерах, с минификацией и с бандлингом в принципе не существует. ES6 — это всего лишь инструмент, а не проблема. Без него вполне можно жить, а главное, нельзя сказать, что это существенно снизит продуктивность разработки.
1) пофиг на поисковики,
2) а бэкендщики не хотят делать HTML, они хотят
Старый добрый jQuery не очень умеет делать V из REST API.
И так пока не попался на глаза vue. Теперь взял и переписал простенький сайт с применением vue — скорость создания возросла раз в 10, количество ошибок меньше (заметно на глаз, даже без метрик). Писать — одно удовольствие. Не зря его хвалят, рекомендую. Буду использовать и в серьезных проектах, однозначно.
Просто попробуйте, поймете что jquery и ванилла — это хорошо, но точно не везде и не всегда.
А вообще вопрос немного некорректен. Потому что не задача под технологию, а «вот эту задачу лучше решать так». Можно, если поднапрячься, придумать почему vue может быть очень полезен даже на домашней страничке. Ну как самое простое что в голову пришло — быстрое прототипирование. И можно придумать почему его не стоит использовать в мега-супер-проекте.
Кроме того если освоить связку vue\vuex + .core получаются очень неплохие результаты. Быстро, красиво, удобно, приятно. И код приятно посмотреть и работает отлично. (Оговорка — конечно не всегда и не для всех задач)
Иногда можно и простые вещи на этом мегакомбаине делать потому что есть уже готовый набор темплейтов, сниппетов, настроек CI и т.п. Так что если это имеет смысл — можно и страничку Васи Пупкина сделать на стеке который нравится и под рукой. Оверэнджиниринг? Да. С другой стороны знаю случаи когда такая страничка перерастала в мегапортал. (тут есть доля шутки).
Простите за Капитана Очевидность™ но вы первый начали (шутка)
Для тех кто читает только комменты: в статье речь идет о инструментах для разработки и поддержки.
Славно, что я не фронтендщик. Верная смерть
Слушал как-то лекцию по Webpack — понял, что если его не контролировать, со временем он может внутри бандла зародить жизнь, построить цивилизацию и устроить пару госпереворотов.
Не нужно зубрить весь синтаксис как в школе.
Сколько вам потребовалось изучить GULP? годы? Перелопатили все пакеты?
Мне ровно 30 минут, я понял общую концепцию посмотрел популярные библиотеки.
И кстати я уже забыл как он работает, что бы освежить память мне нужно зайти на их сайт, прочитать около 10 строк текста.
Webpack?
Настроил 1 раз конфиг и забыл про него на пол года.
Вышла новая фича — прочитал про нее — и перенастроил свой старый конфиг (используешь его под все проекты).
Вышел новый Webpack _ прочитал нотацию о миграциях, переписал либо остался со старой версией
Знания нужны и если хотите делать как надо, а не чтобы работало — за неделю никак не осилить. Имхо, конечно
И не стоит забывать, это npm и webpack — это всего лишь инструменты, упрощающие разработку. Их знание не делает вас фронденд-разработчиком.
Я динозавр и у меня остался вопрос: как отлаживать?
Я так понял, что мне надо собирать проект каждый раз для запуска в браузере. А после сборки, а тем более — транспиляции, код будет не похож на то, что я писал, и ошибки, бросаемые браузером, мне нужно — как-то сопоставлять с исходниками.
А тут либо выставлять sourceMap. Либо дебажить "как есть". К сожалению, sourceMap очень часто уступает второму подходу, хотя и визуально приятнее. В особенности когда вы привыкли во время дебага что-нибудь править на лету в консоли. К примеру вместо this.someVar на деле может быть _this.someVar. А вместо libraryFunction будет (0, _libraryFunction3.default). В общем тут на вкус и цвет. Страдать и дебажить огромные монолитные портянки babel-я, но видеть всё как есть и иметь больше возможностей, или же быть ближе к коду, но то и дело сталкиваться с какими-нибудь странностями.
А какая связь между заворачиванием в замыкания и осознанным динозавром?
что делает отладку через консоль невозможной в принципе
А зачем для отладки через консоль доступ к переменной из глобальной видимости? Ставите breakpoint или debugger, дожидаетесь срабатывания, открываете консоль и пишете в рамках видимости текущего стек-кадра. Очень сильно помогает в решении сложных debug-задач.
А ещё частенько выручает на сторонних сайтах. Смотрите event-listener-ы нужных вам DOMelement-ов. Изучаете их callback-и ("развернув" код). Ставите в нужном из них точку останова. И вуаля. Есть доступ к чему угодно, можно делать что угодно. Манкипатчить функции, утащить значение какого-либо объекта, провести какие-нибудь эксперименты и пр… Ну в общем базовые debug-вещи.
При использовании import-export системы модулей у вас все файлы по умолчанию обёрнуты в замыкание. Чтобы что-то навязать в глобальную область — это нужно сделать руками (window.blabla =, global.blabla =).
В исходный код расширений тоже залезть проще пареной репы. Покопайтесь в web developer tools. Там столько всего вкусного есть… Времена когда инструментарий frontend разработчика был деревянным давно прошли.
Мы, кажется, понимаем под словом debug с вами очень разные вещи. Если вам нужно публичное API — сделайте его. А если вам нужное публичное API для сторонних независящих от вас вещей — напишите им об этом в issue, или сделайте pull request, или просто свой fork, где будет всё по вашему. А для debug-а всё есть и область видимости слабая помеха.
Если вам нужно публичное API — сделайте его.
Я-то делаю, за меня волноваться не стоит.))
А если вам нужное публичное API для сторонних независящих от вас вещей — напишите им об этом в issue, или сделайте pull request
И все так сразу взяли, меня послушали и по-быстренькому запилили / приняли пулл-реквести, ага. Если бы всё так было в реальности, я бы тут не ныл про юзерскрипты. Один знакомый не-динозавр наоборот закрыл на своём сайте почти всё публичное API, несмотря на массовые протесты юзерскриптоделов, включая меня. При этом проблемы, которые ранее исправлялись юзерскриптами, исправлять, естественно, не стал.
или просто свой fork
Который будет никому не нужен. Огромное количество сайтов (включая вышеупомянутый) живёт в интернете только за счёт контента и аудитории, и если контент ещё можно кое-как скопировать (чем я старательно занимаюсь в свободное время, держа собственные копии некоторых сайтов), то аудитория будет переходить крайне неохотно, если вообще будет — пока технические проблемы не станут совсем уж невыносимыми. А будь форк сколь угодно крутым — какой в нём смысл, если народа не будет? Если разработчики отзывчивые, баги фиксятся, пулл-реквесты принимаются — проблема «замкнутого» API не столь остра, но ведь так бывает не всегда, и в моей практике «бывает» очень редко.
А для debug-а всё есть и область видимости слабая помеха.
Но помеха. Зачем эта помеха существует?
Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?
Но помеха. Зачем эта помеха существует?
Зачем существует область видимости? Масса причин. Загуглите. Кстати говоря, на подходе приватные поля классов (#someProperty). Так что помех будет ещё больше.
Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?
Проблемы индейцев шерифа… ;)
Вот объясните, зачем нужно указывать name, version, description, author, license и main если делается не общая библиотека, а веб-приложение или вовсе сайт? Кстати, вы еще repository забыли в список добавить. Не удивлюсь если эти поля в package.json самим своим существованием отпугивают динозавров...
Для приложений достаточно { "private": true } и все. Или можно даже просто {} (пустой объект) в файле написать — npm будет кидать несколько варнингов, но работать.
В 2017 ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript, даже нужно, если вы делаете простую верстку лендинга, а не полноценное веб-приложение.
Я вам больше скажу — есть и альтернативы, возможно экзотические, но работающие. webjars, например, в качестве средства для замены npm — вполне работает, а если вам не нужно много экзотических пакетов прямо сегодня — то и удобно работает.
В 2017 ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript
Не, тут вы не правы. Вы можете делать сто раз олдскульный сайт, но завтра к вам придет заказчик, и скажет, что хотел бы посмотреть сайт с iPad, например. Или из IE 11 (не говоря уже про более старые). И вам потребуется, чтобы ваш javascript вдруг сразу стал совместим с тем JS движком, который там работает. Вы все еще можете жить без npm, но вам уже нужен babel.
Babel в принципе запускается например из JVM Nashorn, но вовсе не безпроблемно, в том числе потому, что сам в какой-то степени завязан на зависимости (пресеты и плагины).
Вот это и мешает. Вы можете делать олдскульные сайты, но часть описанных тут инструментов все равно вам окажутся нужны. Менеджеры зависимостей, разного рода сборщики и пакеры — тут да, вариантов много (взять скажем gradle из того же мира Java). И их нужность конечно зависит от сложности, от наличия и числа зависимостей.
Ведь по сути, весь npm, в той части, в которой он нужен простому приложению — это два-три тривиальных REST запроса к Node registry, один чтобы узнать список версий пакета, другой — чтобы достать tarball. Да, если там внутри окажутся скрипты для сборки — вы попали, но в простых случаях установка пакета npm куда-то на локальный диск — это строк 20 кода на чем угодно.
вам уже нужен babel
А чё, писать на чистом ES5 (опционально с полифиллами) уже запретили?)
Ну, нет конечно, никто не мешает. Просто есть еще и зависимости, например.
Ну вот скажем, такой вполне реальный пример — есть Nashorn, который работает в JVM. Там кажется ES5.1, т.е. не самый последний. И я хочу там запустить что-то, что написано под ES6 (это не паковщик, и вообще это не инструмент, а вполне прикладная зависимость, какой-нибудь Topojson, скажем). Какая мне радость от того, что свой код у меня написан под ES5?
Агащазблин. На самом деле все еще хуже, чем я описывал. Во-первых, даже если прогнали и залили — вам придется лично копаться в скриптах, чтобы понять, это ES5, или какая-то другая версия. Потому что нигде в метаданных пакета npm это не пишется. И завтра в новой версии может оказаться другая, потому что никто вам ничего не обещал.
А во-вторых, даже если минифицированный пакет в репозитории вам подошел, рано или поздно вы можете захотеть внести в него исправления, потому что кода без багов почти не бывает. И вот тут вы уже просто вынуждены пользоваться тем тулчейном, которым пользовался автор, а не своим.
P.S. Вот реальный код topojson:
export {default as topology} from "./src/topology";
и в Nashorn это не работает. Так что проблема как раз совершенно реальная. Простой переносимости JS кода между разными окружениями не существует, это миф.
Вы точно разбирались в этом вопросе, или просто поныть решили?
Вообще-то в package.json есть две секции
- main — указывает на обычный CommonJS файл
- module — указывает на код с
import/exportдля тех окружений кто его поддерживают, например Node.js с флагом--experimental-modules.
Для вашего особого случая, когда ваше окружение не знает ни require ни import авторы положили файл dist/topojson.js в котором модулей нет вообще.
Это вы не поняли, а сразу пытаетесь поучать, отвечая на один коммент, и не читая ветку.
Окружение не просто не знает require и import, оно еще и не содержит npm (и node вообще). И речь как раз шла о том, что даже если вы пытаетесь писать в олдскульном стиле в любой среде, и на любой версии языка, то вам рано или поздно попадаются зависимости, которые хотелось бы использовать, которые просто требуют развертывания той экосистемы, которая описана в данном посте.
Ну т.е., беру я github, делаю себе clone — и на минуточку, там вообще нет папки dist, ага?
Конечно в git папки dist нет, зачем коммитить сгенеренный код в VCS? Папка dist подготавливается в билде и публикуется в npm.
Если у вас нет возможности (или желания) ставить npm-cli, вы можете скачать файл руками: https://registry.npmjs.org/topojson/-/topojson-3.0.2.tgz, распаковать его, и получить заветные файлы из dist.
это ES5, или какая-то другая версия
У любой нормальной либы указывается список поддерживаемых браузеров. Если такого нет или вместо него отписка типа «only for modern browsers», то это плохая либа, её использование — ваша ошибка, страдайте, чо уж :)
вы можете захотеть внести в него исправления
Ни за что не поверю, что у вас это обыденность. Ни сам я не вносил исправления в чужой код, ни знакомых, занимающихся этим регулярно, нет. Но если уж очень сильно приспичит, то весь этот тулчейн нужен будет лишь до выхода релиза, в котором баг пофиксят.
P.S. Вот реальный код topojson:
Ни за что не поверю, что у вас это обыденность.
Хм. У меня в проекте пара сотен зависимостей. с десяток из них я лично дорабатывал. Доработка topojson, чтобы он работал в Nashorn, стоит в планах, потому что альтернатив ему найти не удалось,
P.S. Я вам показал реальный код, который лежит в github. А вы мне — вообще какую-то хрень непонятно откуда, из какого-то кеша. Для начала, попытайтесь понять, о чем я пишу, а потом уже наглейте до обвинений во вранье.
Доработка topojson, чтобы он работал в Nashorn
Значит официально Nashorn не поддерживается, значит на этом тему можно закрыть. Topojson фактически становится не сторонней зависимостью, а вашим кодом, а его пишите на чём хотите, хоть на ES3 — проблема зависимостей снова перестала существовать :)
А вы мне — вообще какую-то хрень непонятно откуда
Никакая не хрень, с гитхаба и скачано https://github.com/topojson/topojson/releases/download/v3.0.2/topojson.zip
Еще раз, вернемся к тому, с чего начали: я собственно утверждал, что вы можете писать в любом олдскульном стиле, до тех пор, пока у вас не появляются зависимости. Если они появились, вам так или иначе нужно будет иметь дело с тем набором инструментов, какой был у их автора. Всем набором или некоторой частью — зависит от ваших потребностей по адаптации под себя, и от того, под какую среду автор выпускает релизы.
То что в частном случае бывает иначе — я верю. Я даже могу поверить, что иначе бывает в 90% случаев. Это не меняет того факта, что вы полностью свободны в выборе инструмента только пока весь код сами пишете.
вам так или иначе нужно будет иметь дело с тем набором инструментов, какой был у их автора
под набором инструментов вы имеете в виду node.js/npm вообще, или конкретный инструмент сборки, которым собирается и тестируется topojson?
Это не меняет того факта, что вы полностью свободны в выборе инструмента только пока весь код сами пишете.
А когда Вы не весь код пишете сами — то весь разговор бессмыслен. О каком способе подключения зависимостей в коллективе ДОГОВОРИЛИСЬ — тот и надо использовать. И всего делов.
Есть многое на свете, друг Горацио, что… Мало ли чего вы не видели и не слышали? У меня есть крупный Java проект, который работает с геометрией. Мне нужен конвертор geojson->topojson, который удалось найти ровно в одном экземпляре — у автора самого формата. У меня есть два простых варианта — либо его переписать (что возможно, но довольно геморройно, там много сложной математики), либо запустить как есть. А есть именно Nashorn, который декларирует ES5.1, и не умеет из коробки ни require, ни модулей.
Тестировать? Ну так если что, протестируем. Это-то тут при чем? Даже если бы среда была поддерживаемая, все равно сторонним компонентам на 100% доверять нельзя.
либо его переписать (что возможно, но довольно геморройно, там много сложной математики)
Две тысячи строчек, покрытых тестами — у меня одноразовые скрипты-однодневки весят больше) Хотя, быть может, переписать и протестировать всё будет таки немножко геморройно, но мне со стороны кажется, что профита от этого будет больше и для вас, и для сообщества, чем от геморроя с Nashorn.
Или у вас фиак-фигак и в продакшен и некогда кого-то куда-то портировать? Тогда все разговоры вообще не имеют смысла.
Тестировать? Ну так если что, протестируем.
Именно. Портируйте, тестируйте и на гитхаб ;)
Две тысячи строчек, покрытых тестами — у меня одноразовые скрипты-однодневки весят больше
Вы не учитываете простой вещи — того что сегодня могут быть другие, более важные дела. Ну и потом, если я соберусь портировать скажем на Java, то а) скорее всего в основе будет либо JTS, либо geotools, и логика сильно может поменяться (надеюсь, в сторону упрощения), б) тесты можно будет выкинуть по большей части, тут они не помогут.
А геморрой с Nashorn — это совершено другого рода геморрой. По сути в основе него будет попытка перенести к себе окружение из Node. Скажем, npm подключить — это вообще не задача, я большую часть функций использовать не буду, а чтобы миррорить к себе выбранные пакеты из репозитория — это совсем простая задачка уровня "два-три REST запроса, выкачать tar.gz, распаковать". Я это уже почти сделал, там кода строк на 30 от силы.
require в каком-то виде есть, но надо состыковать с предыдущим пунктом.
Babel вполне работает в этом окружении, ему не хватает того самого require, чтобы где-то взять пресеты и плагины.
Ну т.е. это — чисто техническая задача, по больше части рутина.
Не, не пробовал. А оно разве поддерживает Nashorn? Я вроде видел баги у них в github, на предмет добавления, и они не закрыты, и там описаны проблемы, с которыми столкнулись в попытках это реализовать.
Вот, например: https://github.com/ModuleLoader/es-module-loader/issues/444
Вообще, в моем понимании тут ситуация пока такая, что нужна некоторая поддержка со стороны Оракла или OpenJDK. Иначе некоторые вещи сделать трудно.
По-моему у нас как раз все относительно хорошо :). Если я могу запустить Babel внутри JVM, и он работает — это совсем неплохо, и говорит о приличной совместимости JS движка.
Я не думаю, что в другой какой-то экосистеме (кроме самой ноды) получится сделать что-то похожее. Понятно что проблемы есть, но народ над Nashorn работает, его не забросили. Есть вот такая например штука, как jvm-npm, которая реализует requre (и которой я как раз пользуюсь). Если ей как следует объяснить, где у нас модули, и установить их заранее. И сделать сервис, который будет проксить node registry. Вполне реализуемая задача, на первый взгляд.
игнорируя тот факт, что async/await это сахар для промисов)
Значит у него на сей сахар индивидуальная непереносимость. Его право, как говорится.
Я видел утверждения (в некотором роде — доказательства), что async/await это do-нотация для монады promise, т.е. это не просто сахар, а они эквивалентны. Это не мешает мне лично все равно предпочитать промисы, и я даже могу попытаться сформулировать, почему: потому что промис самодостаточен, это более фундаментальное понятие, и я могу (и знаю куда) смотреть, чтобы понять, как он работает.
Ну т.е. упрощенно, промис — это библиотека, я и знаю, где в общем случае искать ее код, и вдруг если нужно, то могу подключить вместо одной библиотеки промисов другую, и тоже посмотреть в ее код, и сравнить их. А для синтаксической конструкции языка это все далеко не так очевидно.
ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript
Дело в пальцевой механике: если кодер пишет в основном на es6, он рано или поздно на автопилоте зафигачит в «олдскульный» JavaScript что-то типа
let {foo, bar} = baz и даже не заметит (потому что сидит в последнем Хроме). В рантайме «новомодный зоопарк» жрать не просит, так зачем отказываться от привычного процесса?
Обратите внимание на аргумент --save-dev — он сохраняет бандлер как зависимость среды разработки, так что она не понадобится на production-сервере.
Это как? Если на проде нет сборки, то там и moment.js не понадобится. Если есть сборка, она без бандлера не заработает.
На самом деле отличие в другом: если кто-то решит использовать ваш пакет как зависимость, ваши зависимости из devDependencies не будут подтягиваться в его node_modules.
По сути, мы просим webpack найти все .js-файлы (за исключением лежащих в папке node_modules) и применить babel-транспилирование
Мы не просим вебпак искать файлы. Мы ему объясняем что делать при импорте js-файла. В вашей формулировке получается что-то типа
gulp.src('src/*.js'), но вебпак так не работает =)Иногда нужно разделять модули на два типа не только при разработке библиотеки. Некоторые пакеты имеет смысл ставить не только там где идет билд — но и на сервере. В таком случае можно на сервере выполнить команду npm install --only=prod.
В сценарии с webpack такая команда не нужна, а вот при использовании какого-нибудь require.js или systemjsразделение модулей на два типа пригодится.
Я не призываю все пихать в dependencies, порядок это вообще хорошо. Просто надо понимать, как оно работает, боюсь из статьи динозавр бы понял не совсем правильно +)
И здесь появляется бандлер (bundler). Это инструмент для сборки модулей в единые пакеты, имеющий доступ к файловой системе. Получающиеся пакеты совместимы с браузером, которому не нужен доступ к файловой системе. В нашем случае бандлер нужен для поиска всех выражений require (имеющих ошибочный, с точки зрения браузера, JS-синтаксис) и замены на настоящее содержимое каждого требуемого файла. В финале мы получаем единый JS-файл без выражений require!
Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?
Я правильно понимаю, что в JS был, фактически, заново изобретен #include?
Нет. Импорт модуля больше похож на линковку с объектным файлом чем на текстовое включение заголовочного файла: у каждого модуля есть свои импортируемые и экспортируемые символы; внутренности модуля от других модулей спрятаны.
Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?Я вам больше скажу export/import уже даже поддерживается браузерами. Файлы со своими областями видимости и прочие плюсы.
"заново", "изобретен" — неправильные слова. Скорее "имлементировано что-то похожее на include в других языках".
А как разрешаются кольцевые зависимости?
Импорты инициализируются лениво. Вы можете импортировать любые модули, в том числе и циклические, но нельзя циклически обращаться к переменным. Использовать в функции, коллбеке — пожалуйста:
// a.js
import b from "./b.js";
// b.js
import a from "./a.js";
function logA() {
console.log(a); // внутри функции можно
}
// а во время инициализации нельзя
// console.log(a);
Вот так мы создавали сайты с JS-библиотеками. Процедура была простой для понимания, но раздражала необходимость искать и скачивать новые версии библиотек при каждом их обновлении.Стоп-стоп-стоп… т.е. это и есть основная причина, по которой нужно городить такой зоопарк? Но ведь если раньше вам нужно было просто искать, скачивать и прописывать script src=, то теперь надо это делать в package.json, следить за зависимостями и множество других узких мест. Не могу сказать, что вы облегчили себе жизнь. Точнее «сначала усложнили», а потом автоматизировали.
Но ведь и при обновлении новых версий библиотек нужно также быть очень аккуратным, ведь никогда не знаешь, поломает ли новая библиотека тебе сайт, или нет.
Далее немного непонятно, зачем во фронте использовать библиотеки, предназначающиеся для полноценного серверного node? Ведь в браузере нет файловой системы, нет кучи других заточенных под сервер функций(сходу придумываю: sql-коннектор. или есть?). Я не утверждаю, что этого делать не надо, мне просто непонятно и буду рад, если кто-то ответит, что есть в npm юзабельного и под node и под фронт. А иначе выглядит как дикий костыль пихать в npm то, что не подходит для node, но подходит для фронта.
В общем так и не стало особенно понятно, какую именно проблему решает такой метод, но зато расписано что и какой модуль делает, за это спасибо
Стоп-стоп-стоп… т.е. это и есть основная причина, по которой нужно городить такой зоопарк?
https://habrahabr.ru/company/mailru/blog/340922/#comment_10494366
Далее немного непонятно, зачем во фронте использовать библиотеки, предназначающиеся для полноценного серверного node?
Незачем. Но в репозитории npm лежат еще и клиентские библиотеки. Собственно, npm выиграл (первую) войну пакетных менеджеров и сейчас практически все популярные открытые библиотеки можно найти в его репозитории.
Моё первое правило — минимум движений чтобы начать разработку. Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.
В случае со всем этим зоопарком приложений — такое не сработает.
Теперь пройду по порядку по каждому пункту:
1. Использование диспетчера пакетов — диспетчер пакетов вещь хорошая, если она встроена в IDE (как NuGet в VS). Но как часто вы добавляете пакеты в проект? Я думаю это происходит в самом начале работы над проектом, плюс немного в ходе разработки. Раньше просто создавалась папка в проекте и туда помещались сторонние библиотеки (в отдельных папках), и всё это добро выкладывалось в систему контроля версий, поэтому для всех остальных разработчиков достаточно было просто забрать последние изменения. И это работает!
Webpack — судя по описанию сценарий его использования — это создать себе проблему и героически его решать. Т.е. сначала мы пишем не-JS код, а потом его преобразуем. Почему бы сразу не писать JS-код. Не подключать библиотеки как раньше одной строкой с сылкой на файл?!
Babel — примерно также как и Webpack. Я не понимаю зачем использовать синтаксис, неподдерживаемый браузерами. Если сейчас 90% браузеров поддерживают ES5, то пишите на ES5. Как только большинство браузеров стало поддерживать ES6 — переходите на ES6 и т.д. C HTML5 и CSS3 это отлично сработало, так почему для JS нужны костыли?
TaskRunner — опять же полезная вещь, но только для минификации и оптимизации картинок, а не для «компиляции» JS — кода. В идеальном случае выполняется, как часть нового билда, а не как часть ежедневной работы программиста.
Вообщем, как и положено динозавру, я буду продолжать писать JS-код, который не требует никаких преобразований и в браузере у клиента будет работать точно также как у меня на машине, а в случае крайней необходимости его и на проде можно подправить. Может быть года через 3-5, когда все браузеры будут поддерживать TypeScript или ES2016/2017 прямо из коробки, тогда уже буду использовать их. Но чтобы без «компиляции»…
Полностью согласен с вами.
Кроме того, совершенно неочевидна польза от "объединения всех зависимостей". Скорее даже наоборот — существенное осложнение развёртывания, да и поддержки всего этого. Ради чего, собственно? Возможно (?), какой-то смысл для крупных проектов это имеет.
Ждал этого очевидного ответа. Но HTTP/2 решает эту проблему куда более эффективно. Особенно при использовании push.
Кстати, о динозаврах, да? ;-)
Вовсю.
А браузеры ваших посетителей?
Все современные браузеры и довольно давно HTTP/2 поддерживают. Примерно сейчас 70% пользовательского трафика по нему идёт.
http://caniuse.com/#feat=http2
Все современные и ныне используемые — это не одно и то же.
Скажем полно еще устройств с Android 4.2. Как раз в то время Андроид пошел в массы. И пользователи тех браузеров зачастую пользуются именно дефолтным системным.
А если бы проблема была только в степени реализованности фич в современных браузерах, то мы бы даже не использовали babel
~70% обращений клиентов (без роботов) по HTTP/2 это реальная статистика у меня в этом месяце.
Кстати, ещё момент. Описанный процесс упаковки вряд ли стоит сравнивать с компиляцией, поскольку никакого преобразования кода при этом не происходит. Вот кабы при этом была, хотя бы, некоторая (автоматическая) оптимизация за счёт, к примеру, удаления неиспользуемых функций и т.п., тогда я бы понял смысл.
удаления неиспользуемых функций
В какой-то мере присутствует. Плюс может всякие статические выражения рассчитать. Может внедрять свои переменные в код и срезать неиспользуемые куски кода. Скажем было:
if(process.env === 'DEBUG')
{
// a lot of code
}стало… нифига не стало, всё срезало, ибо process.env === 'PRODUCTION'. Таким макаром срезается для prod-режима гора кода, предоставляющая удобства для дебага. Плюс минификация в prod-режиме.
Ещё ряд плагинов именно преобразуют код. Скажем JSX плагин только этим и занимается по сути. А есть плагины к нему, которые превращают <If condition={}/> в тернарные операторы а <For .../> в .map-конструкции.
Чего там только не, если честно.
На ES6+ пишут, главным образом, по одной простой причине: это удобнее и исходники получаются компактнее.
А еще на TypeScript пишут например, и там уже дело не только в красоте (синтаксическом сахаре).
Так никто не мешает создать пустое веб-приложение из шаблона.
Так помимо шаблона ещё требуется установка зоопарка приложений и их конфигурация.
Вы кладёте бинарные зависимости в контроль версий?
Вы не поверите, но да. Для сторонних библиотек считаю это допустимым.
Предлагаете браузеру выкачивать 100500 файлов библиотек и исходных кодов приложения
Если в вашем приложении 100500 файлов библиотек, то я бы задумался о том, всё ли вы делаете правильно… А бандлер в ASP.Net используется для минификации и для того, чтобы написать одну строчку кода вместо 10 для подключения зависимостей.
На ES6+ пишут, главным образом, по одной простой причине: это удобнее и исходники получаются компактнее. Что в этом плохого? Кстати, для CSS3 вы префиксы вручную расставляете?
80% того что есть в ES6+ — синтаксический сахар. Решается написанием своего метода, с последующей заменой кишков на ES6 комманду в случае миграции.
Я и на старом-добром JS не жалуюсь на длину кода… Про префиксы к CSS3 — может у меня нет изысков в дизайне, но префиксы чаще всего не нужны и современные браузеры знают команды без префиксов.
А как запускать, например, тесты?… серьёзных больших проектах «компиляция» делается на CI-сервере.И тесты запускаются там-же. Либо вручную перед коммитом.
Потом благополучно забыть внести в source control и огрести регрессий в следующий деплой.Я так не делаю и другим не советую. Но бывают случаи, когда приходится. И лучше иметь такую возможность, чем не иметь её.
— Запустил IDE
— Создал новый проект
— Написал код
— Нажал выполнить
— Открылся браузер и в нём всё работает
— Если вижу ошибку, то иду в средства отладки браузера и сразу нахожу место поломки
— Возвращаюсь в IDE на эту строчку кода и исправляю
Если в вашем приложении 100500 файлов библиотек, то я бы задумался о том, всё ли вы делаете правильно…
У вашего оппонента была всего лишь гипербола.
Эффект заметен уже на паре десятков файлов
Так помимо шаблона ещё требуется установка зоопарка приложений и их конфигурация.
Это ваша работа. И всего лишь ваши рядовые профессиональные инструменты.
Не ничего страшного. Если это ваша постоянная работа.
Иначе, если вы случайно зашли, а основная деятельность другая, то зачем вам даже знать об этих инструментах. Вручную можно если это мелкий разовый проект
Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.
Visual Studio давно уже поддерживает TypeScript именно в таком режиме. И да, вместе со студией ставится нода довольно старой версии исключительно для запуска tsc или каких-нибудь grunt.
А в ASP.NET Core, к слову, из коробки поддерживается использование внедренной ноды для изоморфного рендеринга.
nmp это хорошая тема. поначалу бесила, потом норм (см ниже). Nuget уже торт.
студия 2017 тяжела и не поворотлива. перешел на VS Code
Конечно этот зоопарк реально бесит, но потом как то привыкаешь.
переходим на Kestrel net Core. не надо никаких большее IIS'ов.
и как вишенка на торте — плавный переход на Centos. И вот там все выше перечисленные шаги работают.
прелесть Kestrel — это линух/виндос, легковестность, И привычная, удобная отладка кода. в отличии от Ноды и ГО. так что как динозавр динозавру рекомендую. b vim уже не кажется чем то диким.
вобще связка Vue+Core(+Go)+Linux это то, куда стоит смотреть. Go пока нужен. Нода наврятли.
и да, Kestrel, в отличии от GO,Node позволяет правку в рантайме на брекпоите. что в студии, что в vc code.
ВебПак не компилятор, а линковщик.
Пишем код на ES5 для 90% браузеров и тут заказчик/начальник говорит «на ие9 5% сидит ещё, давай-ка и его поддерживать». В случае наличия транслятора только таргет изменим/добавим…
Может я и динозавр, но ваша статья меня не убедила.
Моё первое правило — минимум движений чтобы начать разработку. Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.
Но а если это сделаю я, то у меня ничего не получится, потому что я не знаю какие пакеты устанавливать в вашем Nuget, я не знаю как устанавливать и конфигурировать всякие entity и прочее добро.
Почему я не знаю этого и мне сложно понять как это работает? Я считаю что нужно очень много телодвижений что бы развернуть свою сайт визитку на ASP.NET под Windows.
А потому что я не являюсь .NET разработчиком и для меня это все кажется дикостью, ваша документация самая ужасная на планете.
Сейчас вы начнете говорить, что я слишком туп, а почему вы такое же не говорите себе? Я оказался в такой же ситуации в которой оказались вы.
А теперь немного про меня, теперь я захожу в свою IDE и оп-ля у меня есть и статическая типизация и все новшества веб разработчика, мне ну нужно ничего настраивать
Я не задумываюсь ни о чем, я сразу же пишу хороший современный код.
А почему вас беспокоит как работает WebPack? Это его проблема, вам нужно просто нажимать CTRL+S и ваш проект автоматические погонится через WEbpack, у меня это занимает около 1 секунды на старом железе.
Вообщем, как и положено динозавру, я буду продолжать писать JS-код, который не требует никаких преобразований и в браузере у клиента будет работать точно также как у меня на машине,
Зависит от проекта, где-то реально лучше использовать Jquery.
Люди которые несут Angular в сайт визитку — идиоты.
1. Для объединения с Babel — чтобы писать код в новом стиле, и при этом поддерживать старые браузеры. Причём поддержка не обязательно заключается в пользователях, которые не обновляли свой браузер несколько лет — некоторые фичи появились очень недавно, и конечно же, ещё появятся новые. Если кто-то скажет, что можно писать и в старом стиле, то нет, новых фич стало настолько много, и многие из них настолько хорошие (это не шутка), что в старом стиле писать не получится. Конечно же, если вы никогда не писали в новом стиле, вы не сможете меня понять.
2. Для возможности модульной разработки. Вы не представляете, как это нужно. Без неё разработка сильно затруднена из-за большого количества причин. Сейчас модули стали поддерживаться нативно в браузерах, но WebPack нужен всё-равно, т. к.:
1) Поддержка введена очень недавно, а в некоторых браузерах ещё работает только с флагами.
2) При уровне зависимостей больше 1 не требуется прописывать все подзависимости вручную, чтобы не замедлить загрузку (иначе браузеру придётся вначале грузить первый уровень, потом второй и т. д.).
3) Не нужно указывать все модули в index.htm, чтобы не замедлить загрузку.
4) Удобная работа с node_modules и сторонними модулями.
5) Более быстрая загрузка бандла (спорный момент из-за HTTP2). Не нужно переживать, что когда-нибудь модулей станет слишком много.
3. Для объединения с минификатором. Конечно минифицировать можно и без Babel, но у вас на это уйдёт не меньше времени, чем на изучение Babel и использование уже готового решения.
4. В webpack много функций — захотели препроцессор для CSS — не проблема. Захотели что-то ещё — не проблема. Конечно же, можно писать свои модули для webpack. Если вам что-то вдруг понадобилось, вы больше не скованы необходимостью изучать вебпак.
4.1. Ну, кроме препроцессоров для CSS возьмём, к примеру, модуль «define». Для тестирования у вас может быть дополнительный код в проекте, а при сборке дефайны заменятся на сами значения, после чего неиспользуемый код полностью вырежется минификатором. Удобно и очень логично.
В общем, как видно, всё это можно сделать и без вебпака, но это будет сложнее, чем изучить вебпак.
Конечно же, начать проект можно и без вебпака — при этом 1) он будет работать только в определённых браузерах, 2) может понадобится настройка браузера, 3) он будет работать медленнее, но в итоге всё-таки будет работать, т. е. добавить вебпак можно не сразу, а немного позже, тем самым упростив себе жизнь и сильно расширив список возможностей, которые можно использовать в проекте.
Лично у себя я делаю, чтобы js-код мог работать и без вебпака (например, при тестировании), но клиентам отдаётся бандл, собранный вебпаком.
И чтобы все это работало, придется искать Babel «той самой версии 2017 года, когда ES9 еще не было», от npm отказаться, потому что половина библиотек переедет на другие сервера, а webpack окажется давно заброшен, «так как в стандарте еще в 2019-м появились нормальные инклюды».
И вместо того, чтобы легко найти и поправить строчку в нужном файлике, придется искать детранспилятор Unbabel, распаковщик webunpack, и по крупинкам вычищать синтаксический сахар «еще того года».
А уж если в этих тулзах обнаружится какая-то дырка… то привычка автоматически тянуть 10 используемых и 20 не очень используемых библиотек из веба очень дорого обойдется.
Одним словом, эти технологии через еще 5 лет поменяются до неузнаваемости, окажутся уязвимы или просто отпадут. Будет, уверен, нормальный менеджер пакетов с графическим интерфейсом, отвалится Babel и Webpack за ненадобностью. Это мода, гонка за новыми технологиями, причем до того, как они будут достаточно отлажены.
Раньше бета- и альфа- версиями ответственных инструментов мы не пользовались — и сейчас не надо поддаваться моде. Пусть сначала допилят это всё от сырого уровня до чего-то стабильного. А мы по-старинке, как прадеды программили — надежно, совместимо, поддерживаемо.
P.S. Мне тут один старый заказчик недавно позвонил — «помнишь, ты нам в 2000 году сайт делал? Вот он что-то перестал русские буквы показывать нормально...» Нехилый аптайм в 17 лет… и все вылечилось правкой collation ;-) я даже не помню, какой версии PHP тогда был… и работает зараза!
А если серьёзно, то всё что вам нужно будет лет через 5 — развернуть виртуалку с нужной версией node.js. Собственно, можно начинать работу над проектом с создания виртуалки с выбранным дев-окружением и работать в ней. Другой вариант — разворачивать его прямо на сервере заказчика, хотя бы перед сдачей.
На срок 5+ лет я виртуалкам доверяю больше :)
Я не хочу через 5 лет столкнуться с тем, что софт в контейнере не сможет работать с текущим ядром докером. Введут там какие-нибудь политики безопасности или из ядра что-то выпилят. А в виртуалке у каждой машинке своё ядро.
Хотя никто не мешает и докер в виртуалке держать, если уже разработка и, тем более, прод под докером пашет даже для проектов с планируемым циклом "написал и забыл на 5 лет".
Этих проблем, конечно, нет, если использовать в каждом новом проекте одни и те же (читай: старые) версии пакетов. Но хочется-то и новинки пощупать, и не просто пощупать, но и реально их использовать. Надеюсь, в ближайшие годы стек устаканится немного, и я не буду удивляться «как это третий вебпак вышел, а когда второй был?» :)
И в чем же проблема использования устаревших инструментов? У вас что, кто-то их отбирает? Не вижу ничего неправильного в том, что проект начинается с использованием самых свежих инструментов, а потом 10 лет развивается без переписывания на новый стек технологий.
Искать babel "той самой версии" не придется потому что, во-первых, новый стандарт должен быть совместимым со старым, а потому ваш код без проблем скомпилируется новым babel. А во-вторых, все версии babel от начала времен с самой первой лежат в репозитории npm, и никто не запрещает использовать любую, даже если разработка babel прекратится. В-третьих же, эта самая версия "того самого babel" при условии непрерывности работы над проектом должна лежать у вас в node-modules.
Ну вот, навскидку — https://m.habrahabr.ru/post/310302/
Годовой давности пост. Сейчас как этот подход, ничего не устарело, не поменялось? Redux, Koa (новый фреймворк нового поколения!), Helmet — это все по-прежнему?
Так что, тот проект перестал работать с выходом какого-нибудь Vue — или как?
Что бы знать Express Нужно знать HTTP
Я не знаю KOA, но я уверен что он такой же как Express и он также наследуется от HTTP
Обучится я смогу за пару вечеров.
Я не знаю VUE.JS, но уверен что мне потребуется ровно неделя, для того что бы пересесть с REACT.
И так далее.
Мне — легко.
тяжело тем кто не является веб разработчиком и пытается что-то сотворить, что бы не тратить деньги на найм веб разработчика.
А ещё окажется, что не зря вы сидите на REACT, а не на VUE, потому что VUE был с какими-то косяками и его забросили, фиксы три года уже не выпускаются.
И получается, что инструменты, которые ускорили разработку тогда, мешают поддержке теперь.
Когда был бум CMS-ок, тоже были сотни новых, лучших и модных. Сколько их сейчас, заброшенных и неподдерживаемых? Нельзя брать сырые технологии и надеяться, что с их помощью можно сделать что-то надежное.
И получается, что инструменты, которые ускорили разработку тогда, мешают поддержке теперь.
Не путайте "мешают" и "не так сильно ускоряют как современные".
И я смогу пересаживаться на проекты, которые написаны на этой технологии.
Ничего плохого в этом нет, но что бы до этого не дошло, я могу прям сейчас потратить 2 недели, на изучения этой технологии.
Но почему я это не делаю? А потому что у нас руководство хорошее, оно выбрало только 1 технологию, если вдруг мне покажется что REACT говно, то я уволюсь с работы и через месяц буду искать работу на Vue.
Сейчас сотни фреймворков, но это лишь цифра, на деле только 2-3 актуальны, остальные никому не нужны, так же и с CMS, актуальны только 3-4.
А ещё окажется, что не зря вы сидите на REACT
Для меня он идеален, но если все же такое случится, то я оставлю свою компанию, переучусь и пойду в компанию где работают только на VUE.
Вместо меня найдут нового человека за 1 неделю.
Нельзя брать сырые технологии и надеяться, что с их помощью можно сделать что-то надежное.
По этому нужно оставлять в системе DOS, сервера крутить на windows sever 2003, а программистов искать под DELPHI 7?
И получается, что инструменты, которые ускорили разработку тогда, мешают поддержке теперь.
Если пройдет 5 лет и REACT умрет, а через 10 лет руководитель скажет: «ну вот, не найти теперь спеца, зря мы тогда выбрали react»
То тут вина руководителя, он идиот и ему вообще не следует быть руководителем.
Вот это ад:
hh.ru/vacancy/22869652?query=delphi%207
Тут в руководстве скорей всего дядя 60 лет, который вообще не хочет ничего менять. пройдет еще 10 лет и они не смогут найти специалиста.
5 лет работает и еще 5 лет обновлять?
Да за это время целые эпохи в Вебе прошли.
Делаю сайт 11 лет. Переписывался с нуля уже 5 раз.
Уж очень его владелец хочет чтобы сайт ему бабло приносил. Посему — вкладывается
Я, как динозавр, привык, что если я делаю сайт — он прослужит лет 5
Но только вот через 3 года вы уже не сможете поддерживать свой продукт другим человеком.
Попробуйте сейчас найдите специалиста на DElphi 7, никто не пойдет работать на Legacy за обычную зарплату, потому что Legacy это карьерная смерть.
От таких работодателей нужно бежать как от огня.
У таких работодателей как правило в компании даже JIRA нет и все вопросы решаются по телефону или почте mail.ru
Так что скоро на JS наконец то можно будет забить.
JS эволюционирует с бешеной скоростью и в этих стандартах уже черт ногу сломит. Ситуацию усугубляет набор постоянно устаревающих инструментов, которые тоже взаимонезаменяемы. Их нужно практически с нуля осваивать.
По факту эта эволюция не может идти бесконечно. Старое legacy нужно выбрасывать. Очевидно, что это позволит сделать тот же WASM, который сам по себе разумеется не убьет JavaScript, но зато позволит появиться\выйти на рынок языкам, которые позволят писать сайты без всего этого геморроя.
не прошу 100, не прошу 1000.
Хотя бы 1 или 2 сайта.
Именно сайты, т.е. через которые заходим по http://
Я его использую по работе, и субъективно — это сплошной тормоз.
Сижу через прокси, потому что сайт заблокирован в РФ.
Могу заснять видео, что у меня все быстро работает, ничего не виснет и так далее :)
Оперативной памяти он ест — 215мб
Ember.js
RequireJS
jQuery
Handlebars
легаси проект
Меня как потребителя все устраивает и сейчас все лучше чем было 5 лет назад.
Еще стоит помнить что мы пользуемся популярными сайтами бесплатно и никто никому ничего не обязан :)
Потому все же выясняется что сайты норм, а вот приложения которые написаны на Electron не норм, приводят в пример slack — я соглашаюсь.
Потому я привожу в пример 100 проектов в том числе Visual Studio COde — мне говорят что это исключения.
Утечка какая-то, скорей всего в анимации.
Ну баги везде бывают
Ну то есть: «как там, у 95% пользовательских веб-сессий страница не успевает выжрать всю память? Тогда наплюйте на рефакторинг, пилите следующую фичу».
Аналогично нехорошей с моей т.з. тенденцией идет утяжеление среднего веса веб-страницы там, где это это не надо.
Титульная страница Хабра у меня сейчас весит 3.4Мб. Из которых 1.7 Мб весит картинка из топика про Unreal Engine. «Мобильные пользователи? конечно сайт оптимизирован под мобайл! Вес сайта? Да какая разница, во всем мире сейчас у всех пользователей безлимитный 4G !»
Ну, и так далее ворчать хочется… За без малого 20 лет, что я сижу в инете, скорость моего канала связи увеличилась примерно в 2000 (две тысячи) раз, а скорость загрузки «среднего сайта» — ну, раза в два наверное, или около.
Visual Studio COde
Я ранее писал, что VS Code хавает полгига оперативы сразу же после первого запуска, ещё до открытия какого-либо проекта. Так что нет, он не исключение, а такое же электроноговно как и Slack :)
Gitter
Да всё разжирело донельзя, что уж там. Прогресс привёл к тому, что мало кто думает о реальной оптимизации в угоду скорости разработки уповая на то, что современное железо, средства хранения и сети пережуют любое количество кода.
Меня лично (как динозавра) всё это удручает.
Почему я не жалуюсь что у меня лагает комп, если я запущу 40 процессов Photoshop? (а потому что я понимаю что это глупо делать)
Никто вам ничего не обязан, тем более бесплатно, у вас всегда есть альтернатива.
Либо подстаривайтесь либо берите альтернативу.
Вы ничего не поменяете, таких недовольных людей как как вы — около 1-5% во всем мире.
умножаем на 4 получаем примерно 2.4 ГБ за 40 вкладок.
Сейчас вы скажете подонки, но дело все не в веб разработчиках, это не программисты Microsoft Такие тупые что допустили утечку памяти, это браузеры вас избаловали.
Хотите я подскажу вам как сделать так что бы 40 вкладок microsoft.con Занимали около 50 оперативной памяти? Это можно сделать очень легко, только вот придется убрать оптимизацию браузера, теперь после каждого перехода на вкладку вам придется отправлять запросы на сервере заново.(т.е. все сайты будут выгружаться из памяти)
Хотя насчет эдакой «оптимизации» я бы поспорил…
Я печатаю карты на бумаге. Тогда с ними можно работать, а не только смотреть.
Почему у меня ничего не тормозит? Хотя тут скорей всего зависит от города, может вы реально живете где-нибудь в Сибири и там реальные проблемы с интернетом, мобильной связью и т.д.
В недельном походе по лесам и болотам от яндекс-карт мало толку.
Я знаю особое место всего в пятидесяти километрах от города-миллионника, где живу: там почти плоская лесостепь с населёнными пунктами, железной дорогой и автомагистралью неподалёку — а связи нет! Точнее, она может быть, но не всегда и не везде. И это не в Сибири: до неё от того места — те самые километров пятьдесят с хвостиком. А уж в горных районах области таких мест без связи — дофига и больше.
Реально мобильная связь работала (и только мобильная!) только на высоте 10 метров над землей (за связью лазали на ЛЭПку).
Интернет, интернет. Может быть во внутримкадье он и есть.
Аналогично. Несмотря на наличие гаджетов с навигационными программами, в машине лежат два атласа (область, где живу — в двухкилометровках и бывший СССР — в куче странных масштабов типа 1:1400000) плюс пара карт соседних областных центров. А если иду в поход — печатаю отдельные листы.
Вы, к сожалению, не поняли смысла моего поста. Попробуйте ещё раз.
Да-да. Как и на чём. "А возьмём-ка этот чудо-фреймворк… Ой, а тут такого нет. Добавим чудо-библиотеку. Ой, неудобная она, оказывается. Добавим ещё одну более чудесную… И т.п. и т.д.". В итоге пытаются на всей этой хрени летать. Но быстро не получается. "Поэтому давайте попробуем завернуть всё это в новую упаковку.". Об этом и статья.
Не очень понятно, каким образом wasm сможет сделать то, что вы от него ждете? legacy нужно выбрасывать? Что именно выбросить, IE как браузер? Ну так это во-первых, не зависит от нас с вами (это пользователи почему-то сидят на старых версиях), а во-вторых, wasm-то тут каким боком?
Вроде, к этому все едет.
Погодите. Я вот видел недавно, что поддержка самого wasm браузерами где-то на уровне 58%, что очень низко. Поясните сами, какие проблемы вы пытаетесь решить при помощи wasm, если он сам пока не в релизе и не поддерживается у львиной доли клиентов?
Понятно что в перспективе все будет, но опять же — это инструмент для решения немножко других проблем, как мне кажется. Не с legacy кодом.
webassembly.org/docs/high-level-goals
А какие там фичи хотят внедрить?
webassembly.org/docs/future-features
То, что там пишут — это очень круто. С помощью WASM можно будет писать хорошо засендбокшеный код, который будет запускаться не только в браузере, и люди смогут писать на подходящем для себя языке, а не быть вынужденными запускать транспилятор.
На счет legacy: большинство разработчиков браузеров давно додумалось до автоматических обновлений своих браузеров, и вообще крайне не надежно не обновлять такую вещь как браузер, потому что в открытом доступе лежит большое количество описаний дыр для ишака и чего хотите. Можете их использовать, чтобы обновить им браузер.
www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-9900/Microsoft-Internet-Explorer.html
большинство разработчиков браузеров давно додумалось до автоматических обновлений своих браузеров
Вы о чём-то не том думаете. legacy — это практически синоним IE.
Можете их использовать, чтобы обновить им браузер.
А потом в лучшем случае — лишиться большого и толстого корпоративного клиента, а в худшем — быть обвинённым в попытке его взлома.
Вам не кажется, что почти никто из тех, кто не принимает WASM, вообще ничего о нем не читал хотя бы из официальных док или они просто боятся представить, что когда-то можно будет иметь хороший бинарный формат?
Может ты до сих пор long polling используешь вместо вебсокетов или совсем не используешь local storage, а пытаешься в куку все запихать? А знаешь, еще бывают сайты, которые по законодательным требованиям должны работать без JS. Может ты и таких пользователей поддерживаешь?
Я так не думаю. Обратные несовместимости появляются постоянно, и люди используют новые возможности. И ты в том числе. Проблема WASM лишь в головах разработчиков, которые туеву хучу лет пишут на JS, и не могут понять, что в нем есть вещи, которые невозможно решить засахариванием.
для вас важно legacy oriented programming
Это реальность, с которой я имею дело каждый рабочий день.
Просто в вас вбито, что вот буду до последнего поддерживать эти старые браузеры.
Нет, это в моих клиентов вбито "я не буду обновлять браузер своим сотрудникам ну пока совсем совсем не прижмёт". А клиенты — толстые и платят хорошо.
Вконтакт давным давно посылает пользователей, которые браузер не обновили.
У Вконтакта клиентура такая, на которую можно плюнуть и забыть. А вот послать, например, РЖД или "Почту России" — слегка неудобно.
Последующие рассуждения — это совсем не про мою работу. Сайты я не пишу и никогда не писал.
Вопрос скорее в том был, для чего таки создали WASM?
Для каких целей?
Вопрос скорее в том был, для чего таки создали WASM?
Мне трудно судить, но кажется для того, чтобы можно было компилировать для браузера приложения, написанные не на JS. Например, что-то для работы с графикой или анимацией, я с этим не работал, мне трудно что-то ещё придумать. Короче, что-то такое, что уже давно написано, и переписывать на JS неохота.
Или, может, какие-то библиотеки, которые существуют не только для браузера, чтобы не поддерживать одно и то же на нескольких языках.
П.С: Вот будет весело, если можно будет PHP в WASM компилировать ))) Можно будет писать сервер на JS, а клиент на PHP )))
П.П.С.: Кстати, закономерное продолжение — аналог WASM для сервера.
Он должен будет запускаться на кофеварке тоже. Мне кажется, это продолжение идей джавы, но более удачное.
webassembly.org/docs/tooling
Вот выдержка про цели:
Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms, including mobile and IoT.А это выдерджка про языки:
Compilers and language virtual machines:Они хотят смочь запускать считай ЛЮБЫЕ языки на чем угодно (я правда не допонимаю как они рантайм питона туда засунут правда). Я не понимаю как эту цель можно считать не амбициозной и классной.
Compilers for languages which can target WebAssembly (C/C++, Rust, Go, C#) should be able to run in WebAssembly themselves, emit a WebAssembly module that can then be executed.
Virtual machines for languages such as bash, Python, Ruby should work.
Virtual machines which use a just-in-time compiler (JavaScript VMs, luajit, pypy) should be able to support a new just-in-time backend for WebAssembly.
А, еще. Я упоминал, что есть изоляция рантайма. Это очень круто. Потому что в тот же WASM рантайм ты можешь прокинуть нужные апишки через JavaScript, и этот код не сможет внезапно вызвать какой-то eval из JS, или прочитать что-то из кук. Ты просто сам задаешь, что твой модуль может делать.
Ну у меня нет сомнений, что фронтенд пойдет туда через определенное время. Может, я ошибаюсь, конечно. Ну увидим.
Да полно. Он упомянутого LinkedIn до FaceBook. Два отличных примера упоротых сайта.
>legacy нужно выбрасывать?
Совершенно верно. Про поддержку IE вообще смешно слышать в 2017 году. Перестанете его поддерживать и люди перейдут на другие браузеры. Боитесь потерять сказочные 5% прибыли от клиентов которые сидят на старом говне? А не боитесь потерять 15-20-30% тех, кто с вашего сайта уйдет т.к. он будет медленно открываться, в нем будет неудобная навигация, он не будет адаптирован для людей с плохим зрением (а их куда больше чем пользователей IE) и еще 101 причина?
Вот буквально вчера пытался открыть www.zolotoy-vavilon.ru/rostokino в FireFox у меня он не открывается от слова совсем. Оранжевая хрень загружается какая-то и все.
>во-вторых, wasm-то тут каким боком?
Можно будет писать на любых других языках, многие из которых проще, быстрее, логичнее чем JavaScript. А значит более эффективны по цене\качеству.
Во-первых, если вы готовы выбросить IE, то вам не нужен для этого никакой инструмент, вы и так можете спокойно себе писать под новые стандарты.
многие из которых проще, быстрее, логичнее чем JavaScript.
Ну, скажем прямо, на сегодня реально работающий тулчейн — это emscripten. Это вы про какой язык, тот которые проще и логичнее, C что-ли? :) И потом, в сегодняшних реалиях у wasm настолько ограниченный API, что о замене JS им говорить пока рано. Даже DOM пока нет. И GC нет — так что компиляция для многих языков, где он есть, пока под вопросом.
Кроме всего прочего, писать на разных языках можно и сегодня. Много их, чего уж там. Десятки пожалуй. И что это реально меняет? Возможность писать на любых других языках — это вовсе не решение тех проблем, на которые вы жалуетесь. Ну вот например, сайт медленно открывается… разве причина в javascript? А уж тем более неудобная навигация, или адаптация под людей с плохим зрением или дальтонизмом? wasm — это всего-лишь переносимый байткод, по большому счету. Он этих проблем, во всяком случае непосредственно, никак не решает. И даже не собирается.
Про поддержку IE вообще смешно слышать в 2017 году
Не смешно. Приходится поддерживать, чтоб хоть как-то работало. Не уверен, что в IE6, но что в IE не новее восьмого — точно приходится.
Я поддерживаю в полной версии продукта IE9, в урезанной — IE8. При этом полная версия должна в IE8 не упасть и обеспечить работоспособный интерфейс переключения на урезанную (на случай отказа автоопределения). А урезанная не падает и выдаёт читаемое предупреждение в IE7 (и, в принципе — работает, хотя за это мы уже не отвечаем).
И, честно говоря, считаю неполноценными тех, кто думает будто подобная поддержка — это что-то непосильное.
А у моих клиентов компов в норме от 10000 (десяти тысяч) штук.
в этой арифметике есть один нюанс. Стоимость поддержки старого софта — не константная величина, а множитель к стоимости каждой добавляемой фичи.
В долгосрочной перспективе мождет оказаться лучше один раз потратиться на апгрейд железа, чем переплачивать за каждый апдейт софта.
WASM усилит JS, но не будет такого что JS программистов всех уволят и вместо них начнут админки клепать С++ программисты, это можно делать и сегодня.
Статья хорошая, но не без ложки дёгтя. Что-то никто из комментирующих не заметил большой логической дыры вот здесь:
Всё это прекрасно, но если вы попробуете использовать приведённый код в браузере, то получите ошибку, в которой говорится, что require не определён. У браузера нет доступа к файловой системе, поэтому такая загрузка модулей реализована очень хитро: файлы нужно грузить динамически, синхронно (замедляет исполнение) или асинхронно (могут быть проблемы с синхронизацией).Простите, это как: функция загрузки не определена, но реализована очень хитро? Святым духом, что ли? А где же описание require.js, которое должно быть в этом месте? Повествование должно было развиваться так:
requireне определён;- добавим функцию
requireс асинхронной подгрузкой, имитирующую работу с файловой системой; - это всё работает не очень удобно, куча асинхронных запросов (читай, тормоза), поэтому давайте объединим всё в один файл, но так, чтобы исходники трогать вообще не пришлось. Тут переход к сборщикам.
Пункт 2 в статье почему-то пропущен.
Вот вам пропущенное звено пункта 2: https://github.com/systemjs/systemjs
Все как вы и описали, неудобно, тормозит, поэтому автор сразу перешел к следующему пункту
Все как вы и описали, неудобно, тормозит, поэтому автор сразу перешел к следующему пункту
О том и речь, логическая цепочка оказалась нарушенной.
Обязательно нужно самому наступить на грабли, рассказа о том что это больно — недостаточно?
Ну и потом, статья не резиновая, если отвлекаться на тупиковые ветки, то не хватит времени/места на основное
Эм, какое из слов во фразе «логическая цепочка оказалась нарушенной» непонятно? Ещё раз, в статье чёрным по белому написано: «поэтому такая загрузка модулей реализована очень хитро». Какая такая? Через функцию require, «которая не определена»?
Пропущен этот пункт потому что настраивать require.js сложнее чем webpack.
При изменении JavaScript-кода в index.js webpack-dev-server будет пересобирать свой собранный в пакет JavaScript и автоматически обновлять браузер. Это действительно экономит время, потому что можно сосредоточиться на коде, а не постоянно переключать внимание с кода на браузер, чтобы просматривать изменения.
То это можно было делать и раньше — надо просто закрыть броузер, например Alt+F4, и сосредоточиться на коде. Но мне почему-то кажется, что в броузер все-же надо поглядывать иногда. Повеяло олд-скулом…
«Ребят а давайте возьмем JQUERY на портал биллинга, зачем нам хипстерские технологии.Архитектор в фронтенде? да вы смеетесь, во фронтенде??? джуниора нанимаем и точка! я тут власть! *Прошел год или два* — Гребанный JS(JQ) — он угробил наш проект в 2017»
Лично приходилось писать проект на старом ASP.Net WebForms всего 2 года назад, но старая технология не помешала сделать хороший продукт, хотя на чём-то более современном мог бы написать процентов на 20 быстрее…
Еще раз, я не про сайты визитки говорю, для сайтов визиток современный веб вообще не нужен, там достаточно Jquery 1.1
проектов с большим количеством клиентского кода — не было.
Были многостраничые приложения, где каждая страница сама по себе и чуть что — ходит на сервер.
проектов с большим количеством клиентского кода — не было
Ась? А с чем я тогда работаю? Аж с 11 года? Исходников — порядка полутора мегабайт. Одностраничное приложение.
Да, конечно, у нас самописный MVC-фреймворк (точнее, это бывший JavaScriptMVC, но мы постепенно заменили все его части своими), но под капотом у него jQuery.
Отдельные проекты может и были, но согласитесь, это не было таким мейнстримом, как сейчас.
Или как всегда, от 1 человека, разрабатывающего CORE фреймворка будет зависеть жизнь всего предприятия))
Мы макак не держим. Из-за чего меня и не любят на хабре.
(Правда, почитав на хабре же статьи про подводные камни с нулабельными переменными в C#, я понял, за что программисты на других языках так ненавидят JS. Мы то с нулабельными переменными и всеми сопутствующими неприятностями (а ещё — с многими другими неприятностями) — живём).
У Вас ложная дихотомия.
А можно ли в вашем проекте заменить всех людей и нанять новых, смогут ли они разобраться в коде?
Или как всегда, от 1 человека, разрабатывающего CORE фреймворка будет зависеть жизнь всего предприятия))
Новые люди разобраться смогут, но не сразу. Однако, достаточно любого одного из ныне работающих клиентских разработчиков, чтобы ввести нового человека в курс дела и в стандарты кода.
Как я понял, это является стандартной ситуацией для всех проектов.
1) Да, это выгодно для вас, вы получаете опыт разработке велосипедной архитектуре. Да, вас теперь нельзя заменить, руководство можно шантажировать и постоянно повышать себе оклад, работодатель ваш не опытный мягко говоря, человек старой закалки из мира Delphi, скорей всего вы ему внушили что так будет лучше.
Господи, вы даже Yandex обошли, даже они лошки пишут на react в новых проектах, а вы создали свой, потому что вы умней чем они, а там работают ...., которые умеют брать только готовый продукт и пользоваться готовыми паттернами.
2) Да человек сможет использовать ваш фреймворк.
Но какая выгода этому человеку?
Чему он научится?
Куда он пойдет после вашей работы?
Сейчас вы скажете, что если он знает хорошо JS, то быстро переучится, нет, ему придется начинать все с нуля и 5 летним опытом в вашей компании можно будет подтереться.
Человек который знает хорошо JS не пойдет работать за 50к в говно контору где пишут свой фрейморк на JQ.
Нет во фреймворках ничего страшного. Даже в самописном — если там поддерживают чистоту и ясность кода. А вот как раз «макаки» так и будут рассуждать: если единственный изученный ими фреймворк отсутствует в описании вакансии, компания сразу отправляется в сад, да :)
Это проблема руководства (тимлида)
Нужно следовать миграциям.
Про Delphi я писал, опять таки, это проблема того, кто рулит проектом.
Так в любой сфере, попробуйте сейчас найдите человека, который будет считать на счетах, вместо калькулятора или компа, не найдете, а если и найдете, то ему это не понравится, он попросит закупить партию из 10 калькуляторов и 10 компов.
На JQUERY не реально поднять крупную SPA что бы ее можно было поддерживать и расширять, без современного фронта нет смысла вообще лезть в крупные проекты.
Сейчас вы скажете что SPA это хипстерство конечно же и нужно брать PHP с его файловой шаблонизацией, а JS генерировать через PHP(тут может быть любой язык)
На JQuery можно написать что угодно — очень гибкая и удобная библиотека сэкономивая кучу времени разработки до появления всяких ангуляров. В том числе можно написать SPA, если это необходимо. Конечно сейчас уже в чистом виде очень редко применяется, но это не уменьшает её достоинств. Вот сейчас осваиваю Vue.js, т.к. вижу преимущества его использования (в отличии от React-а и Angular-а) — но это личные предпочтения — никому не навязываю…
Я не скажу, что SPA — это хипстерский подход, но в некоторых случаях его прменение неоправдано. Если у вас при переходе от странице к странице меняется 80% содержимого, то SPA вам нафиг не нужен. Другое дело, если у вас есть одна страничка в приложении на которую завязан весь бизнес процесс и логика этой страницы довольно сложная. Тут SPA оправдан. А ловить гемморой с маршрутизацией и прочими проблемами SPA ради создания сайта-визитки я бы не стал…
Кстати крупный проект можно написать с минимальным использованием JS — взять к примеру ASP.Net MVC для этих целей.
Нам вот ангулар проект угробил. Он жрал 900 мегабайт, а у 80% клиентуры были офисные компы с гигабайтом оперативки. Закопано в это всё 15 лямов в итоге. Зато SPA, рилтайм и пыщь-пыщь-звонки через webrtc.
А что скажете на то что мои проекты жрут по 250 мб оперативки?
Я вам могу минимум 20 проектов скинуть от других компаний.
А что скажете на то что мои проекты жрут по 250 мб оперативки?
Предложу написать аналог слака, который 600 мегабайт при звонке не будет кушать. Ибо у нас было нечто на него похожее, только с большим набором фич и сильно другой ЦА.
Вообще на самом деле там вообще не надо было лезть в веб, а просто пилить себе нативное приложение. Так что мы стали жертвой не сколько ангулара, сколько хайпа вокруг "теперь всё можно в вебе делать".
Знакомый недавно запилил клиент(админку) для сайта на десктопе, весит 200мб.
оперативки занимает 30мб.
Директору лень было в браузер заходить. хотел заходить и управлять всем через MAC OS приложение.
NET framework весит 200мб, мне недавно пришлось скачивать эту зависимость что бы запустить десктопное приложение.
А что можете вы этому директору предложить?
сказать что нужно поднимать новый отдел и выделить 100 000 рублей?
Сделать ярлык на сайт?
Да, это не по поцански, лишние байты и т.д.
Но заказчика все устроило (экономия сроков/финансов + удобство)
я тоже бы хотел сейчас покупать телефон за 1000 рублей.
Но я понимаю что это невозможно и мне приходится подстариваться под современные реалии
Ну так мы этот чудо-сайт и обернули в "приложение", только тогда это был не электрон, а просто CEF. Жрал те же самые 800-900 мегабайт.
Собственно как только начали всех принудительно переводить со старого винформс-приложения (которое кушало 60 мегабайт на тот же набор фич но без звонков и красивой вёрстки) на чудесную версию с ангуларом, так проблемы с привлечением клиентуры и начались.
Что касается "дотнета в 200 мегабайт", то это откровенный троллинг уже пошёл. Во-первых, он предустановлен. Во-вторых, я лично приложение на AvaloniaUI и .NET Core ужимал линкерами в 20, куда входят все нужные компоненты рантайма).
А я бы вот возрадовался, если бы кути ставились как мсвс или дотнет тот же — один раз и для всех прог, но фиг там, нет в жизни щастя…
Собрал сейчас для интереса каталог контролов авалониевский под макось. 25 мегабайт в zip весит полный бандл приложения вместе с .NET Core внутри, ничего на макось доустанавливать не надо. Это без использования линкера, линковкой можно до 15 где-то ужать. Standalone-приложение, ничего доустанавливать не надо.
Ну так собирайте под вторую, если вам винформ хватает. Все фичи языка там доступны. Если же предполагать использование Win7, то проблем вообще особых нет.
А что там с неткором на маке, его тоже можно компилить или это закрытый блоб для каждой платформы?
кто софт делает на дотнете, делать его под 2 версию.
ну мы вот по 4-ый для поддержки ХР делали, никто не умер.
А что там с неткором на маке, его тоже можно компилить или это закрытый блоб для каждой платформы?
Под MIT-лицензией всё давно. А до неткора было моно с вполне вменяемыми биндингами для Cocoa.
А моно да, но для виндов я его видел только раз. Еще видел ОпенЖДК, в игрушке его пихнули.
Мне кажется если выходит за 100 Мб, то уже что-то не то в проекте.
Рисую я их не вручную, а через готовые библиотеки. (d3.js hightCharts)
Заказчику нельзя сказать:
— Слушайте, давай лучше 1 график показывать на странице, а не 10, если что сделаем чекбоксы и будут появляться нужные оси.
— Тут у них кривая реализация, давайте я с нуля напишу мне нужен месяц.
Конечно же я не стану брать все эти фейрморки и т.д.)
Вы понимаете как работает программист.
Но вы не понимаете как работает бизнес.
Я не буду писать целенаправлено под диназавров, например под IE9,10(либо чувак с Nokia на opera mini), если этого нет в ТЗ
Если есть, то я беру +50% к заказу условно.
Потому что мне нужно писать вместо 10 строк — 100 строк грубо говоря.
Недавно на конференции докладчик писал код под андроид. Он копировал функции по 10-15 строк и извинялся, что нет времени вбивать руками, так как это не веб и после каждой правки потребуется полминуты на сборку и каждая правка опечатки будет стоить этой самой пересборки.
Я почти заплакал, ведь мой самое маленькое приложение собирается две минуты из за необходимости собирать в бандл не только один файл но весь чертов ангуляр с плагинами и зависимостями. Ускоряем разработку, пишем на кофесрипте, используем транспиляторы и минимизатор. Светлое, мать его, будущее.
Интересно будет почитать, как вы организуете работу с полученными от сервера данными, какой-нибудь шаблонизатор или фреймворк?
Может было выше, но почему в статье webpack запускается не просто:
webpack index.js bundle.js
А из node_modules:
$ ./node_modules/.bin/webpack index.js bundle.js
Запускать вебпак не из модулей, куда проще.
Большое спасибо, от динозавров!
Объясните динозавру зачем в бэкенде javascript
Экономия на сотрудниках.
Позволительно когда проекты не сложные и высокие знания особо не нужны.
Не знаю какой привести пример, но если вы делаете что-то типа: «Показать записи, сгруппировать, вывести комментарии, показать среднее число постов в сутки, отправить данных на клиента, добавить, отредактировать», то вам не нужен крутой бекендер, там особо много ума не нужно, подойдет и фронтендер со знаниями бека.
Если это что-то реально серьезное нужно сделать на беке, то такой разработчик уже будет плох.
Зачем node.js пихают на другие типы проектов — это уже глупый хайп по типу: «А давай на Java/SpringMVC будем делать сайты визитки»
Вы точно под тем постом комментарий оставили?
В статье рассказывается только о фронтенде, коде, который запускается в браузере.
Меня в мире JS смущают вовсе не новые инструменты, а то, что новые инструменты появляются каждый год. Это показатель незрелости. Прежние инструменты забрасываются — разработка чахнет (либо их несовместимо переделывают под видом новой версии), специалистов, у которых они в стеке фиг найдёшь.
В итоге для проектов большой длительности (от года и больше) проще по старинке разрабатывать, ибо какой инструмент не возьми, через год он уже «не модный», вся команда требует нового, в проекте или зоопарк, или все заняты «делом» — переписывают с ангуляра на реакт или вью.
Я правда сейчас про фронт, может на бэке лучше.
Специалистов можно найти за неделю, просто специалисты не хотят работать за вшивые 80 000 рублей :) 80 000 это стоимость Junior — pre-middle (человек с 1 опытом годы работы. в МСК)
Очень глупо открывать веб направление и кидать в архитекторы человека за 50 000 рублей, а потом жаловаться что в WEB все плохо и он все запорол.
С этим согласны хоть?
Переучится с react на Vue займет неделя или месяц максимум, для кого-то пару дней.
Технологии кардинально не меняются раз в год, последняя революция была примерно 3 года назад. Все что происходит сейчас, это лишь дополнения к технологиям, которые учатся за сутки, приведите мне конкретный пример и я могу аргументировать все до последней мелочи.
Все остальные инструменты познаются в процессе работы.
Что бы уверенно себя чувствовать в FRONTEND, сейчас, через год и через 6 лет нужно изучать нативный JS + CSS и читать новости, хотя бы раз в неделю.
И еще, если у вас в компании руководитель установил стек в виде ангуляра 1, потом никто не соблюдал миграции и жалуется что все плохо — это проблемы вашего руководства.
Если у вас пишут не поддерживаемый код — это проблема руководства.
Если у вас нельзя заменить людей — это проблема руководства.
> С этим согласны хоть?
Я совершенно не знаю масштабов цен в Москве, поэтому не могу ничего сказать — просто не знаю где у вас там не вшивость начинается.
> Переучится с react на Vue займет неделя или месяц максимум, для кого-то пару дней.
Речь даже не о переучивании, а альтернативе — зоопарк или вечное переписывание.
Другая половина поступает от бизнеса, жалуются что не могут найти JS разработчика за 60 000 рублей.
Если бы вы занимались веб разработкой в течении последних 2 лет, все нововведения бы вас не пугали.
Давайте ещё раз. Проблема следующая: из-за постоянной смены моды, либо приходится терпеть зоопарк, либо переписывать каждый год на новый подстек. Если вы лепите сайтики, проблем нет, если у вас продукт длительностью в годы с полмиллионом строк, то появляются трудности.
Причём тут найм сотрудников вообще?
Про миллион строк кода это вы загнули, даже в таком проекте как яндекс метрика (JS версия) — нет столько кода, а он пилится уже много лет.
У вас откуда такая информация про зоопарк? из негативных отзывов разработчиков других языков, которые никогда не работали в веб сфере?
Люди как писали на Angular в компании так и пишут.
Люди как писали на React так и пишут, я не вижу проблемы.
Новые проекты кто-то начинает на VUE, но в нашей компании как писали на React так и будут писать, меня он всем устраивает.
Если у вас пишут одновременно на reac+angular+vue+ember то это проблема вашего руководства.
Сейчас вы мне скажете про ангуляр 1, а миграции для кого придуманы?
Есть много средств, которые позволяют упрощять разработку, линтеры, сборщики и прочее, но я скажу вам с уверенностью, что это учится за 1 неделю веб разработчиком.
Главное требование в современном вебе:
1) Знать идеально JS
2) Знать идеально CSS
3) Знать английский
Нода прекрасно заменяет баш или batch (windows shell)
А толку? :)
На самом деле я был не совсем прав. Нода может заменить /bin/bash. Но в ряде случаев баш эффективнее.
К примеру мне для одного моего мелкого поделия нужно было собирать финальный JS из кучи мелких файлов. Я решил пойти по "модному" пути — GULP/GRUNT… потом плюнул, написал за 5 минут 10 строк на баше. И меня устраивает, знаете — не 15 мегабайт тысяч JS файлов в node_modules, а 10 строк на баше.
Webpack — это полная замена gulp'у?
Я так и не понял — а зачем это всё надо? Менеджеры пакетов, серверный яваскрипт, коффескрипт… что это за бред пьяных наркоманов? Нормально так… ща какой-то яваскриптик там у себя обновится, а у меня из-за этого весь сайт полетит. Если мне понадобится обновление какой-то библиотеки — мне не сложно будет вручную заменить файлик на сервере. Гораздо сложнее настраивать это всё бесполезное говно.
Как-то Вы больно абстрактно ответили. Не с простым сайтом, а с более серьёзными вещами? Каким простым сайтом? По-вашему сайты на каком-нить битриксе — это простые сайты? Что же тогда за более серьёзные вещи?
Сайты на каком-нибудь битриксе — это простые сайты. То, что там дохрена WTF-кода — это проблема другого порядка. Более серьезные вещи… ну попробуйте гуглодок тот же посмотреть, по моим ощущениям (нифига не фронтэндера) там посложнее код будет.
Вот на битрикс как раз часто ругаются за запутанность его кода. Которая возникла потому что при разработке не применялись общеизвестные средства борьбы со сложностью (да-да, те самые менеджеры пакетов и прочее).
Понимаете, пока ваша задача — писать джаваскриптом Hello World или поднимать 3 попапчика с двумя алертами — вам все эти инструменты нахрен не нужны.
Если мне понадобится обновление какой-то библиотеки — мне не сложно будет вручную заменить файлик на сервере
… после чего весь сайт полетит :-)
После самостоятельного обучения JS с помощью learn.JS.ru и книги 'выразительный JS', столкнувшись с NPM, Webpack, Babel действительно чуствовал себя динозавром. Конечно после пары проектов, где приходилось править конфиги этих инструментов, многие моменты стали понятны, но общей картины не вырисовывалось еще долго.
Отправлю ссылку паре знакомых Junior
Но мало кто пишет, что современный ES и концепция Web Components позволяет выкинуть половину зависимостей из проекта.
Но я, пожалуй, еще чуток побуду динозавром…
А теперь пришёл ES6 и вместо require используем import и часто вместо webpack используем rollup.
Объясняем современный JavaScript динозавру