Действительно, в последнее время это становится несколько монструозненько.
07.10.2016, 15:57
Ничо не знаю
npm i browserify
npm i babelify
npm i babel-preset-2015
Уже можно писать код
npm i browserify
npm i babelify
npm i babel-preset-2015
Уже можно писать код
А никто и не говорит, что это сложно. Но это становится сложно, когда ты хочешь поставить какой-то модуль, а у него пять зависимостей, некоторые их которых могут не работать с теми версиями модулей, что стоят у тебя. И тебе приходится сидеть ковыряться, разбираться с зависимостями, выяснять что там для чего нужно. Когда долго в этой кухне варишься это кажется элементарно, но на самом деле всё не так радужно. А потом какой-то из модулей перестаёт поддерживаться, и цепочка рушится.
Раньше как-то попроще было. И работало нормально. Но это не моя область, я просто не понимаю, зачем все эти нагромождения.
Раньше как-то попроще было. И работало нормально. Но это не моя область, я просто не понимаю, зачем все эти нагромождения.
Раньше было хуже. Раньше был ie6, ie7 и не было этих волшебных транспайлеров.
Ад зависимостей - похоже вы таки не знакомы с npm и темой поста. Как раз таки в npm каждый модуль ставится в свою папку, а его зависимости - в его личную внутреннюю папку node_modules. То есть, если у вас два модуля с одинаковыми зависимостями - npm не ебя себе мозга, продублирует их для каждого модуля отдельно. И это хорошо.
Ад зависимостей - похоже вы таки не знакомы с npm и темой поста. Как раз таки в npm каждый модуль ставится в свою папку, а его зависимости - в его личную внутреннюю папку node_modules. То есть, если у вас два модуля с одинаковыми зависимостями - npm не ебя себе мозга, продублирует их для каждого модуля отдельно. И это хорошо.
Т.е. у меня в проекте будет одновременно несколько версий одного и того же модуля, и это считается нормой и хорошей практикой? Я всё меньше и меньше понимаю логику всего этого.
Есть другой способ решить известную проблему Hell dependencies?
Нет, конечно можно резолвить версии, и общие сваливать в корень. Можно в принципе сваливать все в корень, делая постфикс папке в виде версии, почему бы и нет. Увы, npm не совершенство (да адище оно внутри тормозное честно говоря), но он стандарт дефакто в мире javascript. Но по крайней мере проблему с зависимостями он решает.
Нет, конечно можно резолвить версии, и общие сваливать в корень. Можно в принципе сваливать все в корень, делая постфикс папке в виде версии, почему бы и нет. Увы, npm не совершенство (да адище оно внутри тормозное честно говоря), но он стандарт дефакто в мире javascript. Но по крайней мере проблему с зависимостями он решает.
Ну если принять как данность миллиард плохо подддерживаемых модулей, то действительно, такой вариант хорош и удобен. Но думаю, ты согласишься, что это - скорее костыль, который появился как результат разброда в сообществе. Хотя, честно говоря, весь фронтенд всегда был набором костылей, и всё, что люди придумывали для облегчения жизни в нём, было, как правило, попытками привести всё это к удобоваримому удобному виду.
вроде как webpack это решает.
даа еще один пакет. Хуева туча пакетов для других пакетов, чтобы написать виджет кнопочки, эхх
даа еще один пакет. Хуева туча пакетов для других пакетов, чтобы написать виджет кнопочки, эхх
Да, были же времена, когда jQuery был единственной библиотечкой. А сейчас? Количество фреймворков, библиотек, языков и прочих фишек во фронт энде за последнее время просто зашкаливает. Назовите любое английское слово и скорей всего окажется, что им уже назван какой-нибудь фреймворк.
Единственной? А prototype, dojo, yui, mootools? Да и Backbone с Knockout вышли аж 6 лет назад. Их всегда было много. Просто jQuery был на слуху из-за своей универсальности и покрывал 100% того что требовалось от фроненда в те времена.
во-первых - помимо jQuery была уймы, во-вторыз Jquery сейчас стал настолько мнстроузомрным что проще с 0 написать свою ось и она меньше ресурсов будет жрать
Lesbians?
Только недавно прочел копипасту про "Как я решил кодить на JS в 2016"
Угу. Когда прочёл, подумал: слава Столлману, что я больше не занимаюсь фронтэндом. По-моему это какой-то ад. И за адом коллбеков люди не замечают ад зависимостей. Вот сейчас почитал про React, как он работает и думаю. А нахера весь этот огород? Зачем всё больше выносить логику представления юзеру на компьютер, туда, где её неудобно разрабатывать? Ну ладно, допустим в целях снижения нагрузки на сервер и улучшения UX. Но вот был backbone, angular. Работали и справлялись со своими задачами: получить данные и показать их пользователю. Что такого невероятного даст к удобству разработки\поддержки это нагромождение модулей?
А видео WATMAN смотрел? Ну оно не так называется, но, думаю, ты по слову поймешь о чем я.
Насчет же всего остального ничего не могу сказать, ибо я сам только начинающий кодер который фронтенд мало трогал, хоть и понимаю что без него не обойтись.
Насчет же всего остального ничего не могу сказать, ибо я сам только начинающий кодер который фронтенд мало трогал, хоть и понимаю что без него не обойтись.
Вот это? https://www.destroyallsoftware.com/talks/wat
Если да, то ржал, аки конь.
Да это были больше риторические вопросы, про-фротендщики мне наверняка расскажут телегу про то, насколько это облегчает разработку и поддержку, но честно сказать, мне это не очень интересно, я с фронтендом стараюсь как можно меньше общаться.
Если да, то ржал, аки конь.
Да это были больше риторические вопросы, про-фротендщики мне наверняка расскажут телегу про то, насколько это облегчает разработку и поддержку, но честно сказать, мне это не очень интересно, я с фронтендом стараюсь как можно меньше общаться.
Да нет там ада. Я ушел из геймдева в верстку и фронтенд. До геймдева когда я был в вебе, были этот jquery, и ie6. Жизнь была страданием. Теперь я ни о чем не парюсь. Есть прекрасный postcss, который сам за меня пишет все костыли. Есть переменные в css, наследование, вложенность, все чего не хватало. И без bower легко обойтись - browserify и babelify чудесно запускаются напрямую из node make.js. Да и babel я бы обошелся, так то. Но хочу писать js по разным файлам, и в синтаксисе js6/2015, это красиво и удобно. React? и без него можно обойтись. Он применяется в больших одностраничных веб приложениях, помимо него есть virtualdom и еще много реализаций, собирай свой пакет как хочешь.
К чему это я. Не надо слушать "модных" разработчиков. Они используют многоуровневые связки не чтобы усложнить себе жизнь, а потому что именно им так удобнее. Если тебе так не удобнее - да пожалуйста, пиши как удобно тебе. jQuery сейчас вполне ок. А если уж так вышло, что пришел в чужой проект, то там уже есть package.json, делай npm i и просто пиши код как он писался до этого в проекте.
К чему это я. Не надо слушать "модных" разработчиков. Они используют многоуровневые связки не чтобы усложнить себе жизнь, а потому что именно им так удобнее. Если тебе так не удобнее - да пожалуйста, пиши как удобно тебе. jQuery сейчас вполне ок. А если уж так вышло, что пришел в чужой проект, то там уже есть package.json, делай npm i и просто пиши код как он писался до этого в проекте.
Да я вообще не парюсь по этому поводу. Надо будет писать на чём-то новом, буду писать. Благо что мне всегда интересно новое изучать. Просто я сторонник толстого сервера и тонкого клиента, по соображениям безопасности и удобства разработки\отладки. А сейчас в моде смещение в сторону клиента, но, так как он для этого не приспособлен, люди начинают городить огороды из всяческих надстроек над js, компиляторов, менеджеров пакетов и т.д. Вот мне и не понятно, зачем было потрачено столько усилий, чтобы сделать то, что уже давно было придумано и сделано на серверной стороне.
К тому же новые решения, фреймфорки и модули появляются как грибы, они кричат, что решат все проблемы, но через пару месяцев появляется новый фреймворк, более лучше прежнего, и так далее. И вместо того, чтобы улучшать и развивать то, что и так хорошо работало, где есть устоявшиеся практики и решения, люди начинают пытаться решить проблему с другого конца.
К тому же новые решения, фреймфорки и модули появляются как грибы, они кричат, что решат все проблемы, но через пару месяцев появляется новый фреймворк, более лучше прежнего, и так далее. И вместо того, чтобы улучшать и развивать то, что и так хорошо работало, где есть устоявшиеся практики и решения, люди начинают пытаться решить проблему с другого конца.
Погодите секундочку. Во первых, много инструментов в этой кухне направлены как раз таки на тонкий клиент - все эти траспайлеры css, js, они для того, чтобы итоговый код css и js чистился от мусора, ненужных функций\стилей, минифицировался по максимому, ужимался в один файл, дабы браузер грузил его один раз, кешировал и радовал скоростью.
Другая же часть конечно да - направлена на толстый клиент. Это касается SPA - подход, когда пользователю доставляется само приложение, а не сервис. Тут не может быть сторонников одного и другого, это вопрос удобства пользователя - google drive может работать offline, многие react приложения отзывчивы, тот же github при просмотре репозитория не грузит страницу заного, а подменяет часть по ajax. В общем, эти ваши сервера еще ждать приходится, а клиентский код отзывается мнгновенно для пользователя.
Другая же часть конечно да - направлена на толстый клиент. Это касается SPA - подход, когда пользователю доставляется само приложение, а не сервис. Тут не может быть сторонников одного и другого, это вопрос удобства пользователя - google drive может работать offline, многие react приложения отзывчивы, тот же github при просмотре репозитория не грузит страницу заного, а подменяет часть по ajax. В общем, эти ваши сервера еще ждать приходится, а клиентский код отзывается мнгновенно для пользователя.
Я вам про про Фому, а вы мне про Ерёму. "тонкий" и "толстый" - это имеется в виду соотношение логики, которая выполняется на сервере или клиенте, а не объём трафика.
Насчёт SPA - где я хоть что-то про них плохое говорил? Но это отдельная, очень узкая ниша. Опять-таки, не совсем мне понятная - зачем, если есть настоящие приложения, которые удобно разрабатывать, у них больше возможностей и они быстрее. Но спишем всё на кроссплатформенность. Которой, впрочем, всё равно нет. Но спишем на неё.
А насчёт подгрузки частей страниц аяксом ради user experience - всё это было удобно и легко делать ещё в jQuery.
Насчёт SPA - где я хоть что-то про них плохое говорил? Но это отдельная, очень узкая ниша. Опять-таки, не совсем мне понятная - зачем, если есть настоящие приложения, которые удобно разрабатывать, у них больше возможностей и они быстрее. Но спишем всё на кроссплатформенность. Которой, впрочем, всё равно нет. Но спишем на неё.
А насчёт подгрузки частей страниц аяксом ради user experience - всё это было удобно и легко делать ещё в jQuery.
Короче не будем разводить холивар, я повторюсь в который раз - я не разрабатываю фронтедов достаточно давно, поэтому вполне могу упускать важность и удобство всех этих новшеств. Тому, кто это знает изнутри, конечно, виднее. Просто со стороны бэкэндщика всё это выглядит загромождённо и неэффективно.
Конечно без холивара, любой инструмент под соответствующую задачу.
Но продолжу разговор.
Я знаю что есть толстый и тонкий клиент, я лишь сказал, что очень много модулей в npm направлены на улучшение тонкого клиента - инструменты верстки, минификации js и css.
Насчет узкой ниши SPA. Тут индустрия как себя повела - есть мир, где клепаются сайты, много сайтов. Либо там вообще не используется npm, либо там используется npm ради вот этих вот пакетов для минификации и оптимизации верстки и js кода. И есть мир, где клепаются front-end приложения, и вот там да, толстые клиенты и транспайлер обмазывается транспайлером.
Подгрузка страниц аяксом - возможно я вас удивлю, но и сегодня это точно также делается через jQuery. npm тут не причем, npm и его модули лишь экосистема для сборки.
Кстати, на сторону бэкенда я тоже часто попадаю. Все зависит от выбранного инструмента, есть много отличных бэков. Но вот например Laravel - это такой вот себе аналог npm ада в мире php back end. Его папка Vendor - точно такое же адище из зависимостей, тысяч папок с глубинной вложенности 10-15.
Но продолжу разговор.
Я знаю что есть толстый и тонкий клиент, я лишь сказал, что очень много модулей в npm направлены на улучшение тонкого клиента - инструменты верстки, минификации js и css.
Насчет узкой ниши SPA. Тут индустрия как себя повела - есть мир, где клепаются сайты, много сайтов. Либо там вообще не используется npm, либо там используется npm ради вот этих вот пакетов для минификации и оптимизации верстки и js кода. И есть мир, где клепаются front-end приложения, и вот там да, толстые клиенты и транспайлер обмазывается транспайлером.
Подгрузка страниц аяксом - возможно я вас удивлю, но и сегодня это точно также делается через jQuery. npm тут не причем, npm и его модули лишь экосистема для сборки.
Кстати, на сторону бэкенда я тоже часто попадаю. Все зависит от выбранного инструмента, есть много отличных бэков. Но вот например Laravel - это такой вот себе аналог npm ада в мире php back end. Его папка Vendor - точно такое же адище из зависимостей, тысяч папок с глубинной вложенности 10-15.
Я еще помню времена когда джава-скрипт был джаваскриптом, над "програмистами на фреймворках" все смеялись, и шла война VB-script и JavaScript. Да, славные были времена, еще до смерти предыдущего тысячелетия.
Вот JS6\2015 на самом деле неплох, неплох.
