Architektura strony w JS

Czesc ucze sie js i zastanawia mnie czy w dzisiejszych czasach warto budowac strone w js. O co mi chodzi, chodzi mi o to czy warto budowac strone przez funkcje, uzywajac petle uzywac metod typu

createElement

appendChild
ni jezeli robiac to statycznie? i wklepujac wszystko? Bo nie wiem czy warto zbudowac architekture html w js, a pozniej podpinac to do css, czy tradycyjnie zbudowac schemat htmla.

Na pewno widze budowanie htmla przez js, jesli mialbym stworzyc apke ktora umozliwia w jakis tam sposob budowe stron dla laikow ktorzy nie wiedza o co kaman, ale czy robiac strone dla klienta co lepiej sie sprawdza?

Teraz właściwie każda strona ma modyfikowany dom w po stronie klienta. Kliknij chociażby tutaj w "Szybka odpowiedź". Z drugiej strony możesz zrobić sporo błędów i tak dodanie 100 buttonów w pętli na bieżąco jest wolne. Na początek (i na koniec) najlepiej użyć frameworków lub chociaż sporo doczytać o JS żebyś nie zrobił wolnej kobyły.

A przydaje się to w miejscach gdzie jakaś informacja jest opcjonalna, ale czasami przydatna. Tak tutaj, "Szybka odpowiedź" przydaje się raz na 100 wejść w post, ale ten raz pozwala zaoszczędzić zbędnego przeładowania strony.

Ja pracuję na co dzień w React, style ładowane per komponent (masz wtedy w stylach przestrzenie nazw chociażby) + ogólne reguły typu normalize.css. Piszesz w JSX i generujesz sobie DOM. Plusy tego podejścia są takie, że masz w jednym pliku JS i "HTML" i nie musisz skakać, przełączać się między kontekstami, co w przypadku złożonych komponentów zabiera sporo czasu. Do tego możesz ogółem pisać CSS w JS, wtedy już w ogóle bajka jak dla mnie (nie każdemu to się podoba, ale warto się zapoznać: https://speakerdeck.com/vjeux/react-css-in-js). Łatwiej się też testuje takie izolowane komponenty. Całość spięta webpackiem i babelem (do kompilowania ES 6/ES 2015). Kolejna korzyść jest taka, że możesz renderować sobie taki komponent po stronie serwera i nawet wybrać, co chcesz, żeby było renderowane po stronie serwera, a co już w przeglądarce. Dzięki temu możesz różne wersje stron serwować w zależności od medium - mobile, desktop, google bot, etc. Przydatne, jeśli wspierasz starsze przeglądarki, ale też urządzenia z np. słabszym internetem.

Tak to wygląda w skrócie.

Na Twoim miejscu nie skupiałbym się na rozwiązaniu autorskim w JS, a skorzystał z jakiś lekkich bibliotek w zależności od potrzeb. W miarę nabierania doświadczenia być może wypracujesz sobie własne rozwiązania - wiele osób tak robi, ale jest to trudne i czasochłonne.

Pracowałem też w podejściu node.js + jade, a potem część rzeczy w angularze i kod dyrektyw (+html) budowany gruntem/gulpem. Ma to swoje plusy i minusy. Kiedyś było fajne, teraz bardziej z przyzwyczajenia i wygody wybieram html bezpośrednio w JS.

Jest też opcja użycia edytorów wysiwyg. W przeszłości potępione, ale obecnie w miarę sensowne strony można w tym zrobić, więc jeśli nie piszesz dużych aplikacji, to można się nad tym zastanowić. Popularne narzędzia to np. webflow czy macaw.

Generalnie siegnalem juz frameworka js, a wlasciwie tylko jednego a mianowicie angulara. Cale wakacje praktycznie mu poswiecilem, wiec dosc gleboko w tym siedzialem a zawsze chcialem brac sie za reacta, myslisz ze ten kurs jest odpowiedni na poczatek? https://egghead.io/lessons/react-hello-world-first-component Moze troche za szybko za frameworki sie wzialem, ale wszystko rozumialem, wiec mysle ze az takiego bledu nie zrobilem, no ale od jakiegos czasu poznaje czystego js-a i sie wlasnie zastanawialem nad tymi funkcjami w czystym jsie.

Odbiegajac od tematu, sporo ludzi spisywalo angulara na straty ze wzgledu na nowa wersje. Ja jestem zdania, ze nawet jesli faktycznie wersja 2 sie juz ustabilizuje, bo to troche potrwa, naprawia pierwsze niedociagnieca i nowe projekty zacznie sie pisac w v2, to znajomosc angulara moze sie przydac przy prowadzeniu projektow przepisywania z v1 na v2.
Co o tym myslicie?

Nie chcę sugerować Reacta, bo nie jest to jedyna właściwa biblioteka, tak samo jak Angular, czy Ember. W moim przypadku zwykle się sprawdza, bo aplikacje mam mocno "skomponentyzowane" i dużo rzeczy jest reużywalnych w ramach modułów. I owszem, to samo można napisać dyrektywami w Angularze dodając własną implementację Fluxa. Nawet tak próbowałem, ale w konsekwencji skończyłem z tym, że jedyna rzecz "angular way" to były serwisy, stąd można rzec, że doszedłem do podobnych wniosków jak twórcy Angulara 2 (gdzie de facto właśnie logika biznesowa z serwisów jest wspólna dla obu wersji frameworka). Dlatego nie widziałem sensu używania Angulara w moim przypadku.

Tobie radziłbym szkolić sobie JS, poznać wzorce projektowe i różne architektury. Polecam: http://staltz.com/unidirectional-user-interface-architectures.html jako bardzo, bardzo entry point. Co do samego Reacta: https://github.com/enaqx/awesome-react . Egghead miał świetne tutoriale odnośnie Angulara. Jeśli poziom tych w React jest podobny, to śmiało oglądaj. Weź poprawkę tylko na wersję Reacta, bo kilka rzeczy w starych filmikach jest już deprecated (np. odchodzi się od mixinów na rzecz kompozycji).

Angular 2 jest na tyle odmienny w stosunku do Angulara 1.x, że wątpię, żeby się to przydało w praktyce. Natomiast nie da się ukryć, że w korpo HR będzie miał niezły mętlik w głowie jak będą 2 wersje stabilne różnych frameworków pod tą samą nazwą (a już teraz mają problemy z odróżnieniem podstawowych kwestii, no offence), więc wtedy tak - może zadziałać to na Twoją korzyść. Co do samego frameworku to czas pokaże - aktualnie nadal jest niestabilny i trochę jeszcze feature'ów może ulec zmianie. Martwi mnie to, że Google/team Angulara nie uczy się na błędach i bardzo im trudno przyznać się do porażki. Mają tendencję wynajdywania koła na nowo, bo przecież nie można iść do konkurencji i wziąć ich open source'ową bibliotekę i ulepszyć lub wcielić do własnego narzędzia. W związku z tym patrząc na kod Angulara 2 mam w paru miejscach deja vu. Taka polityka jest niekorzystna dla developerów i powoduje duży rozstrzał technologiczny, gdzie spora część rozchodzi się o syntactic sugar niż rzeczywiście jest "przełomem". I potem ludzie w community śmieją się, np. http://i.imgur.com/OTEDFD6.jpg ;)

Dzieki wielkie za dluga recenzje i rady. Naprawde przyda mi sie to. I powiem szczerze ze dzieki tobie dostalem w koncu zajawki na reacta na ktorego mialem juz dawno. :) Takze zaczynam zabawe z nim. Mam takie pytanko co do komponentow. Jak najlepiej je laczyc? Tworzyc je warstwami przydzielonych do odpowiednich zadan, czy jak? Bo to fajna sprawa, tylko nie wiem jak dobrze ukladac komponenty.

Warto przeczytać: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 oraz https://medium.com/@learnreact/container-components-c0e67432e005 (zwróc uwagę, że w tym ostatnim przykładzie nie ma Fluxa, dlatego nie ma do końca ładnej separacji). W gruncie rzeczy komponenty dzieli się na takie 2 grupy.

Jeśli chodzi o poukładanie komponentów w ramach projektu, to ja robię tak:
a) w przypadku bardzo małych aplikacji, np. bloga wystarczy stworzyć sobie strukturę na zasadzie app/components/Component.js, app/components/ComponentSpec.js i odpowiednio upakować elementy Fluxa jeśli masz zamiar korzystać; same komponenty układamy tak jak drzewo, więc mamy jakby entry point, z którego wychodzą dzieci (kolejne komponenty), do których przekazuje się propsy (czyli masz jeden smart component i x dumb components)
b) w przypadku bardziej rozbudowanych aplikacji zauważam dwa podejścia: jedno feature-based jeśli masz rozrośnietą appkę, czyli organizujesz komponenty wokół danego feature'a (całość odzwierciedlona w strukturze, np. app/Calendar/components/CalendarHeader.js) - można całość dzielić potem na osobne aplikacje; druga opcja to zastosowanie podejścia z punktu a) i po prostu dodanie jednej warstwy katalogów, np. app/components/Component/ComponentSpec.js. Do tego jeszcze rozbudowuje nam się drzewo i powstaje kilka/kilkanaście smart components, które zasilają danymi dumb components i do których (w sensie do smart components) deleguje się odpowiedzialność. Jeśli masz np. listę elementów, gdzie każdy element ma przycisk "usuń element", to sam element listy nie powinien decydować o usunięciu, a przekazać tę odpowiedzialność dalej. Taki element list jest właśnie "dumb". Więcej masz w artykułach. ;) Smart components łączą się bezpośrednio z Fluxem że tak powiem lub wykonują operacje w bezpośredni sposób, np. odpytują serwer o dane. Za pomocą React Routera możesz niektóre ze smart componentów ustalić jako entry pointy, jakby kontenery dla całego widoku. Pamiętaj jedynie, że smart components są ogólnie trudniejsze w testowaniu niż dumb components (taki hint). Jeśli masz dużo dzieci w głąb struktury (czyli dużo zagnieżdzonych komponentów), to możesz skorzystać z "magii" kontekstu aplikacji: https://medium.com/@skwee357/the-land-of-undocumented-react-js-the-context-99b3f931ff73 .

Zauważ, że umieściłem pliki z testami obok komponentów - ma to swoje zalety, ale są ludzie, którzy wolą mieć testy w jednym katalogu w głównym katalogu aplikacji i albo pogrupowane typami (testy akcji, store'ów), albo ścieżkami, np. /tests/Calendar/components/CalendarHeaderSpec.js . Ja osobiście preferuję testy blisko komponentów, podobnie ze stylami, jeśli trzymasz w osobnych plikach.

Mam nadzieję, że jakoś Ci to pomoże. Sugeruję też popatrzeć na przykłady różnych aplikacji na githubie (trochę tego jest) - niektórzy łatwiej tak załapują patterny.