Разработка на ES6 для браузеров

    Доброго времени суток.



    Поддержка нового стандарта EcmaScript 6 в браузерах все ближе и ближе, и тем кому не терпится начать разрабатывать с использованием новых возможностей ES6 предлагаю взглянуть на шаблонный проект для этой цели.

    Представляю вашему вниманию github.com/DavidKlassen/es6-browser-boilerplate.

    В основу шаблона лег github.com/babel/babel-library-boilerplate, но gulpfile.js был основательно почищен и упрощен. Многие зависимости я убрал и оставил возможности, которые необходимы для разработки приложений для браузеров.

    Основные цели, которые я преследовал:


    • Шаблон должен быть хорошей стартовой точкой для разработки SPA и third party SDK.
    • Минималистичность и расширяемость.
    • Весь код, то есть и само приложение и тесты можно писать на ES6.


    Рабочее окружение


    Требования к рабочему окружению достаточно стандартные и скорее всего, если вы разрабатываете на JavaScript у вас уже все установлено. Вам потребуется NodeJS либо io.js, NPM, Gulp, Bower и Java 7+ (java нужна, т. к. для минификации используется Google Closure Compiler) см. UPD2.

    Возможности шаблона


    • Для поддержки синтаксиса ES6 используется компилятор Babel.
    • Проверка качества кода обеспечивается двумя утилитами, ESLint и JSCS.
    • За сборку проекта отвечает browserify и babelify.
    • Минификацию кода делает Google Closure Compiler UglifyJS2.
    • Unit тесты используют mocha, chai и sinon.
    • Отчет о покрытии кода тестами генерируется с помощью istanbul и isparta.
    • Integration тесты запускаются в karma.
    • В качестве таск раннера используется Gulp.


    Как использовать



    Скачать и подготовить проект к работе очень просто:
    $ git clone git@github.com:DavidKlassen/es6-browser-boilerplate.git
    $ cd es6-browser-boilerplate
    $ npm run setup
    

    После этого можно удалить .git и начинать кодить.

    Список доступных задач gulp:
    • gulp lint — запускает проверку качества кода с помощью ESLint и JSCS.
    • gulp test:unit — запускает unit тесты.
    • gulp coverage — запускае unit тесты и генерирует отчет о покрытии кода тестами.
    • gulp test:integration — запускает интеграционные тесты в браузере с помощью karma.
    • gulp test — запускает все тесты.
    • gulp browserify — собирает скрипт готовый для использования в браузере.
    • gulp compile — собирает минифицированную версию скрипта.
    • gulp build — собирает обе версии скрипта.
    • gulp — дефолтная задача, запускает проверку кода, тесты и сборку проекта.


    Вещи которые хотелось бы улучшить


    Помимо всяческих мелочей типа подключения test-frameworks глобально для всех файлов с тестами и мелких улучшений в gulpfile, хотелось бы подключить возможность использования Google Closure Compiler в режиме ADVANCED_OPTIMIZATIONS и статический анализ типов на основе аннотаций gcc.

    Ну и конечно же я жду отзывов, пожеланий и пулреквестов. Спасибо за внимание! :)

    UPD: В коментариях возник спор о распространенности Java на машинах разработчиков, так что добавляю голосовалку. Если не уверены есть ли java на вашей машине или нет, запускаем: java -version
    UPD2: По просьбам трудящихся заменил google closure compliler на uglifyjs.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Установлена ли у вас Java

    • 70,8%Да350
    • 29,2%Нет144

    Комментарии 41

      0
      ES2015 же. :)
      www.ecma-international.org/publications/standards/Ecma-262.htm
        0
        Для оригинала есть также генератор для Yeoman, наверное можно и его адаптировать.

        А еще, почему бы не webpack вместо browserify?
          0
          Я если честно не пробовал использовать webpack, поверхностный осмотр создал у меня впечатление, что он нацелен больше на разработку SPA. Я хоть и упомянул SPA в статье, но честно признаюсь, последние пару лет я не касался разработки сайтов, больше занимался разработкой всяческих SDK и прочих сторонних скриптов. И естественно, я перенес в шаблон привычный лично для меня сетап. webpack посмотрю подробнее, тем более, что часто слышу про него в последнее время. Можно еще подумать над какой-нибудь pluggable системой сборки, чтоб совсем уж все были довольны :)
          +6
          А что, минификацию кода умеет делать только Google Closure Compiler? Для этого нужно такую зависимость от JAVA тащить?
            +1
            Нет, не только, зато closure compiler умеет то, что не умеют другие, например ADVANCED_OPTIMIZATIONS и поддержку аннотаций, это вещи, которые я считаю полезными и хочу прикрутить к шаблону. А Java у многих установлена, так что не думаю, что это большая проблема.
              0
              >А Java у многих установлена
              это у Вас немножко заблуждение.
                +1
                www.w3resource.com/browsers/java-support.php
                Думаю, что 84% вполне подходит под определение «многих». Подтверждений у меня нет, но подозреваю, что среди девелоперов этот процент еще выше.
                  –1
                  Думаю статистика вранье. Наверняка ее мерили в самом Oracle. Там еще да. На реальном рынке нет.
                    +1
                    Почему вы так уверены, что именно ваша выборка более честная и репрезентативная?
                      –1
                      Потому что за много лет ремонта компов и за точно такой же период работы программистом я Java видел дай бог на 5% компов. Ту же самую статистику подтверждают мои коллеги по работе.

                      Да и зачем она на компе? Софта написанного на ней очень и очень мало.
                        +2
                        Охотно верю, что на ремонтируемых вами компьютерах обывателей все это не встречалось. Пускай даже Java обошла вас и ваших коллег-программистов стороной, что маловероятно — однако ваше утверждение все равно голословно. На Java написана добрая половина сред разработки — семейство Idea, семейство Eclipse, Netbeans, клиент Smartgit, разработка под Android также обычно ведется на Java.
                          –6
                          99% пользователей не программисты. Соответственно все это им нафиг не надо. А юзерского софта на Java нет.
                          Из того, что на Java написано кучу сред не следует, что все или хотя бы большая часть программистов их использует. Опять таки я не видел (хотя и читал про них) ни одного программиста который бы писал в одной из перечисленных сред разработки.

                          Итог такой: что даже путем диких натяжек и допущений процент Java на десктопах ну никак выше 5 не прыгнет. Ее просто не ставят за ненадобностью.
                            –2
                            Добавил голосовалку в пост, посмотрим, подтвердится ли ваш тезис про 5%.
                              0
                              Уважаемый, вы жонглируете 2 разными цифрами. Данные статистики привели для всех пользователей. А теперь говорите про то, что у программистов Java не редкое явление. Возмущение вызвала именно первая цифра. Т.е. 84%

                              Среди фронтенд-программистов это вполне реально. Но среди всех пользователей интернета — точно нет.
                                0
                                Я не в курсе на какой аудитории собиралась статистика по ссылке которую я привел. Просто запостил первую ссылку, которую смог нагуглить. Упоминаний оракла на их сайте я не нашел. Опрос запостил в ответ на предположение о том что даже с учетом всех натяжек процент не выше 5. Где и чем я жонглирую? Ну не нравятся цифры, приведите свою статистику, никто же не против.
                                  0
                                  Проблема в том, что вы взяли статистику для одной аудитории и пытаетесь применить ее как аргумент для другой аудитории. Это и есть жонглирование данными.
                                +2
                                Добавьте тогда сразу кто ставит джаву для минификатора гугловского, у меня джава стоит но только в силу тех причин что она необходима для запуска IDE. В противном случае вообще не вижу иметь ее на машине. Для минификации использую углифайжс.
                          0
                          Я тоже считаю что 84% это перебор. Java на клиентских windows встречается очень редко. В отличии от .net из коробки ее нет. А надобности в ней мало.

                          Обычный пользователь скорее всего не знает что такое Java или .NET и зачем оно. Поэтому вряд ли будет ставить сам. Только если Java нужна какому-то другому софту. А много вы софта знаете (для обычного пользователя), который требует Java?

                          Вот .NET может быть установлен и пользователь может не знать об этом и не использовать его.
                            0
                            удалено
                              +3
                              Статья же про инструмент для фронтенд-разработчика, причем тут софт для обычного пользователя?
                                0
                                А статистика в 84% это тоже среди разработчиков? Или для всех?
                      0
                      По существу, о 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 и пока ни чуть не жалею.
                        0
                        а в чём проблема поставить яву на сервере?
                          0
                          не безопасно это.
                            –1
                            > не безопасно это.

                            Серьезно? Небезопасно иметь жаву на билд-сервере? Расскажите поподробнее, какие угрозы это несет.
                              –1
                              Кто говорил про билд сервер? Сказано было просто «на сервере».
                              И да — установка любого нового компонента, уменьшает безопасность системы в целом, так как этот компонент может содержать в себе разного рода уязвимости.

                              То, что в вашем случае это билд сервер, он отключен от сети, стоит в бункере, данными с внешним миром обменивается через дискеты — это уже другая история, не имеющая отношения к первоначальному вопросу.
                                0
                                > Кто говорил про билд сервер?
                                monolithed говорил
                                > но на сборочном сервере для этой задачи ее ставить мало кто решится

                                Какое вообще отношение имеет «просто сервер» к контексту данного топика? Куда-то вас не в ту степь понесло. Здесь java используется исключительно для сборки пакета, с трудом представляю себе сценарий в котором это будет представлять угрозу безопасности. Чушь какая-то…
                            0
                            Любой пакет нужно мониторить и поддерживать и конфигурировать, для такой пустяковой задачи выделять время админов и безопасников никто не будет, поскольку это нецелесообразно.
                            Поставить же npm-пакет значительно проще, особенно есть уже есть свой npm-репозиторий и для этого не нужно рутовых прав.
                              0
                              ИМХО проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы). Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.
                                0
                                проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы).

                                Любое решение требует согласования. В данном случае, мне бы потребовалось обсудить это решение со своим непосредственным руководителем, специалистом который отвечает за деплой, специалистом по безопасности и админами, которые в свою очередь тоже должны это обсудить со своим руководством чтобы выделить время на конфигурирование машин.

                                Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.

                                Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.
                                  0
                                  > Любое решение требует согласования.

                                  Могу только посочувствовать этому примеру явно неадекватной бюрократии.

                                  > Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.

                                  Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?
                                    0
                                    Могу только посочувствовать этому примеру явно неадекватной бюрократии.

                                    Далеко не все разработчики обладают достаточной квалификацией и способностью нести ответственность за свои решения и уж тем более мало кто может самостоятельно определить трудозатраты других сотрудников.
                                    Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?

                                    После того как пакет собрался (CI) его нужно доставить на рабочие сервера (CD). Не думаю что сюрпризы в пакете кому-то понравятся.
                            0
                            npm install closurecompiler я один додумался и всегда делаю?
                            Превосходное API, как CLI, так и программно, поддержка пайпов, сорсмапов, хотя последнее никогда не требовалось. Компилится незначитьно дольше углифая.
                            Но в целом да, uglify2 проще.
                      0
                      Очень интересно, спасибо.

                      На сколько трудно будет его подружить с Go проектом? Т.е., например, у меня тесты для Go и автоматизация через makefiles. Будет ли стратегия proxify gulp commands through the makefile tasks правильной?
                        0
                        Я бы не стал смешивать код бэкенда с клиентским в случае разработки sdk или spa.
                        0
                        Кто первый форкнет и заменит closure compiler на uglufy2 — тот молодец и тому плюсик в карму (не только здешнюю, но и IRL):)
                          +3
                          Делов то :)

                          $ 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
                          
                            0
                            > Делов то :)
                            Ну вот и я не понял, чего народ на джаву жалуется, долго ли заменить:)
                              +1
                              Внял голосу жава-хейтеров и поменял на uglifyjs в репе
                                0
                                Я думаю, идеально было бы оставить два варианта — в виде веток или флагов или еще как-то.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое