Mój ulubiony stack oraz rzeczy, które przestałem lubić
Czasem po prostu musisz skompletować sobie własny stack technologiczny, dojść do tego, które narzędzia lubisz, a które narzędzia uważasz za ułomne.
Jeśli chodzi o framework do obsługi DOMu, to wybieram ReactJS. Prosta i elastyczna biblioteka do tworzenia komponentów.
Obecnie też testuję Redux (biblioteka do obsługi stanu aplikacji w ReactJS) wcielająca w mniejszym lub większym stopniu założenia Flux), chociaż zaczynam dostrzegać ograniczenia związane z tym w jaki sposób Redux jest powiązany z Reactem. Nie wiem czy nie będę musiał napisać własnego bindingu (już tłumaczę, że Redux jest uniwersalną i prostą biblioteką i nie wymaga do działania Reacta. Natomiast jego twórca dostarcza specjalne bindingi do tego, żeby połączyć Redux z Reactem. Niestety jak dla mnie te wiązania nie są za bardzo jeszcze dopracowane pod kątem założeń. A przynajmniej nie sprawdzają się w aplikacji, którą robię).
Zawiodłem się na Angularze. Miałem okazję pracować z nim dłużej i głębiej i okazuje się, że nie jest taki wspaniały. Dość mało elastyczny, ciężko utrzymywać kod, trudny w debugowaniu i obsłudze, oraz mający zbyt dynamiczną naturę, przez to żadne IDE go dobrze nie wspiera (tak, wiem, że WebStorm robi co może, ale nawet WebStorm lepiej wspiera bardziej uporządkowanego Reacta niż chaotycznego Angulara).
Jeśli chodzi o build system to również przeszedłem podobną transformację: przestałem lubić Grunta, gdy tylko zacząłem pracować z Gulpem. Grunt - toporne wypełnianie struktur konfiguracyjnych. Gulp - radosne i w miarę intuicyjne łączenie różnych elementów w pipeline.
Także przypadło mi do gustu pisanie w ES6 z użyciem transpilatora Babel (który BTW transpiluje również przy okazji komponenty reactowe JSX do zwykłego JS i sami twórcy Reacta go polecają). Całość przepuszczam przez Browserify.
Jeśli chodzi o narzędzia do programowania grafiki. To najbardziej cool rzeczą, z jaką się spotkałem jest ThreeJS, ponieważ można robić trójwymiarowe aplikacje w WebGL z dziecinną łatwością, bez zbędnych inicjalizacji, tylko na zasadzie "piszesz i masz", zachowując odpowiedni poziom abstrakcji.
Narzędzie do grafiki 2D: to Pixi(jeśli używasz Phasera, to jedziemy na tym samym wózku, ponieważ Phaser to tylko nakładka na Pixi (Chociaż już przepisują Phasera i nowa wersja ma już nie korzystać z Pixi tylko mieć własny renderer). Chociaż Phaser ma parę ciekawych ficzerów, więc nie lekceważyłbym tego frameworku. Właściwie moja niechęć do Phasera polega na tym, że uważam, że jest to framework słabo zaprojektowany pod kątem architektury, a nie z powodu jego braku możliwości.
Narzędzie do robienia wykresów, wizualizacji:
oczywiście, że D3, bo jest to elastyczna biblioteka o wielkich możliwościach. Tyle, że jej API jest dość chaotyczne i nieintuicyjne, i jeśli mam zrobić coś w D3, robię to trochę na oślep.
Do CSSów:
Hmm... testuję postCSS;, ale w tej chwili nie mam wiele do powiedzenia w tym względzie (będę miał do powiedzenia, jak zrobię parę własnych pluginów, z których inni ludzie będą korzystać. Na razie jestem na etapie eksperymentowania). Jako coś bardziej pewnego sprawdził się SCSS/Sass, tym niemniej... cóż, wadą Sassa jest to, że przy większych projektach wszystko zaczyna się w nim lekko rozłazić.
Ciekawą opcją (chociaż nie wiem na ile mądrą) jest też podejście reactowe i inline styles w postaci injectowanych obiektów JavaScriptowych (żeby zachować modularyzację). Nie stosowałem tego, ponieważ mam podobne odczucia co John Resig:
Ale pewnie nadejdzie czas, żeby sprawdzić czy naprawdę to takie straszne. W końcu już mieszam HTML z JS i okazało się to być całkiem fajne. Po prostu traktuję JS jako dość ekspresywny język szablonów (architektura Flux zresztą i tak zachęca do przenoszenia logiki poza komponenty, więc moje komponenty są i tak dość głupie. Nie mieszam logiki z widokiem, bo logika siedzi zupełnie w innym pliku niż komponenty reactowe).
Jeśli chodzi o backend, to preferuję NodeJS oraz Express, ale w zasadzie czuję, że czas zacząć nadążać za trendami i wreszcie poznać tego Meteora
No i to tyle. Taki przegląd mojego ulubionych i mniej ulubionych jsowych tooli. Chociaż zabrakło tutaj oczywistości typu jQuery czy lodash (ciężko się nad tym dłużej rozpisywać) czy róznych pobocznych narzędzi. No i zapewne jak mnie zapytacie za pół roku czy rok, lista ta być może będzie już nieco inna. Wszystko płynie. Trzeba znaleźć jednak odrobinę stabilizacji w tym szalejącym nurcie, jakim jest frontend.
Jeśli chodzi o framework do obsługi DOMu, to wybieram ReactJS. Prosta i elastyczna biblioteka do tworzenia komponentów.
Obecnie też testuję Redux (biblioteka do obsługi stanu aplikacji w ReactJS) wcielająca w mniejszym lub większym stopniu założenia Flux), chociaż zaczynam dostrzegać ograniczenia związane z tym w jaki sposób Redux jest powiązany z Reactem. Nie wiem czy nie będę musiał napisać własnego bindingu (już tłumaczę, że Redux jest uniwersalną i prostą biblioteką i nie wymaga do działania Reacta. Natomiast jego twórca dostarcza specjalne bindingi do tego, żeby połączyć Redux z Reactem. Niestety jak dla mnie te wiązania nie są za bardzo jeszcze dopracowane pod kątem założeń. A przynajmniej nie sprawdzają się w aplikacji, którą robię).
Zawiodłem się na Angularze. Miałem okazję pracować z nim dłużej i głębiej i okazuje się, że nie jest taki wspaniały. Dość mało elastyczny, ciężko utrzymywać kod, trudny w debugowaniu i obsłudze, oraz mający zbyt dynamiczną naturę, przez to żadne IDE go dobrze nie wspiera (tak, wiem, że WebStorm robi co może, ale nawet WebStorm lepiej wspiera bardziej uporządkowanego Reacta niż chaotycznego Angulara).
Jeśli chodzi o build system to również przeszedłem podobną transformację: przestałem lubić Grunta, gdy tylko zacząłem pracować z Gulpem. Grunt - toporne wypełnianie struktur konfiguracyjnych. Gulp - radosne i w miarę intuicyjne łączenie różnych elementów w pipeline.
Także przypadło mi do gustu pisanie w ES6 z użyciem transpilatora Babel (który BTW transpiluje również przy okazji komponenty reactowe JSX do zwykłego JS i sami twórcy Reacta go polecają). Całość przepuszczam przez Browserify.
Jeśli chodzi o narzędzia do programowania grafiki. To najbardziej cool rzeczą, z jaką się spotkałem jest ThreeJS, ponieważ można robić trójwymiarowe aplikacje w WebGL z dziecinną łatwością, bez zbędnych inicjalizacji, tylko na zasadzie "piszesz i masz", zachowując odpowiedni poziom abstrakcji.
Narzędzie do grafiki 2D: to Pixi(jeśli używasz Phasera, to jedziemy na tym samym wózku, ponieważ Phaser to tylko nakładka na Pixi (Chociaż już przepisują Phasera i nowa wersja ma już nie korzystać z Pixi tylko mieć własny renderer). Chociaż Phaser ma parę ciekawych ficzerów, więc nie lekceważyłbym tego frameworku. Właściwie moja niechęć do Phasera polega na tym, że uważam, że jest to framework słabo zaprojektowany pod kątem architektury, a nie z powodu jego braku możliwości.
Narzędzie do robienia wykresów, wizualizacji:
oczywiście, że D3, bo jest to elastyczna biblioteka o wielkich możliwościach. Tyle, że jej API jest dość chaotyczne i nieintuicyjne, i jeśli mam zrobić coś w D3, robię to trochę na oślep.
Do CSSów:
Hmm... testuję postCSS;, ale w tej chwili nie mam wiele do powiedzenia w tym względzie (będę miał do powiedzenia, jak zrobię parę własnych pluginów, z których inni ludzie będą korzystać. Na razie jestem na etapie eksperymentowania). Jako coś bardziej pewnego sprawdził się SCSS/Sass, tym niemniej... cóż, wadą Sassa jest to, że przy większych projektach wszystko zaczyna się w nim lekko rozłazić.
Ciekawą opcją (chociaż nie wiem na ile mądrą) jest też podejście reactowe i inline styles w postaci injectowanych obiektów JavaScriptowych (żeby zachować modularyzację). Nie stosowałem tego, ponieważ mam podobne odczucia co John Resig:
I refuse to put inline styles in my React JSX. Separation of HTML + CSS is too ingrained in my DNA to throw it away so casually!— John Resig (@jeresig) July 23, 2015Ale pewnie nadejdzie czas, żeby sprawdzić czy naprawdę to takie straszne. W końcu już mieszam HTML z JS i okazało się to być całkiem fajne. Po prostu traktuję JS jako dość ekspresywny język szablonów (architektura Flux zresztą i tak zachęca do przenoszenia logiki poza komponenty, więc moje komponenty są i tak dość głupie. Nie mieszam logiki z widokiem, bo logika siedzi zupełnie w innym pliku niż komponenty reactowe).
Jeśli chodzi o backend, to preferuję NodeJS oraz Express, ale w zasadzie czuję, że czas zacząć nadążać za trendami i wreszcie poznać tego Meteora
No i to tyle. Taki przegląd mojego ulubionych i mniej ulubionych jsowych tooli. Chociaż zabrakło tutaj oczywistości typu jQuery czy lodash (ciężko się nad tym dłużej rozpisywać) czy róznych pobocznych narzędzi. No i zapewne jak mnie zapytacie za pół roku czy rok, lista ta być może będzie już nieco inna. Wszystko płynie. Trzeba znaleźć jednak odrobinę stabilizacji w tym szalejącym nurcie, jakim jest frontend.
+1, za tematykę i sposób prowadzenia :) Od czasu do czasu zerkam, żeby przekonać się czy jeszcze coś nowego poznałeś :)
OdpowiedzUsuńWkrótce pojawi się nowy wpis o czymś niebanalnym :)
Usuń