Jakie są plusy i minusy Asset-Pipeline/Turbolinks z Rails 4 dla dużej aplikacji?

Question

Pracujemy nad dość dużą i szeroką aplikacją. Strona internetowa będzie miała wiele różnych sekcji z bardzo różnymi wymaganiami i zachowaniami interfejsu użytkownika.

Patrząc w przyszłość, Rails 4 oddzielił potok zasobów w oddzielny klejnot, abyśmy mogli go uwzględnić lub nie. To samo może się zdarzyć z turbolinkami.

Pytanie, które ostatnio sobie zadaję i nie mogę znaleźć odpowiedzi brzmi: czy powinienem korzystać z tych bibliotek w naszym projekcie, czy nie?

Głównymi problemami w mojej refleksji jest to, że strategia plików typu "wszystko w jednym" prawdopodobnie nie będzie działać i będziemy musieli używać pakietów plików w różnych częściach aplikacji. Jak to reaguje z turbolinkami, ponieważ musi założyć, że wszystkie js/css są już załadowane? Czy zalety takiej konfiguracji przezwyciężą złożoność kodu wynikającą zarówno z rurociągu, jak i turbolinków?

Nie oczekuję odpowiedzi Tak/Nie, tylko niektóre opinie na ten temat.

Answer 1

Oba są ważne narzędzia, które niekoniecznie wzajemnie się znoszą.

Turbolinks: Umożliwia załadowanie tylko części strony, dzięki czemu działa jako żądanie AJAX (przykładem takiego zachowania może być to, że Facebook ma).

Zalety:

• pomija zadanie przeglądarki w pełni trójwymiarowa nową stronę, eliminując w ten sposób „Pusta strona” czas, w którym przeglądarka nie odpowiada.
• Powiązanie z poprzednim: W przypadku zachowania, które może zostać zakłócone przez ładowanie nowej strony, np. Odtwarzanie utworu, turbolinki nie będą miały na nie wpływu (patrz dalej: soundcloud).
• Nie ponownie ładuje nagłówka dokumentu, dlatego nie ładuje tych samych tagów/treści dwukrotnie (jeśli jest taki sam).
• Umożliwia ci nadal buforować zawartość widoku po stronie serwera.

Wady:

• przeciąganie jeśli znaczniki nagłówka naprawdę muszą być odnowione (nowe pliki JS nowe pliki CSS, metatagi aktualizacji ...)
• Jeśli chcesz użyć po stronie klienta renderowanie widoku, to po prostu nie jest na to narzędzie.
• Zachowanie domyślne w celu wyłączenia zachowania jest po prostu bolesne (używanie klas css do wyłączania znaczników zakotwiczenia w sekcji - to jest po prostu do bani).

To właściwie pytanie o to, jaka jest architektura Twojej aplikacji, na co ją kieruje.

Jeśli chodzi o potok zasobów, to miałem z nim mieszane wyniki, mimo że powiedziałbym, że ma więcej zalet niż wad. Ogólnie rzecz biorąc, narzędzia do wstępnego przetwarzania zwiększają produktywność w różnych przeglądarkach, ale nie polegają na nich w produkcji. Ale w przypadku potokowania zasobów, musi to zrobić z tym, czego potrzebujesz. Możesz wstępnie przetworzyć SASS, Coffeescript, masz świetne biblioteki, takie jak kompas lub bourbon, ale może to również zwiększyć obciążenie związane z wydajnością. Warto więc go porównać i sprawdzić, czy powinny to być narzędzia dla ciebie.

Answer 2

Zacznijmy poście o wady: http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html

Jeśli nie jest to problem dla ciebie: http://geekmonkey.org/2012/09/introducing-turbolinks-for-rails-4-0/

Aby zawijać rzeczy: Turbolinks poprawi strona załadowała znacząco jeśli strony udostępniają style JavaScript i CSS. PJAX przydaje się, gdy wydajność po stronie serwera jest problemem.

• Nadzieja to pomaga :)