Предисловие
Качество приложения зависит не только от того, какие задачи и с какой скоростью оно решает, но и от таких, казалось бы, второстепенных факторов как «красота кода».
Под красотой кода я (полагаю, и многие другие) понимаю:
- Читабельность
- Простоту изменения и дополнения
- Возможность другим разобраться, как это работает
Каждый на заре своего пути разработчика писал код, который был способен решить определённую (часто даже непростую) задачу, но при попытке что-то изменить или адаптировать под похожую задачу возникали проблемы.
Да и презентабельность такого кода вызывала сомнения.
Давайте разберёмся с двумя инструментами, которые не смотря на свою простоту повысят презентабельность исходников вашего приложения и наведут порядок в голове.
Gulp
Что есть gulp?
Это сборщик проектов.
Для чего он нужен?
Вопрос сложнее.
Не теряя удобства разработки на выходе вы получаете проект в том виде, в котором он должен быть:
- Оптимизированные картинки
- Минимизированные стили и скрипты
- Прочее
По сути вы получаете две копии приложения: рабочую, которая понятна вам, в которую удобно вносить правки и публичную (public), уже собранную из ваших кусочков и оптимизированную.
Говоря о собранном из кусочков проекте я имел в виду осуществление модульного подхода к программированию, который, на мой взгляд крайне полезен и является отправной точкой на пути повышения квалификации разработчика. Причины тому, очевидно: возможность легко интегрировать любой модуль в любой проект (не допиливая напильником), удобство тестирования и, главное, порядок в голове.
Gulp по сути является js скриптом (набором скриптов), который работает на сервере node.js.
Это вовсе не означает, что вам надо изучить nodejs, чтобы использовать gulp, но базовые знания его менеджера пакетов (npm) понадобятся.
Задача первая: поставить локально сервер node.js.
Не буду заострять на этом внимание, слишком просто. После установки мы сможем использовать npm.
Задача вторая: установить (по сути скачать) gulp с помощью менеджера пакетов.
Для маководов это заключается в следующем: в терминале напишем
npm install gulp -g
Флаг -g означает, что мы устанавливаем его глобально, чтобы можно было запускать его в терминале командой
gulp
gulp task
Затем настроим окружение для нашего проекта, перейдя в консоли в нужную папку
mkdir assets public assets/js assets/img assets/css
touch gulpfile.js
npm init
npm i --save-dev gulp
По порядку:
- Создаем структуру папок
- Создаем файл настроек нашего сборщика
- Инициализируем npm, чтобы установить полезные в сборке модули
- Устанавливаем gulp с ключем "--save-dev", то есть в директории нашего проекта
Аналогично с последней строчкой установим все модули, нужные нам в сборке
npm i --save-dev gulp gulp-autoprefixer gulp-concat-css gulp-connect gulp-livereload gulp-minify-css gulp-sass gulp-rename gulp-uncss gulp-uglify gulp-imagemin imagemin-pngquant
- gulp-autoprefixer // Добавляет стили с префиксами для поддержки браузеров
- gulp-concat-css // Склеивает стили в один файл
- gulp-connect // Сервер
- gulp-livereload // Обновляет страницу в браузере после изменений кода
- gulp-minify-css // Минификация стилей
- gulp-sass // Без комментариев (пока не нужно)
- gulp-rename // Переименовывает файлы
- gulp-uncss // Удаляет лишние стили
- gulp-uglify // Минификация скриптов
- gulp-imagemin // Минификация изображений
- imagemin-pngquant // Минификация изображений
Примеры использования и подключения наипонятнейшим образом описаны здесь.
Теперь все, что нам нужно — это описать файл настроек, то как именно надо собирать наш проект.
Для этого в нашем файле настроек (gulpfile.js) создадим задачи (таски)
gulp.task('js',function(){ // Таск "js"
gulp.src('./assets/js/*.js') // С чем работаем
.pipe(uglify()) // Что именно делаем. В данном случае минифицируем
.pipe(gulp.dest('./public/js/')) // Куда складываем результат
.pipe(connect.reload()); // Обновляем страницу (не обязательно)
});
На самостоятельное изучение оставляю полный код моего
var concatCss = require('gulp-concat-css');
var minifyCss = require('gulp-minify-css');
var rename = require(«gulp-rename»);
var autoprefixer = require('gulp-autoprefixer');
var livereload = require('gulp-livereload');
var connect = require('gulp-connect');
var sass = require('gulp-sass');
var uglify = require('gulp-uglify');
var imagemin = require('gulp-imagemin');
var pngquant = require('imagemin-pngquant');
// Основные
gulp.task('css', function () {
gulp.src('./assets/css/*.css')
.pipe(concatCss(«style.min.css»))
.pipe(minifyCss({compatibility: 'ie8'}))
.pipe(autoprefixer({
browsers: ['last 10 versions'],
cascade: false
}))
.pipe(gulp.dest('./public/css/'));
gulp.src('./assets/css/fight/*.css')
.pipe(concatCss(«fight.min.css»))
.pipe(minifyCss({compatibility: 'ie8'}))
.pipe(autoprefixer({
browsers: ['last 10 versions'],
cascade: false
}))
.pipe(gulp.dest('./public/css/'))
.pipe(connect.reload());
});
gulp.task('sass', function () {
gulp.src('./assets/sass/*.ccss')
.pipe(sass(«style.css»))
.pipe(minifyCss(''))
.pipe(rename(«style.sass.min.css»))
.pipe(autoprefixer({
browsers: ['last 10 versions'],
cascade: false
}))
.pipe(gulp.dest('./public/css/'))
.pipe(connect.reload());
});
gulp.task('html',function(){
gulp.src('./assets/*.html')
.pipe(gulp.dest('./public/'))
.pipe(connect.reload());
});
gulp.task('fonts',function(){
gulp.src('./assets/font/**/*')
.pipe(gulp.dest('./public/font/'))
.pipe(connect.reload());
});
gulp.task('js',function(){
gulp.src('./assets/js/*.js')
.pipe(uglify())
.pipe(gulp.dest('./public/js/'))
.pipe(connect.reload());
});
gulp.task('jslibs',function(){
gulp.src('./assets/js/libs/*.js')
.pipe(uglify())
.pipe(gulp.dest('./public/js/libs/'))
.pipe(connect.reload());
});
gulp.task('jsmods',function(){
gulp.src('./assets/js/modules/**/*.js')
.pipe(uglify())
.pipe(gulp.dest('./public/js/modules/'))
.pipe(connect.reload());
});
gulp.task('img',function(){
gulp.src('./assets/img/*')
.pipe(imagemin({
progressive: true,
svgoPlugins: [{removeViewBox: false}],
use: [pngquant()]
}))
.pipe(gulp.dest('./public/img/'))
.pipe(connect.reload());
});
// Connect
gulp.task('connect', function() {
connect.server({
root: 'public',
livereload: true
});
});
// Watch
gulp.task('watch',function(){
gulp.watch("./assets/css/**/*.css", [«css»]);
gulp.watch("./assets/*.html", [«html»]);
gulp.watch("./assets/js/*.js", [«js»]);
gulp.watch("./assets/js/libs/*.js", [«jslibs»]);
gulp.watch("./assets/js/modules/**/*.js", [«jsmods»]);
});
// Default
gulp.task('default', [«html», «css», «sass», «js»,«jslibs», «jsmods», «connect», «watch»]);
Заострю внимание лишь на паре вещей.
Любая из созданных задач (тасков) запускается из консоли по шаблону
gulp task
Если мы напишем просто «gulp», что запустится таск по умолчанию, то есть default.
Таск watch — встроенный таск для отслеживания изменений в файлах. Его настройка настолько очевидна (см приведенный код), что уверен, каждый справится. Этот таск позволяет не вызывать каждый раз процесс сборки проекта после любого изменения кода. Как только вы сохраните файл, gulp это увидит и пересоберет проект, а в данном случае еще и обновит страницу в браузере, и вам останется только перевести взгляд на нужный монитор, чтобы увидеть результат.
Чтобы собрать проект с вышеприведенными настройками просто введите в консоли (находясь в папке проекта)
gulp img
gulp
Работу с картинками вынес в отдельный таск для удобства (моего).
После этого не закрывайте консоль, у вас запущен watch'ер и сервер.
По сути вы можете писать в каждом отдельном файле маленькую js функцию, а сборщик соберет все это в один файл.
Тут мы вплотную подошли к вопросу модульности. Вышеприведенная ситуация очень похожа на модульный подход (издалека) — каждой функции (модулю) отдельный файл. Не запутаешься. Но что делать когда один модуль зависит от другого, от нескольких других, а те еще от других.
Да, тут уже посложнее, надо продумать правильный порядок подключения модулей. И тут нам на помощь приходит requirejs, который осуществляет AMD (Asynchronous module definition) подход (есть еще common.js, но о нем в следующей статье).
Require.js
Require.js будем осваивать на живом примере. В одной из предыдущих статей мы делали карточную игрушку. В результате у нас получилась просто куча кода, которую сейчас и будем разгребать.
Для начала скачаем reuirejs и подключим в нашем index.html, это будет единственный скрипт, который мы подключим таким образом.
<script data-main="js/config" src="js/libs/require.js"></script>
В параметре data-main передаем путь к точке входа нашего приложения (не указываем расширение).
Config.js в простейшем случае представляет собой список алиасов (хотя можно обойтись и без него)
requirejs.config({
paths: {
"rClck" : "modules/disable_rclck",
"app" : "app",
"socket" : "modules/webSockets",
"Actions" : "modules/Actions",
"User" : "modules/User",
"userList" : "modules/userlist",
"Matreshka" : "libs/matreshka.min",
"Modal" : "modules/Modal",
"fight" : "modules/fight",
"jquery" : "libs/jquery",
"myCards" : "modules/myCards",
"opCards" : "modules/opCards",
"mana" : "modules/mana"
}
});
require(['app'],function(app){
app.menu();
});
Синтаксис requirejs прост — передаем массив зависимостей (допустимы как пути, так и алиасы, все без расширения js указывается), описываем функцию, которая срабатывает после удовлетворения зависимостей (не забываем в качестве аргументов передавать модули, от которых зависим).
require(['app'],function(app){
app.menu();
});
Подключили модуль app, после вызываем метод menu() этого модуля.
Описание модулей выглядит следующим образом: передаем массив зависимостей, пишем функцию-коллбэк, которая возвращает наш модуль.
define(['socket'],function(socket){ // Завтсть от модуля socket
var app = {
menu: function(){
require(['Actions', 'Modal'],function(Actions, Modal){ // Выполняем функцию после удовлетворения зависимостей
if (socket.readyState === 1) {
Actions.exec('loginFailed','Введите желаемый логин (не менее 4 символов)');
}else{
Modal.box('Нет соединения с сервером');
}
});
}
}
return app; // Возвращаем объект модуля
})
Метод socket.readyState проверяет, есть ли соединение с сервером. Если да, то вызываем метод Actions.exec, если нет, модальное окно (Modal.box).
Actions, socket и Modal — отдельные самостоятельные модули наравне с модулем app. У них есть свои зависимости, своя логика, свои методы.
Все, что раньше у нас было в одном файле, мы разбили на модули. Просто потому, что логически это разные куски кода, отвечающие за разные задачи, будь то соединение с сервером по WebSockets, манипулирование картами или «прочие задачи».
К прочим задачам я отношу то, что связывает все модули. Раньше у нас все это было в объекте Actions
var Actions = {
send: function(method, args){
console.log('send: ' + method);
args = args || '';
socketInfo.method = method;
socketInfo.args = args;
socket.send(JSON.stringify(socketInfo));
},
resume: function(){
User = JSON.parse(localStorage['PlayingCardsUser']);
this.send('reConnect',User.login);
},
setMotion: function(login){
console.log('setMotion: ' + login);
User.currentMotion = login;
this.motionMsg();
this.getCard();
this.setTimer();
}
...
Данные с сервера приходят в формате JSON в виде
{'function': 'fooName', 'args': [массив/объект аргументов]}
И раньше мы вызывали нужный метод так:
socket.onmessage = function (e){
if (typeof e.data === "string"){
var request = JSON.parse(e.data);
Actions[request.function](request.args);
};
}
Но по мере разрастания и усложнения нашего приложения объект Actions будет разрастаться до уровня, когда уже трудно будет держать его в памяти и ориентироваться в нем. Именно поэтому разобьем его на мелкие модули (простейшие единицы, выполняющие элементарную функцию. Эту идеологию я увидел в gulp, и она мне понравилась).
Для начала нам понадобится обертка вызова методов Actions
define(["socket"],function(socket){
// Config
var path = 'modules/Actions/';
var Actions = {
exec: function(){
var args = Array.prototype.slice.call(arguments);
var actionName = args.shift();
require([path + actionName],function(action){ // Подключаем модуль
action.run.apply(action,args); // Запускаем его
});
}
}
return Actions;
})
В метод exec модуля Actions в качестве первого аргумента принимаем название нашего действия (action), остальные аргументы передаем аргументами в этот модуль.
В простейшем случае модуль действия будет выглядеть так:
define(['myCards'],function(myCards){ // Зависит от модуля myCards
var action = {
run: function(card){ // Метод run() мы вызываем при подключении в Actions.js: action.run.apply(action,args);
myCards.hand.add(card); // Реализация модуля
}
}
return action; // Возвращаем объект модуля
})
Этот модуль является оберткой вызова метода добора карт
myCards.hand.add(card);
Это нужно для того, чтобы максимально изолировать модули друг от друга. Чтобы в любой момент можно было безболезненно переписать его, например, используя другой фреймворк.
Теоретически можно было бы сразу с сервера получать информацию о том, что надо запустить метод myCards.hand.add(), но мы же работаем с тем, что есть. Пытаемся понять, как разгрести кучу кода, которая уже есть, разложить по полочкам.
Итак, имея изначально один js файл, где описывалось все от и до, мы разделили его на модули, отвечающие за реализацию карт (на столе и в руке каждого игрока), websocket'ов и прочего. А так же давайте напишем новый модуль и внедрим его, чтобы лучше во всем разобраться. Это будет модуль, отвечающий за ману:
define(['Matreshka'],function(Matreshka){ // Зависит от модуля Matreshka (js фреймворк)
// var diamond = $('#icons #diamond').html();
var diamond = '';
/////////// Карты в моей руке
var manaModel = Matreshka.Class({ // Модель списка
'extends': Matreshka.Object,
constructor: function(data){
this.jset(data);
this.on('render',function(){
this.bindNode('active', ':sandbox', Matreshka.binders.className( 'active' ));
});
}
});
var manaArray = Matreshka.Class({ // Класс списка
'extends': Matreshka.Array,
Model: manaModel,
itemRenderer: '<li></li>',
constructor: function(){
this.bindNode('sandbox','#mana'); // Засовываем в песочницу
},
add: function(){
// Добавить активный кристалл
if (this.length >= 10) return;
this.push({active:true});
},
spend: function(num){
var num = num || 0;
var actives = this.filter(function(obj){
if (obj.active) return true;
return false;
});
if(actives.length < num) {
console.log('Недостаточно маны');
return false;
}
// Деактивировать num маны
for (var i = this.length - 1; i >= this.length - num; i--) {
this[i].active = false;
};
return true;
},
setAllActive: function(){
for (var i = this.length - 1; i >= 0; i--) {
this[i].active = true;
};
}
});
var mana = new manaArray; // Экземпляр класса списка
return mana;
})
Модуль представляет собой список (массив) кристаллов маны. Что он должен уметь?
- Добавлять кристалл на каждом ходу: add()
- Тратить полные (активные) кристаллы маны: spend()
- Пополнять (делать активными) кристаллы маны каждый ход: setAllActive()
Смысл в том, что другим модулям не нужно знать, как реализованы эти методы. Это необходимо все для той же возможности безболезненно переписать модуль. Главное, сохранить логику.
Давайте внедрим наш новый модуль в имеющуюся игрушку, пусть отныне учитывается стоимость карт.
Начнем с пополнения кристаллов маны каждый ход. Каждый ход начинается с вызова действия (модуля, вызываемого модулем Actions через наш метод exec) setMotion, который устанавливает то, какой игрок сейчас ходит.
define(['Actions', 'User', 'myCards','mana'],function(Actions, User, myCards, mana){
var action = {
run: function(login){
User.currentMotion = login;
Actions.exec('motionMsg'); // Сообщение о том, чей сейчас ход
Actions.exec('setTimer'); // Установка таймера (ход длится 2 минуты)
if (User.meCurrent()) { // Если мой ход
myCards.arena.enableAll(); // Активируем мои карты на арене. Спящие просыпаются
Actions.exec('getCard'); // Добираем карту
mana.setAllActive(); // Делаем все кристаллы активными
mana.add(); // Добавляем кристалл маны
};
}
}
return action;
})
Как видите, внедрение первого шага оказалось несложным. Мы просто добавили вызов этого метода в нужный момент времени (в начале нашего хода). И если мы перепишем наш модуль, все будет работать как и работало. Главное не забыть реализовать ту же логику.
Как тратить ману? Очевидно, это происходит на этапе выкладывания карт из руки на стол. Внесем изменение в этот метод:
this.on('click::sandbox',function(){ // Клик по карте в руке
if(!User.meCurrent() || myCards.arena.length >= 7) return; // Если хожу не я или на арене много карт - false
myCards.arena.push(this); // Добавляем карту на арену
myCards.hand.splice(myCards.hand.indexOf(this),1); // Убираем ее же из руки
Actions.exec('send', 'putCard',this.toJSON()); // Показываем это сопернику
});
this.on('click::sandbox',function(){ // Клик по карте в руке
if(!User.meCurrent() || myCards.arena.length >= 7) return;
if(!mana.spend(this.mana)) return; // Если не удается потратить нужное кол-во маны - false
myCards.arena.push(this);
myCards.hand.splice(myCards.hand.indexOf(this),1);
Actions.exec('send', 'putCard',this.toJSON());
});
Заключение
Применив простые в освоении вещи, изучение которых не займет у вас более одного дня, мы совершили значительный скачек вперед на пути к качественному приложению.
Конечно, код еще далек от идеала, но гораздо читабельнее, презентабельнее и позволяет работать над ним дальше. Ведь проще заставить себя переписать маленький кусочек, чем огромный скрипт.
Мы будем продолжать улучшать эту игрушку в процессе изучения новых технологий. Чтобы набить руку, рекомендую взять какой-нибудь свой старый проект (не самый простой, чтоб было где шишек набить) и переделывать его вместе с нами.
Повторенье — мать ученья.
Ссылки
Комментарии (71)
justusebrain
17.08.2015 10:00+6Мир уже перешел на быстрый вебпак с инкрементальными обновлениями и require-ом всего, что только можно, а тут «level up» заключается в require.js. Смех.
seokirill
17.08.2015 10:12Level Up для новичков заключается в модульном подходе в принципе. И про webpack расскажем. Если подскажите, как протестировать производительность, буду благодарен. Я такой же новичек во всем этом.
enleur
17.08.2015 11:55Все же в чем профит от перехода с requirejs на webpack?
andreysmind
17.08.2015 12:23+2Возможность писать import $ from 'jquery'; без 100500 разных скобочек. Да и вообще код чище и аккуратнее выглядит.
hot-reload, простое подключение модулей для less, jsx, прочих модных слов.
конфиг webpack для меня выглядит понятнее и логичнее чем shim require.js
Я require.js пользовался довольно долго, а вот с тех пор как первый раз увидел как работает проект с webpack, про другие варианты даже думать забыл.
f0rk
17.08.2015 12:41Только причем тут webpack? CommonJS и ES6 modules прекрасно работают и без webpack.
andreysmind
17.08.2015 13:07Не причем, тоже прокомментировать что-нибудь захотелось.
в webpack _мне_es6_модули_так_удобнее_подключать_.
tamtakoe
19.08.2015 13:28Перешли только школьники. Впрочем, они каждый год переходят на что-то новое. Читая комментарии про CommonJS и es2015, создается впечатление, что народ даже со средними проектами не работал. В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет. Статья, конечно, дурацкая, человек рассказывает о первом опыте, но это никак не превозносит Webpack, который, вообще глупо сравнивать с RequireJS, т. к. это технологии разных уровней.
justusebrain
19.08.2015 14:05Люди переходят на новые технологии, которые облегчают жизнь (и действительно это делают, в том числе благодаря «школьникам», которые посылают патчи и пишут об ошибках), что за нытьё про школьников/хипстеров/etc?
> В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет.
Пруфы? Особенно про ошибки компиляции. Боюсь даже представить, сколько же будет тормозов от вебпака, который бьёт бандл на чанки и в дев-режиме обновляет только конкретный чанк. И это включая лоадеры типа scss/babel.
> но это никак не превозносит Webpack, который, вообще глупо сравнивать с RequireJS, т. к. это технологии разных уровней
RequireJS только для джса, вебпак для всего, был бы подходящий лоадер. Зачем нужен requirejs, если вебпак в разы лучше? Особенно пресловутые чанки и hot mode.tamtakoe
19.08.2015 18:57-2Пруфы?
Ошибки не по вине компилятора, а по вине разработчика. Отступ лишний поставил, IDE при вставке куска напортачила. Сложнее система — больше ошибок.f0rk
19.08.2015 19:06+1Что? Какой отступ? Какая IDE? Вы что несете?
tamtakoe
19.08.2015 20:07-1yaml и stylus файлы чувствительны к отступам. Копипаст там не всегда корректно работает, какой-то не тот вид пробела может поломать сборку. С компилятором Кофе скрипта больше пары дней не выдержал, пока не заметил, что вместо того чтобы писать код разбираюсь почему опять сломалась сборка. И консолька ОС далеко не так информативна как консолька Хрома. Jade, polymer — та же фигня. А еще библиотеки имеют свойство обновляться. А еще нужно чтобы со всем этим хламом умели новые сотрудники работать. У адекватного разработчика в проекте будет только самое необходимое, а для этого Вебпак вовсе необязателен.
Fesor
19.08.2015 21:27+1у меня на бэкэнде в yaml все конфиги, а еще есть ansible у которого вообще все (кроме модулей) на yaml, и почему-то никаких проблем. stylus — тут так же как и с python, привык и нет проблем (хотя я сам испольюзую less и потиху подумываю уходить на postcss).
вместо того чтобы писать код разбираюсь почему опять сломалась сборка
Ну а если нет таких проблем? Ну вот… я на кофе не пишу (и не люблю по непонятным мне причинам), но я повсеместно использую сборщики, и у меня почему-то никаких проблем с настройкой сборки нет. Более того, 90% всего того что настраивается можно спокойно реюзать. Меня в этом плане очень радует gulp4, у него больше гибкости в плане управления тасками.
И консолька ОС далеко не так информативна как консолька Хрома.
Ну… а я просто ставлю в любимой IDE бряку чуть что, не так клево как консолька хрома, но для CLI скриптов больше и не нужно. Да и сборку я дебажил только когда ее в последний раз настраивал с нуля, что бывает не часто.
Jade, polymer
А как это вообще попало в один список? На счет jade, хоть я его и использую, согласен. Мне он нравится, позволяет не писать лишних символов и удобно бороться с излишне жирными директивами… Но полимер то? Вы еще скажите что web-components это все лишняя отвлекающая штука.tamtakoe
20.08.2015 03:27Для меня jade нет имеет смысла потому что архитектура не предусматривает больших шаблонов (больше 100 строк), как и стилевых файлов и скриптов. Polymer случайно затесался. Имел в виду полифилы (или по нашему костыли), которые добавляются сборкой.
Fesor
20.08.2015 10:07Ну у меня тоже нет больших шаблонов (больше 100 строк), и jade тут только лучше смотрится. Что до полифилов добавляемых сборкой — у меня пока такого так же нет, все полифилы подключаются через bower а уж то что подключено через bower хэндлится сборкой.
Fesor
19.08.2015 19:54Вот давайте так, если у вас нет опыта работы с ES2015/TypeScript/Coffee то и не надо придумывать несуществующих проблем. IDE прекрасно с ними работает (с typescript лучше чем с js собственно). А сделать ошибку синтаксическую можно и в js.
tamtakoe
19.08.2015 20:29-1С Coffee точно не все так гладко. По крайней мере пару лет назад было. В любом случае, ES2015/TypeScript/Coffee не дают такого профита, чтобы на них писать что-либо отличное от исследовательского или игрового проекта. Даже синтаксический сахар там не такой сладкий как в ES5 был. Часто классы используете? Можно посчитать количество классов в коде Ангуляра, Реакта, в своем собственном проекте — десятка не наберется. Без стрелочныйх функций не прожить? Хотите обучать новых сотрудников как пользоваться генераторами, хотя сами смутно представляете? В данный момент (2015-2016) всё это баловство. А потом народ пишет, что Вебпак крут, потому что в нем легко баловаться, при том что до сих пор нет ни одной статьи где бы говорилось почему он действительно крут.
Fesor
19.08.2015 21:21+1классы — регулярно (2/3 директив содержат контроллер и не содержат линка, все контроллеры и сервисы — классы). В случае со сложной бизнес логикой на клиенте у меня появляются еще сущности, которые так же являются классами и имеют внутри какую-то логику. И да, код от этого становится чище (есть с чем справнивать), что положительно сказывается на суппорте приложения. Так же проще организовать внутренние правила аля «дробите приложение на директивы, юзайте контроллеры и т.д.». Без классов, только с Object.create как-то грустно все же.
Стрелочные функции — опять же удобно, особенно когда часто пользуешься map/reduce/filter/etc. Это, как вы правильно заметили, просто сахар, который позволяет сократить количество информационного мусора.
Что до генераторов — говорите за себя, я знаю как устроены и генераторы и корутинки могу пописать, но да, их я сейчас не использую ибо для команды это перебор. Генераторы и корутины это круто, но их чаще можно встретить на бэкэнде (php, python, ruby). Для JS будет счастьем async/await, что валяются в черновиках ES7.
В данный момент (2015-2016) всё это баловство.
На текущий момент (2015-2016) использование ES2015 это уже необходимость, так как при должном подходе это упрощает поддержку кода за счет того сахара и плюшек. которые оно дает. Да взять хотя бы дефолтные значения для аргументов, это совсем уж мелочь но так упрощает восприятие кода.
Ну а webpack — я не знаю чем он так крут и я его не использую так как не вижу преимущест перед gulp конкретно для себя.tamtakoe
20.08.2015 04:10-1все контроллеры и сервисы — классы
Ангуляр давно решил эту проблему. Там ни Object.create не нужно использовать, ни new делать. Другие фреймворки предоставляют свои обертки. Со времен jQuery не встречал фронтендского проекта, где бы слово new (по отношению к пользовательским классам) употреблялось бы чаще 20 раз.
я знаю как устроены и генераторы
Нужно не просто знать, а уметь использовать, чего пока никто не умеет даже на node.js. Даже когда async/await появится, должны появиться фреймворки их использующие, выработана практика, набиты шишки, средний разработчик должен уметь с этим работать. А это не год и не два.
О коллегах нужно так же думать, о контрибьютерах если проект открытый. Не забегать слишком вперед, чтобы другим не пришлось ломать голову и разбираться в неутвержденных или нереализованных спецификациях.
Совсем отошли от темы :-) Просто на фронтенде СТОЛЬКО нерешенных задач… Судя по публикациям, народ до сих пор топчется на уровне «делаем приложение на Ангуляре/Реакте/Метеоре за 10 дней», зато в комментариях все достигли таких высот, что от нечего делать обновляются на ES6.Fesor
20.08.2015 10:22Ангуляр давно решил эту проблему
Можно подробнее, какую именно проблему решил ангуляр и почему там не нужны классы? Про Object.create ладно, заменим просто на Object.defineProperties, мы же должны определить методы прототипа и все такое. Тут вопрос в том как организовать методы объектов и т.д. С классами это очень легко и хорошо читается. А уж инджектор позоботится обо всем остальном.
Нужно не просто знать, а уметь использовать
У вас может выборка не репрезентативна? Опять же, корутины мало кто пишет потому что это сложнее чем юзать промисы, но их пишут. С генераторами намного проще, это просто сахар над итераторами. Ну и да, генераторы уже реализованы в хроме и фаерфоксе (не полностью но с большего).
Судя по публикациям, народ до сих пор топчется на уровне «делаем приложение на Ангуляре/Реакте/Метеоре за 10 дней»
Да я вам больше скажу, я не видел на гитхабах ни одного проекта на ангуляре, который я мог бы спокойно дать посмотреть другим как пример «как надо делать». Какого рода публикаций вы ждете (вдруг кто будет читать этот диалог да напишет чего)? Ну и ES6 не от нечего делать, за 4 месяца после внедрения люди начали писать более чистый код, что я считаю достаточным оправданием что бы усложнять инфраструктуру. С ES6 мне было проще определить какие-то границы и правила о том «как надо чего делать», а эти правила в последующим упростят людям поддержку кода и позволят быстро мигрировать на angular2 как только он выйдет. Была б моя воля я бы сразу всех на TypeScript перевел, но это было бы уже слишком резким изменением.tamtakoe
20.08.2015 11:43Можно подробнее, какую именно проблему решил ангуляр и почему там не нужны классы?
Классы в Ангуляре создаются через методы-обертки factory(<имя>, <конструктор>), соntroller(<имя>, <конструктор>) и т. п., поэтому код типа (и более сложный )
var MyClass = function() { ... } MyClass.ptototype.blabla = blabla var myClass = new MyClass() //или в es2015 class MyClass { ... }
приходится писать крайне редко.
Какого рода публикаций вы ждете
Любых, которые бы показывали что люди растут, а не кидаются с одной технологии на другую. Сейчас подавляющее большинство публикаций из разряда: «новая технология такая-то», «мой первый опыт, не бейте сильно», «посмотрите какие костыли мы внедрили в своей компании». По тому же Вебпаку ни одной статьи, описывающей бест практис, а не детские примеры.Fesor
20.08.2015 11:55Классы в Ангуляре создаются через методы-обертки 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-шник).
Любых, которые бы показывали что люди растут
С этим сложно, на нормальную статью нужно убить довольно много времени, альтруизма не хватит.
Fesor
19.08.2015 16:42В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции
В большом проекте я в любом случае возьму TypeScript, а инкрементные билды не добавляют большого оверхэда. Ошибки компиляции возможны (напарывался на парочку в babel первое время) но они оперативно устраняются. Полифилы в этом плане чаще косячат.
это никак не превозносит Webpack,
Статья описывает не только профит require.js но и как собирать модули, так что сравнения webpack vs amd никто не делает (это глупо так как оный поддерживает и amd).
f0rk
19.08.2015 18:55Читая комментарии про CommonJS и es2015, создается впечатление, что народ даже со средними проектами не работал. В большом проекте прекомпилятор добавит столько тормозов и ошибок компиляции, что никакой Webpack не спасет.
Ухты как интересно! Расскажите, в чем проблема commonjs на больших проектах, а то пока что звучит как очень безосновательное утверждение.tamtakoe
19.08.2015 19:44-1CommonJS-модули не работают в браузерах т. к. у них нет изолированной области видимости. Для этого каждый файл нужно обернуть. Это должен делать сборщик и делать это на каждый чих. Изменения на сайте появляются не сразу, особенно, когда зависимостей много, что раздражает. При отладке не виден исходный файл, source map опять же добавляют лишнюю сложность, а сложный проект нужно делать как можно проще, потому что его собственной сложности хватает. Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена. Максимум библиотечку типа lodash и набор функций для валидации. Синтаксис не проще и не сложнее. Пока использовать их на фронтенде в любых проектах кроме исследовательских бессмысленно. Возможно через пару лет всё изменится.
Fesor
19.08.2015 19:59+1Это должен делать сборщик и делать это на каждый чих. Изменения на сайте появляются не сразу
И с этим нет никаких проблем, инкрементная сборка происходит быстрее чем вы можете переключить внимани е от IDE к дебагеру/браузеру. А с livereload еще и успевает за это время загрузиться. Скажем для reactjs есть hot reload, когда отдельные компоненты перезагружаются без необходимости перезагрузки страницы. И там на каждый чих компилится JSX.
source map опять же добавляют лишнюю сложность
Отчасти да, но эта сложность относительно небольшая, а профит который дают инструменты (модули, надстройки над js, штуки требующие трансляции) снижают сложность поддержки и разработки решений (за исключением того что требуется разобраться с инструментом).
Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена
Альтернатива? На node.js к слову необходимость крайне высока.
Максимум библиотечку типа lodash
А теперь скажите что для вас большой проект? Или вы предлагаете все писать тупо на javascript без фреймворков и лишней «сложности»? Я конечно чуть утрирую ваши слова, но выходит как-то так. Для большинства эти инструменты экономят кучу сил и времени. Да, можно и без них, но сложность возврастает в других местах. Ну и да, вы пишите тесты?tamtakoe
19.08.2015 20:55geometria.ru, vozovoz.ru большие проекты? Сейчас RequireJS, Angular, Stylus, Jasmine, Karma, Gulp. От Coffee через пару дней отказался, Jade тоже пошел лесом, Stylus пока больше плюсов приносит. От jQuery удалось избавиться, как и от всех компонентов его использующих. Lodash бы тоже кастрировал так как по факту из него используется несколько функций, причем многие в костыльных местах. Возможно вместо Jasmine вернусь к Mocha, чтобы одна технология и на фронтенде и на бэкенде была. Чем больше говна выпиливается, тем проще: не нужно учить лишнего, не нужно обучать лишнему, не нужно ловить ошибки в чужом коде, не нужно следить за совместимостью, код проще читается.
Кучу сил и времени экономит хорошая архитектура, а не модные плюшки.f0rk
19.08.2015 21:19+1geometria.ru, vozovoz.ru большие проекты?
Обычные сайтики на ангуляре, на фронтенд не больше 1-1.5к человекочасов каждый.tamtakoe
20.08.2015 04:16На поддержку и 0.5 хватит. На разработку значительно больше :-) Приведите примеры сложных сайтов на Ангуляре. Самому интересно глянуть.
f0rk
20.08.2015 18:24+1На поддержку? 0.5? Вы вообще в курсе что такое поддержка? Если на разработку ушло более 1.5к — это очень грустно.
Приведите примеры сложных сайтов на Ангуляре.
Сайт в традиционном понимании (интернет-магазин, веб-портал и т.п.) — , на мой взгляд, очень редко бывает большим, сложным проектом. Если хотите посмотреть большой проект на JS, вот вам пример: sdk.amazonaws.com/js/aws-sdk-2.1.45.js, как ни странно, на commonjs. Видимо в amazon не в курсе, что его не стоит в больших проектах использовать.
f0rk
19.08.2015 20:36+1CommonJS-модули не работают в браузерах т. к. у них нет изолированной области видимости.
Открою секрет, они не по-этому в браузере не работают.Для этого каждый файл нужно обернуть.
Browserify делает это автоматически.Изменения на сайте появляются не сразу, особенно, когда зависимостей много, что раздражает.
На больших проектах изменения на сайте появляются только после деплоя из CI-системы.source map опять же добавляют лишнюю сложность
УжсУжсУжс… какая же все таки сложная штука source map, никогда бы не подумал.Необходимость использования CommonJS модулей на фронтенде и на node.js преувеличена.
Неверно.
… и т.д. и т.п.
Судя по тому что вы пишете, это как раз вы вряд ли имели дело с проектами больше и сложнее обычного интернет-магазина.
voidnugget
17.08.2015 18:43+2Посмотрел на это
и дальше перестал читать…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 просто не обеспечивает должной гибкости, да и больших преимуществ по скорости работы, как многие голосят, я раньше не замечал…voidnugget
17.08.2015 18:48+1Ещё, кстати, нужно использовать callback'и
var plato = require('plato'); gulp.task('plato', function(done) { plato.inspect(config.projectFiles.js, 'reports', config.plato, done); });
PerlPower
17.08.2015 23:38-1Какой фреймворк у нас сегодня в моде, d
С чем ты опять проснуля не в ладу… dvoidnugget
18.08.2015 04:12+2Работал почти со всем что более-менее актуально и распространено.
Получается такая ситуация что как только контра хочет разработать какое-то актуальное решение — нужно пилить свой гибрид лигерада с токамаком. Так было с 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 на сервере, для меня он часто становится бутылочным
Существует не так много решений, которые действительно удовлетворяют современные потребности рынка и обеспечивают должное качество реализации решений.
ShpuntiK
20.08.2015 11:55+1Кажется requirejs и AMD уже умер. CommonJS и ES6 modules — все крутые ребята на них сидят.
tamtakoe
20.08.2015 15:35-1requirejs нужен для того, чтобы сайт не состоял из одного гигантского js-файла, а грузился в несколько асинхронных потоков
Fesor
20.08.2015 16:01requirejs нужен для того что бы загружать модули, но без http2 с мультиплексирование трафика всеравно придется модули собирать в бандлы.
xGromMx
20.08.2015 16:24Вот прикольная альтернатива для require.js jspm.io
Fesor
20.08.2015 16:31+1Это не альтернатива. Это совсем из другой оперы, это просто менеджер пакетов для тех кому лень выбирать между npm/bower и для тех кто хочет один менеджер пакетов. У меня помимо npm и bower есть еще composer и ansible-galaxy так что мне эта штука вообще как-то не понравилась. Проблемы она мои не решает и только привносит лишнюю сущность.
xGromMx
20.08.2015 16:34Насколько я помню там github.com/systemjs/systemjs, который позволяет делать также как и в require.js
Fesor
20.08.2015 16:46ну так дали бы ссылку на systemjs, я использую его как загрузчик в dev окружении (es2015 модули).
Proxmiff
А почему выбрали requirejs, а не webpack?
enleur
Недавно еще была шумиха вокруг browserify, теперь webpack. Чем webpack лучше requirejs?
Fesor
Не знаю чем там что лучше, но… может просто юзать модули из es2015 + esperanto + babel?
seokirill
Разве babael c gulp нельзя использовать? Ссылка
Fesor
Не понял вопроса, тип то что я не перечислил gulp? Это уже детали, я вот с gulp-ом использую.
seokirill
Подумал, вы приводите babel в качестве преимущества webpack
Fesor
Я не использую webpack и не вижу в нем никаких преимуществ что бы на него переходить. Ну как, преимущества определенные есть, но все то же самое можно сделать и без него с нормальным уровнем контроля.
seokirill
Выходит, это вопрос религии
Fesor
Религия это глупость. gulp просто универсален и позволяет решить все юзкейсы связанные со сборкой (особенно 4-ая версия хороша), webpack для меня лично просто был лишним. То что я не увидел в нем преимуществ для моего воркфлоу не означает что их нет для других людей.
DIKunin
Вопрос предпочтения нотации. Лично мне больше нравится добавлять модули commonjs стилем — поэтому я перешел на browserify/webpack с require и ни разу не пожалел. Но, как говорится, на вкус и цвет фломастеры у всех разные)
enleur
Не знаю как webpack, но от browserify отказался потому что он не умеет в браузере работать без предварительной компиляции. С Requirejs удобно как раз таки в режиме разработки все зависимости в браузере подгружать.
DIKunin
Соглашусь — дополнительный шаг компиляции — не всегда супер удобен — динамическая подгрузка — в данном вопросе для Require — плюс по сравнению с browserify.
xGromMx
Тогда вам подойдет jspm.io. Большой плюс — легкость работы с babel.
Fesor
и при этом не надо вводить еще один мнеджер пакетов помимо bower и npm. Согласен что свои плюсы этот подход несет, но мне не удобно иметь один универсальный менеджер пакетов. Когда идет разделение как-то проще понять что где искать и что есть для чего. Ну и в релиз собирать через esperanto.
xGromMx
Я сам долгое время пользуюсь gulp, но потихоньку поглядую на npm scripts + webpack.
frst
webpack.github.io/docs/comparison.html
можно на горячую обновлять реакт, есть автоматическая разбивка бандла на части, можно в бандл закинуть картинки и шаблоны, можно настроить так чтобы сливались только картинки менее определенного размера, а большие складывались в ресурсы, дофига магии разной полезной, и common js синтаксис нормально поддерживается, lazy loading умеет, компилится в dev режиме за долю секунды, вобщем при переходе с requirejs стало жить приятнее
tamtakoe
Раз Вебпак такой крутой, сбилдить папку
distв таком AMD-проекте раз плюнуть. Разумеется изменение состава модулей не должно влиять на код сборки.Есть ссылки на подобные примеры?
xGromMx
Читали это? webpack.github.io/docs/code-splitting.html
tamtakoe
Читал
xGromMx
Все просто, я могу с легкостью писать amd, common, es 2015 и не будет проблем это все интегрировать github.com/webpack/webpack/tree/master/examples/mixed
seokirill
Это стандартный функционал webpack'а? Любопытно.
xGromMx
Да, более того, есть куча лоадеров.
seokirill
Webpack реализует подход другой. Он на очереди в списке. Просто про require раньше узнал. Webpack еще и gulp, получается, заменяет.
Proxmiff
Многие задачи решает, но таскраннер все равно нужен.
xGromMx
Npm scripts + github.com/kimmobrunfeldt/concurrently?