• Пора ли увольняться?
    +4
    Не бывает «некуда уходить». Бывает только «страшно». Просто начинайте смело работать над своим желанием лучшего. Заставьте себя хотеть перемен. Убедите себя в том, что иного выхода, кроме как двигаться вперед у вас тупо нет. Прямо так – или я тут в конце концов сопьюсь (утрированно), или я стану крутым парнем из столицы. Никто, вообще никто не держит вас на месте, кроме вас самих. Поймите это, и все потихонечку начнет двигаться.

    Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
  • 42 строки кода для выхода из лимба
    0
    Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.

    Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
  • 42 строки кода для выхода из лимба
    0
    Спасибо, сработали суеверия. Вы совершенно правы. Подправил, обновил.
  • 42 строки кода для выхода из лимба
    0
    Если у вас есть событие «Aa» и событие «a», то это два разных события.
  • 42 строки кода для выхода из лимба
    0
    Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.

    С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
  • 42 строки кода для выхода из лимба
    0
    Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).

    У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Извините, Борис

    Но я никак не могу понять, что вы хотите сказать/доказать?

    • Что react знает больше людей? Очевидно.
    • Что я покусился на святое? Я уже ответил Вам ниже, что никто react «уделывать» не собирается.
    • Что react и подобное нужно использовать везде (даже в до безобразия маленьких проектах)? Весьма и весьма спорный тезис.
    • Что не нужно / нельзя / запрещено искать собственные решения для тех или иных задач? А как же тогда тот же react на свет появился? До него, что не было альтернатив? А как быть с нашим Яндексом? Уж сколько он «пилит» своих решений. Он тоже плохой?
    • Или может вы считаете, что если некий проект сделан на react, то его с ходу «прочитает» любой сторонний разработчик? Да, нет. Все также придется какое-то время сидеть и разбираться, что к чему.


    Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.

    Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.

    То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.

    Спасибо.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Спасибо
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    +1
    У меня, конечно, то еще самомнение, но в одиночку противопоставлять себя замечательным, талантливым и умным ребятам, создавшим react?

    Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.

    Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.

    Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.

    Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.

    Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.

    Спасибо за ваш вопрос и ваше время на эксперимент )

  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Ну на самом деле – это верный подход. Должны быть некие свойства/характеристики, которые отличают продукт от его конкурентов/аналогов.

    Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.

    Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:

    • Избегание дополнительного окружения (библиотек, тулзов и прочего). Полная самодостаточность и возможность расширения функционала внутри решения со стороны разработчика. Это уже во многом реализовано. Flex.Patterns легко позволяет добавлять свой функционал к тому, что уже есть. Скажем вы «прицепились» к узлу, Flex.Patterns даст вам основной набор инструментов (ну там события прицепить, размеры снять, стили переопределить, анимацию применить и прочее). Но на ряду с этим у вас есть простой интерфейс для добавления своих инструментов к данному функционалу и, что очень важно, интегрировать эти вот свои инструменты внутрь Flex.Patterns – то есть делать свою собственную сборку конечного продукта.
    • Только стандартный синтаксис. Ну об этом я уже очень много говорил.
    • Хранение шаблонов и их ресурсов на клиенте.


    Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.

    Спасибо за ваш вопрос.

  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    спасибо
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Спасибо, исправил.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    +1
    Я бы не был столь категоричен. Да и нет здесь предмета спора.

    Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».

    Поэтому если приходит заказчик и мы видим, что он сам еще толком не знает на какой именно результат ему рассчитывать, до конца не понимает (а порой и не верит) в успех своего проекта – да, мы настоятельно рекомендуем делать проще (не в ущерб бизнес-модели), чтобы как минимум посмотреть, пощупать и понять, как оно там будет. И чаще всего заказчик с нами соглашается.

    Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
  • Front-end шаблонизатор
    0
    Спасибо, обязательно посмотрю.
  • Front-end шаблонизатор
    0
    Спасибо за ваш комментарий.

    Чуть выше в комментарии я рассказал с чего все началось (как этот шаблонизатор был выделен в отдельное решение). Оба тех проекта, где всецело применено это решение – это админки. То есть по существу – это одинаковый набор элементов управления, где разница есть в их компоновке и данных. В такой ситуации перенос представлений на клиента дал хороший результат. Первая загрузка подольше будет, зато вторая и последующие ощутимо шустрее. В свою очередь разбиение разметки на компоненты дало возможность их отладки в отрыве от приложения, что было очень удобным. Кроме того, после реализации первого проекта к началу работы над вторым уже была хорошая коллекция контролов, которые просто брали и использовали.

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

    Требования к мобильным устройствам в данных проектах практически не выставлялись, хотя и на них работает (но не тестировалось так глубоко и основательно, как десктоп).
  • Front-end шаблонизатор
    0
    Спасибо всем за радужный прием)

    Из всего спектра комментариев лишь одно дельное замечание, про экранирование (упущенное из виду). Спасибо.
    На все остальное (там, где я проигнорировал) я могу ответить парой абзацев, потому как обсуждать, например, то, как проект выложен на github’е я смысла не вижу.

    Я писал свое решение, не потому что других решений не существует, а потому что хотел разобраться как это работает. Для меня это здоровая (от слова здоровье) мотивация разработчика. И если собственник проекта не против экспериментов, то для программиста – это находка и глупость упускать подобный шанс; шанс понять, как оно работает изнутри; шанс проверить себя – смогу / не смогу сделать работящее самостоятельное решение. Не пригодится в будущем? Возможно. Кому-то не понравится? Конечно! Но, хвала Зевсу, для меня это не главное и практически не важно.

    Видимо часть людей просто стала забывать, что разработка – это прежде всего творчество, искусство, возможность дать своей мысли форму. По крайне мере для меня – это именно так и именно по этой причине я пришел в эту профессию. Поэтому что я могу сказать? «Велосипедил» и буду «велосипедить» дальше, даже несмотря на то, что рядом лежит ReactJS, AngularJS, Jade, EJS и прочие тысячи инструментов.

    Еще раз спасибо за Ваше время.

  • Front-end шаблонизатор
    0
    Спасибо за комментарий. На это уйдет какое-то время, чтобы создать сопоставимые и наглядные примеры и «красиво привинтить» их к документации. Думаю, что неделя или две и я что-то подобное выложу.
  • Front-end шаблонизатор
    –2
    Спасибо за комментарий.
    Потому что тег TEMPLATE часть стандарта, а мне не хотелось свое «нестандартное» решение смешивать со стандартами. Однако в patterns предусмотрена простая возможность переопределения корневого тега шаблона.

  • Front-end шаблонизатор
    0
    Спасибо )
  • Front-end шаблонизатор
    +1
    Спасибо за ссылку. Почитал, очень интересно. У нас с вами разное целеполагание. У вас более глобально, что ли. У меня же все приземленно )). Моя задача была – шаблонизатор только для front-end.

    Да, есть возможность вставки шаблонов в HTML, но опять же и сборка шаблона, и вся работа по его анализу – все на клиенте.

    Кроме того, все началось с простой и банальной задачи. Я опишу, если позволите. Было приложение, со множеством разных «окошек» (админка в общем). И там была куча разных контролов. Почти все создавалось на серверной стороне. Потом пришла в голову мысль – а не перенести ли нам все это на клиента – нехай он сам парится, а на сервере все почистить, минимизировать и в идеале оставить только API. Посчитали количество контролов, вышли на несколько десятков очень простых элементов, которые могут работать автономно (то есть не зависят от какой-либо библиотеки и/или фреймвока). Тогда и пришла в голову мысль, а не распихать ли эти контролы по папочкам с JS и CSS, которые к ним относятся. Ну а на клиенте просто их подключать по мере необходимости.

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

    Потом была еще пара подобных проектов, где перенос представлений на клиента прошел довольно успешно.

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

    Иными словами, вот эта штука, которую я тут на ваш суд выставил – это такой инструмент, который позволяет представления вытаскивать с back-end на front-end. И главное, это позволяет проводить отладку каждого шаблона в отрыве от всего проекта. И такого рода инструмент он не универсален, безусловно, он для определенного круга задач.
  • Front-end шаблонизатор
    –10
    Поясните, пожалуйста, зачем выкладывать «расковырянную» версию и почему то, что лежит сейчас на github нереальные исходники? )

    Просто я искренне полагал (и полагаю), что рабочий «мусор» на паблике ни к чему. Есть файл, есть история с которой видны изменения ну и так далее.

    Если вам интересен какой-то отдельный модуль, то просто сверните код до второго уровня вложенности и вы увидите все девять модулей по отдельности. Да и станет очевидным то, как все это собирается.
  • Front-end шаблонизатор
    –3
    Если посмотреть на код и свернуть блоки до 2-ой вложенности, то вы увидите 9-ть независимых друг от друга модулей (в том смысле, независимых, что они могут существовать отдельно). То что вы видите на github, да и на промо сайте — это уже результирующий файл.
  • Front-end шаблонизатор
    –1
    Спасибо за комментарий. Я думаю, что сравнивать этот шаблонизатор с React нельзя — разные масштабы, да и React — это не шаблонизатор. Ну а то что сделал я — это для очень узкого круга задач — фактически это просто инструмент для создания не слишком сложных UI компонентов (по крайне мере я его так применяю). У React спект применения значительно, значительно шире.
    Для меня (я могу судить только по себе :)) главное приимущество: это возможность открывать шаблоны в отрыве от проекта, отлаживать их, править стили. Мне это удобно. Даже если компонент стал сложный, с логикой какой-то, то на создание тестовой страницы (что бы открыть его отдельно) уходит 3-и минуты и все, я снова могу отлаживать копмонент в отрыве от всего приложения.
  • Front-end шаблонизатор
    0
    .
  • Front-end шаблонизатор
    0
    Значит мы с вами по разному понимаем то, что есть архитектура. По мне, будь это вопрос архитектуры, я бы не добавил экранирование за 11 минут )
  • Front-end шаблонизатор
    0
    Я с вами согласен тоже, но добавил сериализацию. Пусть будет )
  • Front-end шаблонизатор
    0
    Добавлен новый параметр [serialize] в колекцию параметров метода _patterns.get(). Пока заменяет экранирует только теги. Но расширить функционал — не проблема. По умолчанию в true. Еще раз спасибо за предложение.
    ЗЫ
    Документацию обновлю позже )
  • Front-end шаблонизатор
    0
    Экранизацию я как-то из виду упустил. Но это не вопрос архитектуры. Кроме того, вы легко можете это и предотвратить средствами шаблонизатора, добавив обработчик к соответствующей модели.
    Но все равно, спасибо за хорошее критическое замечание, правда какое-то категоричное )
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Спасибо большое за комментарий.

    Я (честно) все время с момента моей публикации думаю о том, почему регистр модулей — это «зло». В том смысле, что в регистре объявляются только имена модулей и настройки кэширования – ничего больше – никаких зависимостей.

    И я не могу понять, в чем потенциальная проблема такого регистра. Вы не первый, кто обращает внимание на некую проблему, пока характеризующуюся как «хлебнете», «не используйте» и так далее.

    Я хочу, очень хочу понять в чем эта самая потенциальная проблема. И я понимаю, что регистр, где объявляются зависимости – это геморрой. Но если зависимостей в нем не объявляется?

    Не эффективно с точки зрения дополнительной сущности? Да, с этой точки зрения – однозначное да – дополнительное телодвижение только для того, чтобы «убрать» пути из объявления модулей. Но разве с этого можно «хлебнуть»?

    Изначально (пару лет назад) этот злополучный регистр как раз и содержал зависимости. То есть зависимости объявлялись не при объявлении модулей, а в регистре. И очень быстро я пришел к тому, что это крайне, крайне неудобно и неэффективно. Поэтому я оставил в регистре только и исключительно пути (ссылки на JS-файлы модулей), а также настройки кэширования. Ну и вроде как неудобств особых не испытывал в проектах до 50 модулей где-то.

    Да, регистр засорялся ненужным ссылками (в результате copy / paste с других проектов), но и чистился за пару минут.

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

    Я совершенно не исключаю, что я не прав, я даже знаю, что я ничего не знаю ))) Но очень прошу вас, развернуть ваш тезис о нависшем надо мною «хлебну» ))

    Еще раз спасибо.

    P.S.
    Я либо не выспался, либо что-то не понимаю:
    «…но не выносите зависимости из кода…»

    «Выносить зависимости из кода необходимо.»
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Честно — не погружался глубоко.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Спасибо.

    Таких больших проектов просто не встречал в практике и, честно сказать, не думал о них вовсе, работая над своим великом. Наиболее крупный, что был у меня – это где-то около 200 модулей (только JS файлы), где хоть и не использовались мои решения, но все же был единый регистр всех модулей, вынесенный в один файл. Было порядка 500 срок с описанием всяких особенностей и это было довольно удобно.

    Может быть существует некий предел, после которого архитектура и применяемые решения должны как-то учитывать масштаб системы. Конечно, для проекта, где описание модулей занимает 4 – 5 тыс. строк что-то должно быть сделано иначе.

    И еще, просто чтобы убедиться, что мы говорим об одном и том же. Под модулем я понимаю модуль без учета ресурсов. То есть модуль может запрашивать еще и какие-то ресурсы (CSS к примеру), которые не в какие регистры не вносятся, а определяются в рамках объявления модуля.

    Я видел регистр всех ресурсов для большого проекта. Да, там было, если не ошибаюсь, порядка 6 тыс. строк. Но убери оттуда все CSS и вспомогательные ресурсы (вроде сторонних библиотек JS) и количество строк сократится кратно (именно кратно, потому что многие вспомогательные ресурсы объявляются многократно для указания зависимостей одного от другого).

    flex.register.modules.js задумывался не как перечень всего и вся, а как место, где определяются «ключевые» (не знаю какое слово подобрать) модули. И никаких зависимостей, никаких ресурсов, ничего кроме просто путей к модулям в этом регистре не объявляется. Все ресурсы объявляются только на уровне объявления модуля (то есть в файле самого модуля). И с этой точки зрения для проекта с количеством модулей, скажем меньше 100, наличие единого регистра мне видится больше в позитивном свете, нежели, чем в негативном.

    Но опять же, у меня нет богатого опыта работы с огромными проектами, где только модулей тысячи. Поэтому мое мнение очень субъективно, и я это понимаю.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Пока не пробовал реализовать, но мысли такие есть )
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Хотя нет… eval.apply(window, ...) и module.call(window) далеко не тот же самый результат. faiwer, спасибо за наводку на мысль )
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Поясните, пожалуйста, что вы имеете ввиду под «ручным» управлением зависимостей? Спасибо.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Ну так у меня все еще впереди )
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Спасибо за ваш комментарий.

    Я просто отвечал на вопрос о встреченных трудностях, ну и перечислял те что встретил. eval я не использую, создав функцию через module = new Function(js_txt), я просто делаю module.call(window), что тоже самое с точки зрения результата.

    А интеграция модулей вообще идет и без function и без call, чтобы сохранить привычку браузера «править» наши рутинные ошибки. Вот здесь flex.core.js, строки 4400 — 4410 – то как интегрируются модули в систему.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Вы все верно поняли ) И предложенные вами решения верны со всех точек зрения и мало того применяются в том числе мною. Не в этом ли вся прелесть нашей профессии – во множестве решений одних и тех же задач? )

    Тут большую роль играет личная мотивация. Посмотрите мой ответ вам чуть ниже выше ).
  • JS Загрузчик + шаблонизатор или история очередного велика
    +1
    Спасибо за комментарий.

    Знаете, меня столько раз это стопорило «Все уже придумано, написано – бери и используй!». Вот упрусь в какую-нибудь дилемму и сразу подобные мысли в голову лезут.

    А потом вспоминаю, что ключевая мотивация у меня – это вопрос «а как это работает вообще?» и возвращаюсь к разработке ). Собственно, большую часть того, что можно делать в JS я узнал не из рабочих проектов (основная работа), а в процессе изобретения этого велика. Поэтому личный profit в виде опыта уже есть )

    Что же касается AngularJS или же knockoutJS, или чего-то еще, то тут дело в том, что нет «конфликта интересов» — у меня просто нет такого выбора: использовать мои решения или AngularJS или же knockoutJS. Если заказчик говорит – делай что хочешь, я вежливо его спрашиваю – не против ли он стать «полигоном» для моих собственных наработок (если я понимаю, что оно не навредит). Не против? Чудно, беру ответственность на себя. Если решение должно быть на чем-то другом – не вопрос.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Спасибо ) На счет шрифтов, мне даже такая мысль в голову не приходила ) Но это интересно, спасибо за наводку.
  • JS Загрузчик + шаблонизатор или история очередного велика
    0
    Спасибо за комментарий. И вопрос.

    Если честно, на счет «трудного» не знаю. Как только реализовано – уже и не трудное, вроде.

    Ну вот был момент, с которого «нахлебался». Разного рода артефакты встречались. «Достаешь» из localStorage что-то, а там что-то, чего быть не должно (какой-нибудь левый символ). Я не изучал что это было и не смог бы изучить, так как было это 2-3 года назад, когда опыта у меня было меньше. Но вот еще тогда принял решение ничего в первозданном виде в localStorage не хранить – все преобразуется в base64String.

    Что еще? Вот есть до сих пор не разрешенная проблема – сброс. До сих пор ломаю голову как его реализовать корректно. Суть проста. В проекте используется модули A, B, С и D. Спустя какое-то время их взяли и переименовали на _A, _B, _С и _D. С точки зрения контроллера кэша – это новые ресурсы, так что в localStorage мы получим не 4-е модуля, а 8-ь, что не хорошо. Пока проблема решена через параметр при подключении flex.core.js?v=xxx, где xxx – произвольное число (версия). Если оно не совпадет с тем, что был ранее зафиксирован на клиенте (или не был зафиксирован вовсе), то будет выполнено localStorage.clear(). Кстати по этой же причине я отказался от кэширования картинок, что ранее задумывалось в рамках хотя бы иконок. Лучше браузера это пока никто не сделает :)

    Вот другая сложность. Например, не все JS получится получить через xmlhttprequest – origin policy может быть настроена, что никак.

    Есть еще проблема куда хуже, чем те что я перечислил уже. И тоже связана с JS. Это плохой код. Например, вот забыли вы поставить где-то банально «;». В 99 случаях из 100 вы этого даже и не узнаете, потому как браузер такие вещи «подправляет» за нас (что мне лично очень не нравится). Но браузер это подправляет только если скрипт подключен обычным способом, а вот если вы из localStorage его достали и интегрировали через new Function(content), просто как пример, то вас может ожидать сюрприз – throw какого-нибудь исключения, потому как в данном случае браузер уже ничего не «подправляет» за нас.

    Или у вас есть old-school модуль, который требуется включить в проект. И этот вот модуль использует глобальные переменные. И объявляет их не как window[‘my_global_var’], а вот так var my_global_var. В результате такой модуль не будет работать корректно, потому как его интеграция будет проводится через new Function(content), то есть переменная my_global_var станет не глобальной к window, а глобальной в контексте функции.

    Еще сложно «ловить» окончание загрузки CSS файлов. Это вам лучше посмотреть в коде flex.core.js, начиная со строки 4140. Сама проблема на 4178.

    Если же говорить непосредственно о шаблонах, а не о ресурсах вроде JS и CSS, то здесь проблем не было. Были и есть проблемы со сборкой, как уже упомянутый тег table. Дело в том, что браузер не дает вам поместить, например, div в table (оно и верно), но это вас ограничивает, так как вы не можете создать временные «обертки» при сборке. В результате приходится проверять «совместимость» тегов, что несколько усложняет логику.

    Надеюсь я в верном русле понял вопрос и с пользой ответил )

    П.С.
    В целом, задача сохранения ресурсов (JS и CSS) в localStorage может быть решена безусловно, но выставляет требования к качеству самих ресурсов, особенно JS.