Комментарии 41
ES2015 же. :)
www.ecma-international.org/publications/standards/Ecma-262.htm
www.ecma-international.org/publications/standards/Ecma-262.htm
Для оригинала есть также генератор для Yeoman, наверное можно и его адаптировать.
А еще, почему бы не webpack вместо browserify?
А еще, почему бы не webpack вместо browserify?
Я если честно не пробовал использовать webpack, поверхностный осмотр создал у меня впечатление, что он нацелен больше на разработку SPA. Я хоть и упомянул SPA в статье, но честно признаюсь, последние пару лет я не касался разработки сайтов, больше занимался разработкой всяческих SDK и прочих сторонних скриптов. И естественно, я перенес в шаблон привычный лично для меня сетап. webpack посмотрю подробнее, тем более, что часто слышу про него в последнее время. Можно еще подумать над какой-нибудь pluggable системой сборки, чтоб совсем уж все были довольны :)
А что, минификацию кода умеет делать только Google Closure Compiler? Для этого нужно такую зависимость от JAVA тащить?
Нет, не только, зато closure compiler умеет то, что не умеют другие, например ADVANCED_OPTIMIZATIONS и поддержку аннотаций, это вещи, которые я считаю полезными и хочу прикрутить к шаблону. А Java у многих установлена, так что не думаю, что это большая проблема.
>А Java у многих установлена
это у Вас немножко заблуждение.
это у Вас немножко заблуждение.
www.w3resource.com/browsers/java-support.php
Думаю, что 84% вполне подходит под определение «многих». Подтверждений у меня нет, но подозреваю, что среди девелоперов этот процент еще выше.
Думаю, что 84% вполне подходит под определение «многих». Подтверждений у меня нет, но подозреваю, что среди девелоперов этот процент еще выше.
Думаю статистика вранье. Наверняка ее мерили в самом Oracle. Там еще да. На реальном рынке нет.
Почему вы так уверены, что именно ваша выборка более честная и репрезентативная?
Потому что за много лет ремонта компов и за точно такой же период работы программистом я Java видел дай бог на 5% компов. Ту же самую статистику подтверждают мои коллеги по работе.
Да и зачем она на компе? Софта написанного на ней очень и очень мало.
Да и зачем она на компе? Софта написанного на ней очень и очень мало.
Охотно верю, что на ремонтируемых вами компьютерах обывателей все это не встречалось. Пускай даже Java обошла вас и ваших коллег-программистов стороной, что маловероятно — однако ваше утверждение все равно голословно. На Java написана добрая половина сред разработки — семейство Idea, семейство Eclipse, Netbeans, клиент Smartgit, разработка под Android также обычно ведется на Java.
99% пользователей не программисты. Соответственно все это им нафиг не надо. А юзерского софта на Java нет.
Из того, что на Java написано кучу сред не следует, что все или хотя бы большая часть программистов их использует. Опять таки я не видел (хотя и читал про них) ни одного программиста который бы писал в одной из перечисленных сред разработки.
Итог такой: что даже путем диких натяжек и допущений процент Java на десктопах ну никак выше 5 не прыгнет. Ее просто не ставят за ненадобностью.
Из того, что на Java написано кучу сред не следует, что все или хотя бы большая часть программистов их использует. Опять таки я не видел (хотя и читал про них) ни одного программиста который бы писал в одной из перечисленных сред разработки.
Итог такой: что даже путем диких натяжек и допущений процент Java на десктопах ну никак выше 5 не прыгнет. Ее просто не ставят за ненадобностью.
Добавил голосовалку в пост, посмотрим, подтвердится ли ваш тезис про 5%.
Уважаемый, вы жонглируете 2 разными цифрами. Данные статистики привели для всех пользователей. А теперь говорите про то, что у программистов Java не редкое явление. Возмущение вызвала именно первая цифра. Т.е. 84%
Среди фронтенд-программистов это вполне реально. Но среди всех пользователей интернета — точно нет.
Среди фронтенд-программистов это вполне реально. Но среди всех пользователей интернета — точно нет.
Я не в курсе на какой аудитории собиралась статистика по ссылке которую я привел. Просто запостил первую ссылку, которую смог нагуглить. Упоминаний оракла на их сайте я не нашел. Опрос запостил в ответ на предположение о том что даже с учетом всех натяжек процент не выше 5. Где и чем я жонглирую? Ну не нравятся цифры, приведите свою статистику, никто же не против.
Добавьте тогда сразу кто ставит джаву для минификатора гугловского, у меня джава стоит но только в силу тех причин что она необходима для запуска IDE. В противном случае вообще не вижу иметь ее на машине. Для минификации использую углифайжс.
Я тоже считаю что 84% это перебор. Java на клиентских windows встречается очень редко. В отличии от .net из коробки ее нет. А надобности в ней мало.
Обычный пользователь скорее всего не знает что такое Java или .NET и зачем оно. Поэтому вряд ли будет ставить сам. Только если Java нужна какому-то другому софту. А много вы софта знаете (для обычного пользователя), который требует Java?
Вот .NET может быть установлен и пользователь может не знать об этом и не использовать его.
Обычный пользователь скорее всего не знает что такое Java или .NET и зачем оно. Поэтому вряд ли будет ставить сам. Только если Java нужна какому-то другому софту. А много вы софта знаете (для обычного пользователя), который требует Java?
Вот .NET может быть установлен и пользователь может не знать об этом и не использовать его.
По существу, о GCC
Минусы:
1. Требуется Java (на домашнем ПК это не проблема, но на сборочном сервере для этой задачи ее ставить мало кто решится).
2. Отсутствует привычное JS-API (даже официальный npm-пакет не предоставляет такой возможности).
3. Долгий процесс компиляции.
4. Большой размер пакета (6.3 Mb в сжатом виде), для CI это минус.
5. Чтобы использовать ADVANCED_OPTIMIZATIONS нужно писать сложно читаемый код (использовать скобочную нотацию, забыть про модульность, избегать void function, держать файлик с аннотацией глобальных переменных и пр.) иначе можно недосчитаться нужного куска кода. Без достаточного опыта лучше не пытаться использовать этот режим.
6. Линтер успешно заменяет ESLint, он даже более предпочтителен, т.к. имеет поддержку ES6.
7. Не все аннотации совместимы с JSDoc 3, это может быть проблемой для каких-то редакторов кода.
8. Нет особого смысла использовать GCC вместо Uglify если сервер отдает Gzip. Такой проблемы попросту не возникает.
Когда-то я писал вот-такие замечательные скрипты и радовался до безумия статическому анализу, но когда в Uglify поддержали AST я без сожаления перешел на него, а со статический анализ доверил ESLint и пока ни чуть не жалею.
Минусы:
1. Требуется Java (на домашнем ПК это не проблема, но на сборочном сервере для этой задачи ее ставить мало кто решится).
2. Отсутствует привычное JS-API (даже официальный npm-пакет не предоставляет такой возможности).
3. Долгий процесс компиляции.
4. Большой размер пакета (6.3 Mb в сжатом виде), для CI это минус.
5. Чтобы использовать ADVANCED_OPTIMIZATIONS нужно писать сложно читаемый код (использовать скобочную нотацию, забыть про модульность, избегать void function, держать файлик с аннотацией глобальных переменных и пр.) иначе можно недосчитаться нужного куска кода. Без достаточного опыта лучше не пытаться использовать этот режим.
6. Линтер успешно заменяет ESLint, он даже более предпочтителен, т.к. имеет поддержку ES6.
7. Не все аннотации совместимы с JSDoc 3, это может быть проблемой для каких-то редакторов кода.
8. Нет особого смысла использовать GCC вместо Uglify если сервер отдает Gzip. Такой проблемы попросту не возникает.
Когда-то я писал вот-такие замечательные скрипты и радовался до безумия статическому анализу, но когда в Uglify поддержали AST я без сожаления перешел на него, а со статический анализ доверил ESLint и пока ни чуть не жалею.
а в чём проблема поставить яву на сервере?
не безопасно это.
> не безопасно это.
Серьезно? Небезопасно иметь жаву на билд-сервере? Расскажите поподробнее, какие угрозы это несет.
Серьезно? Небезопасно иметь жаву на билд-сервере? Расскажите поподробнее, какие угрозы это несет.
Кто говорил про билд сервер? Сказано было просто «на сервере».
И да — установка любого нового компонента, уменьшает безопасность системы в целом, так как этот компонент может содержать в себе разного рода уязвимости.
То, что в вашем случае это билд сервер, он отключен от сети, стоит в бункере, данными с внешним миром обменивается через дискеты — это уже другая история, не имеющая отношения к первоначальному вопросу.
И да — установка любого нового компонента, уменьшает безопасность системы в целом, так как этот компонент может содержать в себе разного рода уязвимости.
То, что в вашем случае это билд сервер, он отключен от сети, стоит в бункере, данными с внешним миром обменивается через дискеты — это уже другая история, не имеющая отношения к первоначальному вопросу.
> Кто говорил про билд сервер?
monolithed говорил
> но на сборочном сервере для этой задачи ее ставить мало кто решится
Какое вообще отношение имеет «просто сервер» к контексту данного топика? Куда-то вас не в ту степь понесло. Здесь java используется исключительно для сборки пакета, с трудом представляю себе сценарий в котором это будет представлять угрозу безопасности. Чушь какая-то…
monolithed говорил
> но на сборочном сервере для этой задачи ее ставить мало кто решится
Какое вообще отношение имеет «просто сервер» к контексту данного топика? Куда-то вас не в ту степь понесло. Здесь java используется исключительно для сборки пакета, с трудом представляю себе сценарий в котором это будет представлять угрозу безопасности. Чушь какая-то…
Любой пакет нужно мониторить и поддерживать и конфигурировать, для такой пустяковой задачи выделять время админов и безопасников никто не будет, поскольку это нецелесообразно.
Поставить же npm-пакет значительно проще, особенно есть уже есть свой npm-репозиторий и для этого не нужно рутовых прав.
Поставить же npm-пакет значительно проще, особенно есть уже есть свой npm-репозиторий и для этого не нужно рутовых прав.
ИМХО проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы). Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.
проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы).
Любое решение требует согласования. В данном случае, мне бы потребовалось обсудить это решение со своим непосредственным руководителем, специалистом который отвечает за деплой, специалистом по безопасности и админами, которые в свою очередь тоже должны это обсудить со своим руководством чтобы выделить время на конфигурирование машин.
Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.
Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.
> Любое решение требует согласования.
Могу только посочувствовать этому примеру явно неадекватной бюрократии.
> Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.
Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?
Могу только посочувствовать этому примеру явно неадекватной бюрократии.
> Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.
Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?
Могу только посочувствовать этому примеру явно неадекватной бюрократии.
Далеко не все разработчики обладают достаточной квалификацией и способностью нести ответственность за свои решения и уж тем более мало кто может самостоятельно определить трудозатраты других сотрудников.
Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?
После того как пакет собрался (CI) его нужно доставить на рабочие сервера (CD). Не думаю что сюрпризы в пакете кому-то понравятся.
npm install closurecompiler я один додумался и всегда делаю?
Превосходное API, как CLI, так и программно, поддержка пайпов, сорсмапов, хотя последнее никогда не требовалось. Компилится незначитьно дольше углифая.
Но в целом да, uglify2 проще.
Превосходное API, как CLI, так и программно, поддержка пайпов, сорсмапов, хотя последнее никогда не требовалось. Компилится незначитьно дольше углифая.
Но в целом да, uglify2 проще.
Как это решает проблему с установкой Java?
Очень интересно, спасибо.
На сколько трудно будет его подружить с Go проектом? Т.е., например, у меня тесты для Go и автоматизация через makefiles. Будет ли стратегия proxify gulp commands through the makefile tasks правильной?
На сколько трудно будет его подружить с Go проектом? Т.е., например, у меня тесты для Go и автоматизация через makefiles. Будет ли стратегия proxify gulp commands through the makefile tasks правильной?
Кто первый форкнет и заменит closure compiler на uglufy2 — тот молодец и тому плюсик в карму (не только здешнюю, но и IRL):)
Делов то :)
uglify.patch:
$ rm bower.json
uglify.patch:
diff --git a/gulpfile.js b/gulpfile.js
index 11f787a..c2fb852 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -7,10 +7,10 @@ const istanbul = require('gulp-istanbul');
const babelify = require('babelify');
const browserify = require('browserify');
const source = require('vinyl-source-stream');
-const closureCompiler = require('gulp-closure-compiler');
const karma = require('karma').server;
const isparta = require('isparta');
const babel = require('babel/register');
+const uglify = require('gulp-uglify');
function unitTests() {
return gulp.src(['tests/unit/**/*.js'])
@@ -69,10 +69,7 @@ gulp.task('browserify', function () {
gulp.task('compile', ['browserify'], function () {
return gulp.src('dist/lib-build.js')
- .pipe(closureCompiler({
- compilerPath: 'bower_components/closure-compiler/compiler.jar',
- fileName: 'lib-build.min.js'
- }))
+ .pipe(uglify())
.pipe(gulp.dest('dist'));
});
diff --git a/package.json b/package.json
index 208bbd3..afbe449 100644
--- a/package.json
+++ b/package.json
@@ -22,6 +22,7 @@
"gulp-istanbul": "^0.10.0",
"gulp-jscs": "^1.6.0",
"gulp-mocha": "^2.1.2",
+ "gulp-uglify": "^1.2.0",
"isparta": "^3.0.3",
"karma": "^0.12.37",
"karma-browserify": "^4.2.1",
$ npm i
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка на ES6 для браузеров