Comments 71
А почему выбрали requirejs, а не webpack?
Недавно еще была шумиха вокруг browserify, теперь webpack. Чем webpack лучше requirejs?
Не знаю чем там что лучше, но… может просто юзать модули из es2015 + esperanto + babel?
Разве babael c gulp нельзя использовать? Ссылка
Не понял вопроса, тип то что я не перечислил gulp? Это уже детали, я вот с gulp-ом использую.
Вопрос предпочтения нотации. Лично мне больше нравится добавлять модули commonjs стилем — поэтому я перешел на browserify/webpack с require и ни разу не пожалел. Но, как говорится, на вкус и цвет фломастеры у всех разные)
Не знаю как webpack, но от browserify отказался потому что он не умеет в браузере работать без предварительной компиляции. С Requirejs удобно как раз таки в режиме разработки все зависимости в браузере подгружать.
Соглашусь — дополнительный шаг компиляции — не всегда супер удобен — динамическая подгрузка — в данном вопросе для Require — плюс по сравнению с browserify.
Тогда вам подойдет jspm.io. Большой плюс — легкость работы с babel.
легкость работы с babel.
return gulp
.src('src/**/*.js', {sourcemaps: true})
.pipe(util.plumber())
.pipe(babel({
modules: 'system'
}))
и при этом не надо вводить еще один мнеджер пакетов помимо bower и npm. Согласен что свои плюсы этот подход несет, но мне не удобно иметь один универсальный менеджер пакетов. Когда идет разделение как-то проще понять что где искать и что есть для чего. Ну и в релиз собирать через esperanto.
webpack.github.io/docs/comparison.html
можно на горячую обновлять реакт, есть автоматическая разбивка бандла на части, можно в бандл закинуть картинки и шаблоны, можно настроить так чтобы сливались только картинки менее определенного размера, а большие складывались в ресурсы, дофига магии разной полезной, и common js синтаксис нормально поддерживается, lazy loading умеет, компилится в dev режиме за долю секунды, вобщем при переходе с requirejs стало жить приятнее
можно на горячую обновлять реакт, есть автоматическая разбивка бандла на части, можно в бандл закинуть картинки и шаблоны, можно настроить так чтобы сливались только картинки менее определенного размера, а большие складывались в ресурсы, дофига магии разной полезной, и common js синтаксис нормально поддерживается, lazy loading умеет, компилится в dev режиме за долю секунды, вобщем при переходе с requirejs стало жить приятнее
Раз Вебпак такой крутой, сбилдить папку
Есть ссылки на подобные примеры?
dist в таком AMD-проекте раз плюнуть. Разумеется изменение состава модулей не должно влиять на код сборки.project
|- dist
|- vendor-<random>.js
|- module1-<random>.js
|- module2-<random>.js
|- module3-<random>.js
|- index.html
|- src
|- module1
|- index.js
|- service1.js
|- someDir
|- service2.js
|-module2
|-module3
|- vendor
|- config.js //like requireJs config
|- index.html
gulpfile.js
Есть ссылки на подобные примеры?
Читали это? webpack.github.io/docs/code-splitting.html
Все просто, я могу с легкостью писать amd, common, es 2015 и не будет проблем это все интегрировать github.com/webpack/webpack/tree/master/examples/mixed
Webpack реализует подход другой. Он на очереди в списке. Просто про require раньше узнал. Webpack еще и gulp, получается, заменяет.
Webpack еще и gulp, получается, заменяет.
Многие задачи решает, но таскраннер все равно нужен.
Npm scripts + github.com/kimmobrunfeldt/concurrently?
Мир уже перешел на быстрый вебпак с инкрементальными обновлениями и require-ом всего, что только можно, а тут «level up» заключается в require.js. Смех.
Level Up для новичков заключается в модульном подходе в принципе. И про webpack расскажем. Если подскажите, как протестировать производительность, буду благодарен. Я такой же новичек во всем этом.
Ну так статья «от новичка для новичков», что вы хотите. Технических статей тут и так не хватает, хоть что-то.
Все же в чем профит от перехода с requirejs на webpack?
Возможность писать import $ from 'jquery'; без 100500 разных скобочек. Да и вообще код чище и аккуратнее выглядит.
hot-reload, простое подключение модулей для less, jsx, прочих модных слов.
конфиг webpack для меня выглядит понятнее и логичнее чем shim require.js
Я require.js пользовался довольно долго, а вот с тех пор как первый раз увидел как работает проект с webpack, про другие варианты даже думать забыл.
hot-reload, простое подключение модулей для less, jsx, прочих модных слов.
конфиг webpack для меня выглядит понятнее и логичнее чем shim require.js
Я require.js пользовался довольно долго, а вот с тех пор как первый раз увидел как работает проект с webpack, про другие варианты даже думать забыл.
Перешли только школьники. Впрочем, они каждый год переходят на что-то новое. Читая комментарии про CommonJS и es2015, создается впечатление, что народ даже со средними проектами не работал. В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет. Статья, конечно, дурацкая, человек рассказывает о первом опыте, но это никак не превозносит Webpack, который, вообще глупо сравнивать с RequireJS, т. к. это технологии разных уровней.
Люди переходят на новые технологии, которые облегчают жизнь (и действительно это делают, в том числе благодаря «школьникам», которые посылают патчи и пишут об ошибках), что за нытьё про школьников/хипстеров/etc?
> В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет.
Пруфы? Особенно про ошибки компиляции. Боюсь даже представить, сколько же будет тормозов от вебпака, который бьёт бандл на чанки и в дев-режиме обновляет только конкретный чанк. И это включая лоадеры типа scss/babel.
> но это никак не превозносит Webpack, который, вообще глупо сравнивать с RequireJS, т. к. это технологии разных уровней
RequireJS только для джса, вебпак для всего, был бы подходящий лоадер. Зачем нужен requirejs, если вебпак в разы лучше? Особенно пресловутые чанки и hot mode.
> В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет.
Пруфы? Особенно про ошибки компиляции. Боюсь даже представить, сколько же будет тормозов от вебпака, который бьёт бандл на чанки и в дев-режиме обновляет только конкретный чанк. И это включая лоадеры типа scss/babel.
> но это никак не превозносит Webpack, который, вообще глупо сравнивать с RequireJS, т. к. это технологии разных уровней
RequireJS только для джса, вебпак для всего, был бы подходящий лоадер. Зачем нужен requirejs, если вебпак в разы лучше? Особенно пресловутые чанки и hot mode.
Пруфы?
Ошибки не по вине компилятора, а по вине разработчика. Отступ лишний поставил, IDE при вставке куска напортачила. Сложнее система — больше ошибок.
Что? Какой отступ? Какая IDE? Вы что несете?
yaml и stylus файлы чувствительны к отступам. Копипаст там не всегда корректно работает, какой-то не тот вид пробела может поломать сборку. С компилятором Кофе скрипта больше пары дней не выдержал, пока не заметил, что вместо того чтобы писать код разбираюсь почему опять сломалась сборка. И консолька ОС далеко не так информативна как консолька Хрома. Jade, polymer — та же фигня. А еще библиотеки имеют свойство обновляться. А еще нужно чтобы со всем этим хламом умели новые сотрудники работать. У адекватного разработчика в проекте будет только самое необходимое, а для этого Вебпак вовсе необязателен.
у меня на бэкэнде в yaml все конфиги, а еще есть ansible у которого вообще все (кроме модулей) на yaml, и почему-то никаких проблем. stylus — тут так же как и с python, привык и нет проблем (хотя я сам испольюзую less и потиху подумываю уходить на postcss).
Ну а если нет таких проблем? Ну вот… я на кофе не пишу (и не люблю по непонятным мне причинам), но я повсеместно использую сборщики, и у меня почему-то никаких проблем с настройкой сборки нет. Более того, 90% всего того что настраивается можно спокойно реюзать. Меня в этом плане очень радует gulp4, у него больше гибкости в плане управления тасками.
Ну… а я просто ставлю в любимой IDE бряку чуть что, не так клево как консолька хрома, но для CLI скриптов больше и не нужно. Да и сборку я дебажил только когда ее в последний раз настраивал с нуля, что бывает не часто.
А как это вообще попало в один список? На счет jade, хоть я его и использую, согласен. Мне он нравится, позволяет не писать лишних символов и удобно бороться с излишне жирными директивами… Но полимер то? Вы еще скажите что web-components это все лишняя отвлекающая штука.
вместо того чтобы писать код разбираюсь почему опять сломалась сборка
Ну а если нет таких проблем? Ну вот… я на кофе не пишу (и не люблю по непонятным мне причинам), но я повсеместно использую сборщики, и у меня почему-то никаких проблем с настройкой сборки нет. Более того, 90% всего того что настраивается можно спокойно реюзать. Меня в этом плане очень радует gulp4, у него больше гибкости в плане управления тасками.
И консолька ОС далеко не так информативна как консолька Хрома.
Ну… а я просто ставлю в любимой IDE бряку чуть что, не так клево как консолька хрома, но для CLI скриптов больше и не нужно. Да и сборку я дебажил только когда ее в последний раз настраивал с нуля, что бывает не часто.
Jade, polymer
А как это вообще попало в один список? На счет jade, хоть я его и использую, согласен. Мне он нравится, позволяет не писать лишних символов и удобно бороться с излишне жирными директивами… Но полимер то? Вы еще скажите что web-components это все лишняя отвлекающая штука.
Вот давайте так, если у вас нет опыта работы с ES2015/TypeScript/Coffee то и не надо придумывать несуществующих проблем. IDE прекрасно с ними работает (с typescript лучше чем с js собственно). А сделать ошибку синтаксическую можно и в js.
С Coffee точно не все так гладко. По крайней мере пару лет назад было. В любом случае, ES2015/TypeScript/Coffee не дают такого профита, чтобы на них писать что-либо отличное от исследовательского или игрового проекта. Даже синтаксический сахар там не такой сладкий как в ES5 был. Часто классы используете? Можно посчитать количество классов в коде Ангуляра, Реакта, в своем собственном проекте — десятка не наберется. Без стрелочныйх функций не прожить? Хотите обучать новых сотрудников как пользоваться генераторами, хотя сами смутно представляете? В данный момент (2015-2016) всё это баловство. А потом народ пишет, что Вебпак крут, потому что в нем легко баловаться, при том что до сих пор нет ни одной статьи где бы говорилось почему он действительно крут.
классы — регулярно (2/3 директив содержат контроллер и не содержат линка, все контроллеры и сервисы — классы). В случае со сложной бизнес логикой на клиенте у меня появляются еще сущности, которые так же являются классами и имеют внутри какую-то логику. И да, код от этого становится чище (есть с чем справнивать), что положительно сказывается на суппорте приложения. Так же проще организовать внутренние правила аля «дробите приложение на директивы, юзайте контроллеры и т.д.». Без классов, только с Object.create как-то грустно все же.
Стрелочные функции — опять же удобно, особенно когда часто пользуешься map/reduce/filter/etc. Это, как вы правильно заметили, просто сахар, который позволяет сократить количество информационного мусора.
Что до генераторов — говорите за себя, я знаю как устроены и генераторы и корутинки могу пописать, но да, их я сейчас не использую ибо для команды это перебор. Генераторы и корутины это круто, но их чаще можно встретить на бэкэнде (php, python, ruby). Для JS будет счастьем async/await, что валяются в черновиках ES7.
На текущий момент (2015-2016) использование ES2015 это уже необходимость, так как при должном подходе это упрощает поддержку кода за счет того сахара и плюшек. которые оно дает. Да взять хотя бы дефолтные значения для аргументов, это совсем уж мелочь но так упрощает восприятие кода.
Ну а webpack — я не знаю чем он так крут и я его не использую так как не вижу преимущест перед gulp конкретно для себя.
Стрелочные функции — опять же удобно, особенно когда часто пользуешься map/reduce/filter/etc. Это, как вы правильно заметили, просто сахар, который позволяет сократить количество информационного мусора.
Что до генераторов — говорите за себя, я знаю как устроены и генераторы и корутинки могу пописать, но да, их я сейчас не использую ибо для команды это перебор. Генераторы и корутины это круто, но их чаще можно встретить на бэкэнде (php, python, ruby). Для JS будет счастьем async/await, что валяются в черновиках ES7.
В данный момент (2015-2016) всё это баловство.
На текущий момент (2015-2016) использование ES2015 это уже необходимость, так как при должном подходе это упрощает поддержку кода за счет того сахара и плюшек. которые оно дает. Да взять хотя бы дефолтные значения для аргументов, это совсем уж мелочь но так упрощает восприятие кода.
Ну а webpack — я не знаю чем он так крут и я его не использую так как не вижу преимущест перед gulp конкретно для себя.
все контроллеры и сервисы — классы
Ангуляр давно решил эту проблему. Там ни Object.create не нужно использовать, ни new делать. Другие фреймворки предоставляют свои обертки. Со времен jQuery не встречал фронтендского проекта, где бы слово new (по отношению к пользовательским классам) употреблялось бы чаще 20 раз.
я знаю как устроены и генераторы
Нужно не просто знать, а уметь использовать, чего пока никто не умеет даже на node.js. Даже когда async/await появится, должны появиться фреймворки их использующие, выработана практика, набиты шишки, средний разработчик должен уметь с этим работать. А это не год и не два.
О коллегах нужно так же думать, о контрибьютерах если проект открытый. Не забегать слишком вперед, чтобы другим не пришлось ломать голову и разбираться в неутвержденных или нереализованных спецификациях.
Совсем отошли от темы :-) Просто на фронтенде СТОЛЬКО нерешенных задач… Судя по публикациям, народ до сих пор топчется на уровне «делаем приложение на Ангуляре/Реакте/Метеоре за 10 дней», зато в комментариях все достигли таких высот, что от нечего делать обновляются на ES6.
Ангуляр давно решил эту проблему
Можно подробнее, какую именно проблему решил ангуляр и почему там не нужны классы? Про Object.create ладно, заменим просто на Object.defineProperties, мы же должны определить методы прототипа и все такое. Тут вопрос в том как организовать методы объектов и т.д. С классами это очень легко и хорошо читается. А уж инджектор позоботится обо всем остальном.
Нужно не просто знать, а уметь использовать
У вас может выборка не репрезентативна? Опять же, корутины мало кто пишет потому что это сложнее чем юзать промисы, но их пишут. С генераторами намного проще, это просто сахар над итераторами. Ну и да, генераторы уже реализованы в хроме и фаерфоксе (не полностью но с большего).
Судя по публикациям, народ до сих пор топчется на уровне «делаем приложение на Ангуляре/Реакте/Метеоре за 10 дней»
Да я вам больше скажу, я не видел на гитхабах ни одного проекта на ангуляре, который я мог бы спокойно дать посмотреть другим как пример «как надо делать». Какого рода публикаций вы ждете (вдруг кто будет читать этот диалог да напишет чего)? Ну и ES6 не от нечего делать, за 4 месяца после внедрения люди начали писать более чистый код, что я считаю достаточным оправданием что бы усложнять инфраструктуру. С ES6 мне было проще определить какие-то границы и правила о том «как надо чего делать», а эти правила в последующим упростят людям поддержку кода и позволят быстро мигрировать на angular2 как только он выйдет. Была б моя воля я бы сразу всех на TypeScript перевел, но это было бы уже слишком резким изменением.
Можно подробнее, какую именно проблему решил ангуляр и почему там не нужны классы?
Классы в Ангуляре создаются через методы-обертки factory(<имя>, <конструктор>), соntroller(<имя>, <конструктор>) и т. п., поэтому код типа (и более сложный )
var MyClass = function() { ... }
MyClass.ptototype.blabla = blabla
var myClass = new MyClass()
//или в es2015
class MyClass { ... }
приходится писать крайне редко.
Какого рода публикаций вы ждете
Любых, которые бы показывали что люди растут, а не кидаются с одной технологии на другую. Сейчас подавляющее большинство публикаций из разряда: «новая технология такая-то», «мой первый опыт, не бейте сильно», «посмотрите какие костыли мы внедрили в своей компании». По тому же Вебпаку ни одной статьи, описывающей бест практис, а не детские примеры.
Классы в Ангуляре создаются через методы-обертки factory
Да, и это проблема:
angular
.module('app')
.factory({
foo: fooFactory,
bar: barFactory,
buz: buzFactory
})
.service('fooBar', FooBar)
;
// среднестатистическая фабрика
function fooFactory (depA, depB) {
return {
foo: foo
}
function foo () { return 'foo'; }
}
// ваш вариант
function barFactory(depA, depB) {
function Bar() {}
Bar.prototype.foo = function () { return 'foo'; };
return Bar;
}
// а если мы захотим рид онли свойства (ну а вдруг? Я лично считаю это дурным тоном но всякое бывает)
function buzFactory(depA, depB) {
var readOnlyVal = 'read only';
function Buz () {}
Object.defineProperties(Buz.prototype, {
buz: { value: buz },
readOnlyVal: { get: function () { return readOnlyVal; } }
});
function buz() { return 'buz'; };
}
// ну и как это у меня
class FooBar {
constructor(depA, depB) {
this.depA = depA;
this.depB = depB;
}
fooBar () {
return 'foobar';
}
get readOnlyVal () {
return readOnlyVal; // ну тип это может быть взятие значений из weakmap например
}
}
возможно кода больше но зато аккуратнее как-то. ну и для людей пришедших из других языков это кажется логичнее (я вообще php-шник).
Любых, которые бы показывали что люди растут
С этим сложно, на нормальную статью нужно убить довольно много времени, альтруизма не хватит.
В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции
В большом проекте я в любом случае возьму TypeScript, а инкрементные билды не добавляют большого оверхэда. Ошибки компиляции возможны (напарывался на парочку в babel первое время) но они оперативно устраняются. Полифилы в этом плане чаще косячат.
это никак не превозносит Webpack,
Статья описывает не только профит require.js но и как собирать модули, так что сравнения webpack vs amd никто не делает (это глупо так как оный поддерживает и amd).
Читая комментарии про CommonJS и es2015, создается впечатление, что народ даже со средними проектами не работал. В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет.
Ухты как интересно! Расскажите, в чем проблема commonjs на больших проектах, а то пока что звучит как очень безосновательное утверждение.
CommonJS-модули не работают в браузерах т. к. у них нет изолированной области видимости. Для этого каждый файл нужно обернуть. Это должен делать сборщик и делать это на каждый чих. Изменения на сайте появляются не сразу, особенно, когда зависимостей много, что раздражает. При отладке не виден исходный файл, source map опять же добавляют лишнюю сложность, а сложный проект нужно делать как можно проще, потому что его собственной сложности хватает. Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена. Максимум библиотечку типа lodash и набор функций для валидации. Синтаксис не проще и не сложнее. Пока использовать их на фронтенде в любых проектах кроме исследовательских бессмысленно. Возможно через пару лет всё изменится.
Это должен делать сборщик и делать это на каждый чих. Изменения на сайте появляются не сразу
И с этим нет никаких проблем, инкрементная сборка происходит быстрее чем вы можете переключить внимани е от IDE к дебагеру/браузеру. А с livereload еще и успевает за это время загрузиться. Скажем для reactjs есть hot reload, когда отдельные компоненты перезагружаются без необходимости перезагрузки страницы. И там на каждый чих компилится JSX.
source map опять же добавляют лишнюю сложность
Отчасти да, но эта сложность относительно небольшая, а профит который дают инструменты (модули, надстройки над js, штуки требующие трансляции) снижают сложность поддержки и разработки решений (за исключением того что требуется разобраться с инструментом).
Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена
Альтернатива? На node.js к слову необходимость крайне высока.
Максимум библиотечку типа lodash
А теперь скажите что для вас большой проект? Или вы предлагаете все писать тупо на javascript без фреймворков и лишней «сложности»? Я конечно чуть утрирую ваши слова, но выходит как-то так. Для большинства эти инструменты экономят кучу сил и времени. Да, можно и без них, но сложность возврастает в других местах. Ну и да, вы пишите тесты?
geometria.ru, vozovoz.ru большие проекты? Сейчас RequireJS, Angular, Stylus, Jasmine, Karma, Gulp. От Coffee через пару дней отказался, Jade тоже пошел лесом, Stylus пока больше плюсов приносит. От jQuery удалось избавиться, как и от всех компонентов его использующих. Lodash бы тоже кастрировал так как по факту из него используется несколько функций, причем многие в костыльных местах. Возможно вместо Jasmine вернусь к Mocha, чтобы одна технология и на фронтенде и на бэкенде была. Чем больше говна выпиливается, тем проще: не нужно учить лишнего, не нужно обучать лишнему, не нужно ловить ошибки в чужом коде, не нужно следить за совместимостью, код проще читается.
Кучу сил и времени экономит хорошая архитектура, а не модные плюшки.
Кучу сил и времени экономит хорошая архитектура, а не модные плюшки.
geometria.ru, vozovoz.ru большие проекты?
Обычные сайтики на ангуляре, на фронтенд не больше 1-1.5к человекочасов каждый.
На поддержку и 0.5 хватит. На разработку значительно больше :-) Приведите примеры сложных сайтов на Ангуляре. Самому интересно глянуть.
На поддержку? 0.5? Вы вообще в курсе что такое поддержка? Если на разработку ушло более 1.5к — это очень грустно.
Сайт в традиционном понимании (интернет-магазин, веб-портал и т.п.) — , на мой взгляд, очень редко бывает большим, сложным проектом. Если хотите посмотреть большой проект на JS, вот вам пример: sdk.amazonaws.com/js/aws-sdk-2.1.45.js, как ни странно, на commonjs. Видимо в amazon не в курсе, что его не стоит в больших проектах использовать.
Приведите примеры сложных сайтов на Ангуляре.
Сайт в традиционном понимании (интернет-магазин, веб-портал и т.п.) — , на мой взгляд, очень редко бывает большим, сложным проектом. Если хотите посмотреть большой проект на JS, вот вам пример: sdk.amazonaws.com/js/aws-sdk-2.1.45.js, как ни странно, на commonjs. Видимо в amazon не в курсе, что его не стоит в больших проектах использовать.
CommonJS-модули не работают в браузерах т. к. у них нет изолированной области видимости.Открою секрет, они не по-этому в браузере не работают.
Для этого каждый файл нужно обернуть.Browserify делает это автоматически.
Изменения на сайте появляются не сразу, особенно, когда зависимостей много, что раздражает.На больших проектах изменения на сайте появляются только после деплоя из CI-системы.
source map опять же добавляют лишнюю сложностьУжсУжсУжс… какая же все таки сложная штука source map, никогда бы не подумал.
Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена.Неверно.
… и т.д. и т.п.
Судя по тому что вы пишете, это как раз вы вряд ли имели дело с проектами больше и сложнее обычного интернет-магазина.
Посмотрел на это
Постоянно наблюдаю ситуацию когда юзвари забывают возвращать потоки с тасков в gulp'e или не знают про merge-stream.
Надо делать вот так
и вот так
Это нужно что бы время выполнения задачи нормально логировалось, и синхронизация происходила без побочных эффектов.
А то большая часть gulp адептов меня расстраивают :|
Мне, обычно, browserify watchify debowerify deamdify babelify с головою хватает — 2-3 секунды на сборку бандла погоды не делают, а WebPack просто не обеспечивает должной гибкости, да и больших преимуществ по скорости работы, как многие голосят, я раньше не замечал…
gulp.task('js',function(){
gulp.src('./assets/js/*.js')
.pipe(dosomestuff());
});
Постоянно наблюдаю ситуацию когда юзвари забывают возвращать потоки с тасков в gulp'e или не знают про merge-stream.
Надо делать вот так
gulp.task('js',function(){
return gulp.src('./assets/js/*.js')
.pipe(doSomeStuff());
});
и вот так
var merge = require('merge-stream');
gulp.task('js',function(){
merged = merge();
[
'mdpi', 'hdpi', 'xhdpi'
].forEach(function(density) {
merged.add(gulp.src('app/images/**/*.@(png|gif|jpeg)')
.pipe(doSomeMagicStuff()))
.pipe(gulp.dest('dist/images/' + density)));
});
return merged;
});
Это нужно что бы время выполнения задачи нормально логировалось, и синхронизация происходила без побочных эффектов.
А то большая часть gulp адептов меня расстраивают :|
Мне, обычно, browserify watchify debowerify deamdify babelify с головою хватает — 2-3 секунды на сборку бандла погоды не делают, а WebPack просто не обеспечивает должной гибкости, да и больших преимуществ по скорости работы, как многие голосят, я раньше не замечал…
UFO just landed and posted this here
Работал почти со всем что более-менее актуально и распространено.
Получается такая ситуация что как только контра хочет разработать какое-то актуальное решение — нужно пилить свой гибрид лигерада с токамаком. Так было с Rails / Grails / Gulp.js / React.js / Sproutcore (ember) / Cappuccino / Symfony / Play2…
A практике получается так что MVC подходит только для простых UI, и на бэкенде порождает тонну шаблонной копипасты из-за Scaffolding'a. Рано или поздно, люди всеравно скатываются в CQRS-ES с всякими German / Celery / Sidekiq / beanstalk / rabbitmq и т.п. Ну или, что ещё хуже, потом обзывают это всё микросервисами. Хотя на самом деле для REST CRUD'ов, не зависимо от размера (нормализованной) базы, хватит 6 шаблонных front controller'ов.
Большую часть существующего фронта можно очень сильно абстрагировать: избавится от потребности дублирования моделей их валидации, и представления — генерировать это всё на лету автоматом с существующих серверных шаблонов, не смотря на целевые языки и платформы, полностью избавиться от node.js на сервере, для меня он часто становится бутылочным
Существует не так много решений, которые действительно удовлетворяют современные потребности рынка и обеспечивают должное качество реализации решений.
Получается такая ситуация что как только контра хочет разработать какое-то актуальное решение — нужно пилить свой гибрид лигерада с токамаком. Так было с Rails / Grails / Gulp.js / React.js / Sproutcore (ember) / Cappuccino / Symfony / Play2…
A практике получается так что MVC подходит только для простых UI, и на бэкенде порождает тонну шаблонной копипасты из-за Scaffolding'a. Рано или поздно, люди всеравно скатываются в CQRS-ES с всякими German / Celery / Sidekiq / beanstalk / rabbitmq и т.п. Ну или, что ещё хуже, потом обзывают это всё микросервисами. Хотя на самом деле для REST CRUD'ов, не зависимо от размера (нормализованной) базы, хватит 6 шаблонных front controller'ов.
Большую часть существующего фронта можно очень сильно абстрагировать: избавится от потребности дублирования моделей их валидации, и представления — генерировать это всё на лету автоматом с существующих серверных шаблонов, не смотря на целевые языки и платформы, полностью избавиться от node.js на сервере, для меня он часто становится бутылочным
Существует не так много решений, которые действительно удовлетворяют современные потребности рынка и обеспечивают должное качество реализации решений.
Кажется requirejs и AMD уже умер. CommonJS и ES6 modules — все крутые ребята на них сидят.
requirejs нужен для того, чтобы сайт не состоял из одного гигантского js-файла, а грузился в несколько асинхронных потоков
requirejs нужен для того что бы загружать модули, но без http2 с мультиплексирование трафика всеравно придется модули собирать в бандлы.
Вот прикольная альтернатива для require.js jspm.io
Это не альтернатива. Это совсем из другой оперы, это просто менеджер пакетов для тех кому лень выбирать между npm/bower и для тех кто хочет один менеджер пакетов. У меня помимо npm и bower есть еще composer и ansible-galaxy так что мне эта штука вообще как-то не понравилась. Проблемы она мои не решает и только привносит лишнюю сущность.
Насколько я помню там github.com/systemjs/systemjs, который позволяет делать также как и в require.js
Что вам мешает писать модульный код с CJS/ES6 modules и асинхронно их загрузать по мере необходимости? Тот же webpack это позволяет легко сделать.
Sign up to leave a comment.
Level Up для новичков: gulp и requirejs