Задать вопрос
Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (3)

Наибольший вклад в теги

Все теги (23)

Лучшие ответы пользователя

Все ответы (42)
  • На что лучше перейти на Angular, React, Vue?

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

    Рассмотрим упомянутые варианты...

    AngularJS. JS. Он пляшет от шаблонов. В этом его сила (заверстали страницу, добавили директив и готово) и слабость (динамическое формирование страниц, как вы заметили, даётся с большим трудом). Криво реализованное двустороннее связывание и обнаружение изменений приводит к странным костылям и тормозам.

    Angular. TS. Опять же пляшет от шаблонов. Но внутрення архитектура улучшилась. С одной стороны она стала ещё сложнее, с другой - гибче. Динамику реализовать в нём проще, но придётся поломать голову ковыряясь в абстракциях. "Проталкивающая" модель реактивности не очень удобная и эффективная, но жить можно.

    Vue. JS. По уму сделанный AngularJS. Довольно практичный (если не пытаться прикручивать TS) с приятной "затягивающей" реактивностью. Из трендовых фреймворков я бы обратил внимание именно на него.

    React based. JS. Сам реакт - не более чем библиотека для рендеринга. Так что под его лейблом подразумевается на самом деле "мы написали свой фреймворк, в котором рендерим через реакт". Достаточно легко в нём реализуется динамика. Но с переиспользуемостью кода и его лаконичностью - просто беда. Куча копипасты во имя великой идеи с глобальным состоянием - типичная ситуация. Каждый такой фреймворк по своему уникален, так что "знание реакта" мало чем помогает при вхождении в проект.

    Polymer. JS. Попытка воспользоваться самыми последними стандартами. Всё крутится вокруг DOM, что весьма не эффективно. Реактивности как таковой нет. Спека ShadowDOM имеет уже вторую версию и та весьма ограниченна и требует костыльных костылей и вытягивания гланд через анус при использовании. Динамика с одной стороны отличная - рендерите что угодно куда угодно и динамически всё подгружается. Но без "вулканизации" вся эта динамика дико тупит, поэтому всё-равно всё объединяют в один бандл.

    $mol. TS. Полностью динамичен и ленив. Что угодно может быть динамически загружено, но в этом нет необходимости, так как компоненты получаются крайне компактными, а в бандл тянется лишь то, что реально используется. Рендерит тоже по возможности лениво, что позволяет быстро показать даже очень большую страницу. Имеет стандартную библиотеку компонент. В качестве примера, могу привести визуальный редактор компонент, который динамически строится по его коду и тут же в рантайме этот компонент изменяет (он ещё в разработке, но уже много чего позволяет): mol.js.org/#demo=mol_app_hello/edit/path

    К тем вариантам, что "JS", разумеется можно прикрутить сбоку и TS, но очень ограниченно:
    1. Будет много кода с декларациями типов и мало выведения типов.
    2. Практичная с точки зрения JS магия вырождается в весьма непрактичную борьбу с типизацией.
    3. Многие библиотеки/плагины/компоненты написаны на JS. В лучшем случае вы сможете своими силами написать для них типы.
    Итого:
    1. Под вашу задау идеально подходит $mol, но он далеко не в тренде (80 звёзд на гитхабе, ага). На нём можно быстро разрабатывать приложения, но сложно найти работу. Если есть желание, то мы ищем разработчиков от стажёров до сеньёров.
    2. Из востребованного сейчас на рынке: AngularJS, React*. Мой прогноз - скоро реакт выйдет из моды. Многие уже обожглись на нём, нафигачив горы говнокода, и переползают на более практичный Vue.
    3. Для устройства в Я имеет смысл изучать BEMJS (тогда точно возьмут :-D) или что-то трендовое типа React или Vue ну и VanillaJS нужно знать обязательно. Я сам в нём 2 раза работал, но как видите самореализоваться там не смог.
    4. Так как сроки у вас поджимают, то переписывать проект уже поздно. Так что лучше подумать о типичных костылях: CDN, нескучная анимация загрузки, агрессивное кеширование. Тем не менее по скорости разработки я бы отсортировал решения в следующем порядке (от быстрой к медленной): $mol, Vue, Angular, Polymer, React*
    5. Производительность и размер приложений на упомянутых фреймворках можете сравнить тут: mol.js.org/app/bench/#bench=https%3A%2F%2Feigenmet...
    6. Так как у вас энтерпрайз, то выбирать стоило бы из фреймворков, предоставляющих свою библиотеку высокоуровневых компонент (ExtJS,OpenUI5,KendoUI,VCL.JS,$mol). Энтерпрайзу обычно скорость разработки, богатство и единообразие функциональности важнее кастомных дизайнерских изысков на каждом экране.
    7. Для разработки более-менее крупных поектов имеет смысл брать фреймворки написанные с использованием статической типизации, тогда вы получите от типизации больше преимуществ и меньше боли. Их пока ещё не очень много: Angular (TS/Dart), $mol (TS), CycleJS (TS), VCL.JS (TS)...
    8. Джуниору лучше не заниматься созданием нового фреймвора (даже на Реакте), ничем хорошим это не закончится. Тут нужен опыт, чутьё и рациональность. Не у каждого сеньёра это всё есть.
    9. IE10 - это боль и страдания. Вы профилировали, на что именно уходит больше всего времени (загрузка, инициализация приложения, загрузка данных рендеринг)? Возможно стоит уменьшить объём единовременно отображаемых данных или подумать о серверном рендеринге ангуляровских шаблонов.
    Ответ написан
  • Есть ли смысл подписывать REST API запросы?

    @vintage
    Кука - это тоже access_token, только подставляемый браузером автоматически, даже если запрос инициирует не ваша страница, а страница левого сайта. Соответственно, при пробрасывании токена через куки, сторонний сайт сможет делать запросы к вашему, от имени пользователя. Нужно ли такое разрешать - вы решаете сами. Если нужно - просто используйте куки. Если не нужно, то самое простое - с запросом посылать взятый из куки токен в хедере, а на сервере сверять их идентичность. Получить куки скриптом можно лишь с того же сайта, кто их поставил. В урле токен лучше не посылать, чтобы он не светился в логах.
    Ответ написан
    2 комментария
  • При подобном подходе всегда использовать bind?

    @vintage
    Используйте стрелочные функции:

    router.get('/', ( ...args )=> index.mainPage( ...args ) );
    Ответ написан
    Комментировать
  • Как исказить div таким образом?

    @vintage
    Ответ написан
    Комментировать
  • На что переехать с knockout.js и стоит ли?

    @vintage
    Observables так или иначе будут везде. Так что поменяете шило на мыло.

    React вы не сможете адекватно встроить в уже готовый HTML.
    Angular превратит вашу простую задачу в звездолёт.
    Vue сможет встроиться в ваш HTML так же легко, как и Knockout. Там те же observables и computed, разве что вместо this.foo( val ) вы будете писать this.foo = val, а все computed нужно будет объявлять отдельно.

    Но если всё же соберётесь сделать SPA, то я бы рекомендовал наш велосипед: https://github.com/eigenmethod/mol
    Ответ написан
    3 комментария

Лучшие вопросы пользователя

Все вопросы (2)