В этой статье я расскажу как можно организовать процесс сборки фронтэнда «от и до».

Советую начать со вводной статьи, если кто не читал.

Там я рассказывал про TeaCSS как про надмножество CSS, и это была неправда. Точнее – полуправда. И таким он был во времена своего создания (откуда и название).

Сейчас – это декларативный метаязык для генерации контента, во многом черпающий вдохновение из QML, Lisp, Clojure, Nemerle.

На конференции Google I/O 2012 во второй части своего выступления Paul Irish представил проект yeoman.io. Главной целью которого является собрать для разработчика лучшие библиотеки и фреймворки в одном месте и создать идеальную среду для разработки за кратчайшее время.

При разработке приложений с модульной структурой на JavaScript возникает две проблемы:

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

Обе эти задачи решаются при использовании подхода Asynchronous Module Definition. Он сводится к описанию модулей функцией define и подключению их с помощью require. На данный момент есть несколько инструментов, реализующих AMD. Я начал своё знакомство с ними с RequireJS и был удивлён, насколько удобно и просто можно описывать зависимости модулей. Расскажу, как это работает, на простом примере.

Есть такая библиотека knockout.js. Она отличается от прочих хорошим туториалом для начинающих и кучей понятных рабочих примеров. Еще там стройная MVVM модель, декларативные связи и так далее.

Короче, если вы, как и я, поиграли с этой библиотекой, понаписали красивых формочек, и вам это понравилось, то все это дело захотелось применить на реальном проекте. И тут проблема — в реальном проекте формочек больше чем одна. А раз такие инструменты, то хочется single web page application и никак иначе. А делать один контроллер и все темплейты заверстывать на одну страницу тоже тупо и тормозно.

Под катом приведу основу своего сложного приложения. Само оно совсем не сложное, но модульное и допускает расширения, а темплейты и модели подгружаются динамически. Идея была подсмотрена в этой презентации — http://www.knockmeout.net/2012/08/thatconference-2012-session.html, код презентации выложен на github — https://github.com/rniemeyer/SamplePresentation — на базе этого кода будем писать свой.

Известно, что все хорошие джедаи используют внедрение зависимости (перевод) в своих проектах, это увеличивает концентрацию мидихлориан в крови и тестируемость кода в приложении. В данной статье я хочу рассмотреть некоторые аспекты использования UnityContainer в ASP.NET приложении, а именно, использование инжекции зависимостей через конструкторы контроллеров в ASP.NET MVC и WebApi и хабов в SignalR. Пример приложения присутствует.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

Модули или подобные структуры это неотъемлемая часть любого взрослого языка программирования. Просто иначе никак. Модули позволяют ограничить область видимости, позволяют реиспользовать части приложения, делают приложение более структурированным, отделяют ресурсы от шума и вообще делают код нагляднее.

Вот в JavaScript своя атмосфера — в языке нет официальных модулей, более того все файлы лежат удаленно, один поток приложения. Приходится постоянно решать какие-то странные проблемы с загрузкой, хитро паковать модули в один файлы, чтобы ускорить время загрузки. Бывает, что нужно воевать с двойными стандартами, адаптировать модули другого формата.

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

При разработке одного сайта мне понадобился загрузчик скриптов, так как хотелось что бы загрузка вызывалась из js кода. Из готовых решений нашел requirejs и yepnope. Requirejs — модульный, что к моим требованиям не подходило. Yepnope — асинхронный, это означает, что код в каждом файле мне пришлось бы обертывать в callback функции. Ничего не оставалось, кроме как написать что-нибудь самому. И вот что у меня получилось: wakeloader — безмодульный синхронный загрузчик скриптов для JavaScript. В этой статье я расскажу про него.

У меня сложилось впечатление, что в обществе все же есть предубеждение против использования глобальных переменных в служебных целях. В связи с этим, хочу дать некоторые разъяснения с примерами, которые снимут всякие сомнения и будут полезны всем, кто жаждет модульности и гибкости в JavaScript разработке. Я не могу проследить источники всех идей, приведенных ниже, но я не претендую на их авторство, а лишь на творческое обобщение. Так же я отказываюсь от претензий на один универсальных паттерн определения модулей для всех случаев жизни, надеюсь, всем ясно, что такого не может быть никогда. Все это существенно отличается от подходов RequireJS, CommonJS и того, как модули оформляются в node.js через module.exports, однако, каждый из этих паттернов имеет свое место, если подходить к задаче без фанатизма и предубеждений.

Доброго времени суток.
Современный мир оставляет мало возможностей не сталкиваться с javascript. Nodejs стал для меня последней каплей и, разочарованный в RoR (слишком много магии и генераторов — никаких холиваров, рубисты!), я снова поддался безумию: один язык на клиенте и сервере. Хоть javascript и прекрасен как язык, фреймворков, которые реализуют MVVM или хотя бы MVC и которые бы мне понравились, нет. Они все тяжеловесны и требуют написания лишнего (мусорного) кода. Поэтому я бы хотел представить на суд мое видение MVVM и получить от сообщества пинков в нужном направлении. Лучшим направлением было бы: «Вы пропустили библиотеку, посмотрите %library_name%», ибо все, что на поверхности (angularjs, knockoutjs, etc.) я посмотрел. Ну а так как фреймворк сырой и вряд ли принесет сейчас кому-то пользу, в обмен на долгожданные пинки я попытаюсь кратко сформулировать свой опыт, полученный при его написании.

Добрый день уважаемые, хабрачеловеки.
В данной статье я хочу поделиться с вами своим опытом работы с такими фреймворками как AngularJS и Knockout.
Cтатья будет интересна тем, кто хорошо знаком с JavaScript-ом и имеет представление хотя бы об одном из упомянутых фреймворков и естественно желает расширить свой кругозор.

Hello World,

Helios Kernel — это библиотека позволяющая описывать зависимости между javascript-модулями «в стиле include»:

// объявление зависимостей
include("path/to/library1.js");
include("../path/to/another/library2.js");

init = function() {
    // использование зависимостей
    library1.doSomething();
    ...
}

Я уже писал про Helios Kernel раньше, с тех пор проект переехал на гитхаб, а поводом к новому релизу стал тот факт, что весь платформо-зависимый код был выделен, и после некоторого допиливания тесты наконец прошил и под nodejs:



Поэтому теперь я могу написать здесь про библиотеку громкое слово «кроссплатформенная»

Hello World,

Helios Kernel — это библиотека для управления зависимостями между javascript-модуями, реализующая «классический» подход, часто встречаемый в других языках и средах — с помощью функции include().

Такой способ отличается от других подходов своей простотой: зависимости перечисляются в начале модуля по точному пути к файлу, тело модуля содержит код, который выполняется после загрузки зависимостей модуля.

Helios Kernel придерживается принципа KISS, поэтому здесь отсутствуют некоторые возможности, которые сегодня принято ожидать от библиотеки по управлению зависимостями. При использовании Helios Kernel не нужно описывать конфиг с правилами поиска путей для разных модулей, или экспортировать библиотечные функци через специальный объект. Но эта библиотека была написана как раз потому, что хотелось просто подключать нужные модули и писать код, не натыкаясь на крутые возможности при указании каждой новой зависимости.

Helios Kernel поддерживает динамическую загрузку (и выгрузку) зависимостей в рантайме, а сама библиотека и формат модулей являются совместимыми между nodejs и броузерной средой — то есть модули можно использовать без изменений или трансляции.

В этой статье классический подход реализованный в Helios Kernel сравнивается с управлением зависимостями с помощью RequireJS и показывается, каким образом подход Helios Kernel позволяет избежать некоторых сложностей.

Как веб-разработчик, вы, наверное, часто писали код JavaScript в одном файле, и, когда количество кода становится все больше и больше, его трудно поддерживать. Для решения этой проблемы вы можете разделить свой ​​код на несколько файлов, добавить дополнительные теги script и использовать глобальные переменные для доступа к функциям, объявленным в других файлах. Но это загрязняет глобальное пространство имен и для каждого файла дополнительный запрос HTTP снижает пропускную способность, что увеличивает время загрузки страницы.

Если это знакомо вам, наверное вы осознали необходимость в реорганизации вашего фронтенд кода, особенно если вы создаете крупно-масштабируемое web-приложение с тысячами строк кода JavaScript. Мы должны по-новому организовать всю эту неразбериху, чтобы код стало легче поддерживать. Новый метод заключается в использовании загрузчиков скриптов. В интернете можно найти много реализаций, но мы возьмем один из лучших, под названием RequireJS.

В этой пошаговой инструкции вы узнаете, как построить простое MVC (Model — View — Controller) приложение с помощью RequireJS. Вам не потребуются какие-либо предварительные знания в загрузке скриптов, основы мы рассмотрим в этой статье.

В конце 2012 мы с ребятами собрались сделать сумасшедшую штуку – засунуть в браузер RAW конвертер, фотошоп и добавить туда возможность совместной работы над фотографиями. С технической стороны мы практически все проверили: технологии, которые позволяли все это воплотить, были сырыми, иногда требовали включения их в настройках браузера… но они были. Мы назвали это Pics.io и начали.

У нас была пачка прототипов/proof-of-concept, простыни кода с огромным количеством хардкодов. Мы решили, что нужно все это объединить в один большой продукт, который будет полностью покрывать рабочий процесс фотографа: придумали архитектуру, написали каркас, начали делать функциональность.

Использование AngularJS в паре с RequireJS — достаточно популярный подход к разработке веб приложений в последнее время. И один из основных вопросов — структура приложения. Существует достаточно известный seed для такого приложения tnajdek/angular-requirejs-seed, но мне это не походит, так как при увеличении функционала приложения — данная структура просто будет засоряться кучей файлов, не будет никакого логического разделения скриптов и достаточно сложно будет их менеджить.

Целью было создать приложение с модульной и гибкой архитектурой (ну скорее просто разбиение приложение не логические части), с простым и понятным описанием зависимостей между частями приложения и уменьшить зависимость кода от структуры приложения.

Во время разработки проектов мы полюбили AngularJs. Но также мы встретили некоторые трудности в борьбе за чистоту модульности, с которой AngularJs справляется хорошо, но все же порой ему чего-то не хватает. RequireJs оказывается полезным там, где AngularJs оставляет желать лучшего, но использование их вместе — не совсем тривиальная задача.

Итак, опишем наш взгляд на решение проблемы.

Для чего?

Работая с AngularJs вы обязательно задумаетесь о правильной организации кода. Конечно уже существуют отличные примеры решения проблемы. Например можно изучить теоретический пост Брайана Форда или практическое руководство Клиффа Мейерса. Я же поделюсь способом организации кода в приложениях AngularJs с использованием RequireJs.

Данный подход будет полезен, если вы хотите:

• перестать беспокоиться о подключении скриптов в правильном порядке;
• загружать javascript код асинхронно;
• иметь возможность скомпилировать код в один минифицированный JS-файл;

Одним солнечным весенним утром, мне пришла в голову замечательная идея — заняться изучением популярной библиотеки RequireJS. Я уже давно читал много хорошего и о простоте использования и о преимуществах, которые она оказывает при использовании в проектах. Поэтому и подумать не мог, что подключение RequireJS к модульному проекту на Backbone может вызвать столько проблем. Я потратил два дня на то, что должно занять не более часа. А если у разработчика нет этих двух дней? Вот и решил поделиться с другими своим опытом, чтобы сэкономить время и нервы.

Недавно передо мной стала задача разработки IPhone и Android приложения. Опыта разработки под IOS у меня ранее не было, да и хотелось написать один раз и запускать на обеих платформах. Соответственно был выбран был выбран Javascript и PhoneGap.

И если с языком я определился относительно быстро, то далее было много вопросов.
Хотелось сделать, что бы приложение максимально повторяло интерфейс IOS7 и было похоже на native по скорости работы. При этом с одной стороны не было желания использовать «монстров», на подобии dojo или jquery mobile. c другой стороны хотелось получить удобную модульную MVC структуру приложения.

В итоге в финал моего личного сравнения вышли:
— Ionic framework: http://ionicframework.com/
— Framework7: http://www.idangero.us/framework7/

О пользе модульного подхода в программировании на любом языке говорилось уже достаточно много, по-этому приведу кратко основные положительные моменты для JS особо не вдаваясь в подробности. Разделение приложения на модули позволяет сделать код:

• значительно более читабельным и прозрачным для понимания
• гораздо более простым в поддержке
• гибким и расширяемым
• пригодным для написания достаточно больших приложений
• легко тестируемым и более простым в отладке

Так же документация модульного кода гораздо более эффективна.

Модульность, наряду с фреймворками, помогает вывести яваскрипт на качественно новый уровень и позволяет ему перейти из ранга вспомогательных и дополнительных в ранг серьезных самостоятельных языков программирования.

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

Существуют хорошо зарекомендовавшие себя библиотеки способные решить большинство поставленных задач и избежать отрицательных моментов. Одной из наиболее популярных библиотек для написания модульных приложений на яваскрипт является RequireJS. RequireJS хорошо документирована и касаться разработки с ее использованием в этой статье мы не будем. Рассмотрим подробнее как интегрировать RequireJS в Symfony2 с последующей оптимизацией созданных нами модулей. Для подобной цели очень кстати может оказаться HearsayRequireJSBundle, так что, какая проблема, берем бандл инсталлируем через компоузер и все! Возможно у кого-то так и получилось, однако могли возникнуть и некоторые нюансы. Чтобы максимально сгладить процесс знакомства с подобной интеграцией предлагаю прочесть то, что изложено ниже.

День добрый, читатели Хабра!
В этой статье спешу вам рассказать (хоть и с опозданием) о том, что такое WebJars на примере приложения в Play Framework.

В практически любом веб-приложении нельзя обойтись без сторонних javascript-библиотек. Самый простой способ добавить их: скачать и добавить в проект, а также добавить файл в git-репозиторий. Решение годное, но лично для меня наличие в проекте какой-либо статики малость раздражает. Есть другой метод: указывать ссылку на внешний хостинг js-библиотек такой как google, yandex. В принципе вариант, но в моей практике были случаи, когда необходимо было продолжить разработку а доступ в интернет оставлял желать лучшего либо его вообще не было, в итоге клиентская часть не функционировала. Наиболее годным решением мне видится добавления js библиотеки в качестве зависимости в проект, с подобным подходом вы могли сталкивать в Ruby on Rails.