Witam 
Po tym jak ogarnąłem więcej railsów, czas na jakiś js framwork. Zobaczyłem składnię i niby najbardziej mi pasuje AngularJS. Natomiast mam pytanie z innej beczki. Zobaczyłem dużo materiałów z przejściem na EmberJS. Dlaczego taka moda? Kolejne pytanie, które z tych frameworków jest najbardziej wpasowane w railsy, tak, żeby pisanie było proste, szybkie i wygodne ? 
Czy tylko mi się wydaje, że AngularJS pomimo popularności, nie jest tak fajnie do wbudowania w railsy, czy po prostu to moja nieznajomość bardziej tematów? Jaki wy byście użyli framework w następnym projekcie, w którym mielibyście wolną rękę ?
Pozdrawiam
Angular w ogóle nie jest fajny. Od pół roku pracuję dla firmy, która ma front-end napisany w Angularze i bardzo chcielibyśmy od tego odejść. Ja sam staram się oglądać tutoriale i czytać dokumentację, żeby pisać lepszy kod w Angularze, ale nie czuję tego, to wszystko co jest tam opisane wydaje mi się nie pasować do moich bardziej zaawansowanych problemów.
Wcześniej pracowałem kilka miesięcy z kombinacją Backbone+Marionette i dużo bardziej mi się podobało.
Nie pracowałem jeszcze zbyt wiele z Emberem, więc może ktoś inny powie więcej na ten temat. Na pewno Ember zyskał popularność wśród Railsowców ze względu na Yehudę (współtwórca Embera, który był członkiem core teamu Railsów).
No właśnie. Przeglądając oferty pracy w railsach, to więcej znalazłem wymagania Backbone’a. I znowu rozkmina: Czy ta cała popularność angulara to ze względu na nodejs?
Pouplarność Angulara to raczej efekt Google’a. Angular zaczął powstawać przed Backbonem (2009 vs 2010), ale stał się szerzej znany dopiero jakoś w 2012, kiedy Google zaangażował się w jego rozwój i promocję.
Popularność Backbone’a wśród firm railsowych wynika z tego, że zaczęły one korzystać z Backbone’a zanim pojawiły się inne frameworki, zainwestowały trochę czasu w opanowanie Backbone’a, i dalej się go trzymają.
1 Like
U nas ostatnio coraz więcej robi się w React.js i wszyscy sobie chwalą. Problem w tym że React załatwia Ci jedynie V z MVC.
React.js albo Backbone.
Angular to jest największe gówno jakie możesz wdpnąć. Nie życze pracy z aplikacjami w Angularze największym wrogom (nawet gosciowi który mnie prześladował w podstawówce). Jak chujowy jest to frejmork brak mi słów żeby opisać. Wystarczyć wam musi fakt że nawet twórcy Angulara doszli do wniosku że to jest zupełne pierdnięcie bo nawet nie rzadkie gówno, bo zabrali się za przepisywanie tego czegoś od zera w … Języku Microsoftu zwanym TypeScript który jest … Javascriptem z Typami. I shit you not. (to tak pozostając przy gównianej retoryce ale dodając odrobinę klasy przez użycie języka obcego).
Nie chciałbym tutaj wchodzić w jakies frameworkowe wojny,
każdy ma swoje preferenecje to oczywiste.
Start-up przy którym pracuje używa Angulara, aplikacja jest ładna i stabilna,
do tej pory nie mieliśmy większych problemów i nikt nie myśli o przesiadce.
AngularJS nie jest zły, zyskał na popularności przez co wielu klientów zainteresowanych budowaniem aplikacji nalega na użycie tego frameworka, nie licząc się z preferencjami programistów.
Więc według mnie warto chociaż go poznać, chociażby właśnie ze względu na wspomniany fame.
To że Google było zainteresowane projektem jest duża szansa że projekt dalej będzie wspierany, i będzie zmieniał się tylko na lepsze.
Codeschool zrobił solidny tutorial z Gregiem Pollackiem (ten typek z Rails for Zombies)
wg mnie warto chociażby przez niego przejść.
1 Like
Haha. Ja znam Angulara bardzo dobrze, robiłem na nim projekt i dwa razy robiłem ewaluację. Powiem to jeszcze raz. Wybranie Angulara jako frameworka do projektu powinno skutkować odebraniem licencji na programowanie. Niestety licencji nie ma więc takie przestępstwa uchodzą na sucho 
A nie powinny.
A tak na serio żeby mnie nie posądził ktoś że troluję. Angular ma bardzo poważne problemy strukturalne. Wiele z nich zostąło poprawionych/załatanych w wersji 1.6 z tego co kojarzę, ale nie da się niektórych naprawić bez dogłębnej reorganizacji frameworka, co twórcy planują zrobić właśnie w Angular 2. Więc inwestycja w angular w tej chwili to strata czasu i pieniędzy.
Dodatkowo i to nie jest nawet opinia Angular jest bardzo błedodajny i cięzki w nauce. Pracowałem dla firmy która wydała jakieś dobre 10 tys funtów na zrobienie filtrowalnej tabelki w Angular (czyli jakieś 50tys złotych). Nie żartuję, płacili 4ce senior developerów zeby w tym kodzili tabelkę dobry tydzień. To byli naprawdę bardzo sprytni ludzie a mieli non stop problemy ze scope’ami. Robili w tępie żółwia. Tą samą tabelkę ja bym trzasnął im w czystym JS w kilka godzin ale mi nie pozwolili.
To jaka to tabelka, skoro widząc filtrowanie danych w Angularze, nie wygląda to tak źle. Nie to żeby bronił Angulara, bo tak naprawdę żadnego z tych nowych js-MVC nie znam. Po prostu nw którego się zacząć uczyć
Patrząc na popularność pobieranych gemów, to Ember wygrywa.
Ja za to stanę w obronie Angulara i powiem, że według mnie warto przynajmniej zapoznać się z podstawami. Co prawda pracuję z Angularem dopiero 4 miesiące, ale jak dotąd nie trafiłem na problem, którego nie dałoby się rozwiązać w “logiczny” i intuicyjny sposób (być może nie trafiłem na coś zbyt zaawansowanego?)
@swistak84 trochę brakuje mi rzeczowych argumentów przeciw uczeniu się tego frameworka w twojej wypowiedzi. Jak 4 seniorów pracowało nad jedną tabelką tydzień, to albo bardzo im się nie chciało tej tabelki zrobić albo była nie wiadomo jak skomplikowana (a jak sam piszesz, w samym JSie dałbyś to radę klepnąć w kilka godzin).
Odpowiednia struktura + trzymanie się praktyk i w Angularze naprawdę da się pisać i jestem w stanie nawet powiedzieć, że można mieć z tego przyjemność. Duże community - kanały na ircu/slacku, reddit itd. i naprawdę łatwo wyeliminiować momenty, w których jest się zblokowanym przez cały dzień.
Angular obecnie (wersja stabilna) jest w wersji 1.3, 1.4 jako beta, przynajmniej bazując na www.angularjs.org a przejście na 2 wiąże się imo z wieloma ważnymi profitami. Co prawda trzeba będzie poświęcić czas na restrukturyzację projektu jeśli chce się go przepisać, ale z drugiej strony to chyba dobrze, że twórcy frameworka posłuchali community, posłuchali sami siebie i postanowili zrobić coś “nowego”, lepszego. Pomijając już to, że Angular w wersji 1.x będzie wspierany jeszcze sporo czasu.
TL;DR : Zrób ToDo w najpopularniejszych frameworkach i wybierz ten, który ci przypasuje, jak trafisz na większy problem to sprawdź jak można go rozwiązać w poszczególnych frameworkach, a po miesiącu-dwóch przywiąż się do któregoś bardziej :).
1 Like
Jeżeli będzie tak, że kod napisany dla Angulara 1.x nie będzie działał w 2.x ani kod napisany dla 2.x nie będzie działał w 1.x, to będzie katastrofa - wyobraź sobie, że masz w aplikacji 30 pluginów, i twórcy części z nich porzucili wsparcie dla 1.x i nie naprawiają bugów, a twórcy pozostałych jeszcze nie przygotowali wersji dla 2.x (myślisz, że to niemożliwe? Sprawdź co się działo z Pythonem przez długi czas po wypuszczeniu wersji 3)
Wracając do sedna:
Podpisuję się pod tym. Wybierz sobie jeden framework i popracuj z nim trochę, potem zrób jakiś mały projekt w innym frameworki i coś sobie w końcu wybierzesz na dłużej.
Angular 2 to zupełnie inny framework. Prawie wszystkie bebechy są do wymiany, także składnia szablonów. Vide: http://what.thedailywtf.com/t/angular-js-is-dead-so-lets-talk-about-everything-else/5644
Nie dość że zupełnie inny framework to jeszcze w zupełnie innym języku programowania. Trzeba być albo:
a) Idiotą
b) Masochistą
żeby w tej chwili inwestować w Angulara. A przynajmniej jedno z dwóch. Idiotą bo jak widać framework się kończy. Masochistą bo teraz wszystkie te gówniane “aplikacje” napisane w angular trzeba bedzie utrzymywać przez lata. Pieniądze w tym pewnie będą, ale trzeba naprawdę nienawidzić swojego życia żeby świadomie zakopać się w górę kompostu.
A jeszcze żeby pokazać jak bardoz gówniany jest Angular https://egghead.io/lessons/angularjs-animating-the-angular-way
Gość zamienia:
$('#element').click( function() {
TweenMax.to($('#animated-element'), 1, {opacity: 0});
});
w
var app = angular.module("app", ["ngAnimate"]);
app.controller("AppCtrl", function() {
this.isHidden = false;
this.fadeIt = function() {
this.isHidden = !this.isHidden;
};
});
app.directive("hideMe", function($animate) {
return function(scope, element, attrs) {
scope.$watch(attrs.hideMe, function(newVal) {
if (newVal) {
$animate.addClass(element, "fade");
} else {
$animate.removeClass(element, "fade");
}
});
};
});
app.animation(".fade", function() {
return {
addClass: function(element, className) {
TweenMax.to(element, 1, {opacity: 0});
},
removeClass: function(element, className) {
TweenMax.to(element, 1, {opacity: 1});
}
};
});
},
To drugie to jest “angular way”. Teraz powiedzcie mi czy chcielibyście pracować z frameworkiem który wymaga circa 30 linijek kodu żeby uruchomić animację po kliknięciu na element, coś co jak widać można spokojnie zrobić w jQuery w 3 linijkach kodu.
Wykonałem 2 projekty z pomocą Angular js - Ror + angular i Symfony 2 + angular. Ogółem spędziłem ok 8 miesięcy w tych projektach. Na początku Angular wydawał mi się fajnym rozwiązaniem, teraz jednak nie przepadam za nim i uważam, że:
- jest za ciężki np. o apkach mobilnych w Angular js raczej nie ma co gadać. Przy skomplikowanym interfejsie widać mocne zużycie cpu i pamięci.
- ohydny kod wynikowy, którego ciężko uniknąć. Widoki w złożonej apce to na ogół koszmar.
- trudność w debugowaniu
Ostatnie pół roku pracuję z React js i nie doświadczam tych problemów - polecam szczerze. React jest prosty, przewidywalny i szybki.
Dziękuję za rzeczową odpowiedź. Ktoś jeszcze może powiedzieć swoje zdanie i podzielić się doświadczeniami? Jak z tym emberem albo backbone ?
My do tej pory zawsze używaliśmy Bacbkone-a. Teraz przy okazji nowego projektu korzystamy z Marionetta który skupia się w ogarnięciu typowych, powtarzalnych problemów z warstwą widokową (zagnieżdżone widoki, bindowanie do różnych eventów modelu w widoku etc). Każde rozwiązanie można samemu niepotrzebnie skomplikować, ale myślę że przy odpowiedniej dyscyplinie o tym kodzie można napisać że jest przejrzysty, stosunkowo łatwy do zmiany. W firmie nie robimy Single Page Appek (mamy rodzinę aplikacji, żadna w ten sposób nie działa), choć prywatnie używałem Backbone i do tego.
Czemu nie React? Z chęcią, ale w momencie gdy zaczynamy nowy projekt w którym nie mamy wystarczająco dużo czasu żeby każdy się odpowiednio podszkolił woleliśmy odpuścić. Pewno w przyszłości.
A jak podchodzicie do apek real time(2way data bindig, itp.) ? Też używacie backbone ? Poza tym świetny post i dużo informacji
W kwestii two way data bindingu, Backbone sam z siebie tego nie daje. Jeśli Ci na tym zależy to musisz to sobie sam zorganizować (czytaj: napisać lub skorzystać z pluginów które już są. Nie korzystałem, ale ten chyba spełnił by Twoje oczekiwania).
Co do real time appek - ja z takowymi na co dzień nie pracuję. Jak dla mnie nie powinno z tym być problemu, zwłaszcza gdy rozgraniczysz fetchowanie danych od ich trzymania (czyli model Backbone-owy masz tylko do tego żeby trzymać w nim dane, ale nie żeby organizować w nim samo pobieranie).
Może co bardziej doświadczeni podzielą się swoimi przemyśleniami.