Moja prawda o Angular.js

Więc jesteś ciekaw tego, jaką prawdę o Angular.js chcę Ci przekazać. W takim wypadku posłuchaj mnie uważnie, ponieważ nie będę tego powtarzał:

Jak ja kurwa nienawidzę Angular.js!

Tak, jeżeli szukasz kogoś nazywanego hejterem, to jest to Twój szczęśliwy dzień – oto jestem! Jednak zanim zechcesz mnie ukrzyżować, pozwól mi przedstawić jasno mój punkt widzenia.

If your Polish is a little bit rusty, read the original post in English.

Dopisek od tłumacza: jest to wtórne tłumaczenie z języka angielskiego. Mimo dołożenia wielu starań, aby jakość tego przekładu była zadowalająca, mogą się znaleźć w nim przeoczone błędy. Ucierpiały też pewne zwroty typowe dla języka angielskiego, których nie da się ładnie przełożyć na polski. Jeżeli jesteś wybitnym purystą językowym, to możesz rozważyć przeczytanie oryginału.
Autorem tłumaczenia jest Sobak.

Pod wieloma względami jestem sieciowym konserwatystą i jestem z tego dumny. Nie oznacza to, że unikam każdego przejawu świeżości, ale zawsze podchodzę do niego sceptycznie – tak też byłem sceptyczny wobec Angular.js. Czasem akceptuję zmiany i dodaję nową zabawkę do mojej piaskownicy, jednak czasem staję się jednym z najbardziej zażartych wrogów nowego dzieciaka w okolicy. Jak pewnie już zauważyłeś, nie pałam miłością do nowego produktu Google. Mam ku temu własne powody, które chcę wyjaśnić i podsumować (i być może – jak dobry Dalek – przysporzyć nowych hejterów Angularowi!) – część z nich jest czysto subiektywnych, część z nich stara się być obiektywnymi (lub raczej intersubiektywnymi).

Jeśli chcę być obiektywny, nie mogę tworzyć tego postu w swego rodzaju próżni, więc przygotowałem kilka zasobów, aby poprzeć moje tezy. Oczywiście cała ta tyrada nie byłaby kompletna bez Biblii wszystkich krytyków Angular.js: słynnego artykułu What’s wrong with Angular.js [Co jest złego w Angular.js]; prawdę mówiąc był to dla mnie największy impuls, aby w ogóle głębiej przypatrzeć się Angularowi (tak, zawsze muszę wyśmiać sprawdzić czy ktoś ma rację). Istnieją także mniej znane artykuły jak You have ruined javascript [Zrujnowaliście JS], Think Twice (or Thrice) Before Using Angular [Pomyśl dwa (albo trzy) razy, zanim użyjesz Angulara] oraz – nie wycelowany bepośrednio przeciwko Angular.js – Stop Breaking the Web [Przestańcie niszczyć Sieć]. W drugim narożniku mamy Why Does There Have to be Something Wrong with AngularJS? [Dlaczego musi być coś nie tak z Angular.js?], What’s “Right” with AngularJS? i bardziej informacyjny, mniej emocjonalny artykuł pt. Add interactivity to HTML with AngularJS [Dodaj interaktywność do HTML używając Angular.js. Oczywiście wykorzystam też dokumentację Angulara, jego kod źródłowy i odwołam się (cytując kod) do dwóch aplikacji powstałych przy użyciu Angular.js: nowej i prostej oraz starszej i bardziej złożonej. Znajdą się także odniesienia do innych artykułów, niepowiązanych z Angularem, ale poświęconym zagadnieniu tworzenia aplikacji webowych. Chcę mniej więcej poruszać się ścieżką wytyczoną przez (nie)sławny artykuł What’s wrong… i porównać to do innych punktów widzenia, komentując to jednocześnie własnymi pomysłami i refleksjami (bleh, brzmi to jak poważne badanie naukowe, a nie prosty hejt!).

Skoro wszystko zostało już powiedzianie, pora na zabawę!

  • App logic and structure expressed in HTML, which is enchanting for beginners (Look’ma no JS, magic!), but terrible for real development. We are developers, we write and debug code.

    [Logika i struktura aplikacji wyrażone są w HTML, co jest kuszące dla początkujących (Nie ma JS, magia!), ale straszne dla prawdziwego developingu. Jesteśmy developerami, piszemy i debugujemy kod.]
    What’s wrong with Angular.js

    Jest to pierwszy (i dla mnie jeden z najważniejszych) powodów, dla których Angular.js jest zły: podejście deklaratywne. Wszyscy dobrze to znamy. Moda na „zadeklarujmy wszystko” rozpoczęła się około roku 1998, gdy W3C zaczął prace nad XHTML. Na pierwszy rzut oka wygląda obiecująco i odświeżająco, prawda? Nie sądzę.

    Jeżeli nazywam coś „frameworkiem JS”, oczekuję, że używa on JS do wykonywania zadań. Jeśli patrzę na Angular.js, nie widzę tam JS, ale – jak oni to nazwali – enhanced [ulepszony] HTML. Chcesz przypiąć funkcję do jakiegoś elementu? Użyj atrybutu [ng-click]. Próbujesz stworzyć przycisk, który powinien być nieaktynwy w okreslonej sytuacji? Użyj [ng-disabled]. Robisz coś innego? Użyj [ng-czegokolwiekCiTrzeba].

    <button class="btn btn--radius" ng-click="resetForm()" ng-disabled="criteria.$pristine">Reset</button>

    Walczyliśmy o unobtrusive JS [nieinwazyjny JS] przez lata i kiedy żyłem szczęśliwy w przekonaniu, że wojna się skończyła, mieszanie JS z HTML-em wróciło tylnymi drzwiami, używając czegoś gorszego niż atrybuty HTML standardu DOM0. Tak, [ng-click] jest gorsze niż [onclick]. Podczas gdy ten drugi jest natywny (i w związku z tym jego zachowanie jest ustandardyzowane, przewidywalne, prawdopodobnie zoptymalizowane przez przeglądarki i ich parsery DOM), pierwszy jest po prostu nieznanym atrybutem. I to jest właśnie to: Angular.js jest zmuszony sparsować całe drzewo DOM, tylko po to, by wydobyć te atrybuty; po zrobieniu tego musi przeparsować same atrybuty. Nie brzmi to zabawnie. Co więcej, Angular.js oczyszcza te atrybuty i kompiluje je do funkcji JS, które mają dostęp tylko do zdefiniowanego zasięgu… Więc framework musi być wyposażony w jakiegoś rodzaju parser i oczyszczacz HTML – a jest on dosyć duży. Jest jeszcze parser do przetwarzania szablonów.

    <label>{{ key | camel2Space | capitalizeFirst }}</label>

    Szablony w HTML? Kuszące, ale niepraktyczne. Tak, wiem, że istnieje tag template w Web Components, ale działa on w całkiem inny sposób. Główną różnicą jest to, że template jest używany do stworzenia poddrzewa DOM, które nie jest włączane do głównego drzewa DOM. Dzięki temu nic nie jest widoczne dla użytkownika, dopóki nie zdecydujemy się mu tego pokazać. Każda zmiana zachodzi poprzez metody DOM, ponieważ… wszystko jest w obrębie DOM. Podejście Angulara jest całkiem inne, gdyż Angular.js traktuje stronę jako szablon. Nieeleganckie. Dochodzą do tego ciche błędy, kiedy coś pójdzie nie tak.

    Dlaczego uważam stronę jako szablon za nieelegancką? Ponieważ strona jest widokiem, a nie szablonem. I w idealnym świecie szablon nie powinien być zależny od DOM. Szablony oparte o DOM są skoncentrowane na przeglądarkach – ścisłe przywiązywanie produktu do urządzenia, w sieci niezależnej od używanego urządzenia, brzmi szaleńczo. Sytuacja w Angular.js jest jeszcze gorsza, ponieważ ciche błędy mogą doprowadzić do sytuacji, w której widok bazuje na niepoprawnie skompilowanym szablonie i staje się nieużywalny.

    Więc jak jest w przypadku template od Web Components, który jest ulepszany przez Polymera, aby zrozumieć wzorce {{mustaches}}? Czy zawsze jest to tak złe? Cóż, tak – jest to złe, ale także jasno oddziela widok od nieskompilowanego szablonu, ponieważ jego drzewo DOM jest w pełni oddzielone od drzewa DOM strony. I to jest główna różnica. Wszystkie inne uwagi wobec systemu szablonów z Angular.js wydają się odnosić także do tagu template (szczególnie w jego odmianie używającej Polymera). Jednak w pewnych wypadkach uważam metody DOM za przyjaźniejsze niż szablony bazujące na łańcuchach znaków – template.querySelector('.img').src jest po prostu… sexy.

    Wracając do naszych atrybutów – John Papa powiedział:

    The declarative nature works great at removing oft used features and making them simple

    [Deklaratywna natura jest świetna w usuwaniu często używanych funkcji i czynienia ich prostymi]

    Why Does There Have to be Something Wrong with AngularJS?

    Cóż, uważam, że przypinanie metod JS do elementów DOM, za pomocą JS, jest łatwiejsze niż deklarowanie ich bezpośrednio w tym elemencie DOM. Jest to też prawdopodobnie mniej powtarzalne.

    <button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>
    	<button ng-click="doSomething()">Do something</button>

    vs.

    bindAction('.do-something', doSomething);

    Oczywiście musimy zaimplementować funkcję bindAction, ale powinno być to banalnie proste, dzięki użyciu document.querySelectorAll i element.addEventListener. I jasno oddziela to nasz JavaScript od HTML-a. Ponieważ JS powinien być w JS, nie w naszym HTML. Modyfikowanie HTML-a tylko dlatego, że nasz JS się zmienił, jest po prostu śmieszne. Bardzo dobrym przykładem oddzielenia HTML, JS i CSS jest metodologia BEM (wolę nazywać ją „architekturą” niż „metodologią”) – jedynym „spoiwem” między tymi warstwami jest atrybut [class]. Nie ma atrybutów takich, jak [ng-click], [on-click] (może to po prostu metody ogłupienia CSP, by myślał, że nie są one w żaden sposób połączone z oskryptowaniem?). Nasz HTML jest banalnie prosty (oraz w pełni semantyczny) i mamy kilka niezłych bindingów [przypisań, dowiązań] w JS i CSS (są jeszcze lepsze, kiedy poznamy koncepcję drzewa BEM).

    Nie rozumiem także upodobania Angulara do powtarzania tych samych informacji – w JS, w modelach (model.$dirty, model.$pristine) i w HTML (.ng-dirty, .ng-pristine). Nawet argument o stylowaniu nie jest dobry – w tym wypadku potrzeba tylko jednej klasy (a w JS potrzeba tylko jednego stanu), ponieważ może być on true [obecny] lub false [nieobecny]. model.$dirty oznacza to samo co !model.$pristinenic więcej. Nie rozumiem także developerów, którzy wychodzą z rozwiązaniami takimi, jak dyrektywa [focus], która robi dokładnie to samo co natywny [autofocus], będąc gorszą, ponieważ nie rozpoznaje, że było inne sfocusowane pole i użytkownik prawdopodobnie nie chce zmiany focusa podczas pisania. Wynajdywanie koła na nowo w najczystszej z postaci.

    Rather than building upon the DOM, we build upon our application’s data.

    [Zamiast budować w oparciu o DOM, budujemy w oparciu o dane naszej aplikacji.]

    Add interactivity to HTML with AngularJS

    Wygląda to jak reklama jQuery. Tak, używając Angular.js nie musimy myśleć o DOM… ale w rzeczywistości budujemy wszystko w oparciu o DOM! Rdzeniem Angulara jest parser HTML/DOM, więc jest głupie sądzić, że nie musimy myśleć o DOM podczas pracy z tym frameworkiem. Był to rak pożerający jQuery, który wytworzył kastę developerów jQuery-only, niewiedzących nic o wewnętrznym działaniu DOM czy JS. Czy nie wydaje się dziwne, że można zostać magikiem nie znając magii? Ba, można być nawet popularnym, ale pewnego dnia po prostu spierdolić którąś ze sztuczek.

    AngularJS absolutely does a lot of HTML parsing. But, if you do any maintenance of apps or care much about productivity then the declarative approach AngularJS provides is refreshing.

    [AngularJS naprawdę często i sporo parsuje HTML. Ale, jeśli utrzymujesz/konserwujesz swoje aplikacje, albo bardzo dbasz o produktywność, wówczas deklaratywne podejście AngularJS jest odświeżające.]
    What’s “Right” with AngularJS?

    Cóż, koncepcja ulepszania HTML jest porywająca… zanim nie zorientujemy się, że jesteśmy w piekle. Po pierwsze, ściśle przywiązujemy nasz JS do HTML i nie jest to dobre (hej, pokażcie mi framework MVC – nie musi być napisany w JS – który twierdzi, że widok i model lub widok i kontroler powinny być tak silnie powiązane!). W Angular.js kod HTML jest nawet ważniejszy niż sam JS – HTML jest bowiem tym, który dyktuje jak zachowują się elementy. Widok decyduje także który kontroler zostanie użyty. Brzmi to szaleńczo i nie mogę tego znieść. Taka architektura przenosi zarządzanie naszą aplikacją na coś, co jest hybrydą widoku i szablonu.

    Not yet convinced? Angular enables us to create custom elements easily, as well as modularising our functionality. We can write a complex web application like so (this is a simplified snippet of one of our production Angular applications):

    [Wciąż nieprzekonany? Angular umożliwia nam łatwe tworzenie własnych, niestandardowych elementów, jak również podzielić funkcjonalność na moduły. Możemy pisać złożone aplikacje internetowe tak (to uproszczona wersja jednej z naszych aplikacji napisanych w Angularze, która znajduje się w środowisku produkcyjnym):]

    <header user="currentUser"></header>
    	<product-list ng-model="products"></product-list>
    	<checkout ng-model="shoppingCart"></checkout>

    Add interactivity to HTML with AngularJS

    Nie, nie jest to dla mnie przekonujące. Angular.js (w wersji 1.x) nie bazuje na Web Components, więc ta struktura nie znaczy absolutnie nic. Tak, nie znaczy absolutnie nic. Semantyka? Nie ma tu takiej. Fajne dodatki DOM? Nie. Dostępność? Też nie. Więc co dostajemy? Rozwlekłość [verbosity] (ten sam problem co z „Semantic” UI). Angular.js nawet nie traktuje tych tagów jako custom elements [elementów niestandardowych], tylko jako nieznane elementy DOM, które mogą być użyte jedynie przez jakiś sprytny JS.

    Można to zrobić lepiej, używając Web Components (i tak będzie w Angularze 2.0), ale to nadal nie rozwiązuje problemu. Web Components, tak jak ja je widzę, powinny być traktowane jako sposób na stworzenie „semantycznego” (dla developera) GUI. Jest to technologia do tworzenia interaktywnych widoków, komponowanych z niezależnych, możliwych do wyizolowania modułów. I nie powinny one zawierać żadnej logiki niezwiązanej z UI. Deklaratywny router to jakieś szaleństwo. Aplikacja/logika biznesowa powinny znajdować się poza Web Components i porozumiewać się z nimi za pomocą zdarzeń. W ten sposób możemy stworzyć reagujące, responsywne GUI, które wciąż jest oddzielone od naszej aplikacji. Pisałem o tym jakiś czas temu. Sytuacja nie jest wesoła. Web Components nie są dostępne i tworzenie tagów, takich jak application, nic nie znaczy bez odpowiedniej ilości ARIA. ARIA jest podstawą dla „semantyki developera” i bez tego wszystkie customowe elementy są po prostu głupie.

    Pójście w „aplikacje deklaratywne” może stworzyć totalnie chore pomysły, jak np. HTML6 (HTML z przestrzeniami nazw XML? Serio?) i umieszczanie logiki w atrybutach HTML jest jednym z nich. Nie wspominając już o tym, że czynienie kodu HTML niepoprawnym, tylko dlatego że [data-attributes] są już passé, wygląda po prostu śmiesznie.

  • Two way databinding is an anti-pattern.

    [Bilateralne dowiązywanie danych to antywzór] ← tak to pięknie brzmi

    What’s wrong with Angular.js

    Mocne stwierdzenie i nie tak prawdziwe. 2-way data binding może pomóc tworzyć aplikacje szybciej i w bardziej wydajny sposób. W zasadzie lubię tę technikę, ale… nie lubię sposobu, w jaki Angular.js z niej korzysta. Jestem zdegustowany jedynym słusznym, deklaratywnym sposobem na zrobienie tego i preferuję użycie DOM Mutation Observer/zdarzeń oraz getterów/setterów z ES5. Prawdopodobnie sposób użyty przez BackBone jest najbliższy memu sercu w tym momencie. Myślę, że jest to po prostu kwestia upodobania – nie wiem jakie są różnice wydajnościowe między tymi dwoma podejściami.

    Dirty checking, accessors (Ember and Backbone), Object.observe and all that stuff. Wrong! It’s slow and brittle and it will consume mobile battery like hungry dog, for no reason. You don’t need it. Use Facebook Flux rather.

    [Sprawdzanie „na czuja”, modyfikatory dostępu (Ember czy Backbone), Object.observer i inne tego typu cuda. Błąd! Są wolne, podatne na błędy i zeżrą baterię komórki jak głodny wilk, bez wyraźnego powodu. Nie potrzebujesz tego. Użyj raczej Facebook Fluksa.]

    What’s wrong with Angular.js

    Cóż, uważam dirty checking [sprawdzanie „na czuja”] za… brudny [ang. dirty – żarcik hehe językowy nie do przełożenia – przyp. tłum.], ale lubię koncepcję accessorów [modyfikatorów dostępu], opartą na wcześniej wspomnianych technikach. Object.observe + Mutation Observer także powinny być niezłym narzędziem.

    Model.bindTo lub coś podobnego – tak widzę 2-way data binding. Wszystko deklarowane w JS, widok pozostaje mały i czysty. Być może użycie WeakMaps i Proxy, by stworzyć wygodne API (ale to nadal przyszłość…). Coś w stylu:

    var user = new User({
    	name: 'User'
    	,email: 'mail@mail.mail'
    	,age: 100
    });
    user.bindTo([dom, elements]);

    Dlaczego nie ma miejsca na bindingi w HTML?

    Do your programming in a programming language. Don’t try to embed it in some crazy will-never-be-a-standard binding expression invented by a fly-by-night JavaScript framework.

    [Programuj w języku programowania. Nie próbuj tego robić w jakiejś szalonej „nigdy-nie-będę-standardem” składni dowiązań aktualnie modnego frameworka JS.]

    You have ruined HTML

    Całkowicie się z tym zgadzam. HTML jest językiem dostarczającym semantyki dla treści. Niczym więcej. Nie jest językiem szablonów (jeżeli chcesz deklaratywnego języka szablonów, spójrz na XSLT i inne zwariowane dziwactwa w XML) ani językiem programowania, który może zapewniać logikę Twojej aplikacji. Chodzi tylko o semantykę.

    Bindingi w JS – tak, bindingi w HTML – nie.

  • Duplicated app structure with obsolete angular.module. Almost for every app feature you have to 1) change HTML 2) change its controller.

    [Zduplikowana struktura aplikacji z niepotrzebnym angular.module. Praktycznie dla każdej nowej funkcjonalności musisz 1) zmienić HTML 2) zmienić jego kontroler.]

    What’s wrong with Angular.js

    Sądzę, że pojechałem już wystarczająco po HTML, więc został nam angular.module. Jak zostało to skomentowane przez obrońców Angular.js?

    Angular motivates you to use modular components. It makes it easy to break things apart and decouple. So I’m not sure why this is a bad thing to create modules.

    [Angular motywuje do używania modularnych komponentów. Pozwala to na łatwy podział aplikacji na części i rozdzielenie ich od siebie. Nie wiem zatem czemu tworzenie modułów jest rzeczą złą.]

    Why Does There Have to be Something Wrong with AngularJS?

    Angular provides the ability to create modules that can be combined with other modules to promote re-use and simplified maintenance. That’s one of the big reasons I like it so this is another comment that made me laugh but also wonder exactly what the author meant. There are certainly improvements that can be made here (lazy-loading of modules, dynamic loading of specific scripts, etc.) but it works well and it’s going to get even better in version 2 as the entire framework becomes more modular – including things like dependency injection.

    [Angular dostarcza możliwości tworzenia modułów, które mogą łączyć się z innymi modułami, tworząc reużywalny kod i ułatwiając utrzymanie aplikacji. To jeden z większych powodów, dla których Angulara lubię, więc to kolejny komentarz przy którym się uśmiałem, ale zacząłem się też zastanawiać co autor miał na myśli. Oczywiście są miejsca, w których można wprowadzić ulepszenia (leniwe wczytywanie modułów, dynamiczne wczytywanie konkretnych skryptów itd.), ale i obecnie działa to dobrze, a w wersji 2 będzie działać jeszcze lepiej, gdyż cały framework stanie się modularny – włączając w to takie rzeczy, jak dependency injection – wstrzykiwanie zależności].

    What’s “Right” with AngularJS?

    Jestem niemal pewien, że pominięto tu kluczowy aspekt. Problem nie leży w modułach, ale w łączeniu modułów z HTML za pomocą [ng-controller]. Jest to kompletnie niepotrzebne – widok nie powinien nawet wiedzieć o kontrolerze!

    Ale, jak także obrońcy przyznali, moduły Angular.js nie są idealne. Główny problem, widoczny dla mnie, to fakt, że Angular.js wprowadził własną składnię modułów. Nie jest kompatybilna ani z AMD, ani z CommonJS, a to zła wiadomość, ponieważ moduły są reużywalne tylko w obrębie Angular.js. Sytuacja jest jasna: mamy dwa standardy (trzy, jeśli liczymy ES6 modules lub nawet cztery, licząc UMD… okej – pięć, z Melchior.js Chainable Module Definition) i ktoś tworzy kolejny, więc mamy teraz trzy standardy (ten Angulara jest standardem tylko dlatego, że Angular.js jest „standardem”). Co śmieszniejsze – moduły Angulara mają składnię bardzo podobną do AMD.

    var services = angular.module('guthub.services', ['ngResource']);
    […]
    services.factory('MultiRecipeLoader', ['Recipe', '$q',
    function(Recipe, $q) {}]);

    W Angular 2.0 jest już lepiej, ponieważ użyta jest składnia modułów z ES6. Oczywiście problem w tym, że dzisiaj nikt nie wspiera tej składni (i użycie ES6 tylko po to, żeby go użyć jest śmieszne).

    Moduły Angular.js powinny używać składni UMD (a nie wynajdywać ją od nowa), aby stać się częścią prawdziwego środowiska JS.

  • Angular is slow.

    [Angular jest wolny.]

    What’s wrong with Angular.js

    If I had a dollar for every time I’ve heard someone say that about a framework over the years I’d be retired! People love to make generalized statements like “Framework X is slow” if they don’t like it and want to turn others off to it.

    [Jeśli dostawałbym dolary za każdym razem, gdy usłyszę kogoś mówiącego to o frameworku, po latach uskładałbym na emeryturę! Ludzie uwielbiają tworzyć zgeneralizowane sądy, typu „Framework X jest wolny”, jeśli czegoś nie lubią i chcą innych zrazić do tego.]

    What’s “Right” with AngularJS?

    Cóż, nie chcę żeby ktoś zarobił pieniądze przez moje słowa, ale naprawdę nie lubię Angulara, więc to powiem: Angular.js jest wolny (ej, patrzcie – świeżutkie statystyki, które w pewnym sensie potwierdzają moje słowa).

    Tak, jest wolny. I nie mówię o faktycznej wydajności tego kodu JS – to nie ma znaczenia w tym wypadku. Angular.js jest wolny, ponieważ odczuwalna wydajność jest zła. Dowód? Spójrz po prostu na to demoprawdopodobnie zobaczysz FOUC (lub raczej FOUT – Flash Of Uncompiled Template [mignięcie nieskompilowanego szablonu – przyp. tłum.]). Ten wróg został pokonany lata temu a teraz – wraz z przypinaniem zdarzeń opartym o DOM0 – powraca.

    Problem jest wywoływany przez traktowanie strony jako szablonu. Musi ona zostać pobrana, sparsowana i w końcu jest używalna dla odbiorcy. Oczywiście, możemy zapobiec efektowi FOUT przenosząc JS do head, ale to prawdopodobnie też zaszkodzi odczuwalnej wydajności, blokując stronę do momentu pobrania JS. I nie, podejście Polymera (body[unresolved], które ukrywa całą stronę dopóki Web Components nie zostaną sparsowane) nie jest lepsze. Prawdę mówiąc, nie ma dobrego rozwiązania. Cóż… Jest jedno, ale jest problematyczne, więc przejdźmy do niego…

  • No server side rendering without obscure hacks. Never. You can’t fix broken design. Bye bye isomorphic web apps.

    [Brak renderowania po stronie serwera bez dziwnych hacków. Nigdy. Nie można naprawić błędnych założeń. Pa pa, izomorficzne aplikacje internetowe.]

    What’s wrong with Angular.js

    Cóż, renderowanie po stronie serwera poradziłoby sobie z problemami opisanymi w poprzednim punkcie, ponieważ Angular.js zawsze będzie wolniejszy niż renderowanie treści na serwerze. Twitter dobrze o tym wie. Ale nie chodzi tylko o wydajność. Renderowanie po stronie serwera naprawdę jest wielkim problemem, niestety zostało kompletnie niezrozumiane przez obrońców Angulara.

    My best guess is that this has to be a reference to Search Engine Optimization (SEO). So let’s assume that is the case. This is probably the biggest area of improvement that is begging for a better solution in the SPA space. Some companies must have SEO ready applications and it is not simple as it should be to use it with Angular. However, there are ways to tackle it such as prerender.io and these techniques.

    [Strzelam, że rozchodzi się o Search Engine Optimization (SEO). Zatem załóżmy, że tak faktycznie jest. To prawdopodobnie obszar SPA, który wręcz domaga się ulepszenia. Niektóre firmy są zmuszone posiadać aplikacje spełniające wymogi SEO, a nie jest to tak proste, jak powinno być, jeśli używamy Angulara. Jednak są pewne techniki, dzięki którym można to osiągnąć, jak np. prerender.io.]

    Why Does There Have to be Something Wrong with AngularJS?

    More than likely he’s referring to Search Engine Optimization (SEO) issues which is the Achilles’ heel of any client-side framework – which he conveniently fails to mention.

    [Najprawdopodobniej chodzi mu o problemy z SEO, które są piętą Achillesową wszystkich frameworków przeglądarkowych – o czym jakoś nie wspomina.]

    What’s “Right” with AngularJS?

    Ekhem… nie chodzi o SEO. Chodzi o UŻYTKOWNIKA! Wspomniałem wcześniej o odczuwalnej wydajności, ale nawet to nie jest główną kwestią. Największe wątpliwości budzi dostępność i używalność. Co z podejściem Progressive Enhancement [Stopniowego Ulepszania]? Serio, nikt? Musicie sobie żartować. I nie, nie chodzi o ludzi bez JS – chodzi o wszystkich.

    Strive for simplicity. Use progressive enhancement. Don’t do it for people who disable JavaScript. Don’t do it for people who use older browsers. Don’t even do it just to be thorough. Do it because you acknowledge the important of delivering content first. Do it because you acknowledge that your site doesn’t have to look the same in every device and browser ever. Do it because it improves user experience. Do it because people on mobile networks shouldn’t have to suffer the painful experience of a broken web.

    [Dążmy do prostoty. Używajmy progressive enhancement. Nie róbmy tego dla ludzi, którzy wyłączają JS. Nie róbmy tego dla tych, którzy używają starszych przeglądarek. Nie róbmy tego nawet po to, żeby być dokładnymi. Róbmy to, ponieważ tym samym pokazujemy jak ważne jest dla nas dostarczanie treści jako pierwszej. Róbmy to, ponieważ pokazujemy tym, że nasza strona nie musi wyglądać identycznie na każdym urządzeniu i przeglądarce. Róbmy to, bo to poprawia komfort korzystania z naszej strony. Róbmy to, bo ludzie używający mobilnego internetu nie powinni cierpieć z powodu zepsutej sieci.]

    Stop Breaking the Web

    Zróbcie to dla tych z wolnymi łączami mobilnymi, dla tych, którzy nie dostają Twojego JS, ponieważ Twój CDN akurat leży i dla niepełnosprawnych, którzy używają czytników ekranu, jak Jaws lub NVDA. Google także na tym skorzysta.

    Więc w czym problem?

    Angular needs a DOM to work. This is unlike other approaches where string templates are used, or even a virtual representation of the DOM that is not coupled to an existing DOM. And in the server we don’t have a DOM available. At least not a real one. We have some libraries that create DOM structures that claim to be compatible, and they may be up to some extent, but they won’t be exactly the DOM that angular needs.

    [Angular potrzebuje do życia DOM. To całkowicie różne podejście od tego, w którym stosuje się szablony tekstowe, czy nawet wirtualną reprezentację DOM, niepołączoną z rzeczywistym DOM. A na serwerze DOM nie jest dostępny. A przynajmniej nie ten prawdziwy. Mamy biblioteki, które są w stanie stwarzać struktury DOM-owe, które niby są z nim kompatybilne – i pewnie nawet są do pewnego stopnia – ale nigdy nie będą dokładnie takim DOM-em, jakiego wymaga Angular.]

    Think Twice (or Thrice) Before Using Angular

    Budowanie całej aplikacji w oparciu o DOM brzmi szaleńczo i prawdopodobnie takie jest. Główna część Angulara wygląda na błędną w założeniach [broken by design – przyp. tłum.].

    Zależność Angular.js od DOM jest jego najgorszą cechą, ponieważ jednocześnie zabija dostępność i użyteczność. ARIA i pokazywanie stanu zmienionych elementów użytkownikowi? Nie ma niczego w tym stylu. Zawartość dla kogoś z wyłączonym JS? Brak. Zawartość dla osób z wolnym Internetem? Nie (ok – jest… kiedy powolna przeglądarka pobierze cały JS i sparsuje szablon). Lepsza semantyczność dla użytkownika? Nie. Odczuwalna dobra wydajność dzięki prerenderowaniu strony? Nie. Nie ma nawet właściwych URIHashbangi są po prostu upośledzone – szczególnie dziś, kiedy mamy History API.

    SPA nie jest tutaj wymówką – tworzenie dostęnych aplikacji jest naszym obowiązkiem, ponieważ tworzymy dla ludzi, nie dla siebie!. A SPA z prerenderingiem po stronie serwera wciąż może być SPA (hej – Angular.js potrzebuje serwera żeby wysłać szablon; więc czemu nie wysłać skompilowanego szablonu?). I tak, aplikacje webowe bez JS nie mają sensu… prawie. Spójrzcie na GMaila – to (nie tak) dobry przykład: także działa bez JS, dostarczając drugi, prostszy interfejs użytkownika (nie tak dobry przykład, bo używając PE mogliby stworzyć tylko jedną wersję i podpinać JS przez metody DOM w JS). Prawie każda aplikacja Angular.js używa pewnego rodzaju usługi REST – więc bez JS, ta informacja wciąż tam jest. Angular.js mogłyby korzystać z JSON-a, a przeglądarki bez JS – z pełnych widoków. Dostępne? Zapewniam.

    I tak, wiem że Angular.js został stworzony z myślą o SPA, ale dziś jest używany wszędzie (tak jak jQuery), psując sieć.

    PE jest zapomnianym fundamentem i bez niego nie mogę nawet patrzeć na Angulara – łamie on wszystkie zasady, w które wierzę.

  • Angular is hard to learn. It’s irony because Angular itself is promoted as easy framework for beginners. But it’s very complicated kind of easiness. You have to learn a lot of Angular specific patterns useful only in Angular world. Yeah, it’s result of bad design. This is both sad and ridiculous. Abstract layer can solve many problems, except problem of having too many abstract layers.

    [Angular jest trudny do nauczenia się. To dość ironiczne, ponieważ reklamuje się jako prosty framework dla początkujących. Ale to bardzo skomplikowany rodzaj prostoty. Trzeba się nauczyć wielu specyficznych dla Angulara wzorców, które są przydatne tylko w jego świecie. Tak, to wynik złych założeń. To równocześnie smutne i śmieszne. Warstwa abstrakcji pozwala rozwiązać wiele problemów, oprócz problemu posiadania zbyt wielu warstw abstrakcji.]

    What’s wrong with Angular.js

    Nie mogę się bardziej zgodzić: Angular.js próbuje zamienić JS w Javę. W dawnych czasach, kiedy chciałem stworzyć obiekt w JS, pisałem new Object. Teraz muszę mieć usługę dostarczającą provider fabryki [factory], który dziedziczy z fabryki fabryk… Boże, nie. Po prostu nie. Kiedy chcę stworzyć nowy obiekt, tworzę nowy obiekt. Kropka.

    Tak, tworzenie warstwy abstrakcji jest dobre, ale przeabstrahowanie jest jedną z najgorszych rzeczy, jakie mogę sobie wyborazić. A Angular.js jest tego najlepszym przykładem. Gdy patrzyłem w kod Angular.js, znalazłem nawet provider obiektu window czy provider obiektu jQuery otaczającego document. Cóż – zangularyzujmy [Angularize] wszystko?

    We had a good thing, you ruined it. We had an escape route from that ridiculous enterprise hand-holding bullshit and instead of learning how to fucking code you’ve just brought your factory provider providers with you into what was once an okay place to get stuff done.

    [Mieliśmy dobrą rzecz, zniszczyliście ją. Mieliśmy drogę ucieczki od tego dziwnego, korporacyjnego pierdolenia, a wy, zamiast nauczyć się jak kodować, przynieśliście ze sobą wasze providery providerów fabryk do miejsca, które niegdyś było najlepsze do robienia rzeczy dobrze.]

    you have ruined javascript

    I to jest to – Angular.js przeabstrahował wiele rzeczy.

    I had a problem and thought to use Angular so now I have a problem directive factory

    [Miałem problem i pomyślałem, że użyję Angulara, więc mam teraz fabrykę dyrektyw problemów].

    Andreas Brekken’s comment

  • Uzależnienie od twórcy, Google go nie używa… Może po prostu przejdziemy dalej.

  • Will be rewriten entirely soon, which is a good thing for framework, but pain for you.

    [Będzie wkrótce całkowicie przepisany, co jest dobrą rzeczą dla frameworka, ale okropną dla ciebie].

    What’s wrong with Angular.js

    To będzie boleć, spójrzcie po prostu na kod Angulara 2.0: ES6 (lub AtScript) oraz Dart, moduły w modułach, jeszcze więcej klas niż teraz… To zupełnie inny framework, z innym podejściem, inną składnią, innymi różnicami… Tylko nazwa ta sama.

    Nie wiem czy Angular 2.0 będzie lepszy, ale wiem jedno: będzie wciąż przeabstrahowany.

  • It’s easy to see how Angular itself could change the face of web design. Dedicate a part of your team to building a part or the whole of your application in Angular – I promise, you’ll never look back.

    [Prosto zauważyć jak Angular może zmienić oblicze webdesignu. Oddeleguj część swojego teamu do tworzenia części albo całości aplikacji w Angularze – obiecuję, że nigdy tego nie pożałujesz.]

    Add interactivity to HTML with AngularJS

    Może zbyt dużo optymizmu…

  • A więc, Panie Hejter, co polecasz?

    Mój ironiczny czytelnik

    Cieszę się, że zapytałeś. Są nowi bohaterowie, tacy jak Taunus lub bardzo prosty Mithril (nic nie może być prostsze niż to, zapewniam!). Starzy wciąż są potężni, na przykład BackBone.js. I… to są moje typy. Nie ma ich dużo, ale mam nadzieję, że ta lista i tak jest wystarczająco długa.

Sadzę że Angular.js nie poprawia HTML – on go psuje. Psuje także JS, przeabstrahowując go. Może być bardziej wydajny i, jak dla mnie, mija się z obecnym trendem prostoty.

Tak, istnieje konieczność rozwoju i poprawiania naszej sieci, ale sądzę, że droga Angular.js jest ślepą uliczką.

47 myśli na temat “Moja prawda o Angular.js”

  1. Cześć. Przeczytałem cały wpis i w 100% muszę się zgodzić. Pierwszy raz jak tylko otworzyłem dokumentację to się przeraziłem. Tak strasznego połączenia jeszcze nigdy nie widziałem. Nie zagłębiałem się w kod Angulara, ale jak przeczytałem o tych providerach do obiektu Window to z jednej strony zrobiłem palmface’a, a z drugiej zacząłem się śmiać.
    Pracowałem przy Angluarze kilka dni tylko, ale muszę przyznać, że nie mogłem się przestawić na niego – po prostu go nie rozumiem. Dla mnie to jest coś strasznie abstrakcyjnego. Jak słyszę słowo Angular dostaję prawie wylewu.

  2. Dzięki za bardzo wyczerpującą analitykę. Jestem na etapie wyboru jednego z frameweworków do zbudowania aplikacji internetowej – przesiadam się z c# desktopowego. Byłem blisko Vaadin, ale wszystko wskazuje na to, że zabiorę się za BackBone’a. Pozdrawiam!

  3. A ja frajer już zacząłem się tego uczyć 🙂

    Zacząłem się właśnie zastanawiać, jak to może działać generując cały HTML w JS, rozwiałeś moje wątpliwości.

  4. Zacząłem się uczyć Angulara i dosyć szybko dopadły mnie dwie myśli:
    1. Ucząc się JSa (i ogólnie frontendu) bardzo często czytałem o tym, że nie należy mieszać HTMLa, CSSa i JSa ze sobą, style powinny być w osobnym pliku, js powinien być uruchamiany przez addEventListener z pliku *.js a nie z HTMLa i taki układ bardzo mi odpowiadał, był czytelny i uporządkowany. Potem zabrałem się za Angulara (bo w wielu ofertach pracy się pojawia, więc warto go znać) i zgłupiałem, bo to co było dobrą praktyką zostało brutalnie wyrzucone do kibla i niespecjalnie to komuś przeszkadza. Teraz korzysta się z tego co zostało uznane za złe.
    2. Chyba jestem tępy, bo nie trafia do mnie organizacja aplikacji w Angularze, nie umiem się w niego „wstrzelić”. Napotkałem problemy z którymi nie męczyłem się gdy nie korzystałem z frameworka a miałem wtedy mniejszą wiedzę. Niby wiem co jest do czego, ale jednocześnie nie mogę pozbyć się wrażenia jakiegoś bałaganu, zbytniego i zbędnego rozdrobnienia.
    Cieszę się, że tu trafiłem, bo teraz wiem, że nie tylko ja mam z tym tworem problemy 😉
    Jak wygląda sprawa z innymi frameworkami? Które są dla mnie a nie ja dla nich? Na razie niespecjalnie ich potrzebuję, ale widzę po ofertach pracy, że są mocno w cenie, więc mimo wszystko warto by się nimi interesować co by móc zarabiać więcej…

  5. Mnie przeraża to że patrząc na oferty firm prawie każda wymaga angularjs nie mam pojęcia po co im to.
    Mógł by mnie ktoś oświecić.

  6. Kilka frameworków js przerobiłem i muszę przyznać, że angular nie jest taki zły na jakiego go opisujecie. Znajdźcie mi kobyłę która potrafi wszystko, a nie ma wad. Po za tym angulara łatwiej jest się nauczyć niż samego js. Nie umiesz js? Masz angulara – nie musi Cię obchodzić co i jak się robi. Ważne, że my wiemy.

    Comandeer – hypem bym tego nie nazwał. Google nie jest jakimś autorytetem żeby dyktować jak i co i jak się w sieci robi. Sam właściciel ma tu jednak przewagę. Z kilkoma „frameworkami” miałem doczynienia, które były fajne, składne, proste, do jednej rzeczy a nie do wszystkiego… ale porzucono je. Bo nikomu za darmo nie chce się robić i cały czas tego utrzymywać.
    Dzięki googlu masz pewność, że projekt nie umrze „bo mi się nie chce”.

    1. Znajdźcie mi kobyłę która potrafi wszystko, a nie ma wad.

      A może miniaturkę? Mithril – super mały, a potrafi tyle, co Angular 😉 Ogólnie dzisiaj wpadłem gdzieś na wpis, gdzie cały framework MVC został przedstawiony tak:
      var M = {},
      V = {},
      C = {};

      I wbrew pozorom nie jest to takie głupie 😉
      Angular jest kobyłą, bo wymusza bardzo wiele konwencji, przez co staje się przeinżynierowany.

      Bardzo ciekawy jest też Taunus, który dodatkowo pozwala szybko wejść w świat izomorficznych aplikacji.

      Nie umiesz js? Masz angulara – nie musi Cię obchodzić co i jak się robi. Ważne, że my wiemy.

      I jak taki „programista” ma później cokolwiek zdebugować? Skoro do samolotu nie wpuszcza się lepszego gościa z ulicy, żeby nie spowodował wielkiej katastrofy, tak IMO do kodu nie powinno dopuszczać się ludzi, którzy nie znają języka. Bo to tak jakbyśmy pozwolili latać komuś, kto wie jedynie jak włączyć autopilota.

      Google nie jest jakimś autorytetem żeby dyktować jak i co i jak się w sieci robi

      Niestety jest. ¾ HTML5 i nowych APIs wymyśla się w Google. Tym samym pojawienie się Angulara i Polymera było wydarzeniem. Teraz hype przenosi się na Reacta + Fluxa, czyli dziecko kolejnego kolosa: Facebooka. Szkoda tylko, że obydwa rozwiązania są stworzone do rozwiązywania konkretnych problemów i sprawiają wrażenie wypuszczonych w fazie koncepcyjnej, nie natomiast jako w pełni przetestowane i sprawdzone w boju rozwiązania.

      Dzięki googlu masz pewność, że projekt nie umrze „bo mi się nie chce”.

      Akurat Google znany jest z ubijania swoich projektów 😉

  7. `Po za tym angulara łatwiej jest się nauczyć niż samego js. Nie umiesz js? Masz angulara – nie musi Cię obchodzić co i jak się robi. Ważne, że my wiemy.`
    To akurat ogromna wada. Przede wszystkim – jeżeli ktoś siada do Angulara to już liznął chociaż trochę JSa a Angular wprowadza na siłę własne rozwiązania, co mnie np. zniechęciło, bo nie dość, że odnalezienie się w tym wszystkim było kłopotliwe, to jeszcze musiałem się „martwić” tym czy jest to po Angularowemu. Strasznie niefajne. Coś podobnego miałem z Zendem (to akurat PHP), gdzie wiedziałem jak coś zrobić przy użyciu czystego PHP, ale już dostosowanie się do pomysłów twórców było dla mnie bardzo ciężkie. Ostatecznie porzuciłem jego naukę równie szybko co Angulara (po około 2 tygodniach ciągłych porażek).
    Niedawno odkryłem Meteor i jak na razie jestem oczarowany jego prostotą i ‚lekkością’. Wprowadza oczywiście swoją warstwę abstrakcji, robi różne ‚magiczne’ rzeczy za mnie, ale nie narzuca się na siłę, pozwala się skupić na rozwiązaniu problemu a nie na gramatyce. Do tego ma świetny, prosty w nauce system szablonów Blaze. Nie ma ‚wymieszajmy js z html żeby stworzyć coś nowego’ jak w React, nie ma ‚HTML na sterydach, czyli powrót do praktyk uznawanych za złe’ jak w Angularze, kilka prostych do zapamiętania zasad i można ‚lecieć z koksem’ 🙂
    `Dzięki googlu masz pewność, że projekt nie umrze „bo mi się nie chce”.`
    Ale przecież Google zabiło Angulara 1.x 😉

    1. Meteor jest fajny pod tym względem, że pozwala postawić apkę w ciągu kilku minut. Jednak to równocześnie sprawia, że bardzo dużo decyzji podejmuje za programistę (np. domyślne korzystanie z MongoDB). Cierpi także przynajmniej na jeden problem, na który cierpi Angular 1.x: domyślnie brak renderingu po stronie serwera, co w większości przypadków mimo wszystko należy uznać za wadę.

  8. Z tego co widzę to umożliwia stosowanie innych baz (w Atmosphere są gotowe paczki), jednak nie testowałem tego jak to działa i czy pozwala na dalsze korzystanie z kolekcji, subskrypcji i publikacji. Natknąłem się za informację (nie weryfikowałem), że twórcy chcą w kolejnych wersjach wprowadzić oficjalne wsparcie innych baz.
    Z renderowaniem po stronie klienta fakt, chociaż z tego co widzę ogólnie mało kto się tym przejmuje, przytaczając argument, że obecnie JS wyłączają ludzie w pełni świadomi tego jak mocno ogranicza to przeglądanie sieci, ponieważ strony bardzo intensywnie z niego korzystają. Jest w tym trochę prawdy.

  9. Z renderowaniem po stronie klienta fakt, chociaż z tego co widzę ogólnie mało kto się tym przejmuje, przytaczając argument, że obecnie JS wyłączają ludzie w pełni świadomi tego jak mocno ogranicza to przeglądanie sieci, ponieważ strony bardzo intensywnie z niego korzystają. Jest w tym trochę prawdy.

    Ale ludzie, którzy świadomie wyłączają JS mnie nie interesują 😉 Każdy może nie mieć JS (bo np. rozłączy Sieć, CDN padnie na 2 minuty itd) → http://kryogenix.org/code/browser/everyonehasjs.html
    Dodatkowo render na serwerze przy 1. wczytaniu prawie zawsze jest szybszy od takiego samego po stronie klienta. Przy kolejnych można już z powodzeniem robić wszystko po stronie klienta (jak to robi np. Taunus, o którym w artykule wspominam).

  10. Dlatego napisałem „trochę” 🙂 Dzięki za link, bardzo fajny 🙂 Chociaż ja jak np. coś nie działa to po prostu uznaję, że trzeba ją przeładować, albo ewentualnie chwilę poczekać „bo coś się zepsuło”. Ale chyba mało ludzi tak podchodzi do tematu 😉

  11. Zwróciłem się w stronę Angular po przejrzeniu kilku ofert pracy, w których jest wymagany. Pomyślałem, że sprawdzę co to za wynalazek? Zrobiłem kilka pierwszych kroków z ich samouczka i naszła mnie myśl, że coś jest nie tak. Masa dyrektyw do nauczenia, wpisywanych bezpośrednio do HTMLa, zwykłe pętle tworzone w dziwaczny sposób (ng-repeat jako tag HTML?) – wymyślanie koła na nowo? To wszystko robię znacznie szybciej przy użyciu PHP + jQuery bez dodawania jakiegoś kolejnego, nieczytelnego kodu frameworka, który dodatkowo wprowadza jakieś ograniczenia do mojej dotychczasowej praktyki. Nie znalazłem w Angular żadnej funkcjonalności, która byłaby niedostępna w dotychczas używanych przeze mnie narzędziach pracy (choć przyznaję, nie dobrnąłem do końca tutoriala).
    Na szczęście w porę znalazłem w google ten artykuł. Potwierdza on wszystkie moje wątpliwości i dodaje masę argumentów, dlaczego nie warto inwestować czasu w Angular. Całkowite odejście od MVC, mieszanie js z HTMLem – wszystko wywrócone do góry nogami bez wyraźnie zaznaczonej korzyści.
    Zastanawia mnie do czego używa się tego narzędzia w prawdziwej pracy? Może się sprawdza w przypadku początkujących programistów albo we współpracy z ludźmi, którzy z programowaniem nie mają nic wspólnego? Można im łatwo wytłumaczyć jak wstawiać dane bezpośrednio do layoutu. Nie mogę nic lepszego wymyślić 🙂
    Ale czy na serio Angular jest używany w firmach, które wpisują go do wymagań? Czy wpisują go, bo inni też go wpisują w ogłoszeniach na podobne stanowiska, a ogłoszenia tworzą ludzie z działu HR, a nie IT? 🙂 Ma ktoś doświadczenie z prawdziwej pracy w tym frameworku i może napisać (choć zdawkowo) w jaki sposób jest on wykorzystywany w jego firmie?

    1. Zastanawia mnie do czego używa się tego narzędzia w prawdziwej pracy?

      Do tworzenia aplikacji internetowych – właśnie z powodu łatwości tworzenia. IMO Angulara widziałbym w projektach typu https://github.com/tsx/shireframe ale do skomplikowanych webappów jakoś mi jednak nie pasuje.

      Ale czy na serio Angular jest używany w firmach, które wpisują go do wymagań? Czy wpisują go, bo inni też go wpisują w ogłoszeniach na podobne stanowiska, a ogłoszenia tworzą ludzie z działu HR, a nie IT?

      Prawdopodobnie jego popularność wzięła się stąd, że po prostu Google go wypromowało. Przynajmniej takie odnoszę wrażenie.

      1. W znacznej mierze tak, ale o to też w tym wszystkim także chodzi – raz, Google nie zrobiłoby milionów linii kodu w kiepskim narzędziu, a dwa gdy masz narzędzie popularne, szybciej uzyskasz w nim pomoc (AngularJS 200k+ pytań sa SO, Backbone dla przykładu 40k). Mając do wyboru 2 narzędzie gdzie jedno jest popularne a drugie nie, w ciemno biorę popularne, bo ktoś to będzie być może przez lata utrzymywał i nie ma co dziwaczyć z narzędziami.

        1. Google nie zrobiłoby milionów linii kodu w kiepskim narzędziu

          Rzeknę tak: Twoja naiwna wiara napawa me serce ciepłem 😉

          gdy masz narzędzie popularne, szybciej uzyskasz w nim pomoc (AngularJS 200k+ pytań sa SO, Backbone dla przykładu 40k). Mając do wyboru 2 narzędzie gdzie jedno jest popularne a drugie nie, w ciemno biorę popularne, bo ktoś to będzie być może przez lata utrzymywał i nie ma co dziwaczyć z narzędziami.

          A nie przyszło Ci do głowy, że może jest tak dużo pytań o Angulara, bo… tak dużo mają ludzie z nim problemów? 😀

          Porównujesz Angular 1.x z Backbone jako „nowy świat” ze „starym” – ale to przecież nie tak. AngularJS też już jest starym światem i na upartego Angular 2+, jako – mimo wszystko – jego duchowy następca też są już starym światem.

          Z Angularem jest trochę jak z konfiguracją Springa adnotacjami na poziomie klas Javy vs konfiguracja z poziomu plików XML. Czytałem artykuł mówiący o tym, że te adnotacje przemieszały konfigurację z logiką itd… I to prawda być może nawet, ale są zwyczajnie bardziej przyjazne – i tak patrzę na to, gdy krytykuje się Angulara za wstrzykiwanie JS do plików HTML czy np za ukrywanie operacji na DOM. Osobiście DOM mnie zawsze męczył, cieszy mnie to że Angular go przykrył, teraz w Backbone/Marionette widzę wiele ręcznych operacji na DOM które Angular przykryłby o niebo czyletniejszym dla mnie (ng-if/ng-class) – dla wielu ludzi jest zwyczajnie prostszy niż natywny JS/jQuery/mutacje jQuery by zrobić z jQuery MVCośtam (Bakcbone).

          I właśnie to jest jeden z największych problemów: DX (developer experience) jest przekładany wyżej od tego, jaka technologia siedzi tam pod spodem i jakie to ma przełożenie na końcowego usera oraz na kod jako taki. Zresztą to widać nawet po React. Owszem, Virtual DOM itd., ale wciąż DX jest IMO w nim postawiony wyżej niż końcowy efekt (patrz: JSX).

          Co do DOM: abstrakcja na DOM – jak najbardziej. Nie wyobrażam sobie na dłuższą metę bez. Ale abstrakcja zamiast DOM – to już IMO ciut niebezpieczne. Tak, obniża to próg wejścia… Tylko pytanie, czy we właściwą stronę i czy na pewno? Zamiast bowiem fundamentalnej technologii uczymy się narzuconych konwencji konkretnego narzędzia. A ta wiedza starzeje się wraz z narzędziem. Wiedza o DOM się z kolei aż tak nie starzeje.

          1. „Rzeknę tak: Twoja naiwna wiara napawa me serce ciepłem ;)”

            Niepotrzebna złośliwość 😉 Przypomina mi się kawał o blondynce, która słyszy w radiu „uwaga uwaga, na drodze X jeden samochód jak wariat jedzie pod prąd” a blondynka na to: „Jeden? Ich są tu całe setki!” 😉

            „A nie przyszło Ci do głowy, że może jest tak dużo pytań o Angulara, bo… tak dużo mają ludzie z nim problemów? :D”

            Pewnie, że może i tak być 🙂 Ale to by oznaczało, że im bardziej narzędzie problematyczne, tym bardziej popularne? Zresztą – tylko z tymi narzędziami nie ma problemów, których nikt nie używa. Idźmy dalej – tag BackboneJS 108 artykułów na Medium.com, AngularJS 2700 artykułów na Medium.com, też dlatego że BackboneJS jest super i nie trzeba o nim pisać bo wszyscy wszystko wiedzą, a Angular to badziewie i każdą rzecz trzeba tłumaczyć po dziesięć razy? Setki wariatów jadących pod prąd? 😉

            „Porównujesz Angular 1.x z Backbone jako “nowy świat” ze “starym” – ale to przecież nie tak. AngularJS też już jest starym światem i na upartego Angular 2+, jako – mimo wszystko – jego duchowy następca też są już starym świecie.”
            Co jest więc „na czasie”? Pytam bez złośliwości, bo może jestem do tyłu – dla mnie Angular 2+, React i Vue to nowoczesność 😉 Nowy vs stary świat – uprościłem tak to sobie, Angular jako nowy (niech będzie, „nowszy” 😉 ) ponieważ bardziej abstrakcyjny.

            „Tak, obniża to próg wejścia… Tylko pytanie, czy we właściwą stronę i czy na pewno? Zamiast bowiem fundamentalnej technologii uczymy się narzuconych konwencji konkretnego narzędzia. A ta wiedza starzeje się wraz z narzędziem. Wiedza o DOM się z kolei aż tak nie starzeje.”

            Nic nie szkodzi temu, by samej fundamentalnej technologii również się uczyć – a dane zadanie ma być zrobione. Zresztą konwencja przestarzała lepsza, niż brak konwencji – a tak było w projektach w jQuery/JS które widziałem. Oczywiście, można napisać na to jakieś abstrakcje, potworzyć „kontrolery”, serwisy które będą ładować dane, obserwatory do aktualizacji DOM gdy wpadną nowe dane tylko, robiłem takie rzeczy dla jQuery, tylko… Czy wtedy nie napisze się kolejnego Angulara/Reacta? Po co wymyslać koło na nowo, które zresztą w każdej innej firme ma inny kształt? Zresztą to jest problem JS, co tydzień nowe narzędzie, nowy framework, nowa biblioteka co to w pół roku postrąca z piedestału starych wyjadaczy od Google’a i FB… Ile piękniejszy byłby świat front-endu, gdyby zamiast wymyslać kolejnego Wjó czy Aulerię (Auleria to chyba zreszta ludzie związani wcześniej z Angular 2+) Ci ludzie pocommitowali do Angulara/Reacta, chociaż po części eliminując to, na co narzekają i jest możliwe do eliminacji bez tworzenia n-tej kopii Angulara/Reacta 😉 Jestem w stanie wprowadzić studenta w Angulara w miesiąc – w dwa tygodnie jeżeli jest kumaty sporo zrobi już sam, w JS/jQuery po roku mniej więcej pracy w Python (pierwsza zawodowa praca) waliłem głową w mur i miałem dość (jestem głupi? Może tak 😉 Ale tacy jak ja też w IT pracują i będzie nas coraz więcej 😉 ). Gdy potem wszedłem w Angulara było mi odczuwalnie łatwiej, W MIĘDZYCZASIE coraz lepiej poznawałem JS – i myślę że to właściwa droga. Najpierw ślepo kopiowałem koncepcje zawarte w projekcie Angularowym -> później coraz lepiej rozumiałem czemu to tak a nie inaczej wygląda -> następnie, mając już obycie z JS zdobyte niejako „naokoło” zacząłem poznawać lepiej samego JS. Zresztą to jest konieczne – raz, by rozszerzyć sobie perspektywę i by przejście z Angulara do Reacta czy Backbone nie paraliżowało, a dwa – i sam Angular ma dość sztywne ograniczenia na niektóre rzeczy. Np – gdy wartość inputa nie przechodzi walidacji, model z nim powiązany jest ustawiany jako undefined – i jeżeli chcemy pokazać monit typu „‚Test’ jest wartością niewłaściwą” trzeba zrobić „niskopoziomowy” querySelector() 😉

          2. Co jest więc „na czasie”? Pytam bez złośliwości, bo może jestem do tyłu – dla mnie Angular 2+, React i Vue to nowoczesność 😉 Nowy vs stary świat – uprościłem tak to sobie, Angular jako nowy (niech będzie, „nowszy” 😉 ) ponieważ bardziej abstrakcyjny.

            Agresywna komponentyzacja z jednej, a z drugiej – próba jak największego uproszczenia developmentu. I tutaj Angular 2 odstaje niemożliwe, bo React ma choćby create-react-app – zero konfiguracji. W Angularze 2 tak się nie da.

            Zresztą konwencja przestarzała lepsza, niż brak konwencji – a tak było w projektach w jQuery/JS które widziałem.

            Przestarzałe konwencje… To gdzież te dorożki na ulicach? 😉 Co do projektów w jQuery – czy to wina jQuery, czy programisty? Pisałeś w jednym z wcześniejszych komentarzy, że Angular umożliwia ładne testowanie jednostkowe. Spoko… tylko że to nie zasługa Angulara przecież. Każdą aplikację JS-ową da się tak napisać, nawet taką w jQuery. A że kod jest pisany tak, że nie da się go testować w izolacji, to świadczy tylko o programiście, nie zaś używanym narzędziu.

            Ile piękniejszy byłby świat front-endu, gdyby zamiast wymyslać kolejnego Wjó czy Aulerię (Auleria to chyba zreszta ludzie związani wcześniej z Angular 2+) Ci ludzie pocommitowali do Angulara/Reacta, chociaż po części eliminując to, na co narzekają i jest możliwe do eliminacji bez tworzenia n-tej kopii Angulara/Reacta

            React i Angular są tworzone w konkretnym celu przez konkretne firmy. To nie jest tak, że stwierdzi się „to jest źle, każmy im poprawić”, bo tak to nie działa. W sumie naprawdę łatwiej jest stworzyć cały framework od podstaw niż przekonać kogoś, że jego projekt należy zmienić u podstaw…

            Gdy potem wszedłem w Angulara było mi odczuwalnie łatwiej, W MIĘDZYCZASIE coraz lepiej poznawałem JS – i myślę że to właściwa droga. Najpierw ślepo kopiowałem koncepcje zawarte w projekcie Angularowym -> później coraz lepiej rozumiałem czemu to tak a nie inaczej wygląda -> następnie, mając już obycie z JS zdobyte niejako „naokoło” zacząłem poznawać lepiej samego JS.

            Jak dla mnie podejście dość mocno od tyłka strony… ale jeśli zadziałało, to w sumie why not?

          3. „Agresywna komponentyzacja z jednej, a z drugiej – próba jak największego uproszczenia developmentu. I tutaj Angular 2 odstaje niemożliwe, bo React ma choćby create-react-app – zero konfiguracji. W Angularze 2 tak się nie da.”

            Fakt, choć zauważyć trzeba, że w wersji stabilnej jest dość młody (pomińmy lata w alfie), zobaczymy co wymyślą. Natomiast komponentyzacja z tego co wiem wyszła im fajnie, dodatkowo ShadowDOM oraz symulację tegoż (poprzez atrybuty, w ogóle to wydaje mi się, że taką symulację ręcznie sobie mozna zrobić w CSS, tylko w w Angularze to kwestia przełączenia jednego ustawienia enkapsulacji w drugie jeżeli juzżbędzie natywne wsparcie), wsparcie dla obiektów immutable.

            „Co do projektów w jQuery – czy to wina jQuery, czy programisty?”

            To mnie akurat mało interesuje – liczy sie efekt. Wolę po gorszym programiście odziedziczyc kod w Angularze niż w jQuery 😉 A dobry programista i w jQuery i w Angularze napisze dobry kod, tylko w Angularze nie musi koła wymyślać na nowo 😉

            „React i Angular są tworzone w konkretnym celu przez konkretne firmy. To nie jest tak, że stwierdzi się “to jest źle, każmy im poprawić”, bo tak to nie działa. W sumie naprawdę łatwiej jest stworzyć cały framework od podstaw niż przekonać kogoś, że jego projekt należy zmienić u podstaw…”
            Pewnie że tak, tylko jak patrzę na Vue to widzę nieco zmodyfikowanego Angulara 1, patrząc na Aurelię zmodyfikowanego Angulara 2+… Aż tak się różnią w bebechach między sobą? Zresztą, na konferencji Google, gdzie promowano łączenie Reacta z Angularem napatrzyłem się na testy, pokazujące że React jest 30 razy szybszy od Angulara jesli chodzi o renderowanie DOM – a potem, po zwróceniu uwagi na błąd na odszczekiwanie tego 😉 Robią to samo, średnio widze powód by miały robić to znacznie inaczej. Nie do końca zresztą dokładnie o to mi chodziło, a raczej o moją perspektywę jako programisty (DX o którym wspomniałeś), bo mając do wyboru 2 niemalże identyczne rozwiązania biorę to znacznie popularniejsze. A jak mi się zachce renderowania na backendzie, przepiszę na Thymeleaf i chrzanić JS.

            „Przestarzałe konwencje… To gdzież te dorożki na ulicach? ;)”
            Przeca to ta sama konwencja – tylko konie rzeczywiste na mechaniczne zamieniono 🙂

            „Co do projektów w jQuery – czy to wina jQuery, czy programisty? Pisałeś w jednym z wcześniejszych komentarzy, że Angular umożliwia ładne testowanie jednostkowe. Spoko… tylko że to nie zasługa Angulara przecież. Każdą aplikację JS-ową da się tak napisać, nawet taką w jQuery.”
            Akurat nie o to mi wtedy chodziło – chodziło mi o to, że (wg mnie, bo tu się różnimy jak widać) to POJO bez skomplikowanych zależności/powiązań/dziedziczeń itd a Ty wspomniałeś o skomplikowaniu ($providery), którego ja nie mogłem dostrzec – nie widzę w Angular 1 po prostu tego skomplikowania: „muszę mieć usługę dostarczającą provider fabryki [factory], który dziedziczy z fabryki fabryk…” – nie wiem o co chodzi.
            Nawet w JS da się napisać – tylko po co wymyślać koło na nowo? Wybudujemy sobie w taki sposób wewnętrzego, firmowego Angulara czy Reacta, czy tam Vue.

            „A że kod jest pisany tak, że nie da się go testować w izolacji, to świadczy tylko o programiście, nie zaś używanym narzędziu”
            Dokładnie tak, natomiast narzędzie może zachęcać do stosowania dobrych praktyk, takich jak DI czy zamykanie logiki w serwisach – które to co prawda tworzy społeczność, ale wtedy gdy narzędzie daje możliwości łatwego ich zastosowania.

            „Jak dla mnie podejście dość mocno od tyłka strony… ale jeśli zadziałało, to w sumie why not?”
            I właśnie TUTAJ chyba siedzi powód, że mamy przeciwne stanowiska 😉

            Dobrrrrra, koniec, na dziś przynajmniej 😉 Dziękuję za dyskusję i dobranoc 😉

  12. Sorry, ale to hejt kogoś kto nie wiem czym jest MVC. Praktyki o których napisał na początku były dobre za czasów świetności jQuery a AngularJS z tym zrywa i przenosi wszystko to co najlepsze zostało wypracowane we frameowrkach MVC do świata webowego frontendu. Cały tej hejtowy post to taki hejt kogoś, kto nigdy nie wystawił nosa poza świat HTML/JS i boi się zmian.

    Ot weźmy ten fragment:
    > Walczyliśmy o unobtrusive JS [nieinwazyjny JS] przez lata i kiedy żyłem szczęśliwy w przekonaniu, że wojna się skończyła, mieszanie JS z HTML-em wróciło tylnymi drzwiami, używając czegoś gorszego niż atrybuty HTML standardu DOM0.

    No kurcze. Czy to, który element w WIDOKU wywołuje logikę biznesową to jest także element logiki biznesowej? No oczywiście, że nie. To jest detal który powinien być zdefiniowany w widoku. Autor oryginalnego posta pisze o mieszaniu JS z HTML a sam chce mieszać logikę biznesową z interfejsem. Again: brak zrozumienia podstaw MVC.

    > Szablony w HTML? (…) Podejście Angulara jest całkiem inne, gdyż Angular.js traktuje stronę jako szablon. Nieeleganckie. Dochodzą do tego ciche błędy, kiedy coś pójdzie nie tak.
    What? W MVC nie ma rozróżnienia na szablon i widok. Nie wiem jak autor chciałby to rozdzielić.

    > I jasno oddziela to nasz JavaScript od HTML-a. Ponieważ JS powinien być w JS, nie w naszym HTML. Modyfikowanie HTML-a tylko dlatego, że nasz JS się zmienił, jest po prostu śmieszne.
    Nie. Skoro istnieje taka potrzeba to znaczy, że autor wstawił obsługę interfejsu do kontrolera. Kontroler powinien zawierać WYŁĄCZNIE logikę biznesową.

    > Nie wspominając już o tym, że czynienie kodu HTML niepoprawnym, tylko dlatego że [data-attributes] są już passé, wygląda po prostu śmiesznie.
    Niepoprawnym bo? Dokumentacja HTML5 której autor najwyraźniej nie przejrzał nie nazywa takich elementów „błędnymi” a jasno i pragmatycznie opisuje, jak przeglądarka powinna się zachować w takim przypadku. Elementu nie obsługuje atrybutu? Zignoruj, wrzuć do tablicy .attributes i leć dalej. Nie ma tagu? Utwórz HTMLUnknownElement i leć dalej.

    Dalej mi się nie chce bo w sumie na wszystko można by odpowiadać: brak zrozumienia MVC.

  13. >Sorry, ale to hejt kogoś kto nie wiem czym jest MVC

    Bardzo dziwnym jest nazywanie Angulara MVC, skoro on nie jest MVC… Prawda jest taka, że w Sieci MVC w czystej postaci de facto nie występuje nigdy i w 95% procentach przypadków mamy do czynienia z MVP. W przypadku Angulara sytuacja jest bardziej skomplikowana (choćby ze względu na oficjalną nomenklaturę) i można powiedzieć, że to framework MV*.

    Zatem wyjście od fałszywego założenia, że coś takiego jak MVC w Sieci istnieje i że Angular tym jest, powoduje, że reszta komentarza nijak nie przystaje do rzeczywistości.

    > Praktyki o których napisał na początku były dobre za czasów świetności jQuery a AngularJS z tym zrywa i przenosi wszystko to co najlepsze zostało wypracowane we frameowrkach MVC do świata webowego frontendu.

    Aha. Czyli strona niedziałająca out of box, ale musząca zaciągnąć cały JS i najlepiej style to „wszystko to co najlepsze”? Jeśli próbujemy przyrównywać praktyki z MVC **niesieciowych** do MVC w Sieci, to popełniamy kolejny błąd logiczny. Sieć to nie aplikacja natywna. Tyle w temacie.

    > Cały tej hejtowy post to taki hejt kogoś, kto nigdy nie wystawił nosa poza świat HTML/JS i boi się zmian.

    A tym mnie ubawiłeś 😀 Skoro całe życie piszę dla Sieci, to po co mam wystawiać nos poza ten świat? Przynajmniej dzięki temu wiem, co naprawdę działa, a co nie.

    > No kurcze. Czy to, który element w WIDOKU wywołuje logikę biznesową to jest także element logiki biznesowej? No oczywiście, że nie. To jest detal który powinien być zdefiniowany w widoku. Autor oryginalnego posta pisze o mieszaniu JS z HTML a sam chce mieszać logikę biznesową z interfejsem. Again: brak zrozumienia podstaw MVC.

    Oczywiście, że nie jest. Ale równocześnie nie ma na to miejsca także w kodzie HTML. Polecam popatrzeć na model eventowy Zakasa choćby (http://www.slideshare.net/nzakas/scalable-javascript-application-architecture ). Przeniesienie bindingów z HTML do JS nie oznacza przeniesienia ich do „kontrolera”. Oznacza przeniesienie właśnie do warstwy widoku, która może być całkowicie niezależną abstrakcją od reszty logiki zawartej w kodzie JS. I można to osiągnąć choćby właśnie przez system eventowy (patrz: Web Components!). Więc nie, nie jest to brak zrozumienia podstaw MVC, a czepianie się fragmentu przy pomocy nadinterpretacji.

    > What? W MVC nie ma rozróżnienia na szablon i widok. Nie wiem jak autor chciałby to rozdzielić.

    Oczywiście, że jest. Widok jest abstrakcją oddzielającą szablon od kodu zajmującego się logiką biznesową. Przy pomocy widoku (rozumianego jako interfejs, nie konkretna implementacja) jestem w stanie renderować tę samą rzecz w różnych szablonach. Zatem to rozróżnienie jest – i to bardzo silne! W przypadku Sieci jest to tym widoczniejsze, że to, co serwuje przeglądarka, powinno być **gotowym widokiem** – zwłaszcza, że JS może nie zadziałać z tysiąca różnych powodów → http://kryogenix.org/code/browser/everyonehasjs.html

    > Nie. Skoro istnieje taka potrzeba to znaczy, że autor wstawił obsługę interfejsu do kontrolera. Kontroler powinien zawierać WYŁĄCZNIE logikę biznesową.

    Tak po prawdzie, w prawdziwym modelu MVC kontroler zajmuje się wyłącznie obsługą żądania użytkownika, a logika – z racji braku istnienia lepszego miejsca – ląduje w modelu → http://programmers.stackexchange.com/a/127632 – co tym bardziej pokazuje, że na Sieci mamy do czynienia z innym patternem, bardziej zbliżonym do MVP (albo nawet jeszcze czymś innym → http://blog.iandavis.com/2008/12/the-web-is-rmr-not-mvc/ ).

    Stąd kontroler, w swojej czystej postaci, powinien po prostu odpowiedzieć na żądanie użytkownika i spowodować zmiany w widoku. A do tego najlepiej nadałaby się właśnie architektura eventowa (i znów: Web Components jako interfejs w pełni odizolowany od reszty aplikacji!).

    > Niepoprawnym bo? Dokumentacja HTML5 której autor najwyraźniej nie przejrzał nie nazywa takich elementów „błędnymi” a jasno i pragmatycznie opisuje, jak przeglądarka powinna się zachować w takim przypadku. Elementu nie obsługuje atrybutu? Zignoruj, wrzuć do tablicy .attributes i leć dalej. Nie ma tagu? Utwórz HTMLUnknownElement i leć dalej.

    Niepoprawność oznacza niezgodność ze specyfikacją HTML5 – czyli brak występowania danych znaczników i atrybutów w standardzie HTML5. To, że Angular świadomie łamie ten standard tylko po to, żeby móc zrobić [ng-click] zamiast [data-ng-click] (czy wręcz [data-click]) jest po prostu głupie. Nie po to wprowadzono taką możliwość do specyfikacji, by każdy framework i tak proponował własny syntax. Owszem, przeglądarki takie rzeczy obsługują i akceptują… bo w Sieci jest może 10% **całkowicie poprawnych składniowo i zgodnych ze specyfikacją HTML5** stron. Zresztą reguły te zostały ostatnio i tak rozszerzone o wsparcie dla custom elements.

    No i zresztą nie rozumiem tego zarzutu. „Niepoprawne” to nie to samo, co „niedziałające”. A dla Twojej informacji, specyfikację HTML5 znam bardzo dobrze, co zresztą można zauważyć jak się trochę zainteresuje moją działalnością w Sieci.

    > Dalej mi się nie chce bo w sumie na wszystko można by odpowiadać: brak zrozumienia MVC.

    Cóż, powtórzę to, co już powiedziałem: w Sieci czyste MVC nie istnieje i próba przełożenia modelu MVC spoza Sieci jest skazana na porażkę. Stąd nigdy nawet nie próbowałem rozpatrywać Angulara jako frameworka MVC. Zresztą ten termin nie pada ani razu w odniesieniu do Angulara na jego oficjalnej stronie… Bo po prostu nie pasuje.

  14. > Bardzo dziwnym jest nazywanie Angulara MVC, skoro on nie jest MVC… Prawda jest taka, że w Sieci MVC w czystej postaci de facto nie występuje nigdy i w 95% procentach przypadków mamy do czynienia z MVP.
    Zacznijmy od tego, że nigdy nie znajdziesz „prawdziwego MVC”. To jest utopijna idea niemożliwa do zrealizowania. Można być jedynie bliżej i dalej a AngualrJS jak na możliwości przeglądarek internetowych jest dość blisko. Alternatywnych nazw do MVC jest od groma jak MVC, MCT, MVT czy SDC.

    > Aha. Czyli strona niedziałająca out of box, ale musząca zaciągnąć cały JS i najlepiej style to „wszystko to co najlepsze”?
    Serio? W 2016 roku przejmujemy się tym, że strona wymaga do działania JS? Ręce mi opadły…

    > Skoro całe życie piszę dla Sieci, to po co mam wystawiać nos poza ten świat? Przynajmniej dzięki temu wiem, co naprawdę działa, a co nie.
    Warto byłoby poznać MVC zaimplementowane w frameworkach aplikacji okienkowych aby potem pouczać innych co jest prawdziwym MVC a co nie. Nie uważasz?

    > Oczywiście, że jest. Widok jest abstrakcją oddzielającą szablon od kodu zajmującego się logiką biznesową. Przy pomocy widoku (rozumianego jako interfejs, nie konkretna implementacja) jestem w stanie renderować tę samą rzecz w różnych szablonach. Zatem to rozróżnienie jest – i to bardzo silne!
    Sorry, ale to rozróżnienie jest ale w Twojej głowie. W MVC nie ma czegoś takiego jak szablon. Czym jest szablon zależy od nomenklatury przyjętej przez framework którego używasz o ile w ogóle takie coś w tym frameowrku istnieje. Samo MVC żadnych szablonów nie wymaga.

    > Oczywiście, że nie jest. Ale równocześnie nie ma na to miejsca także w kodzie HTML. Polecam popatrzeć na model eventowy
    Ok, ale co to ma wspólnego z MVC? Model eventowy to jedno podejście, MVC to drugie podejście. Oba się wykluczają.

    > Tak po prawdzie, w prawdziwym modelu MVC kontroler zajmuje się wyłącznie obsługą żądania użytkownika, a logika – z racji braku istnienia lepszego miejsca – ląduje w modelu
    Ok, fajnie. Tylko czemu polemizujesz z czymś czego nie pisałem? Poza tym tutaj widać, że z MVC nie masz za wiele do czynienia. Od lat to podejście jest uważane, za przestarzałe. Model nie odpowiada już za logikę biznesową. Logika biznesowa ląduje w serwisach które w Angularze działają bardzo ok.

    > http://blog.iandavis.com/2008/12/the-web-is-rmr-not-mvc/
    Ale zauważyłeś, że artykuł mówi o backendzie a nie fronedzie? 😀

    > Stąd kontroler, w swojej czystej postaci, powinien po prostu odpowiedzieć na żądanie użytkownika i spowodować zmiany w widoku. A do tego najlepiej nadałaby się właśnie architektura eventowa
    Wywołanie ng-click to jest nic innego jak żądanie użytkownika na które kontroler odpowiada. Kontroler powinien to obsłużyć i wysłać to do serwisu (czy dawniej modelu). Przecież to jest wzorcowy przykład MVC O.o

    > Niepoprawność oznacza niezgodność ze specyfikacją HTML5
    Wskaż mi który dokładnie fragment dokumentacji HTML5 mówi, że customowe tagi czy atrybuty są niepoprawne.

    > Cóż, powtórzę to, co już powiedziałem: w Sieci czyste MVC nie istnieje i próba przełożenia modelu MVC spoza Sieci jest skazana na porażkę.
    Sorry, ale powtarzasz bezmyślnie zasłyszane slogany. Gdzieś przeczytałeś na stronie kogoś mądrzejszego, że MVC w „sieci” nie istnieje ale nie załapałes, że ten ktoś mówił o backendzie. Zresztą dopiero co wysłałeś mi linka aby udowadnić, że AngularJS to wzorzec RMR w artykule który mówi o framewrokach backendowych 😀

    Jak ktoś mówi, że MVC w „sieci” nie istnieje ma na myśli WYŁĄCZNIE backend gdzie jesteśmy ograniczeniu przez specyfikację protokołu HTTP i faktycznie tam się nie da odtworzyć idealnego MVC. A co niby niemożliwa zaimplementowanie MVC w frontendzie? Nie ma czegoś takiego.

    1. Zacznijmy od tego, że nigdy nie znajdziesz „prawdziwego MVC”. To jest utopijna idea niemożliwa do zrealizowania. Można być jedynie bliżej i dalej a AngualrJS jak na możliwości przeglądarek internetowych jest dość blisko. Alternatywnych nazw do MVC jest od groma jak MVC, MCT, MVT czy SDC.

      Inna nazwa = inny pattern. Nie oszukujmy się. Właśnie dlatego, że MVC jest utopijne, to powstały inne wzorce.

      Serio? W 2016 roku przejmujemy się tym, że strona wymaga do działania JS? Ręce mi opadły…

      Polecam sprawdzić, czym jest Progressive Enhancement i dlaczego wciąż jest ważny. I właśnie to, nad czym Tobie opadają ręce, sprawia, że Sieć się rozwija. Polecam sprawdzić jak mocny jest opór przeciwko PWA – właśnie dlatego, że odrzuca wszelkie dobre praktyki tworzenia aplikacji. A to, który mamy rok, wcale nie zmieniło podstawowego założenia Sieci, która ma być dostępna dla wszystkich. Zamienienie semantycznego HTML-a na JS-ową papkę nijak temu nie służy. Zresztą pokazałem w artykule jak można zrobić to samo, co Angular, przy poszanowaniu podstawowych zasad. Da się – trzeba tylko chcieć.

      Warto byłoby poznać MVC zaimplementowane w frameworkach aplikacji okienkowych aby potem pouczać innych co jest prawdziwym MVC a co nie. Nie uważasz?

      Warto znać dogłębnie Sieć, żeby nie próbować innym wmówić, że jakieś ideologiczne rozumienie pewnego design patternu jest dobre tylko dlatego, że „takie powinno być”. W Sieci nie ma MVC, bo nie działa. I to jest fakt, któremu nie da się zaprzeczyć.

      Sorry, ale to rozróżnienie jest ale w Twojej głowie. W MVC nie ma czegoś takiego jak szablon. Czym jest szablon zależy od nomenklatury przyjętej przez framework którego używasz o ile w ogóle takie coś w tym frameowrku istnieje. Samo MVC żadnych szablonów nie wymaga.

      Eh, MVC jest ideą, która nic nie znaczy bez implementacji. Jeśli większość implementacji tworzy ten podział, to znaczy, że ten podział jest potrzebny. Odwoływanie się do czystej idei, która – jak sam przyznałeś – nie istnieje, jest konfliktem ideologicznym, który do niczego nie prowadzi.

      Ok, ale co to ma wspólnego z MVC? Model eventowy to jedno podejście, MVC to drugie podejście. Oba się wykluczają.

      Ale coś Ty się uparł na to MVC? Sam przyznajesz, że czyste MVC nie istnieje, więc… czemu kłócisz się z rozwiązaniem, które faktycznie działa?

      Ok, fajnie. Tylko czemu polemizujesz z czymś czego nie pisałem? Poza tym tutaj widać, że z MVC nie masz za wiele do czynienia. Od lat to podejście jest uważane, za przestarzałe. Model nie odpowiada już za logikę biznesową. Logika biznesowa ląduje w serwisach które w Angularze działają bardzo ok.

      Przeczysz sam sobie. Non stop odwołujesz się do czystej idei MVC, gdzie istnieją tylko 3 elementy, po czym nagle mówisz o serwisach. A to przecież nie jest już czysty MVC. Zauważ, że de facto żadna implementacja (framework) zawierający serwisy nie nazywany jest frameworkiem MVC – w tym Angular.js.

      Ale zauważyłeś, że artykuł mówi o backendzie a nie fronedzie?

      Ale zauważyłeś, że Angular ma służyć tworzeniu SPA, którym backend praktycznie niepotrzebny i model Sieciowy zostaje przeniesiony na klienta? Router i rozwiązywanie zasobów znajduje się w JS po stronie klienta – zatem nastąpiło przesunięcie backendu na frontend. Jeśli nie w całości, to przynajmniej w sporej części.

      Wywołanie ng-click to jest nic innego jak żądanie użytkownika na które kontroler odpowiada. Kontroler powinien to obsłużyć i wysłać to do serwisu (czy dawniej modelu). Przecież to jest wzorcowy przykład MVC O.o

      Nie myślisz w kategorii Sieci. Oprócz podziału aplikacji na warstwy istnieje jeszcze podział warstwowy narzucony przez same technologie. HTML to warstwa treści, CSS – prezentacji, a JS (dokładniej: DOM) – zachowania interfejsu. I dopiero na tych warstwach jest sens budowania architektury aplikacji. I tutaj sobie można robić MVC itd. Warstwa zachowania interfejsu to właśnie owe V – widok. Tak przy okazji: polecam pobawić się w tworzenie aplikacji przy wykorzystaniu Content Security Policy, gdzie taki podział jest po prostu wymuszony. I dobrze. Bo HTML nie jest miejscem na takie rzeczy.

      Wskaż mi który dokładnie fragment dokumentacji HTML5 mówi, że customowe tagi czy atrybuty są niepoprawne.

      https://www.w3.org/TR/html5/infrastructure.html#conformance-requirements + https://www.w3.org/TR/html5/introduction.html#how-to-catch-mistakes-when-writing-html:-validators-and-conformance-checkers + https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors

      Sorry, ale powtarzasz bezmyślnie zasłyszane slogany. Gdzieś przeczytałeś na stronie kogoś mądrzejszego, że MVC w „sieci” nie istnieje ale nie załapałes, że ten ktoś mówił o backendzie. Zresztą dopiero co wysłałeś mi linka aby udowadnić, że AngularJS to wzorzec RMR w artykule który mówi o framewrokach backendowych

      Sorry, ale mówię z własnego doświadczenia. A fakt, że Angular służy tworzeniu SPA pozwala go porównywać do backendu. Więc tak, załapałem w pełni i świadomie podałem tego linka.

      Jak ktoś mówi, że MVC w „sieci” nie istnieje ma na myśli WYŁĄCZNIE backend gdzie jesteśmy ograniczeniu przez specyfikację protokołu HTTP i faktycznie tam się nie da odtworzyć idealnego MVC. A co niby niemożliwa zaimplementowanie MVC w frontendzie? Nie ma czegoś takiego.

      Ograniczenie przez protokół HTTP? Czemu z Sieci chcemy zrobić nie-Sieć? Poza tym: skoro niby nic nie uniemożliwia, to… dlaczego nie ma?

  15. Polecam sprawdzić, czym jest Progressive Enhancement i dlaczego wciąż jest ważny.

    Ilu użytkowników jest zmuszona korzystać z internetu bez JS? Które przeglądarki czy rozszerzenia dla osób niewidomych i niedowidzących go nie obsługują? Czy za Progressive Enhancement kryje się cokolwiek praktycznego poza mglistą ideą?

    Warto znać dogłębnie Sieć, żeby nie próbować innym wmówić, że jakieś ideologiczne rozumienie pewnego design patternu jest dobre tylko dlatego, że „takie powinno być”. W Sieci nie ma MVC, bo nie działa. I to jest fakt, któremu nie da się zaprzeczyć.

    Jak to nie działa MVC? W AngularJS działa.

    Ale coś Ty się uparł na to MVC? Sam przyznajesz, że czyste MVC nie istnieje, więc… czemu kłócisz się z rozwiązaniem, które faktycznie działa?

    WTF? AngualrJS implementuje MVC na tyle na ile może i to TEŻ działa.

    Przeczysz sam sobie. Non stop odwołujesz się do czystej idei MVC, gdzie istnieją tylko 3 elementy, po czym nagle mówisz o serwisach.

    Sorry. Mam dość. Co Ty próbujesz właściwie udowodnić w tej dyskusji bo ja tu widzę jakieś głupie czepianie się. Model MVC został wynaleziony w latach 70! Od tego czasu ewoluował w taki sposób, że model stracił na znaczeniu. Dziś każdy implementuje MVC trochę inaczej ale dalej to jest MVC. Po drugie gdzie się niby odwołuje do czystego MVC? Ja przez całą dyskusję powtarzam, że to bez znaczenia, że MVC zaimplementowane w Angularze nie jest idealne a dostosowane do potrzeb środowiska a to Ty ciągle mi powtarzasz, że „hurr durr ale po MVC skoro nie jest idealne!”.

    Zauważ, że de facto żadna implementacja (framework) zawierający serwisy nie nazywany jest frameworkiem MVC – w tym Angular.js.

    WTF? Czy Ty wiesz w ogóle czym są serwisy? Serwis to zwykła klasa która zwykle jest interfejsem do wykonywania logiki biznesową a nie jakieś rozwiązanie które czyni frameowrk MVC albo nie MVC. Metoda .service() w Angularze o której pewnie pomyślałeś to swego rodzaju cukier składniowy na Depedency Injection. Nie znasz podstawowych pojęć O.o Każdy język obiektowy de facto zawiera serwisy wiec zgodnie z tym co napisałeś żaden framework nie może być MVC 😀

    Tak przy okazji: polecam sobie pobawić się w tworzenie aplikacji przy wykorzystaniu Content Security Policy, gdzie taki podział jest po prostu wymuszony.

    WTF? Co to ma do rzeczy? Rzucasz losowymi hasłami z nadzieją, że nie zrozumiem o co chodzi? Jak niby Content-Seciurity-Policy, którego głównym zadaniem jest ochrona przed XSS i podobnymi ma wymuszać jakiś podział :D?

    Ale zauważyłeś, że Angular ma służyć tworzeniu SPA, którym backend praktycznie niepotrzebny i model Sieciowy zostaje przeniesiony na klienta? Router i rozwiązywanie zasobów znajduje się w JS po stronie klienta – zatem nastąpiło przesunięcie backendu na frontend. Jeśli nie w całości, to przynajmniej w sporej części.

    No i co z tego? Co z tego, że masz router, rozwiązywanie zasobów czy co tam robiłeś w backendzie skoro kod działa w przeglądarce i nie ogranicza Cię HTTP które uniemożliwiało zaimplementowanie MVC?

    Ograniczenie przez protokół HTTP? Czemu z Sieci chcemy zrobić nie-Sieć? Poza tym: skoro niby nic nie uniemożliwia, to… dlaczego nie ma?

    Jak napisałem – jest. Nie jest to idealne odwzorowanie MVC bo puryści zawsze znajdą odstępstwa. Jednak nie zmienia to faktu, że AngularJS wzoruje się na MVC, implementuje MVC i w porównaniu do innych robi to całkiem nieźle. Na pewno bliżej Angularowi do MVC niż Django, Symfony, Zend, Spring czy Backbone, React a nawet QT (!).

    Wybacz, ale nie masz zielonego pojęcia czym jest MVC. Nie odróżniasz MVC we frontendzie i backendzie. Nie wiesz czym jest model, domena i nie znasz podstawowych wzorców projektowych. Ja nie wiem czy to robisz wyłącznie w sieci ale gorąco Cię zachęcam, abyś szybko nauczył się programować i wzorców projektowych bo AngularJS wymaga takiej wiedzy aby móc go poprawnie używać.

    Podtrzymuje to co napisałem na początku w pierwszym komentarzu.

    1. Ilu użytkowników jest zmuszona korzystać z internetu bez JS? Które przeglądarki czy rozszerzenia dla osób niewidomych i niedowidzących go nie obsługują? Czy za Progressive Enhancement kryje się cokolwiek praktycznego poza mglistą ideą?

      I nie przejrzałeś choćby artykułu, który Ci podałem… A tam wszystko jest wyraźnie wytłumaczone.

      Jak to nie działa MVC? W AngularJS działa.

      Sam sobie przeczysz.

      Sorry. Mam dość. Co Ty próbujesz właściwie udowodnić w tej dyskusji bo ja tu widzę jakieś głupie czepianie się. Model MVC został wynaleziony w latach 70! Od tego czasu ewoluował w taki sposób, że model stracił na znaczeniu. Dziś każdy implementuje MVC trochę inaczej ale dalej to jest MVC. Po drugie gdzie się niby odwołuje do czystego MVC? Ja przez całą dyskusję powtarzam, że to bez znaczenia, że MVC zaimplementowane w Angularze nie jest idealne a dostosowane do potrzeb środowiska a to Ty ciągle mi powtarzasz, że „hurr durr ale po MVC skoro nie jest idealne!”.

      Sorry, ale to wygląda tak, jakbyś wgl nie przeczytał artykułu, który komentujesz, tylko wybrałeś losowe fragmenty i próbujesz mi wmówić, że Angular to MVC i tylko dlatego, że nie znam MVC nie lubię Angulara. A to jest po prostu bardzo słaby argument ad personam.

      WTF? Czy Ty wiesz w ogóle czym są serwisy? Serwis to zwykła klasa która zwykle jest interfejsem do wykonywania logiki biznesową a nie jakieś rozwiązanie które czyni frameowrk MVC albo nie MVC. Metoda .service() w Angularze o której pewnie pomyślałeś to swego rodzaju cukier składniowy na Depedency Injection. Nie znasz podstawowych pojęć O.o Każdy język obiektowy de facto zawiera serwisy wiec zgodnie z tym co napisałeś żaden framework nie może być MVC

      Ładnie odwracasz kota ogonem, ładnie :> Znam pojęcia, więc radzę po prostu mnie nie obrażać, bo jak na razie nie podałeś żadnego merytorycznego argumentu ponad kłótnię ideologiczną o MVC.

      WTF? Co to ma do rzeczy? Rzucasz losowymi hasłami z nadzieją, że nie zrozumiem o co chodzi? Jak niby Content-Seciurity-Policy, którego głównym zadaniem jest ochrona przed XSS i podobnymi ma wymuszać jakiś podział :D?

      W takim razie śmiem przypuszczać, że nie korzystałeś z CSP, bo podstawowa rzecz, jaką wymusza, jest podział na HTML, CSS i JS. Ochrona przed XSS wymaga w podstawowej swojej wersji wyjęcia wszelkich bindingów DOM-owych poza HTML. A zresztą – tłumaczyłem to w artykule, wraz z kontekstem… Nie ma sensu, żebym znów powtarzał wszystko w komentarzach.

      No i co z tego? Co z tego, że masz router, rozwiązywanie zasobów czy co tam robiłeś w backendzie skoro kod działa w przeglądarce i nie ogranicza Cię HTTP które uniemożliwiało zaimplementowanie MVC?

      Trochę szacunku do mnie. Traktujesz mnie jak śmiecia, który nic nie umie i szczeka. A prawda jest taka, że mam na tyle wiedzy i doświadczenia, by móc krytykować frameworki, takie jak Angular. I to bez potrzeby uciekania się do krytyki czysto ideologicznej.

      W sumie bardzo ciekawi mnie stwierdzenie, że HTTP uniemożliwia implementację MVC w backendzie (czemu?) skoro mechanizmy HTTP są przeniesienie także do klienta. Czym się różni router w backendzie od routera w kliencie skoro tu i tu mamy URL, a model żądanie → odpowiedź jest ten sam?

      Jak napisałem – jest.

      To dlaczego nikt go oficjalnie nie nazywa MVC, a wśród programistów JS nazywa się go MV*? Angular nie jest MVC i mało kto twierdzi inaczej. Istnieje nawet model SDC – właśnie dlatego, że to nie MVC.

      Wybacz, ale nie masz zielonego pojęcia czym jest MVC. Nie odróżniasz MVC we frontendzie i backendzie. Nie wiesz czym jest model, domena i nie znasz podstawowych wzorców projektowych. Ja nie wiem czy to robisz wyłącznie w sieci ale gorąco Cię zachęcam, abyś szybko nauczył się programować i wzorców projektowych bo AngularJS wymaga takiej wiedzy aby móc go poprawnie używać.

      Skoro masz mnie obrażać, to nie trać czasu i nie komentuj. Bo jedyne, co robisz, to jedziesz po mnie i próbujesz mi wmówić, że nie umiem programować. Więc pozwól, że Ci coś powiem: odwal się ode mnie. Umiem programować i znam wzorce projektowe. I na szczęście to nie Ty będziesz mnie z tego oceniać. EOT.

  16. Sorry, ale mówię z własnego doświadczenia. A fakt, że Angular służy tworzeniu SPA pozwala go porównywać do backendu. Więc tak, załapałem w pełni i świadomie podałem tego linka.

    Nieświadomie. To, że nie można zaprojektowac idealnego MVC w sieci to nie fakt, że kod działa w „sieci” a to, że w backendzie cała komunikacja przechodzi przez HTTP. We frontendzie tego ograniczenia nie masz i tutaj programowanie interfejsów praiwe w ogóle nie różni się od programowania aplikacji okienkowych do których został zaprojektowany MVC. To, że AngularJS może przejąć zadania backendu nie ma ŻADNEGO znaczenia.

  17. I nie przejrzałeś choćby artykułu, który Ci podałem… A tam wszystko jest wyraźnie wytłumaczone.

    Po prostu żaden z argumentów poza dostosowaniem stron dla osób niepełnosprawnych mnie nie przekonał. Faktycznie, w AngularJS takie dostosowanie jest trudniejsze ale nie niemożliwe. Znam ideę PE. Stosowałem ją jako WebDev jeszcze do 2015 roku! Tylko dziś, widząc różne statystyki wiedząc jak korzystają z internetu niepełnosprawni nie widzę już zalet tego podejścia. Dziś strony bogate w JS są dostępne dla każdego.

    Trochę szacunku do mnie. Traktujesz mnie jak śmiecia, który nic nie umie i szczeka. A prawda jest taka, że mam na tyle wiedzy i doświadczenia, by móc krytykować frameworki, takie jak Angular. I to bez potrzeby uciekania się do krytyki czysto ideologicznej.

    Przepraszam. Serio. Ale nie zmienia to faktu, że mylisz pojęcia.

    W sumie bardzo ciekawi mnie stwierdzenie, że HTTP uniemożliwia implementację MVC w backendzie (czemu?) skoro mechanizmy HTTP są przeniesienie także do klienta. Czym się różni router w backendzie od routera w kliencie skoro tu i tu mamy URL, a model żądanie → odpowiedź jest ten sam?

    Rotuer się niczym nie różni ale różni się działanie kontrolerów. W backendzie mamy kontrolery które czekają na request, wysyłają dane do serwisów (modelów), otrzymane wyniki wrzucają w szablon i wysyłają do klienta. Tak na dobrą sprawę nie ma nawet tutaj kontrolerów bo one niczego nie kontrolują a pełnią jedynie rolę widoków. Dlatego np. framework Django nazwą swoją architekturę MVT (model-view-template). Z drugiej strony wiele innych frameworków nazywa swoją architekturę MVC i nikt się tego nie czepia.

    Na czym polega problem? W backendzie szablon jest statyczny i nie ma dwukierunkowej komunikacji. Zaktualizujesz dane w modelach? Widok u klienta zsotaje stary. Użytkownik kliknie checkboxa? Póki nie wyślesz requesta kontroler o tym nie wie.

    Brak aktywnej dwukierunkowej komunikacji sprawia, że w backendzie nie da się zrobić MVC. Tymczasem w AngularJS-ie to wszystko masz. $scope jest dwukierunkowy. Widok nie jest statyczny. Od taka drobna różnica.

    To jest powód, dla którego według wielu w „sieci” (tj backendzie) nie ma prawdziwego MVC. Czy ta jedna różnica powinna o tym decydować? Ja w sumie nie wiem. To jest dość subiektywne.

    I teraz masz dwie opcje. Albo nie zgodzić się ze mną i uznać, że to jednak jest MVC i wtedy Twoje linki które udowadniają, że jednak w sieci nie ma MVC staną się bezcelowe albo zgodzić się ze mną, że jednak AngularJS to MVC.

    I zostaje ostatnie pytanie. Czy MVC to dobry sposób tworzenia interfejsów? Od lat 70 nikt nie wymyślił niczego lepszego. Nowy JavaScript i AngularJS pozwoliły przenieść sprawdzony MVC do świata stron WWW. Skoro model eventowy jest taki super, dlaczego nie stosuje się go zamiast MVC? Jedyne co na tym tracimy na MVC to klasyczne podejście PE ale znowu wracam do pierwszego pytania – kto traci na porzuceniu PE? Bo moim zdaniem nikt.

  18. https://www.w3.org/TR/html5/infrastructure.html#conformance-requirements + https://www.w3.org/TR/html5/introduction.html#how-to-catch-mistakes-when-writing-html:-validators-and-conformance-checkers + https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors

    Jeśli zdecydujesz się odblokować mój komentarz to ciekaw jestem w którym dokładnie miejscu test to opisane jako błąd. Przyznam szczerze, że zamartwiłem się widząc te linki bo już bałem się, że coś przeoczyłem ale dalej nie widzę, aby gdzieś było to opisane jako błąd.

    1. Po pierwsze, wytłumaczyłem dokładnie, co znaczy słowo „niepoprawne”:

      Niepoprawność oznacza niezgodność ze specyfikacją HTML5

      Ale skoro chcesz cytaty 😉

      Conforming documents are those that comply with all the conformance criteria for documents

      A tymi kryteriami jest specyfikacja. Dokładniej jest to opisane w kryteriach dla walidatorów:

      Conformance checkers must verify that a document conforms to the applicable conformance criteria described in this specification.

      A teraz fragment, który powinien nas zainteresować najbardziej:

      There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.

      I to jest to, o czym mówię: zgodność na poziomie elementów języka, nie składni. No i można zauważyć, że dokumenty nieprzechodzące walidacji nazywane są „non-conformant”, czyli niezgodnymi ze specyfikacją HTML5. Ergo: są niepoprawnym dokumentami HTML5 mimo że ich składnia jest zgodna ze składnią HTML. I o to chodzi. Nie widzę żadnego sensu w wychodzeniu poza zdefiniowaną semantykę, zwłaszcza, że atrybuty [data-*] działają tak samo dobrze jak [ng-*].

  19. . Nie widzę żadnego sensu w wychodzeniu poza zdefiniowaną semantykę, zwłaszcza, że atrybuty [data-*] działają tak samo dobrze jak [ng-*].

    Jeśli to dla Ciebie jest takie ważne aby walidator W3C wyświetlił Ci zielony napis (bo innych zalet to nie ma) to AngularJS dopuszcza używanie tagów zgodnych ze specyfikacją np. data-ng-click. A na koniec niech wypowie się autor walidatora W3C na temat Angulara:

    W3C HTML5 validator maintainer here. We’ve had discussions about how to deal with better facilitating validation of documents that contain custom attributes like Angular’s ng-* attributes—attributes which though while non-standard are still very widely and correctly used, and so having the validator emit “error” messages about them isn’t really helping authors.

    .
    http://stackoverflow.com/questions/18607437/should-i-care-about-w3c-validation

    Trochę szacunku do mnie. Traktujesz mnie jak śmiecia, który nic nie umie i szczeka. A prawda jest taka, że mam na tyle wiedzy i doświadczenia, by móc krytykować frameworki, takie jak Angular.
    To nie ja napisałem autorytatywny artykuł a teraz w komentarzach pisze bzdury pokroju:

    Zauważ, że de facto żadna implementacja (framework) zawierający serwisy nie nazywany jest frameworkiem MVC – w tym Angular.js.

    Nie wiesz czym są serwisy i na czym polega samo MVC a uważasz, że masz doświadczenie by krytykować AngularJS. Serio? Nie – nie masz takiego doświadczenia. Nie traktuje Cię jak śmiecia ale tak – niewiele potrafisz a szczekasz. I gdy palcem pokazuje Ci, gdzie się mylisz to zaczynasz gryźć palec 😉

    Nie czepiałbym się, gdybyś w artykule skoncentrował się np. na sensie używania MVC we frontendzie (choć i z tym bym się nie zgodził, ale wtedy bym nie wytykał błędów) a Ty jedziesz po samej idei MVC, piszesz jakieś bzdury, że MVC miesza logikę biznesową z prezentacją gdy samo MVC jest uważane za dobry pattern przez takie ikony świata IT jak choćby Robert C. Martin.

    Kończąc temat, jednego z twórców AngularJS miałem okazje poznać osobiście na konferencji w Londynie i raczej wątpię, byś miał większe doświadczenie od niego.

    PS: Szkoda, że chcesz opublikować mojego wcześniejszego komentarza.

    1. Jeśli to dla Ciebie jest takie ważne aby walidator W3C wyświetlił Ci zielony napis (bo innych zalet to nie ma) to AngularJS dopuszcza używanie tagów zgodnych ze specyfikacją np. data-ng-click.

      Wiem, ale nie tego dotyczy krytyka. Zresztą to już wyjaśniałem.

      A na koniec niech wypowie się autor walidatora W3C na temat Angulara:

      W jego wypowiedzi nie ma nic, co by wskazywało, że to sprawia, że nagle dokumenty są zgodne ze specyfikacją HTML5 (to tylko filtrowanie informacji o błędach)… Zresztą doskonale sobie zdaję sprawę z tego jak działa walidator – o czym zresztą swego czasu pisałem.

      To nie ja napisałem autorytatywny artykuł a teraz w komentarzach pisze bzdury pokroju:

      Artykuł nie jest autorytatywny, lecz intersubiektywny – odwołuje się do wielu różnych źródeł… Co ciekawe, to Ty praktycznie nie odwołałeś się do żadnego źródła i to Twoja wypowiedź jest autorytatywna.

      Nie wiesz czym są serwisy i na czym polega samo MVC a uważasz, że masz doświadczenie by krytykować AngularJS. Serio? Nie – nie masz takiego doświadczenia. Nie traktuje Cię jak śmiecia ale tak – niewiele potrafisz a szczekasz. I gdy palcem pokazuje Ci, gdzie się mylisz to zaczynasz gryźć palec

      Jawnie nadinterpretujesz moje wypowiedzi i chcesz mnie dzięki temu ośmieszyć. Wiem, czym są serwisy i dlatego nie próbowałem tłumaczyć tego terminu. I nie, wcale nie myślałem wówczas o Angularze, ale o frameworkach pokroju Symfony. Ale na to mi odpowiesz, że to backend i tyle w temacie. A co do mojego doświadczenia – ja wiem lepiej niż Ty, że mam doświadczenie. Mój pracodawca również.

      Nie czepiałbym się, gdybyś w artykule skoncentrował się np. na sensie używania MVC we frontendzie (choć i z tym bym się nie zgodził, ale wtedy bym nie wytykał błędów) a Ty jedziesz po samej idei MVC, piszesz jakieś bzdury, że MVC miesza logikę biznesową z prezentacją gdy samo MVC jest uważane za dobry pattern przez takie ikony świata IT jak choćby Robert C. Martin.

      Artykuł nie jest o MVC, bo Angular to nie jest MVC. Stąd twierdzenie, że plotę bzdury o MVC, bo Ty twierdzisz, że artykuł jest o MVC jest… tak bardzo bzdurne, że nie mam zamiaru tego komentować. A próba wmówienia mi, że twierdzę, że MVC miesza logikę biznesową z prezentacją jest jawnym oszczerstwem – zwłaszcza, że w moich komentarzach to już tłumaczyłem. Ale widać, że po prostu próbujesz mnie gnoić przez naginanie moich słów.

      Kończąc temat, jednego z twórców AngularJS miałem okazje poznać osobiście na konferencji w Londynie i raczej wątpię, byś miał większe doświadczenie od niego.

      Ojej, straszne po prostu. Idę się pociąć 😀

      PS: Szkoda, że chcesz opublikować mojego wcześniejszego komentarza.

      Każdy komentarz jest zatwierdzony (edit: znalazłem jeden w spamie – ale serio, nie mam już ochoty na niego odpowiadać; wszystko jest w artykule i w linkach, które Ci podałem; a alternatywa, którą mi dajesz – zgodzenie się z Tobą lub… zgodzenie się z Tobą – to po prostu śmiech na sali). Ale żadnego kolejnego nie zatwierdzę – będę usuwał. Bo nie mam ochoty pozwalać komuś bezkarnie mnie obrażać. Zwłaszcza, że ten ktoś jest totalnym no-name’em (ładny masz spamowy mail, prawda?). Więc – nie trudź się więcej i nie marnuj swojego czasu na próby oczerniania mnie.

  20. Hah! Praktycznie w 100% moje przemyślenia na temat Angulara 😀 Przy okazji, tak czytam sobie tą waszą kłótnie w komentarzach zasadzie zgadzam się z Tobą Comandeer prawie ze wszystkim, zwłaszcza z tym, że Angular niszczy progressive enhancement ale niestety jako były backendowiec muszę z przykrością przyznać, że w jednej kwestii rację jednak miał MichałD. Troche mylisz pojecia w kwestii MVC bo faktycznie artykuł który zalinkowales wczesniej dotyczył backendu a nie frontendu. MVC w backendzie a frontedzie to zupelnie inna bajka i faktycznie MVC w backendzie nie istnieje ale we frontendzie nic nie stoi na przeszkodzie aby je zrealizować.

    W ogóle najłatwiej wywołać kłótnię wśród programistów, najlepiej doświadczonych nazywając coś MVC 😀 Zaraz wstanie 10 i każdy z tych 10 będzie miał inną teorią czym to coś jest i zaczną padać skróty takie jak MVT, MCT, MVT, MVW, HMVC 😀 Powstało już tyle wariacji MVC a i sama idea MVC przez lata przybierała różne formy, że dziś ciężko powiedzieć co nim jest a co nie.

    1. Ależ ja doskonale zdaję sobie sprawę, że artykuł dotyczył backendu. Jednak front nie może istnieć bez HTTP, co tak trochę haczy z tym czystym MVC.

      Tak, we froncie MVC jest o wiele czystsze, ale wciąż kręci się wokół HTTP. IMO dostatecznie mocno, by nie musieć być nazywane MVC.

  21. tak w 50% sie zgadzam

    Progressive Enhancement? Jeśli dostarczam aplikacje desktopową z wbudowanym Chromium do jej obsługi po co mi to? IE9? Przeglądarka z wyłączonym JS?

    Czy pomyślałeś że niektóre aplikacje mogą robić po stronie klienta coś więcej niż jedynie pobierać zrenderowane templatki z serwera??

    Serwer zrenderuje to szybciej?

    to zależy od serwera, i bardziej liczylbym na Chrome po stronie klienta jesli zasoby serwerowe są ograniczone. To że Twoja firma ma do dyspozycji klaster to nie znaczy że każda tak ma. Niektórzy użyją WebRTC i komunikacji P2P by maksymalnie odciążyć serwer, albo by sie go pozbyc w cholere na rzecz udostepniania statycznego systemu plików. Pamietaj o tym że nie zawsze chcemy „stronki”, tylko technologii HTML5 dla naszego frontu

    Providery i DI

    nic nowego, jak ktoś bawił się w Symfony2 cos takiego go nie zdziwi. Każdy framework ma jakąś specyfike, do tej idzie sie przyzwyczaić, jest prosta.

    jest wolny?

    faktycznie, na $scope’y trzeba uważać, i wykorzystywać je tylko wtedy gdy to niezbędne. Zawalenie $watchers skutkuje slow-downem. Jeśli do tej praktyki sie zastosujesz, będzie szybki. $scope to nie śmietnik, $rootScope to nie God Object to przechowywania glupot miedzy stanami.
    Każda interakcja z nimi powinna mieć uzasadnioną widoczną dla usera zmiane.

    dyrektywa ng-controller

    Jest, niestety. Ale nie musisz jej używać. Dodaj controller z poziomu routera, będzie działać. Mi tez sie podoba ona średnio

    wsparcie IE9?

    Błagam, Commodore64 też wspieramy? Windows 98? XP?
    IE6? Jak każda kolejna strona zacznie wyswietlac monit o zmiane przeglądarki na normalną, może userzy w końcu ją zmienią i nie będziemy musieli tworzyć osobnego CSS’a dla nich
    Świat idzie do przodu, oprogramowanie zwłaszcza. Pogódźmy sie z tym że albo mamy powerfeatury z HTML5 albo sporą kompatybilność wsteczną

    bindingi – w HTML, nie w JS

    Jako też osoba mająca do czynienia z frameworkiem Android, powiem że bardzo powszechnie uzywana jest biblioteka załatwiająca bindingi w XMLowych templatkach Androida. Kiedyś sie je importowało do Javy, i tam sie je konfigurowało, teraz robi sie binding. Jak uzywasz Twig – robisz TO po stronie serwera. I Twoje templatki wyglądają podobnie
    Nie wiem co Cie dziwi, to tylko przeniesienie tej logiki z PHP/Javy na JS.

    (jeżeli chcesz deklaratywnego języka szablonów, spójrz na XSLT i inne zwariowane dziwactwa w XML)
    OK, pisać XML by wyszedł z tego HTML, super opcja…

    Ponieważ JS powinien być w JS, nie w naszym HTML.

    Co otworze repo na githubie to widze pliki *.tpl gdzie robi sie to samo. Masz staly HTML ze zmiennymi wrzuconymi przez jakiś kontroller. Też mi nowość.

    Nadal uważam że nie ma znaczenia czy to robi serwer czy klient. W pewnych przypadkach to klient jest szybszy.

    1. Progressive Enhancement? Jeśli dostarczam aplikacje desktopową z wbudowanym Chromium do jej obsługi po co mi to? IE9? Przeglądarka z wyłączonym JS?

      Polecam najpierw poczytać czym jest PE. Nie wiem skąd wytrzasnąłeś IE9 ani przeglądarkę z wyłączonym JS (zwłaszcza, że zaznaczam to w tekście…). Poza tym argument o aplikacji desktopowej nijak się ma do pisania dla Sieci (bo to aplikacja desktopowa, huh).

      to zależy od serwera, i bardziej liczylbym na Chrome po stronie klienta jesli zasoby serwerowe są ograniczone.

      Masz benchmarki to potwierdzające? Gdyby tak było, żaden framework nie szedłby w server-side rendering… a wszystkie obecnie idą. Dopiero Service Worker + offline first są w stanie coś zmienić w temacie. Poza tym pisałem, że chodzi przede wszystkim o first-time rendering (coś, co dziś się zwie „prehydratingiem”).

      Pamietaj o tym że nie zawsze chcemy „stronki”, tylko technologii HTML5 dla naszego frontu

      Szkoda, że wyrywasz sobie moje wypowiedzi z kontekstu, bo inaczej takiego argumentu po prostu nie mógłbyś użyć… Mówię o posyłaniu danych, bez żadnego HTML-a, co powoduje, że renderowanie zaczyna się dopiero w momencie dociągnięcia całego JS-a. A to jest wolniejsze niż pchnięcie prerenderowanego HTML-a.

      nic nowego, jak ktoś bawił się w Symfony2 cos takiego go nie zdziwi. Każdy framework ma jakąś specyfike, do tej idzie sie przyzwyczaić, jest prosta.

      Ale Symfony to backend. Poza tym DI w Angularze wygląda jak przepisanie AMD po swojemu (zresztą do tego piję w tekście…).

      wsparcie IE9?

      Błagam, Commodore64 też wspieramy? Windows 98? XP?
      IE6?

      Może w końcu przejdziemy do poważnych argumentów? Bo na razie wyciągasz je z kapelusza…

      Co do szablonów vs widoku: pół tekstu jest o tym i Twój argument o tym, że w templatkach są bindingi, jest po prostu dla mnie całkowicie nie na temat. Tak, templatki mogą se mieć bindingi… Ale nie jeśli nie są tekstem, a drzewkiem. Co dodatkowo sprawia, że drzewko strony jest traktowane jako szablon, nie gotowy widok. Zresztą – pisałem o tym w tekście…

  22. Pracowałem w jQuery, kilka miesięcy. Potem kilkanaście w AngularJS. Teraz uczę się Backbone pod kolejny projekt i prawie płaczę 🙂 To sieczka znana mi z jQuery plus nowe API, plus N nowych abstrakcji, gdzie AngularJS to proste POJO. Gdybym miał taką opcję, wrocilbym do Angulara bez chwili wahania. W Angularze klikam prawym i widzę co się wola po kliknięciu, w Backbone latam po JSach i szukam selektora, wg mnie Angular jest banalny w nauce, a że miesza HTML z JS i łamie zasady oddzielenia czegoś tam od czegoś tam? Coś za coś, Wg mnie upraszcza mi to życie w tym sensie, że mniej mam szukania, prościej mi warunkowo ukryć element itd… Angular skasował n jawne operacje na DOM, by pisać w nim jedyne co musze wiedzieć to jak zadeklarować kontroler i zwrócić obiekt w fabryce, skomponowane providery nie są potrzebne. Więc myślę, że Autor trochę przesadza i wpada w ton „a bo wy młodzi to tamto a za naszych czasów było lepiej”, trochę wg mnie strachy na lachy. Żeby nie było że autora nie szanuję i nie wiem kto to – wiem, że Comandeer to doświadczony programista, na biurku leży jego książka czekająca na więcej wolnego czasu (z niej zresztą dowiedziałem się o artykule 🙂 ). No ale pozwoliłem sobie się nie zgodzić, z perspektywy kogoś mniej doświadczonego, młodszego, może też troszkę bardziej otwartego na zmiany 🙂 Oczywiście, pisze z perspektywy roku 2017 gdzie AngularJS nieco się zmienił, kontrolery umierają na naszych oczach a sam post jest z 2014 – czy dziś, po ewentualnym zapoznaniu się z dzisiejszymi standardami Autor podtrzymałby aż tak negatywną opinię? Jestem ciekaw. Pozdrawiam i życzę sukcesów! Przepraszam za ewentualne błędy w wiadomości, piszę z Androida i trochę nie do końca dobrze się tu pisze z telefonu 🙂

    1. Rzeknę tak: z której strony bym na Angulara 2+ nie patrzył, tak POJO tam dostrzec nie umiem…

      Owszem, Angular poszedł do przodu i to znacznie – niemniej cały ekosystem JS-owy również i to, co uderzało w Angularze 1.x, czyli jego kompleksowość, w przypadku późniejszych wersji uderza jeszcze bardziej. I uważam, że właśnie z tego powodu React – mimo że sam jest bardzo kompleksowy – wygrywa z Angularem. I z tego samego powodu Vue.js – które stara się uprościć zarówno Angulara jak i Reacta, czerpiąc z obu po trochu – zaczyna doganiać Reacta. Z tego też samego powodu Ember nigdy nie był niesamowicie popularny (bo ma wręcz własny ekosystem!). Potrzebujemy efektywnych rozwiązań, niekoniecznie kompleksowych.

      1. Jeśli chodzi o POJO – chodzi mi o AngularJS (Angular 1, do którego zresztą cały czas się odnoszę – 2+ znam słabo, zrobiłem tylko obowiązkową TodoApp jeszcze na jakiejś becie), gdzie gdy przypisujesz do kontrolera (np this.user = {id:2, name:”john”}), to się wyrujowuje w HTML, prosty obiekt JS. Bez konieczności implementacji/dziedziczenia czegokolwiek. Analogicznie z serwisami – też są to POJO, z factory zwracasz zwykły obiekt, tyle, że sam go nie tworzysz poprzez wywołanie funkcji (factory) czy operator new (service). Ale nic nie szkodzi, jeżeli ktoś uparcoe chce stworzyć instancje samemu, by zwracał sobie konstruktor 🙂 Backbone (uczepiłem się go, ale jego znam najlepiej ze „starego świata”, używam w połączeniu z Marionette) w moim odczuciu kompiluje rzeczy niesamowicie – klasa View, Model, Collection z pierdylionem funkcji gdzie nawet element do kolekcji nie dodaje się jak w JS poprzez push tylko add(). W Angularze to zwykła lista, bez cudakowania. Piszesz w artykule „Teraz muszę mieć usługę dostarczającą provider fabryki [factory], który dziedziczy z fabryki fabryk” – i tego właśnie nie rozumiem, bo rejestruję funkcję zwracającą obiekt, niedziedziczącą po niczym, niemającą żadnym naleciałości Angularowych (poza DI). Gdyby wynieść każdą taką funkcję poza Angulara, wystarczy odpalając ja podać zależności do wywołania i wszystko gra (sam tak robiłem, jak z QUnit pisałem proste testy jednostkowe).
        Z Angularem jest trochę jak z konfiguracją Springa adnotacjami na poziomie klas Javy vs konfiguracja z poziomu plików XML. Czytałem artykuł mówiący o tym, że te adnotacje przemieszały konfigurację z logiką itd… I to prawda być może nawet, ale są zwyczajnie bardziej przyjazne – i tak patrzę na to, gdy krytykuje się Angulara za wstrzykiwanie JS do plików HTML czy np za ukrywanie operacji na DOM. Osobiście DOM mnie zawsze męczył, cieszy mnie to że Angular go przykrył, teraz w Backbone/Marionette widzę wiele ręcznych operacji na DOM które Angular przykryłby o niebo czyletniejszym dla mnie (ng-if/ng-class) – dla wielu ludzi jest zwyczajnie prostszy niż natywny JS/jQuery/mutacje jQuery by zrobić z jQuery MVCośtam (Bakcbone). Wielu ludziom pozwala wejść w programowanie font-endu, uczynił go znacznie bardziej przystępnym – czyni je prostszym bez konieczności znania niskopoziomowych operacji, w jednym z komentarzy porównałeś taką sytację do wsadzenia człowieka z ulicy do samolotu – no ale nie przesadzajmy 🙂 Dawno minęły czasy, gdy programowała garstka ludzi, i siedzieliśmy po piwnicach w sweterkach w kratkę 🙂 Angular (nie tylko rzecz jasna, ale w dużej mierze) pozwala programowaniu „wejść pod strzechy” – a jeśli chodzi o to, że wymusza konwencje… To jedna z rzeczy za które go kocham 🙂 Kocham konwencje – dzięki konwencjom, mimo że na backendzie sie nie znam, z racji że wszędzie jest konwencja @Controller -> @Service -> @Repository i DTO jako zwracane obiekty jestem w stanie się w backendzie jakoś poruszać. Więc im wiecej konwencji na front-endzie, tym wg mnie lepiej. Angular2+ poszedł znacznie dalej niż 1 w temacie „tak się to robi bo tak to się robi”, to myślę masz na myśli pisząc o kompleksowości, dla mnie to zaleta. Jak to mówi Douglas Crockford – jak masz wybór, to się pomylisz 🙂

  23. Dostałem kiedyś książkę o Angular JS. Zajrzałem i … odłożyłem, nie wchodząc zbytnio w szczegóły.
    Programowanie to dla mnie dopasowanie realnych problemów (zagadnień) do „świata” wirtualnego (przeglądarki itp.). Dlatego szukam intuicyjnie „zabawek do piaskownicy, o których Autor wspomina” po to, aby przełożenie z realu do wirtualu było jak najlepsze.
    Łatwo pisać oponentom Autora o rzekomej prostocie Angular JS podczas tworzenia aplikacji.
    Co mogę powiedzieć…
    Przekonałem się, że im bliżej fundamentu tym lepiej.
    Jak czytam niektóre komentarze, to mam wrażenie, że aplikacja internetowa to „pączek w maśle” wokół którego kręci się cała reszta i można w niej stosować wszystko, byle łatwiej napisać.
    Wracając do Angular JS, gdybym zaczął tego używać nie byłbym w stanie stworzyć tego co chcę, ponieważ zastosowanie go okazałoby się za mało elastyczne w przypadku multi-aplikacji czyli aplikacji dopasowanej funkcjonalnością do wielu użytkowników.
    W moim odczuciu stosowanie tego wynalazku jest zbędne, nie ma szans przejąć sterowania wszystkim na poziomie serwera, co jest kluczowe właśnie w aplikacjach sieciowych, z których korzysta więcej niż jedna osoba na desktopie.

    Pozdrawiam Autora

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *