Каковы плюсы и минусы Asset-Pipeline/Turbolinks от Rails 4 для большого приложения? [закрытый]

мы работаем над довольно большим и широким применением. На сайте есть много различных разделов с различными требованиями пользовательского интерфейса и поведения.

заглядывая в будущее, Rails 4 разделил конвейер активов на отдельный драгоценный камень, чтобы мы могли включить его или нет. То же самое может случиться с turbolinks.

вопрос, который я продолжаю задавать себе в эти дни и не могу найти ответ: должен ли я использовать библиотеки тезисов в наших проект или нет ?

основными проблемами в моем отражении является тот факт, что стратегия "все-в-одном", вероятно, не будет работать, и нам придется использовать пакеты файлов в разных частях приложения. Как turbolinks будет реагировать с этим, потому что он должен предположить, что все js/css уже загружены ? Имеет ли преимущества такой конфигурации преодолеть сложности код подразумевает как производство и turbolinks ?

Я не ожидаю ответа "Да / Нет", просто некоторые мнения по этому поводу.

2 ответов


оба являются допустимыми инструментами, которые не обязательно отменяют друг друга.

Turbolinks: позволяет загружать только тело страницы, тем самым заставляя ее работать как запрос AJAX (примером такого поведения будет тот, который имеет Facebook).

плюсы:

  • пропускает задачу браузера полного рендеринга новой страницы, тем самым устраняя время "пустой страницы", когда браузер не отвечает.
  • связан с предыдущим: в случае, если вы имея поведение, которое может повлиять на загрузку новой страницы, например, скажем, воспроизведение песни, turbolinks не повлияет на нее (см. soundcloud next).
  • не перезагружает голову документа, поэтому не загружает одни и те же теги/содержимое дважды (если оно одно и то же).
  • позволяет по-прежнему кэшировать содержимое представления на стороне сервера.

недостатки:

  • перетаскивание, если теги заголовков действительно нужно обновить (новые JS-файлы, новые css-файлы, обновление метатегов...)
  • если вы хотите использовать рендеринг на стороне клиента, это просто не инструмент для него.
  • поведение по умолчанию для отключения поведения просто болезненно (используя классы css для отключения тегов привязки внутри раздела? это просто отстой).

на самом деле это вопрос о том, что такое архитектура вашего приложения, на что оно нацелено.

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


давайте начнем с сообщения о недостатках:http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html

Если это не проблема для вас: http://geekmonkey.org/2012/09/introducing-turbolinks-for-rails-4-0/

чтобы обернуть вещи: Turbolinks улучшит загрузку вашей страницы существенно, если ваши страницы используют JavaScript и CSS-стилей. PJAX пригодится, когда производительность на стороне сервера вопрос.

  • надеюсь, что это помогает :)