2010-05-29 11 views
11

Jestem na etapie planowania aplikacji internetowej i próbuję wybrać między GWT a Cappuccino. Mam pomysł, który z nich wydaje mi się lepszy, ale mój partner jest sprzedawany z innego wyboru. Miałem nadzieję uzyskać informacje zwrotne na temat zalet i wad dla każdego z ludzi, którzy używali jednego lub drugiego lub obu. Z góry dziękujemy za wszelki wgląd, jaki możesz mieć.GWT vs. Cappuccino

+3

Bez żadnych szczegółowych wymagań dotyczących projektu, którą chcesz zrobić, to rodzaj pytanie nie można odpowiedzieć. I nawet wtedy większość opinii uzyskałbyś po obu stronach płotu - każdy ma swoich faworytów. Zaleciłbym wypróbowanie obu frameworków, aby uzyskać ich "odczucie" i wybrać ten, który najlepiej pasuje do * Twojego * stylu. –

+0

Zgadzam się, że odpowiedzi na to pytanie będą jedynie opiniami lub osobistymi preferencjami, ale nadal chciałbym wiedzieć, co ludzie lubią i nie lubią w obu frameworkach. Dzięki! – James

Odpowiedz

34

Toolkit v/s Framework

GWT jest toolkit. Jego siła tkwi w narzędziach, które zapewnia tworzenie aplikacji. Nie zapewnia jednak ram. Deweloperzy zazwyczaj budują małe ramy w stosunku do GWT w zależności od ich potrzeb. Duży nacisk położono na wzór MVP do tworzenia aplikacji, ale nie jest to jedyny sposób na wykorzystanie GWT.

Cappuccino to Framework. Ma określony sposób budowania aplikacji. Dodatkowo zapewnia biblioteki do wykonywania zadań wysokiego poziomu, takich jak animacja, przeciąganie i upuszczanie cofania/ponawiania itp. GWT nie zapewnia żadnych bibliotek do takich zadań, chociaż biblioteki stron trzecich są dostępne.

Oznacza to, że aplikacje Cappuccino są bogatsze niż odpowiednie aplikacje GWT.

kompilacji Offline v/s Runtime Translation

GWT wierzy w podejmowaniu decyzji w czasie kompilacji. Wykrywanie przeglądarki, I18N, obrazowanie, generowanie ikonek, ocena szablonów uibinder są wykonywane podczas kompilacji. Deferred Binding pozwala programistom wykorzystać tę koncepcję w swoich własnych aplikacjach.

EDIT

Cappuccino, domyślnie nie wymaga kompilacji. Przeglądarka pobiera pliki object-j, a następnie framework tłumaczy/interpretuje je bezpośrednio w środowisku wykonawczym. Możliwe jest jednak compile using jake. Możesz wybierać spośród kilku minifigatorów/kompresorów, w tym google's closure compiler.

W wyniku tej decyzji architektonicznych, GWT aplikacje bywają szybciej niż w czasie wykonywania równoważnych aplikacji cappuccino.Jednak ze względu na koszt czasu kompilacji, rozwój jest wolniejszy niż Cappuccino. Wtyczka do programowania GWT nieco łagodzi ten ból, ale koszt nie znika całkowicie.

Ponieważ GWT jest kompilatorem closed-world, może usunąć nieużywany kod, wbudowane wywołania metod, strunowe łańcuchy i zoptymalizować kod w sposób, w jaki Cappuccino nie może. Jeżeli Cappuccino miałoby wprowadzić etap kompilacji, to może on dokonać tych samych optymalizacji; ale według mojej najlepszej wiedzy nie ma możliwości wykonania tłumaczenia w czasie kompilacji.

Z opcjonalnym krokiem kompilacji ten punkt staje się dyskusyjny. Jednak aplikacje cappuccino, które nie wykonują takiej kompilacji, będą miały słabą wydajność w porównaniu z aplikacją GWT.

Typ bezpieczeństwa

GWT jest Java - a zatem jest type safe. Objective J to javascript, a więc dynamicznie wpisywane. Ma to swój własny numer advantages and disadvantages, a ponieważ jest to dyskusja religijna, powstrzymam się od wydania osądu.

Debugowanie

GWT dostarcza wtyczkę do przeglądarki, która pomaga deweloperom bezpośrednio debugowania kodu Java. W trybie programistycznym programiści zobaczą ślady stosu Java. Jednak w czasie wykonywania wygenerowany kod JS jest zaciemniany i bardzo trudny do debugowania (chociaż jest sposób, aby powiedzieć GWT, "nie zamazywać mojego kodu").

Użycie super-dev-mode jest teraz możliwe do debugowania kodu Java bezpośrednio z przeglądarki internetowej.

Cappuccino nie ma trybu programowania, co oznacza, że ​​do debugowania trzeba użyć istniejących narzędzi, takich jak firebug. Błędy są zgłaszane przez przeglądarkę, a do debugowania kodu potrzebne są debuggery JS.

Unit Testing

z GWT, można napisać czyste java jednostkowych przypadków testowych, które nie wymagają przeglądarki uruchomić. Ma to oczywiste zalety - niektóre z nich to szybkość i możliwość ponownego wykorzystania istniejącej infrastruktury. Kiedy potrzebujesz przetestować przeglądarkę, możesz wybrać GWTTestCase lub HTMLUnit. Można go również testować przy użyciu Selenium.

Aplikacje do cappuccino można testować za pomocą OJTest. Niestety nie mogłem znaleźć wiele dokumentacji na ten temat, więc nie mogę wiele komentować. Oczywiście zawsze możesz użyć Selenium, aby przetestować swoją aplikację.

Współdziałanie z Javascript

GWT zapewnia sposób rozmawiać z istniejących bibliotek JS - jego nazwie Javascript Native Interface. Jest dojrzały i działa dobrze, ale nie jest tak naprawdę intuicyjny. Objective J to javascript, więc nie musisz robić nic specjalnego, aby współpracować z Javascriptem.

Vision

nie mogę wykonać kopię tego argumentu, ale GWT wydaje się skupić się na tworzeniu wysokiej wydajności aplikacji internetowych bez dbając o wygląd. Nigdy nie idą na kompromis w kwestii wydajności.Z kolei Cappuccino koncentruje się na funkcjach i strukturach wyższego poziomu oraz na kompromisach w zakresie wydajności w czasie wykonywania.

W rezultacie aplikacje Cappuccino wyglądają na bogatsze, ale wymagają trochę czasu. Aplikacje GWT ładują się i reagują szybciej, ale wyglądają na nudne. Możesz być pewien, że obydwa problemy, jestem pewien - ale to jest sposób, w jaki jest on gotowy do użycia.

Społeczność Pomoc i pokrywająca

GWT jest wspierany przez Google. Ich zaangażowanie w GWT jest dość silne. Nowsze aplikacje (Wave, Adwords, Orkut) od Google opierają się na GWT. Google IO miał kilka sesji dotyczących GWT. The user forum jest dość aktywny i elastyczny, a sam zestaw narzędzi jest aktywnie rozwijany i utrzymywany przez Google i społeczność open source. Model Cappuccino user group nie jest tak aktywny i ma znacznie mniej członków.

+0

Sri, to mnóstwo dobrych informacji! Dziękuję za porównanie! – James

+1

Świetne podsumowanie. Jednak "Tłumaczenie runtime Offline Compilation v/s" jest niepoprawne. Cappuccino zapewnia kompilator offline. Podczas opracowywania aplikacji możesz jej nie używać, aby oszczędzić sobie kroku kompilacji, a Cappuccino w przejrzysty sposób skompiluje Twój kod w środowisku wykonawczym. Przed wdrożeniem zwykle kompilowałeś się w trybie offline, zanim zminimalizujesz i uruchomisz optymalizatory, takie jak narzędzie do usuwania "martwego kodu" "spłaszcz". –

+1

W języku Cappuccino znajduje się eksperymentalna flaga bezpieczeństwa, chociaż jest to sprawdzanie w czasie wykonywania, a nie kompilacja. W tej chwili nie jest to zbyt użyteczne. –

5

Mam dużo większe doświadczenie z Cappuccino niż z GWT, ale z jego wyglądu GWT wygląda niesamowicie szybko i dość solidnie. Jest przecież wspierany przez dość dużego gracza w Internecie. Demonstracja w Google IO była imponująca. Chociaż może się to zmienić, aplikacje GWT całkowicie opuszczają Cappuccino w kurzu, jeśli chodzi o czasy ładowania i rozmiar wdrożenia.

To powiedziawszy, poszedłem z Cappuccino z dwóch powodów: po pierwsze, podczas gdy GWT jest klasycznym, wystarczająco dobrym rozwiązaniem inżynieryjnym, Cappuccino jest celowo ukierunkowane na tłum tylko "najlepszy, wystarczająco dobry". Wierzę, że dzięki Cappuccino możesz osiągnąć standard rzadko spotykany w sieci wcześniej. Nie tylko w ładne piksele, ale w surowej funkcjonalności i mocy, w której wszystko działa na poziomie "jakości pulpitu". Przeciągnij i upuść, cofnij stos, płynne przewijanie i zmiana rozmiaru, podziel okna i włączaj i wyłączaj. GWT nadrabia zaległości, co widać w Google Wave, ale ma długą drogę, a Google tradycyjnie nie interesowało się zbytnio polszczyzną. Widać to na przykład w Gmailu, który wciąż jest nie tylko szarmancko wyglądający, ale po wielu latach pozostaje w interakcji z użytkownikiem.

Drugim powodem, dla którego poszedłem z Cappuccino, jest to, że Java doprowadza mnie do szaleństwa z nieugiętym, absurdalnie pełnym i nieczytelnym stylem. Ale to może być tylko ja.

+1

poszedłeś z Objective-J z powodu absurdalnie pełnego i nieczytelnego stylu Javy? – seanmonstar

+3

Objective-J jest gadatliwy w tym sensie, że ma długie nazwy metod, Java jest gadatliwa w tym sensie, że trzeba napisać więcej linii kodu. Dla mnie to duża różnica. –

+0

Zauważam nieczytelny styl Objective-J. to jest dla mnie najważniejsze. – seanmonstar