Tomek napisał kilka (ekhem kilkanaście) słów o tym dlaczego stosowanie Marionette ma sens.
http://blog.netguru.co/post/57690641427/marionette-js-and-backbone-a-perfect-match
Przepraszam za hejterzenie, ale jak widzę marionette, to zawsze się zastanawiam po co spinać backbone’a z jakimiś dodatkami, żeby uzyskać framework zbliżony bardziej do embera czy angulara, zamiast po prostu użyć jednego z wymienionych. Rozumiem, że w tekście nacisk jest na refactoring z istniejącej aplikacji backbone, więc to trochę co innego, ale mam nadzieję, że ludzie to czytający nie stwierdzą przez to, że backbone nadaje się do pisania dużych aplikacji 
Za wąski jestem z frameworków javascriptowych, ale Ryan Bigg zrobił frontend do Spree z użyciem Backbone i Marionette: https://github.com/radar/spree-marionette
Aczkolwiek mi też to pachnie tym czym Padrino, czyli robieniem z Sinatry alternatywnych Railsów
O, nie widziałem tego. Będę musiał przejrzeć, bo nie widziałem fajnych realnych przykładów użycia backbone + marionette.
Nie wiem jak Angular i Ember (nie miałem z nimi doświadczenia), ale Marionette umożliwia utworzenie fajnej struktury składającej się ze współpracujących ze sobą modułów / mini aplikacji.
Jakby co zapraszam na PRUG’a kolejnego - bedzie prezka o Marionette https://www.facebook.com/events/611008398933078/
Btw. tutaj jest fajna prezentacja z BackboneConf 2013 o tym jak nalezy budowac duze aplikacje w oparciu o Backbone’a - http://www.youtube.com/watch?v=qWr7x9wk6_c
Nie zgodzę się. Marionette nastawiony jest przede wszystkim na rozwinięcie widoków i usunięcie setek linijek powtarzalnego kodu. Pisząc coś większego w czystym Backbonie wymyślasz koło na nowo. Dodatkowo wprowadza pojęcie modułu, ułatwia zarządzanie dużymi aplikacjami i tworzenie sub-aplikacji.
Angular czy Ember to całkiem inna bajka i Marionette nie idzie w tym kierunku. Tak naprawdę Marionette to kilka dodatkowych klas dziedziczących po Backbone.View + narzędzie do zarządzania modułami. To nie jest żadna magia. Pisząc dużą aplikację w Backbonie każdy i tak robi to samo, więc po co powtarzac?
Czysty Backbone to nawet nie jest framework, tylko bardzo prosta biblioteczka, której wiele brakuje. Cały kod można bez problemu przeczytać ze zrozumieniem (http://backbonejs.org/docs/backbone.html). Brakuje tam masy rzeczy.
Np: w backbonie jest mapa “event” bindująca eventy z DOM. Ale czemu nie ma takiej samej mapy dla eventów modelu? Po co pisać masę kodu typu this.listenTo(this.model,’…’) skoro można użyć analogicznej struktury? Czemu w backbonie nie można mieć wielu callbacków do jednego eventu? I najważniejsze, 90% prostych widoków w Backbone zawiera ten sam kod. W initialize wywołujemy render, w render kompilujemy template i wrzucamy do HTML.
W swoim kodzie Backbonowym wcześniej omijałem to pisząc własną klasę widoku dziedziczącą po Backbone.View - tutaj dziesiątki ludzi z community robi to za mnie.
Marionette wprowadza kilka rodzajów widoków (kolekcji, encji, composite, layouty, regiony), które porządkują dużo burdelu w kodzie. Czytając nieznaną aplikację Marionette na pewno łatwiej się połapać w kodzie. W Backbonie nie ma jedynej słusznej drogi i każdy robi po swojemu. Tutaj ta ścieżka jest wyraźniejsza i uważam to za wielki plus. Zmiany nie są rewolucyjne, a ewolucyjne.
Jeśli nie wszystko w Marionette się podoba, to zawsze można używać część funkcjonalności (np. same widoki bez kontrolerów i paru innych bajerów).
Gorąco polecam Marionette ludziom, którzy bardzo dobrze znają Backbonea - na pewno złapią ideę i zobaczą rozwiązanie problemów, które nieraz sami spotkali. Dla ludzi całkowicie nie znających Backbone może przytłoczyć, ponieważ nie znają problemów aplikacji Backbonowych.
[quote=gogiel]Nie zgodzę się. Marionette nastawiony jest przede wszystkim na rozwinięcie widoków i usunięcie setek linijek powtarzalnego kodu. Pisząc coś większego w czystym Backbonie wymyślasz koło na nowo. Dodatkowo wprowadza pojęcie modułu, ułatwia zarządzanie dużymi aplikacjami i tworzenie sub-aplikacji.
Angular czy Ember to całkiem inna bajka i Marionette nie idzie w tym kierunku. Tak naprawdę Marionette to kilka dodatkowych klas dziedziczących po Backbone.View + narzędzie do zarządzania modułami. To nie jest żadna magia. Pisząc dużą aplikację w Backbonie każdy i tak robi to samo, więc po co powtarzac?
Czysty Backbone to nawet nie jest framework, tylko bardzo prosta biblioteczka, której wiele brakuje. Cały kod można bez problemu przeczytać ze zrozumieniem (http://backbonejs.org/docs/backbone.html). Brakuje tam masy rzeczy.[/quote]
s/backbone/sinatra
s/marionette/padrino
s/ember/rails
[quote=Tomash][quote=gogiel]Nie zgodzę się. Marionette nastawiony jest przede wszystkim na rozwinięcie widoków i usunięcie setek linijek powtarzalnego kodu. Pisząc coś większego w czystym Backbonie wymyślasz koło na nowo. Dodatkowo wprowadza pojęcie modułu, ułatwia zarządzanie dużymi aplikacjami i tworzenie sub-aplikacji.
Angular czy Ember to całkiem inna bajka i Marionette nie idzie w tym kierunku. Tak naprawdę Marionette to kilka dodatkowych klas dziedziczących po Backbone.View + narzędzie do zarządzania modułami. To nie jest żadna magia. Pisząc dużą aplikację w Backbonie każdy i tak robi to samo, więc po co powtarzac?
Czysty Backbone to nawet nie jest framework, tylko bardzo prosta biblioteczka, której wiele brakuje. Cały kod można bez problemu przeczytać ze zrozumieniem (http://backbonejs.org/docs/backbone.html). Brakuje tam masy rzeczy.[/quote]
s/backbone/sinatra
s/marionette/padrino
s/ember/rails
;)[/quote]
Gdzie w tym wszystkim Angular.js? :<
E, no bez przesady Mi się angular średnio podoba z wielu względów, ale pomimo tego, to jest bardzo dobry framework i jeżeli miałbym wybierać pomiędzy backbone+marionette, a angularem, to bym wybrał angulara.
Dodatkowo, oba frameworki są dosyć młode, szczególnie jeżeli liczyć czas we w miarę stabilnym stanie ;), i cały czas istnieją różne rzeczy, które powinny być proste do zrobienia, a niestety nie są. Np. w tym “cage matchu” Tom się trochę pastwi nad przedstawicielem angulara: http://vimeo.com/68215606, a z kolei Ember.js nie doczekał się jeszcze sensownej obsługi animacji - jest to do zrobienia, ale powinno być out of the box.
No właśnie o tym mówię Ludzie w pewnym momencie zaczęli masowo używać backbone’a nie zastanawiając się gdzie pasuje, a gdzie nie do końca i po dłuższym czasie okazało się, że przy większych aplikacjach nie jest różowo. No więc ktoś napisał marionette, ktoś inny napisał http://thoraxjs.org, wydaje mi się, że widziałem jeszcze jedno rozwiązanie tego typu.
Do tego dochodzą też mniejsze pluginy, które też prawdopodobnie przydadzą się przy budowaniu dużej aplikacji.
Ja po prostu wolę jedno rozwiązanie, które od początku jest budowane z założeniem rozwiązywania tego problemu. Ember.js rozwijał się co prawda do tej pory dosyć dynamicznie i dlatego nie polecałem go na lewo i prawo i kompletnie rozumiem to, że ludzie nie brali pod uwagę jego użycia. Teraz sytuacja się zmieniła, od kilku miesięcy nie ma prawie żadnych niekompatybilnych wstecznie zmian, zaczyna się pojawiać więcej materiałów do nauki.
Struktura to dobra rzecz. Nie mam za dużo wspólnego z Backbone (bardziej lubię Angular.js) ale widziałem już sporo złego kodu w nim napisanego, właśnie kiedy niedoświadczony programista, który jeszcze uczy się Backbone nie stosuje ‘dobrych praktyk’. Marionette wygląda bardzo pomocnie.
Z mojej strony tylko taka uwaga coby nie stawiać Backbone, Angulara i Embera obok siebie bo to naprawdę 3 różne frameworki, kładące nacisk na rozwiązywanie innych problemów.
To prawda, że te 3 frameworki kładą nacisk na rozwiązywanie różnych problemów, ale wszystkie są wykorzystywane do budowania aplikacji. Dlatego jestem za tym, żeby robić jak najwięcej porównań, szczególnie jeżeli są to porównania w kontekście jakiegoś konkretnego przypadku, na przykład, właśnie wspomnianego tworzenia pełnych aplikacji.