Оу, очень круто и хитро. Спасибо! Жаль, что при изменении ширины окна для IE это не работает. Если у вас есть аккаунт на гитхабе, напишите мне в личку — я упомяну вас в фиксе.
Подключать SVG как внешний файл — не очень хорошая идея, потому что у Blink были проблемы с таким подключением. В целях кеширования мы хотели сначала сделать подключение через js (который будет вставлять строку со спрайтом в документ), но передумали. Потому что оверхед на получение файла со спрайтом может быть больше, чем вес самого спрайта. В таком случае иконки будут показаны не сразу. В конце-концов, сотня килобайт — пустяки по сравнению с растровой графикой.
Иконки импортируются в виде модуля в приложение, у этого модуля есть свойство-строка со спрайтом внутри, который нужно отрендерить на странице и хелпер для рендеринга отдельных иконок.
Тут, конечно, больше дело вкуса. В первой итерации мы сделали минимально необходимые вещи, в будущем набор regular все равно будет. Потому что каким бы легким не был легкий набор, он не во всех случаях подходит.
Я пока еще не смог придумать нормальный фоллбек: важны масштабируемость и смена цвета — ради них все и делается. Но я экспериментирую в этом направлении, возможно, что-то получится. Или не получится.
Рендеринг страницы на сервере — это то, что мы делали очень долгое время с помощью Perl, Python, Ruby, PHP и т. д. В одностраничных же приложениях рендеринг часто происходит прямо на клиенте, от сервера поступают только данные через API (чаще всего JSON). Потому что такие интерфейсы работают быстро, и пользователь получает примерно такие же впечатления, как от десктопного приложения. Но с таким подходом появляются две проблемы: 1) скорость первичной загрузки; 2) индексирование поисковиками.
Скорость первичной загрузки теряется от увеличения количества запросов — нужно запросить еще несколько раз данные с сервера через API. А с индексированием у поисковиков тоже проблемы — они еще не научились индексировать js (гугл вот только недавно анонсировал такую фичу.)
Эти две проблемы решаются рендерингом страницы на сервере. Но тогда другая — дублирование кода на клиенте и на сервере, и вот тут решения, умеющие и то, и другое, приходят на помощь. Ведь никому не хочется писать два раза одно и то же =) React позволяет писать один код для сервера и клиента, еще в этом могут помочь фреймворки MeteorJS.
Посмотреть, как это примерно выглядит на живом проекте, можно в исходниках демо-сайта:
github.com/outpunk/evil-icons/blob/gh-pages/Gulpfile.coffee#L32
github.com/outpunk/evil-icons/blob/gh-pages/Gulpfile.coffee#L47
github.com/outpunk/evil-icons/blob/gh-pages/src/index.jade#L55
github.com/outpunk/evil-icons/blob/gh-pages/src/index.jade#L105
Для любого проекта на ноде это делается примерно так же.
Скорость первичной загрузки теряется от увеличения количества запросов — нужно запросить еще несколько раз данные с сервера через API. А с индексированием у поисковиков тоже проблемы — они еще не научились индексировать js (гугл вот только недавно анонсировал такую фичу.)
Эти две проблемы решаются рендерингом страницы на сервере. Но тогда другая — дублирование кода на клиенте и на сервере, и вот тут решения, умеющие и то, и другое, приходят на помощь. Ведь никому не хочется писать два раза одно и то же =) React позволяет писать один код для сервера и клиента, еще в этом могут помочь фреймворки MeteorJS.