А чем веломигалки не устраивают, если уж так нужно? Универсальных полно в веломагазинах и в том же Китае. Сам с такими катаю, обе на прищепках, можно снять и к одежде прикрепить или к рюкзаку. Первая, на аккумах типа 2*ААА по 900Mah, вторая с зарядкой от USB. Первой хватает на долго в режиме мигания, а с USB часа на 3 в режиме постоянного света (там тоже много различных режимов), но светит очень мощно + еще можно переключить на белый свет
Само приложение изначально задумывалось как кастомное. А подобная архитектура позволяет легко заменять компоненты(роутер и события) на компоненты от других библиотек, путем подключения пустого модуля и реализации подобного интерфейса.
Backbone.Model и Backbone.View это все-таки уже жесткая привязка к другой архитектуре.
У Backbone, роутер и события находятся в рамках одной библиотеки, что удобно. Решил по новой не писать, а взять уже готовое :)
Да.
Ссылка выше ведет на проект spa-приложения интернет магазина, который весит 100кб (код после gzip-сжатия) и работает без лагов на компе 2001 года с характеристиками Celeron 848Mhz, Озу 128мб и с древней Opera 9
Так же там же есть ссылка на live-demo
Есть SPA-приложение на bootstrap 3.
Минифицированные файлы весят ~100кб с включенным gzip-сжатием на сервере Nginx. А так ~320кб. Туда входит: underscore-min.js, backbone-min.js, jquery.min.js, bootstrap.min.js, bootstrap.min.css + шрифты, свои стили и код самого приложения. А новый bootstrap мне кажется не сильно много. Тут еще главное, чтобы печатные машинки поддерживали его новые фишки типа flex
JS как пластилин. По началу тоже непревычно было. А хорошо это или плохо ответ у каждого свой.
Я хочу получить нормальный «контейнер» в котором будут изолированы функции, я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.
Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути. А если к этому добавить Медиатор(контроллер), который координирует работу модулей + Наблюдатель, который служит для асинхроного общения, то уже получается структура полноценного приложения.
x = (function() {
var
red = 200,
blue = 300,
green,
getTotal , setGreen;
getTotal = function() {
console.log(red + blue + green);
};
setGreen = function(arg) {
green = arg;
};
return {
// public methods
getTotal : getTotal,
setGreen : setGreen
}
}());
x.setGreen(400);
x.getTotal(); // 900
Вроде много лет назад именно для этих целей и сделали классы и пространства имен.
А как же таймеры, воркеры, и его асинхронные события? Воркеры – это отдельные потоки с изолированным контекстом. Написал даже библиотеку для удобной работы с ними: https://github.com/artnv/clientThreads
отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )
Вычитал (не помню в какой книжке), что паттерн Модуль еще с начала 2000х использовали в JS. Это самовыполняющиеся функция которая возвращает объект с методами из замыкания. Де-факто стандарт.
отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )
Стандарты есть, паттерны те же самые, mvc, стили различных фреймворков.
отсутствие нормальных классов / ООП
JS – прототип-ориентированный язык, а это модель ООП. В ПП понятие класса вообще отсутствует, при этом ПП намного гибкий чем классический подход. В объектах вся мощь JS, с помощью них создается структура приложения, неймспейсы, хранятся и передаются данные как между методами так и по сети, с помощью json
отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )
Это скорее мир асинхронности. Нужно понимать как браузер производит загрузку кода, в какой последовательности и когда начинает выполнять. В JS, код может генерироваться, подгружаться и подключаться динамически, в разное время. Достаточно контролировать последовательность и следить за событиями.
отсутствие вывода типов в самом языке или в каком-либо инструменте
console.log(typeof 123) // number
console.log(typeof '123') // string
этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )
this — это объект. this ссылается на внутренний контекст Конструктора (предоставляет доступ к внутренним свойствам) при создании через new, в случае отсутствия new будет ссылаться на глобальный контекст window. По сути, при создании через new возвращается объект this и все его свойства thix.x, this.y и т.д. Аналогично было бы вернуть объект с помощью return {x:1,y:2} в обычной функции. Если пугают конструкторы, this/new, можно использовать литералы объектов
отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )
В JS все же на событиях из-за той же асинхронности. Можно самим написать или взять готовое решение пользовательских событий по паттерну Наблюдатель/Observer, это EventManager/EventEmitter/PubSub.
Например: данные пришли с помощью ajax, публикуется событие
eventManager.trigger('incomingData')
и все подписчики которые подписаны на него, запускаются циклом.
У многих есть ошибочное суждение что в JS всё легко, низкий порог вхождения и т.д. Может быть и так, в небольших приложениях, где нужно использовать пару методов JQuery, а взявшись за разработку чуть более сложного, разработчик сталкивается со своим ложным представлениям о нём. Код нужно как-то организовывать, чтобы через пару дней понять где, что работает. Придется достаточно глубоко изучить сам язык, чтобы использовать больше его возможностей, с ростом задач. Изучить API Браузера и его работу. Научится работать с асинхронностью. А уже после всего этого приниматься за библиотеки, фреймворки, а не на оборот. Впрочем зная язык можно свои велосипеды написать)
Кому нужно больше примеров по этой теме, вот две книги:
«Single Page Web Applications / Разработка одностраничных веб-приложений», Майкл С. Миковски, Джош К. Пауэлл
В книге описывается разработка чата. Большое внимание уделяется проектированию приложения на клиентской стороне и использование паттернов: Медиатор, Модуль и Наблюдатель. А в качестве сервера Node.js. Теории мало, но много кода и практики.
Код для книги: https://www.manning.com/books/single-page-web-applications
«JavaScript Patterns / JavaScript. Шаблоны», Стоян Стефанов
Большое количество шаблонов с примерами
Скриншот со статистикой браузеров — игроков, которые играли в эту змейку, а не из рекламы.
А такая доля IE, наверное, потому что эти люди часто играют в браузерные игры и им часто показывается табличка: «ваш браузер не поддерживается».
Я чуть выше про это написал .
Само приложение изначально задумывалось как кастомное. А подобная архитектура позволяет легко заменять компоненты(роутер и события) на компоненты от других библиотек, путем подключения пустого модуля и реализации подобного интерфейса.
Backbone.Model и Backbone.View это все-таки уже жесткая привязка к другой архитектуре.
У Backbone, роутер и события находятся в рамках одной библиотеки, что удобно. Решил по новой не писать, а взять уже готовое :)
Ссылка выше ведет на проект spa-приложения интернет магазина, который весит 100кб (код после gzip-сжатия) и работает без лагов на компе 2001 года с характеристиками Celeron 848Mhz, Озу 128мб и с древней Opera 9
Так же там же есть ссылка на live-demo
А почему бы и нет? Фору по скорости многим даст)
github.com/artnv/ecommerce-demo
Минифицированные файлы весят ~100кб с включенным gzip-сжатием на сервере Nginx. А так ~320кб. Туда входит: underscore-min.js, backbone-min.js, jquery.min.js, bootstrap.min.js, bootstrap.min.css + шрифты, свои стили и код самого приложения. А новый bootstrap мне кажется не сильно много. Тут еще главное, чтобы печатные машинки поддерживали его новые фишки типа flex
Да, функция это объект), например она может содержать статическое свойство
JS как пластилин. По началу тоже непревычно было. А хорошо это или плохо ответ у каждого свой.
Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути. А если к этому добавить Медиатор(контроллер), который координирует работу модулей + Наблюдатель, который служит для асинхроного общения, то уже получается структура полноценного приложения.
Пример неймспейсов
Классы это хорошо, но в JS их нет, в место них объекты, другой вообще подход
А как же таймеры, воркеры, и его асинхронные события? Воркеры – это отдельные потоки с изолированным контекстом. Написал даже библиотеку для удобной работы с ними: https://github.com/artnv/clientThreads
Вычитал (не помню в какой книжке), что паттерн Модуль еще с начала 2000х использовали в JS. Это самовыполняющиеся функция которая возвращает объект с методами из замыкания. Де-факто стандарт.
Стандарты есть, паттерны те же самые, mvc, стили различных фреймворков.
JS – прототип-ориентированный язык, а это модель ООП. В ПП понятие класса вообще отсутствует, при этом ПП намного гибкий чем классический подход. В объектах вся мощь JS, с помощью них создается структура приложения, неймспейсы, хранятся и передаются данные как между методами так и по сети, с помощью json
Это скорее мир асинхронности. Нужно понимать как браузер производит загрузку кода, в какой последовательности и когда начинает выполнять. В JS, код может генерироваться, подгружаться и подключаться динамически, в разное время. Достаточно контролировать последовательность и следить за событиями.
this — это объект. this ссылается на внутренний контекст Конструктора (предоставляет доступ к внутренним свойствам) при создании через new, в случае отсутствия new будет ссылаться на глобальный контекст window. По сути, при создании через new возвращается объект this и все его свойства thix.x, this.y и т.д. Аналогично было бы вернуть объект с помощью return {x:1,y:2} в обычной функции. Если пугают конструкторы, this/new, можно использовать литералы объектов
В JS все же на событиях из-за той же асинхронности. Можно самим написать или взять готовое решение пользовательских событий по паттерну Наблюдатель/Observer, это EventManager/EventEmitter/PubSub.
Например: данные пришли с помощью ajax, публикуется событие
и все подписчики которые подписаны на него, запускаются циклом.
У многих есть ошибочное суждение что в JS всё легко, низкий порог вхождения и т.д. Может быть и так, в небольших приложениях, где нужно использовать пару методов JQuery, а взявшись за разработку чуть более сложного, разработчик сталкивается со своим ложным представлениям о нём. Код нужно как-то организовывать, чтобы через пару дней понять где, что работает. Придется достаточно глубоко изучить сам язык, чтобы использовать больше его возможностей, с ростом задач. Изучить API Браузера и его работу. Научится работать с асинхронностью. А уже после всего этого приниматься за библиотеки, фреймворки, а не на оборот. Впрочем зная язык можно свои велосипеды написать)
«Single Page Web Applications / Разработка одностраничных веб-приложений», Майкл С. Миковски, Джош К. Пауэлл
В книге описывается разработка чата. Большое внимание уделяется проектированию приложения на клиентской стороне и использование паттернов: Медиатор, Модуль и Наблюдатель. А в качестве сервера Node.js. Теории мало, но много кода и практики.
Код для книги: https://www.manning.com/books/single-page-web-applications
«JavaScript Patterns / JavaScript. Шаблоны», Стоян Стефанов
Большое количество шаблонов с примерами
А такая доля IE, наверное, потому что эти люди часто играют в браузерные игры и им часто показывается табличка: «ваш браузер не поддерживается».