Я думаю, нет смысла ориентироваться на Dart. После оф. отказа представителей Mozilla, Microsoft и Apple от нативной поддержки, он просто встает в ряд со всей массой языков, компилируемых в JS, а это уже не интересно
Отсутсвие сборки никак не мешает тестированию. Или я чего-то не понимаю?
Unit-тестированию не мешает, а функциональному тестированию мешает. Вы не можете провести функциональное тестирование до момента создания консистентного состояния системы, которое достигается успешной сборкой проекта.
А зачем его сохранять? Да, код будет eval'ится (через new Function). Так же eval'ится и код всех модулей, на этом построена работа commonjs. Node.js делает точно так же. И, поверьте, в этом нет проблемы.
А что насчет минификации выходных файлов? Суть в том, чтобы после трансляции coffee->js склеить и минифицировать все JS файлы. Как вы это будете делать, если собираетесь компилировать Coffee на клиенте? Это проигрыш в скорости, как с точки зрения eval'a, так и с точки зрения трафика.
Html подключает javascript, css, изображения и другие файлы. Javascript подключает другие javascript модули и другой контент, такой как шаблоны, словари, json etc, для некоторых вещей свои синтаксические конструкции. Шаблоны — css, изображения, словари, другие шаблоны. И далее…
Ну, во-первых это очень похоже на web-компоненты(см. polymer, mozilla x-tags), особенно идея с подключением стилей для конкретных объектов. По-факту, ваша система позволяет производить инкапсуляцию css, js и html в рамках компонента, верно? В таком случае это 1 в 1 повторяет идеологию web-компонентов.
У вас всегда вся возможная разметка на странице?
Нет, но у меня всегда подключается gzip-пакет, в котором лежат все JS и CSS. А т.к. мои «фреймворки» позволяют мне выбрать шаблонизатор, с которым я буду работать, то компилируется этот код в JS, и позднее склеивается и минифицируется вместе с остальными JS файлами, тем самым получая максимально маленький размер трафика, который мне надо отдать пользователю. Это уже не говоря о том, что я могу провести вашу проверку на использование стилей в несколько раз быстрее, пробежав всего по 2 файлам: 1 css(результирующий) и 1 js(шаблоны), в то время как при вашем подходе мне придется открывать по 1 все стили и все шаблоны.
Спасибо за ссылку на бэнчмарки, поглядел — действительно все очень быстро. По поводу лайв редактирования по-прежнему не понимаю: может, вы имеете ввиду data-binding? Я просто уже теряюсь в догадках :) По поводу «бороться» с фреймворком — это скорее просто говорит об отсутствии правильно спроектированной архитектуры.
Что касается описываемых вами недостатков — это даже не недостатки, а, скорее, небольшие трудности, которые переживает только что зародившийся проект. Я обязательно взгляну на этот проект более подробно, как представится случай. Возможно, я и правда слишком критичен к нему, раз столько человек говорит, что это такая замечательная система.
Уникальность фреймворка, он очень высоко производительный
Хотелось бы в дополнение к слайдам увидеть бэнчмарки, отражающие заявленные цифры
Есть киллер фича лайв редактирование.
livereload.com/ — а такое решение не устраивает? Или я что-то не так понял?
Фреймворк, очень хорошо подходит для больших проектов
Как и любой другой фреймворк, собственно.
Уникален своими инструментами, написанными на привычном для фронтеенд разработчика стеке
Можно поинтересоваться, какие инструменты в этом фреймворке уникальны?
Модульная система позволит вам переиспользовать ваш код без боли, даже в другом проекте.
Это не достоинство фреймворка, это достоинство модульной системы.
Есть и недостатки, но я не буду о них упоминать.)
Почему? У читателей, на мой взгляд, должно складываться комплексное впечатление о фреймворке, который они, возможно, захотят использовать в сл. проекте.
Вообще молодцы ребята, что продолжают развивать проект, а не зарыли его внутри компании, и пытаются поделиться большим опытом разработки действительно сложных фронтенд систем.
А за это и правда большое спасибо. В любом случае — это вклад в развитие экосистемы JS, и весьма немалый.
сборка нужна только для публикации приложения, но не для разработки
Что насчет тестирования? Я придерживаюсь разработки через тестирование, и т.к. я тестирую не отдельные функции, а пользовательские сценарии, я бы хотел иметь собранный проект, т.к. чаще всего пользовательские действия затрагивают сразу несколько модулей, как быть тогда?
Например, у coffeescript есть компилятор написанный на js, это значит что мы можем транслировать его в js хоть на сервере, хоть на клиенте.
Только что вам даст трансляция coffee->js без возможности сохранить результат? Или вы будете eval'ить код, который будет выходить из такого транслятора? И будете делать это для всех coffee файлов? Я могу сказать, что вы здесь ничего не выигрываете.
Можно использовать какой нибудь вотчер, который будет транслировать файлы в css при их изменении, а дальше все будет работать как раньше.
Действительно, можно, однако инкрементальные сборки придумали как раз, чтобы уйти от того, что у вас в одной вкладки консоли открыт sass watch, в другой coffee watch, а в третей бог весть что. И более того, это по-прежнему не покрывает кейсов тестирования после изменения coffee файлов.
не существовало спроса на эту функциональность
Вы считаете, что таск-раннеры а-ля Grunt, или системы сборки типо Gulp, Broccoli, Brunch не пользуются спросом?
Основной смысл, что мы не просто обрабатываем какие то файлы, но строим их взаимосвязи и понимаем как они друг друга используют
То есть суть в том, что обрабатывается не просто какой то определенный файл, или тип файлов. А обрабатываются все файлы сразу, с учетом их связей, перестраиваются структуры
Не могу представить себе иного сценария, как файл index.html как корень графа, из которого идут две ветви: css и js, в которых в css отражаются зависимости директивы @import, а в js — amd/commonJS модулей. Как это помогает разработке?
Например, что такой то класс никогда не используется в разметке, а вот для этого класса в шаблоне нет никаких стилей.
Chrome Dev Tools -> вкладка audit -> start
ни Backbone, ни Angular не являются фрейморками, если что…
Не могли бы вы в таком случае пояснить мне, чем они являются, если не MV* фреймворками?
Лично я основвываюсь классического определения «фреймворк», данного википедией, и в моём понимании, angular и backbone под него подходят
По-моему, все просто имеют ввиду, что фреймворк «опоздал» на несколько лет. В далеком 2006 это был бы огромный прорыв вперед, но в 2014 это просто еще один фреймворк на JS. Если вы со мной не согласны — объясните, в чём он «уникален», т.к. из статьи этого не понятно.
К сожалению, ситуация вокруг сборщика немного сложнее: у вас, насколько я понимаю, нет возможности инкриментальных сборок, нет кеширования, watcher'ов. А это значит, что либо мне придется работать с двумя сборщиками, например, Gulp и ваш, либо писать свои велосипеды для оборачивания shell команд под CoffeeScript или SASS, что явно не упрощает процесс разработки. Это уже не говоря, про, скажем, разделение окружений на dev и production для сборок. А по поводу commonJS, уже естьрешения для разнообразных билд систем, в чём такая сложность его сборки? Что касается «киллер-фичи» с графами файлов — вам ничего не мешает вынести ее как плагин к одной из готовых систем, это намного проще, чем писать очередной сборщик. По поводу ES6 — это не задача фреймворка, но когда стандарт будет увтержден, лично я отдам предпочтение фреймворкам, которые будут иметь нативную поддержку таких вещей, как модули, например, чем буду использовать amd/commonJS. Разумеется, это всё лишь моё мнение и я не претендую, что оно единственное правильное.
P.S. Если посмотреть на все фреймворки, то они отличаются друг от друга подходом к созданию приложений. Например, я думаю, многие не согласятся с вашим мнением, что Backbone не отличается от Angular.
Справедливо добавить, что после просмотра презентации, ссылку на которую кинул vk2, вопрос про сравнение с фреймворками отпадает. Но все же, я думаю было бы лучше, если б вы добавили эту информацию в статью.
Меня интересует несколько моментов:
1) Я так понимаю, что default оформление ui было взято у sencha? Как они к этому относятся?
2) Самописная билд система? Почему не используете уже существующие?
3) Какие решения вы используете для наследования и что вы думаете о примесях
4) Скоро современные браузеры начнут поддерживать ES6, не сигнал ли это к приведению кода к ES6 нотации, особенно для новых фреймворков? Я имею ввиду, что можно уже сейчас реализовывать большую часть спецификации, а поддержку старых браузеров обеспечивать полифилами. Это дало бы вам некоторую отличительную особенность, по сравнению с основными frontend фреймворками.
Вообще, почти любой труд заслуживает благодарности, и я уверен, что ваш фреймворк найдет свою нишу, но пока я не понимаю, чем он принципиально отличается от остальных. Присоединяюсь к xeLL, хотелось бы посмотреть на сравнение бенчмарков с др. фреймворками.
Вообще, в чём-то я с вами согласен, особенно по поводу бума вокруг JS и ноды. Бум действительно преувеличен. Но, к сожалению, у нас есть то, что есть. Я возлагал надежды на Dart, но после оф. заявлений со стороны Mozilla, Apple и Microsoft об отказе поддержки этого языка на нативном уровне, надежды, вы, развеялись. Но я советую вам не расстраиваться — помните, сколько теребили тему NoSQL и в особенности NoSQL+Node.JS? Мода проходит, обкатанные решения остаются, вода сливается. Так было тогда и так произойдет и в этот раз. Node.JS слишком молод и зелен, чтобы конкурировать со сложившимися мастадонтами. Может, когда нибудь… Но явно не сейчас.
Мне немного непонятна ваша позиция: я прочитал всё, что вы написали(правда, в конце уже через строчку, ибо мысли повторяются), но так и не понял, чем вам так не угодил js? То вы сетуете на программистов-студентов, которые пишут быдлокод, то на на непривычные вам конструкции языка, то на разную реализацию стандартов, но язык-то в чём виноват? Он так же развивается и старается соответствовать запросам пользователей и программистов. Его API расширяется, появляются новые конструкции… Складывается ощущение, что язык работает просто «не так, как вы привыкли», и поэтому он плох. Судя по приведенным вами примерам и проблемам, на которые вы указываете, вы не часто работаете с этим языком, тогда зачем ругать то, что относится к иной для вас проф. области?
P.S. После прочтения статьи так и не понял, что вы хотели донести, кроме сильного негатива.
Я постараюсь провести сравнительный анализ нескольких систем для сборки ближе к этим выходным. Думаю, что это будет grunt, gulp, branch и broccoli. Можно ещё добавить fez. Как считаете? Так же надо будет выбрать задачи, для которых я сделаю замеры по производительности, ведь, я так понимаю, никому не интересно будет смотреть на jslint, uglify, concat и imagemin?
Я согласен с вами, что декомпозиция Gruntfile в некоторых случаях является усложнением при дальнейшей поддержке онного. Однако, в большинстве случаев, это все-таки упрощает процесс поддержки. При желании изменить конфигурацию для какой-нибудь задачи, вам не придется искать её в простыне кода, которая может достигать более нескольких тысяч строк. В таком случае, намного удобнее найти интересующий файл с конфигурацией одной задачи и отредактировать его.
В данный момент на проекте, которым я занимаюсь, задачи разнесены именно таким образом. Даже шаблонизация при работе с jasmine + connect выглядит весьма удобочитаемо, несмотря на то, что конфиг этих двух задач находится в разных файлах.
В конце концов, Grunt есть Grunt, и в рамках этой build-системы вряд ли можно добиться лучших результатов по организации кода. Да и меньше код всё равно не станет.
Автор статьи по-моему особо не уделяет внимания Gulp, разве что вскользь упоминает его в самом начале.
Вообще, хоть я и не знаком с Gulp, но такая разница кажется мне слишком большой: правильно написанный Gruntfile, по моему мнению, не может уступать Gulp в 20 раз. Вы не могли бы показать эти два файла? Мне было бы очень любопытно разобраться.
Хотелось бы услышать об этом во второй части статьи
Да, вы правы, такое крайне тяжело разобрать. Но я не до конца понимаю, в таком случае, как вы это делаете?
В общем, жду вторую часть. Надеюсь, в ней будет много интересного.
Unit-тестированию не мешает, а функциональному тестированию мешает. Вы не можете провести функциональное тестирование до момента создания консистентного состояния системы, которое достигается успешной сборкой проекта.
А что насчет минификации выходных файлов? Суть в том, чтобы после трансляции coffee->js склеить и минифицировать все JS файлы. Как вы это будете делать, если собираетесь компилировать Coffee на клиенте? Это проигрыш в скорости, как с точки зрения eval'a, так и с точки зрения трафика.
Ну, во-первых это очень похоже на web-компоненты(см. polymer, mozilla x-tags), особенно идея с подключением стилей для конкретных объектов. По-факту, ваша система позволяет производить инкапсуляцию css, js и html в рамках компонента, верно? В таком случае это 1 в 1 повторяет идеологию web-компонентов.
Нет, но у меня всегда подключается gzip-пакет, в котором лежат все JS и CSS. А т.к. мои «фреймворки» позволяют мне выбрать шаблонизатор, с которым я буду работать, то компилируется этот код в JS, и позднее склеивается и минифицируется вместе с остальными JS файлами, тем самым получая максимально маленький размер трафика, который мне надо отдать пользователю. Это уже не говоря о том, что я могу провести вашу проверку на использование стилей в несколько раз быстрее, пробежав всего по 2 файлам: 1 css(результирующий) и 1 js(шаблоны), в то время как при вашем подходе мне придется открывать по 1 все стили и все шаблоны.
Что касается описываемых вами недостатков — это даже не недостатки, а, скорее, небольшие трудности, которые переживает только что зародившийся проект. Я обязательно взгляну на этот проект более подробно, как представится случай. Возможно, я и правда слишком критичен к нему, раз столько человек говорит, что это такая замечательная система.
Хотелось бы в дополнение к слайдам увидеть бэнчмарки, отражающие заявленные цифры
livereload.com/ — а такое решение не устраивает? Или я что-то не так понял?
Как и любой другой фреймворк, собственно.
Можно поинтересоваться, какие инструменты в этом фреймворке уникальны?
Это не достоинство фреймворка, это достоинство модульной системы.
Почему? У читателей, на мой взгляд, должно складываться комплексное впечатление о фреймворке, который они, возможно, захотят использовать в сл. проекте.
А за это и правда большое спасибо. В любом случае — это вклад в развитие экосистемы JS, и весьма немалый.
Что насчет тестирования? Я придерживаюсь разработки через тестирование, и т.к. я тестирую не отдельные функции, а пользовательские сценарии, я бы хотел иметь собранный проект, т.к. чаще всего пользовательские действия затрагивают сразу несколько модулей, как быть тогда?
Только что вам даст трансляция coffee->js без возможности сохранить результат? Или вы будете eval'ить код, который будет выходить из такого транслятора? И будете делать это для всех coffee файлов? Я могу сказать, что вы здесь ничего не выигрываете.
Действительно, можно, однако инкрементальные сборки придумали как раз, чтобы уйти от того, что у вас в одной вкладки консоли открыт sass watch, в другой coffee watch, а в третей бог весть что. И более того, это по-прежнему не покрывает кейсов тестирования после изменения coffee файлов.
Вы считаете, что таск-раннеры а-ля Grunt, или системы сборки типо Gulp, Broccoli, Brunch не пользуются спросом?
Не могу представить себе иного сценария, как файл index.html как корень графа, из которого идут две ветви: css и js, в которых в css отражаются зависимости директивы
@import, а в js — amd/commonJS модулей. Как это помогает разработке?Chrome Dev Tools -> вкладка audit -> start
Не могли бы вы в таком случае пояснить мне, чем они являются, если не MV* фреймворками?
Лично я основвываюсь классического определения «фреймворк», данного википедией, и в моём понимании, angular и backbone под него подходят
P.S. Если посмотреть на все фреймворки, то они отличаются друг от друга подходом к созданию приложений. Например, я думаю, многие не согласятся с вашим мнением, что Backbone не отличается от Angular.
1) Я так понимаю, что default оформление ui было взято у sencha? Как они к этому относятся?
2) Самописная билд система? Почему не используете уже существующие?
3) Какие решения вы используете для наследования и что вы думаете о примесях
4) Скоро современные браузеры начнут поддерживать ES6, не сигнал ли это к приведению кода к ES6 нотации, особенно для новых фреймворков? Я имею ввиду, что можно уже сейчас реализовывать большую часть спецификации, а поддержку старых браузеров обеспечивать полифилами. Это дало бы вам некоторую отличительную особенность, по сравнению с основными frontend фреймворками.
Вообще, почти любой труд заслуживает благодарности, и я уверен, что ваш фреймворк найдет свою нишу, но пока я не понимаю, чем он принципиально отличается от остальных. Присоединяюсь к xeLL, хотелось бы посмотреть на сравнение бенчмарков с др. фреймворками.
P.S. После прочтения статьи так и не понял, что вы хотели донести, кроме сильного негатива.
В данный момент на проекте, которым я занимаюсь, задачи разнесены именно таким образом. Даже шаблонизация при работе с jasmine + connect выглядит весьма удобочитаемо, несмотря на то, что конфиг этих двух задач находится в разных файлах.
В конце концов, Grunt есть Grunt, и в рамках этой build-системы вряд ли можно добиться лучших результатов по организации кода. Да и меньше код всё равно не станет.
Вообще, хоть я и не знаком с Gulp, но такая разница кажется мне слишком большой: правильно написанный Gruntfile, по моему мнению, не может уступать Gulp в 20 раз. Вы не могли бы показать эти два файла? Мне было бы очень любопытно разобраться.