How to become an author
Search
Write a publication
Pull to refresh

Comments 35

>>> Напишите, какие темы наиболее интересны.

Типизированные массивы.
Total votes 1: ↑1 and ↓0+1
Подумаю… А вам интересно это со стороны производительности, или чтения из сетевых потоков, или по какой-нибудь ещё причине?
This comment wasn’t rated yet0
И то и другое.

С ArrayBuffer в принципе всё понятно, хотелось бы посмотреть на класс DataView на примере.

Но и ArrayBuffer тоже будет не лишним.
This comment wasn’t rated yet0
Работа с LocalStorage будет очень интересной, попробуй сделать поддержку версионности и устареваня данных. Круто будет записывать обьектыв LocalStorage через свою обертку при наличии коей ненужно будет думать у тебя там скаляр или обьект.

P.S. Поддерживаю такую реализацию модулей. Она позволяет имплементировать приватность, что тяжело при помощи других методов.
Спасибо за труды при написанни статьи, коротко и по сути.
Total votes 2: ↑2 and ↓0+2
Да, хранение данных на клиенте — важная штука; думаю, чем умнее будут становиться веб-приложения, тем активнее будет использоваться localStorage.
This comment wasn’t rated yet0
С приветом из 2014-го? :)
В JS сейчас такое безумие творится, что подобная статья смотрится уже устаревшей. Ну и пункт 3 какой-то стремный в сегодняшних реалиях. Gulp многие пытаются на свалку отправить, не говоря уже про Grunt.
Бекендщикам сейчас конечно сложновато погружаться в JS — много времени потребуется на всю эту «хипстоту» :)
Total votes 9: ↑9 and ↓0+9

Я тоже был удивлён, когда не нашёл подобных статей. Но когда я стартанул с JS, мне очень не хватало такого. 


window[config.globalName] = yourApiVar;

Это на самом деле классика. Во многих библиотечках используется. И хипстерских, и супер-оптимизированных. Необходимость.


И что вместо Gulp и Grunt? Прочитал сейчас пару статей, интересно. Рекомендуют чистый npm и прочее.

Total votes 1: ↑1 and ↓0+1
Много чего сейчас есть. Например, определенной (и вполне заслуженной) популярностью пользуется сборка на webpack с использованием npm-скриптов (для действий не покрываемых сборщиком).
«Накладные расходы» на поддержку нормальной модульности минимальны, призывы «только конкатенация» непонятны.
Total votes 2: ↑2 and ↓0+2
Староверы собирают на Apache Ant.
This comment wasn’t rated yet0
Я кстати не пытался призвать всех отказываться от Gulp. Некоторая агитация по npm scripts имеется, но думаю Gulp еще поживет. Причины отказа от него несколько надуманы, но для мелких проектов возможно да, нет особого смысла его тянуть.
This comment wasn’t rated yet0
Спасибо за статью.

Было бы интересно почитать по сокетам. По ним довольно много материала. Но так, чтобы коротко и по делу я не видел. Может плохо искал, каюсь.
This comment wasn’t rated yet0

Хорошая тема, если будет чем поделиться, напишу.

This comment wasn’t rated yet0
Давно собираюсь с силами написать статью, но руки не доходят, так что делюсь идеей, может заинтересует. Напишите про контексты, в которых может оказаться джисер и в чем их разница —
— код в странице открытой с сайта
— во фрейме
— на странице, открытой локально с диска
— в расширении (popup,  background, content) — для хрома(оперы), файрфокса (да, движок хромиум, но обвес там совсем другой),
— далее вебворкеры
— да, для firefox-а — bootstrap.js в интересном контексте запускается, там не все модули доступны, я например до сторейджа (simple-storage) так и не смог достучаться
— pac-файлы тоже, хоть и стандарт есть — везде в разном контексте запускаются (в хроме это не совсем песочница, по крайней мере регексы доступны, хотя по стандарту не должны, а в лисе даже описанные в стандарте функции недоступны)

Так, навскидку вроде все распространенное охватил на клиенте. В общем если займетесь — могу даже подсобить.
This comment wasn’t rated yet0
Я тут заканчиваю небольшой бойлерплейт для создания chrome-расширений на базе webpack с hot module replacement и автоматическим chrome.runtime.reload() при компиляции, есть мысли по завершении статейку написать.
Про контексты в расширениях — это довольно значимый пунктик, в частности, доступ к chrome API из injected-скриптов, доступ к js-окружению на странице, контекст применения HMR-обновлений (т.к. это не обычная страница, пришлось немного подпилить механизм hot-апдейтов) и т.д. нюансы.
Если будут желающие поучаствовать словом и делом — буду рад.
This comment wasn’t rated yet0

На самом деле всё началось именно с chrome extension, а потом функциональность перекочевала в injected script, потом во встраиваемый скрипт.


"доступ к chrome API из injected-скриптов" — я в расширении реализовал специальный channel — он заворачивает функции и шлёт события и на другой стороне вызывает реализацию этих фунций. Вы сделали похоже?


Буду иметь ввиду. Напишите, по крайней мере интересно посмотреть: dmitry@kuoll.com

This comment wasn’t rated yet0
Да, могу накидать хинтов по портированию этого дела в firefox. Созреете — стукните в личку.
This comment wasn’t rated yet0

Да, хороший вопрос, вполне достойный отдельной статьи.

This comment wasn’t rated yet0
Расскажите про удобную работу с куками, ибо это «самое убогое API, которое пролезло в JS». Вы скажете что мол вон, есть localStorage, но бывает когда использование кукисов необходимо.
This comment wasn’t rated yet0

Да, хороший вопрос. И надо ещё подумать когда cookies, а когда localStorage.

This comment wasn’t rated yet0
config = {};
sharedState = {};

Вы действительно хотите сделать эти 2 переменные видимыми снаружи?
Почему не сделать этого явно?
Откуда берется функция start, которую вы вызываете?
Total votes 1: ↑1 and ↓0+1

config и sharedState не видны снаружи, они же ведь объявлены внутри функции.


Функция start() — из пункта 5; её задача — явная инициализация всего API.

This comment wasn’t rated yet0
>config и sharedState не видны снаружи, они же ведь объявлены внутри функции.

Вы ошибаетесь.

(function(){
config={test:'test'};
})();

console.log(config);

Total votes 3: ↑3 and ↓0+3
А если бы код был в strict mode, то проблема бы даже не появилась
Total votes 1: ↑1 and ↓0+1

Это же псевдо-код, там реализации функций нет и прочего.


А так все модули обязательно strict mode. Добавляю к шаблону, чтобы было очевидно.

This comment wasn’t rated yet0
Правильная система модулей? ES next import/export, не, не слышал :D
Total votes 1: ↑1 and ↓0+1
Всё-таки, если стоит вопрос возможности работы библиотеки в среде без поддержки ES2015, UMD – наиболее удобный вариант, т.к. поддерживает AMD, CommonJS, vanilla definition :)
https://github.com/umdjs/umd
This comment wasn’t rated yet0
babel + webpack, typescript + webpack и webpack делает umd из коробки
This comment wasn’t rated yet0
В Webpack нельзя выбрать вариант экспорта (см. Variations в репозитории)
This comment wasn’t rated yet0
Ответ очевиден: когда вы сконкатенируете код таких модулей, всё будет работать безо всяких библиотечек для модулей.

Серьезно?

This comment wasn’t rated yet0

Если есть возражения, мы готовы их услышать.

This comment wasn’t rated yet0

Окей, я даже немного растерялся. Webpack, Browserify, Systemjs, Reflow (пусть меня поправят, если я что-то упустил) не требуют никаких "библиотечек для модулей". Только бандл проекта, использующего RequireJS требует библиотеку, имплементирующую AMD, например Almond (это всего 1К оверхеда), и то, даже с этим древним бандлером можно воспользоваться не менее древним AMD Clean. Ваши знания явно немного устарели.

This comment wasn’t rated yet0
Хотело бы добавить по пункту 4 и 5.

Паттерн «модуль» и паттерн «открытия модуля» однозначно стоит применять. Но на мой взгляд нужно возвращать не инстанс модуля, а конструктор модуля. Это позволит из внешнего кода создать инстанс модуля самостоятельно и пробросить в функцию конструктор модуля нужные параметры или зависимости. Сконфигурировать модуль под место его работы.

Таким образом можно использовать несколько экземпляров одного модуля на странице и каждый настроить на свой вкус.
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Articles

Show the best of all time
Change theme settings

Your account

Sections

Information

Services

Support
© 2006–2024, Habr