Sens frameworków we front-end developingu

Witam

Jestem starej daty komputerowcem. Wiekszosc moich dzialan krecilo sie i kreci wokol aplikacji internetowych, ktore zaczalem tworzyc jeszcze w CGI/PERL w bardzo dawnych czasach kiedy wiekszosci was pewnie nie bylo na swiecie ;)

Chcialbym napisac o czyms co mnie bardzo osobiscie boli, ale dostrzegam ze jest to tendencja we wspolczesnym web developingu a w szczegolnosci we front end developingu. Otoz caly moj problem strescic mozna slowem FRAMEWORKI.

Z mojego punktu widzenia frameworki to nakladki na istniejace technologie, same w sobie nie poszerzajace ich ani nie wzbogacajace, chociaz ulatwiaja i przyspieszaja prace. Jednak rowniez obciazaja przegladarki, redukuja ich zasoby i nie sa tworcze (bo ktos wczesniej musial to stworzyc przed nami) a przez to nie zawsze oferuja potrzebne nam formatki/kontrolki itp. Mozna by wiec podzielic moje pytanie na za i przeciw frameworkom. Ja osobiscie uwazam, ze wspolczesnie zachlysniecie sie frameworkami jest bardzo krotkowzroczne. Wspolczesna aplikacja oparta na dowolnym frameworku staje sie automatycznie zalezna od tworcow frameworka, takze wtedy gdy zdecyduja wiecej go nie rozwijac. W efekcie aplikacje nalezy przerobic uzywajac nowych frameworkow? Na przestrzeni 20 lat pracy bylem swiadkiem pojawiania sie i znikania wielu frameworkow lub bibliotej (w dawniejszych czasach) ktorych dzis nikt nie pamieta nawet ze istnialy. Drazni mnie jednak to, ze doswiadczenie, znajomosc HTML5/CSS3/Javascriptu jest mniej ceniona niz znajomosci pamieciozernego Angulara czy reacta. Z mojego punktu widzenia sam fakt uproszczenia i przyspieszenia pracy nie tlumaczy dlaczego ograniczamy sie dobrowolnie. Ja wiem, ze samodzielne "wynajdowanie kola" tez nie jest najlepszym z mozliwych podejsc do tematu - trzeba wypracowac cos po srodku. Mam tez swiadomosc ze piszac ten post do ludzi majacych aktualnie 20pare lat nie znajde zrozumiania i zostane zrownany z ziemia, ze stary jestem, musze sie przekwalifikowac albo odejsc - takie prawo mlodosci i oczywiscie je rozumiem, nie bez kozery jednak we wszystkich firmach sa seniorzy programisci a to wlasnie tacy jak ja...

To co napisalem jest wlasciwie niezbyt eleganckim wprowadzeniem w pewna dyskusje ktora chcialbym rozpoczac i poznac szczerze zdanie jakie macie w tym temacie. Czy zawod np.: front end developera postrzegacie jako klepacza i znawce frameworkow? Czy osoby znajace technologie bazowe a nieznajace frameworkow uwazacie za gorszych specjalistow, mniej wyedukowanych (a wiec i mniej platnych)? Czy nowoczesne aplikacje internetowe musza byc prawie identyczne w wygladzie? Czy etap tworczy (w sensie indywidualnej grafiki, ukladu strony itp) nalezy ograniczyc do UI designu? Chetnie przeczytam Wasze zdanie za ktore z gory dziekuje.

Ale o jakich ograniczeniach Ty piszesz? Jeśli czegoś ten framework nie obsługuje to jaki jest problem żeby to rozszerzyć? No właśnie, należałoby fundamentalnie poznać żeby wiedzieć co się w tym frameworku dzieje. Podobnie ma się sprawa w samym PHP, też te frameworki i rzekome ograniczanie, i uzależnianie od twórców ale to i tak pryszcz, bo często problemem jest chociażby brak kompatybilności wstecznej i z tego powodu problemy. Akurat tworzę pewien serwis na jednym już powiedziałbym mało popularnym (kiedyś był na niego też hype) frameworku w PHP, wielu też by mnie tu zjadło gdybym tylko wymienił jego nazwę. Ale co z tego? Znam go na wylot, więc jeśli czegoś nie implementuje to sobie tylko dopiszę co trzeba.

W Javascripcie to też działam w zasadzie fundamentalnie i z pomocą jQuery, zaś w CSS z pomocą Twitter Bootstrap, którym zresztą i tak mogę się tylko wspomagać bo tylko część problemów jest rozwiązywana, reszta musi być zrobiona fundamentalnie jeśli o to chodzi.

Zdaję sobie sprawę z tego że np. Google albo Facebook czy tam inni giganci mogą narzucać pewne trendy albo też jest coś w rodzaju takiego hype. Masz tu szczegółowo odnośnie Angulara:

http://www.webkrytyk.pl/krytyka/moja-prawda-o-angular-js/

Ale to jest tylko czyjaś opinia i nic więcej.

Nie wiem natomiast jak się ma sprawa odnośnie Knockout.js i jak się ma sprawa jego udziału w rynku, fajnie można zrobić co niektóre rzeczy i też rozważam użycie w projekcie ale tylko rozważam. Czy ktoś ma jakieś większe doświadczenia z Knockout.js?

Czas to pieniądz, jeśli pisząc front do sporego portalu potrzebowałem 6 miesięcy korzystając z angulara to na napisanie tego samego pisząc od 0 bym potrzebował 2 lat przy dobrych wiatrach. Fakt jest to wszystko obciążające i mnie jako lubiącego optymalizacje nie podoba się to ale co zrobić. Angular ma też tę przewagę nad czystym klepaniem że "kompiluje" htmla w locie. Nie bawi się człowiek z id żeby wstawić wartość tylko robi np coś takiego

Korzystanie z frameworka ma swoje zalety, ale też i wady. Zaletą jest skrócenie czasu tworzenia strony, a wadą narzucone możliwości i pożeranie zasobów. Fakt, że sam framework można przerobić lub rozszerzyć, ale potem jak wychodzi nowsza wersja i się aktualizuje, to trzeba pamiętać, co było zmieniane i te zmiany powtórzyć. Nie wspomnę faktu, że trzeba się dobrze z nim zapoznać, wiadomo, jak to jest modyfikować obcy, nieznany kod.

Mi się wydaje, że te frameworki JS i CSS to jest skutek zachłyśnięcia się Javascriptem i CSS. Ja jestem młodszy, ale pamiętam internet przez modem telefoniczny 56k. Wtedy strony były lekkie łatwe i przyjemne dla kompa i użytkownika. Wtedy w ustawieniach przeglądarki wyłączałem pobieranie obrazów i włączałem zapytanie użytkownika o uruchamianie JS. Strona wczytywała się bez obrazków i przeglądarka pytała się, czy uruchamiać Javascript. Wierzcie lub nie, ale w 80% przypadków nie trzeba było uruchamiać JS, a strona bez obrazków była nadal użyteczna, wtedy mogłem dociągać sobie te obrazki, które mnie faktycznie interesowały. To było podyktowane względami technicznymi (bardzo długi czas ładowania strony obładowanej grafiką i spowalnianie komputera przy zaawansowanych skryptach JS). Technika poszła do przodu, bariery utrudniające korzystanie z Internetu pokonane, wymyślono kombajn zwany HTML5 i wtedy firmy tworzące strony się dosłownie zachłysnęły możliwościami technologicznymi i to trwa do dzisiaj. Czuję, że jestem świadkiem wyścigu na wykorzystanie technologii.

Dobry przykład:
http://cartridgepoznan.pl/
Czy ta strona jest kierowana do ludzi potrzebujących tusz do drukarki, czy do fanów technologii i demosceny (starsi informatycy wiedzą co to jest i że niegdyś było to popularne na komputerach Commodore 64)? Jeżeli to pierwsze, to można odnieść wrażenie, że jakiś informatyk się nudził i wypróbował zmieniając się tła, efekty specjalne, animacje. Po co mi to, można prościej i poświęcić temu mniej czasu i bez kombinowania z frameworkami czy dłubaniną w JS.

Dla mnie to wygląda tak: Chcę zabić muchę (zbudować stronę firmy sprzedającej tusze), otrzymuję armatę do tego celu (technologia HTML5+JS+CSS), a oprócz zabicia muchy (uruchomienie strony pozwalającej na kontakt z firmą i zapoznanie się z jej ofertą) na siłę szukam, co jeszcze i większego warto zabić tą armatą (jak najwięcej efektów specjalnych osiągalnych w HTML5, bo już wszystkie przeglądarki ją wspierają).

Ja mam wrażenie że back end i front end to są dwa różne światy, które są rozwijanie niezależnie i średnio się ze sobą dogadują (mam tu na myśli community obydwu). Liczba frameworków JS (ale i CSS) jest naprawdę spora i nie wiadomo dokładnie po co tyle tego powstało ;) Mocno się to wszystko skomplikowało. Chyba żeby utrudnić web devom życie, a może żeby było więcej pracy, więcej stanowisk, ktoś już tu napisał, że pojęcie "full stack" to ściema i praktycznie nie ma ludzi od jednego i drugiego.

Mały Lew napisał(a):

Ja mam wrażenie że back end i front end to są dwa różne światy, które są rozwijanie niezależnie i średnio się ze sobą dogadują (mam tu na myśli community obydwu). Liczba frameworków JS (ale i CSS) jest naprawdę spora i nie wiadomo dokładnie po co tyle tego powstało ;) Mocno się to wszystko skomplikowało. Chyba żeby utrudnić web devom życie, a może żeby było więcej pracy, więcej stanowisk, ktoś już tu napisał, że pojęcie "full stack" to ściema i praktycznie nie ma ludzi od jednego i drugiego.

Ja tam jestem fullstackem ;) A backend i frontend jest rozwijany osobno i tak ma być. Jest standard rest api więc nie ma co się przejmować co tam się dzieje ważne że api jest takie jak powinno.

Przecież frameworki we froncie to zasadniczo tylko zbiór klas (i ew. skryptów) które mają usprawnić tworzenie warstwy wizualnej, równie dobrze możesz samemu potworzyć uniwersalne klasy, gridu, buttonów, tabel, kart i nazwać swoim frameworkiem.

Dodatkowo frameworki również naprowadzają na świeże rozwiązania, które można modyfikować i kopiować wedle uznania, a niektóre ważą kilkanaście kilo i tylko oferują grida w celu ułatwienia tworzenia strony.

Akurat uzależnienie od frameworka we froncie nie grozi, bo zasadniczo w prosty sposób można wyjść poza jego obszar i dowolnie eksperymentować.
podsumowując:
no drama ;)

Wtedy strony były lekkie łatwe i przyjemne dla kompa i użytkownika.

Dla użytkownika? ;) Mówisz o tych potworkach gwałcących zmysł estetyczny?

Po co mi to, można prościej i poświęcić temu mniej czasu i bez kombinowania z frameworkami czy dłubaniną w JS.

Może po to aby pokazać się większej klienteli i przy okazji jej nie odstraszyć (chociaż zawartość zakładki "Oferta" sugeruje co innego :D). To prościej w przypadku stron oznacza zapewne twór nadający się na grafik płakał jak projektował.
Budżet małych firm trochę wyklucza "kombinowanie" z frameworkami i dłubaninę w JS. Tam raczej leci jakiś CMS i gotowy szablon, bo klient nie płaci za wiele.

Dla mnie to wygląda tak: Chcę zabić muchę (zbudować stronę firmy sprzedającej tusze), otrzymuję armatę do tego celu (technologia HTML5+JS+CSS), a oprócz zabicia muchy (uruchomienie strony pozwalającej na kontakt z firmą i zapoznanie się z jej ofertą) na siłę szukam, co jeszcze i większego warto zabić tą armatą (jak najwięcej efektów specjalnych osiągalnych w HTML5, bo już wszystkie przeglądarki ją wspierają).

To nie jest żadna armata, świetnie się sprawdza do małych stron, a z racji sporych możliwości daje radę też i w większych.
Jakie efekty specjalne wprowadza HTML5?

Autorze,

Ja wiem, ze samodzielne "wynajdowanie kola" tez nie jest najlepszym z mozliwych podejsc do tematu - trzeba wypracowac cos po srodku

Wydaje mi się, że obecnie klaruje się rozwiązanie "po środku", tj. budowanie frontu z małych klocków (...React, Redux), dzięki czemu można podmienić jakiś element na inny w miarę bezboleśnie, co bywa kłopotliwe w przypadku frameworków (Angular).

Czy osoby znajace technologie bazowe a nieznajace frameworkow uwazacie za gorszych specjalistow, mniej wyedukowanych (a wiec i mniej platnych)?

Nie, ale gdy słyszę, że ktoś pisze tylko w gołym JSie (ewentualnie z jQuery) i nie jest absolutnie początkujący to moja podświadomość zaczyna się ratować przed zagładą podsuwając na siłę jakieś miłe wspomnienia... Chociaż może być to spowodowane tym, że ostatnio miałem styczność z paroma agentami z kilkuletnim doświadczeniem we froncie, którzy są tylko vanillia/jQuery.

Czy nowoczesne aplikacje internetowe musza byc prawie identyczne w wygladzie? Czy etap tworczy (w sensie indywidualnej grafiki, ukladu strony itp) nalezy ograniczyc do UI designu?

Czy frontendowiec powinien zajmować się UI/UX?

Przez tyle lat w branży, a jeszcze się nie przyzwyczaiłeś, że wszystko się zmienia? ;) Oczywiście, prawdopodobnie prędzej czy później angular również odejdzie w zapomnienie, przyjdzie jego następca. I wtedy następne pokolenie programistów będzie płakać: "Ale czemu ja nie mogę tego normalnie w angularze napisać, tylko muszę coś tam coś tam..."
Tak samo jak jeszcze kilka lat temu można było spotkać takich: "Ale po co jakiś .NET Framework / JRE, jak wszystko można napisać w C++?".

Ja po prostu zaakceptowałam fakt, że w IT wszystko płynie i uczę się płynąć z prądem, zamiast stawać w miejscu i z nim walczyć (albo jeszcze nie daj boże płynąć pod prąd).

To nie znaczy, że należy rzucać się na hype, do prostych stronek nie ładowałabym od razu frameworka tylko dlatego, że jest taki trend. Ale odrzucanie frameworków wszystkich na raz, tylko dlatego, że są frameworkami jest jeszcze większą pomyłką...

Cóż. Chodzi o to generalnie, żeby rozwiązać pewien problem biznesowy. Jeśli biblioteka/framework w tym pomoże, to się używa. Czasem nie pomaga, a wręcz przeszkadza. Też można się sparzyć. Ale generalnie jest to jak nóż - narzędzie jak narzędzie.

Nie widzę nic złego w używaniu narzędzi, jeśli pomagają rozwiązać dany problem.

Prawdziwy problem bierze się z czego innego. Problemem jest psychologia ludzka i to, że ludzie (programiści ale nie tylko, bo równie dobrze mogą to być czasem menedżerzy czy klienci) traktują frameworki nie jak biblioteki programistyczne ale jak artefakt magiczny, który rzeko ma jakąś magiczną moc. Z tego biorą się problemy, bo jeśli traktujesz Angulara czy Reacta albo TypeScripta jak bożka, to przestajesz myśleć racjonalnie (polecam sprawdzić w google: cargo cult albo np. poczytać o eseju sprzed 30 lat, który to opisuje: https://en.wikipedia.org/wiki/No_Silver_Bullet . Poza tym teraz również się pojawił fajny artykuł na ten temat: https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.45hi5ddyy ).

Ludziom brakuje dystansu i racjonalnego odpowiedzialnego spojrzenia (coś jak "ok ten framework jest fajny, ale czy pomoże rozwiązać nam nasze bardzo konkretne problemy? Czy może chcemy użyć frameworka dla czystej zabawy/zachęceni jego sloganem z landing page'a?" -- niestety bardzo często zdarza się to drugie).

Brakuje też również sensownej architektury. Jeśli ludzie zawierzają frameworkowi w 100% i np. wciskają całą logikę biznesową w dyrektywy Angulara czy do komponentów React to mają problem - przy takim podejściu przepisanie projektu z jednego frameworka na drugi (np. Angulara na React) staje się niemożliwe, gdyż trzeba byłoby przepisać cały kod, co zajęłoby z pół roku, a na to nie ma czasu.

Dlatego lepiej jednak zachowywać jakąś rozsądną separację (np. warstwa widoku oddzielona od logiki) i nie pisać całego kodu we frameworku, ale tworzyć też moduły w czystym JavaScript, które będą definiować logikę aplikacji.

Wtedy nawet używając frameworka, można pisać w ten sposób, żeby dało się łatwo go wymienić (dla przykładu napiszę, że robię sobie teraz dla rozrywki własne IDE w JavaScript (na Electronie) - i teraz np. przepisuję całe swoje GUI z Reacta na Vue i jest to dość proste - właśnie przez to, że całą logikę mam pochowaną w osobnych modułach, framework do renderowania komponentów to tylko warstwa GUI. Nie przepisuję całej apki, ale może z 10% apki odpowiedzialnej za widok.

To wszystko ma jeden wspólny mianownik- pieniądze. Biznes chce rozwiązań możliwie najlepszych i najtańszych a te fw o których piszesz zapewniają szybsze i łatwiejsze kodowanie. A to z kolei oszczędność czasu czyli pieniędzy.

Pietruch napisał(a):

Wtedy strony były lekkie łatwe i przyjemne dla kompa i użytkownika.

Dla użytkownika? ;) Mówisz o tych potworkach gwałcących zmysł estetyczny?

Wyroby lepsze, gorsze i tragiczne zawsze były, są i będą. Pamiętam strony Komputronika, Onet, Allegro kilkanaście lat temu i w ogóle nie narzekałem na wygląd. Niedawno spotkałem się z zestawieniem screenów kilku popularnych portali w parach dawniej i dziś i wersja dawniejsza była brzydsza, ale niezła (kwestia przyzwyczajenia). Niektóre wyglądały, jakby były pisane od nowa. Rozumiem, że technologie się zmieniają bardzo szybko i to decyduje o napisaniu w nowym frameworku, ale też zauważyłem, że wraz z każdą odsłoną jest coraz więcej bajerów i tak na oko mógłbym ocenić, że programista spędził więcej czasu niż za poprzednim razem. Kiedyś bawiłem się z CSS i mam doświadczenie, że tworzenie i testowanie stylów jest bardzo czasochłonne.

SekretarzGeneralnyONZ napisał(a):

To wszystko ma jeden wspólny mianownik- pieniądze. Biznes chce rozwiązań możliwie najlepszych i najtańszych a te fw o których piszesz zapewniają szybsze i łatwiejsze kodowanie. A to z kolei oszczędność czasu czyli pieniędzy.

Wszyscy znają starą regułę: Jeżeli nie wiadomo o co chodzi, to znaczy, że chodzi o pieniądze.
A ja dopatrzyłem się w życiu pewnej zasady, że jeżeli dyskutuje się o sensowności i bezsensowności różnych technologii i rozwiązań technicznych (nie tylko w IT), to bardzo często dyskusja sprowadza się do argumentu, że za tym stoją pieniądze.

akurat portale informacyjne czy sprzedażowe były brzydkie i będą ponieważ mają być przede wszystkim szybkie, prócz zdjęć z newsów czy produktów nie uświadczysz tam większej grafiki, tylko foty+text bez zbędnego rysowania i efektów

andrzejlisek napisał(a):

Rozumiem, że technologie się zmieniają bardzo szybko i to decyduje o napisaniu w nowym frameworku, ale też zauważyłem, że wraz z każdą odsłoną jest coraz więcej bajerów i tak na oko mógłbym ocenić, że programista spędził więcej czasu niż za poprzednim razem.

Zauważ, jedną zasadniczą rzecz: to userzy chcą tych bajerów, to w przytłaczającej większości oni chcą tych animacji i wodotrysków, więc my nie mamy wyjścia musimy to robić. Wystarczy słuchać co mówią znajomi inni niż z it, czy tez nawet rodzina.

Jestem typowym backendowcem, z frontem niewiele mam wspólnego ale wydaje mi się że obciążaniem stron przez wykorzystanie Reacta czy Angulara w czasach kiedy ludzie onanizują się cyferkami (co raz więcej ramu, co raz więcej herzów i co tam jeszcze może być też niech będzie więcej byle być osom) nie ma się co raczej przejmować. Choć wiadomo że nie zawsze tak jest.

Pod niektórymi względami zgadzam się z autorem postu. Niejednokrotnie przerabiałem rzeczy w projektach zbędne a wykorzystane tylko po to żeby być na czasie. Ale to działa w 2 strony.
Aktualnie pracuję w niewielkim niemieckim zespole. Backend jest dość fajnie prowadzony ale front ku mojemu zdziwieniu stoi na GWT. I nie byłoby w tym nic złego gdyby nie to że uparł się na niego jeden programista który go zna i ma do niego napisane masę własnych walidatorów, binderów i ficzerów. A że nie ma typowego frontendowca w zespole to się inni na to zgodzili. Teraz kiedy trafiłem do zespołu, budowanie widoków to dla mnie po prostu katorga. Ogarnia to tylko jeden koleś który jest starej daty i nie chciał się dać przekonać żeby wybrać coś nowszego. Efekt jest taki że GWT które de facto powinno Javowcą ułatwiać pracę z frontem, po prostu jeszcze bardziej nam ją utrudnia. Do tego przez masę udziwnień gościa w internecie niewiele znajdziesz rozwiązań na swoje problemy a On nie zawsze ma czas żeby Ci pomóc. A wszystko to przez to że nie potrafił nadążyć za nowymi rozwiązaniami.

Także działa to w 2 strony. Czas leci i pojawiają się nowości.
Poza tym mówimy tylko o frameworkach ale przecież powstało wiele nowych języków, które rozwiązują problemy innych. Przez lata wypracowujemy pewne wzorce, dobre praktyki itp i przekładamy to na frameworki, biblioteki, narzędzia czy nawet same nowe języki.

Poniekąd się z Tobą zgadzam, trochę zatraciliśmy się w nowościach zamiast szukać dopasowanego rozwiązania dla naszego problemu. Z drugiej jednak strony gdyby ludzkość nie szła do przodu, równie dobrze moglibyśmy nadal siedzieć w jaskinach i pisać po ścianach.

A co się stanie z tymi frameworkami, jeżeli dużo użytkowników zablokuje skrypty JS poprzez wtyczki typu noscript?
Jak ktoś nie lubi ganiać za nowościami to wybiera programowanie w czystym C + jakiś framework GTK i ma zapewnioną prace przy pisaniu systemów komputerowych, sterownikach. Bo wydaje mi się że C++ szybciej się rozwija niż Java ostatnio, może i goni C#.

Świetny Samiec napisał(a):

A co się stanie z tymi frameworkami, jeżeli dużo użytkowników zablokuje skrypty JS poprzez wtyczki typu noscript?

Nie obchodzą mnie ludzie wyłączający js. Jak ktoś wyłącza to już jego problem. Według danych jakie mam z kilku sporych portali przy których robie liczba takich ludzi jest poniżej 0.1%. To tak samo jakbym miał się przejmować ie8 których jest większy odsetek.

Ale niestety sporo firm nadal męczy IE8 co spowalnia postęp i powoduje, że więcej czasu siedzisz nad kompatybilnością niż tworzeniem layoutu :/

Moim zdaniem pisanie bez żadnego frameworka czy biblioteki jest kompletną pomyłką. Podstawową zaletą frameworków/ bibliotek w JavaScripcie jest to, że to autorzy tych tworów dbają o kompatybilność ze standardami i przeglądarkami. Taki np React.js potrafi przechwycić zdarzenia z przeglądarki i emulować poprawne bąblowanie (?) zdarzeń (event bubbling) nawet na przeglądarkach niekompatybilnych z najnowszymi standardami. Ma też inne ficzery, jak np powiadamianie (w trybie debug) o złej obsłudze zdarzeń. Załatwienie kompatybilności to główny powód popularności jQuery - zamiast zastanawiać się jak coś będzie działać pod różnymi przeglądarkami, bierzemy jQuery i czytamy kontrakt dla konkretnych funkcji z tej biblioteki.

Sam React jest względnie lekki:
https://auth0.com/blog/updated-and-improved-more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/

Kolejna sprawa to to, czy rzeczywiście frameworki psują odbiór użytkownikom. Zaawansowane frameworki mają wiele rzeczy zrobione profesjonalnie i wydajnie. Moim zdaniem wynajdywanie koła od nowa i robienie skomplikowanych układów stron za pomocą ręcznie robionej pajęczyny callbacków może przynieść nawet spadek wydajności - rzadko kiedy zwykły programista potrafi sobie wyobrazić jakie mogą być wąskie gardła i to na wielu przeglądarkach jednocześnie. Twórcy frameworków testują je wydajnościowo na wiele sposobów i regularnie poprawiają.

Czy frontendowiec powinien zajmować się UI/UX?

Jeśli jest jedynym programistą w danym projekcie to tak, jeśli pracuje w zespole to często ktoś jest już od UX - ale z drugiej strony myślę, że tak czy siak frontendowiec powinien mieć jakiś wgląd na użytkownika, jakiś zdrowy rozsądek - nawet jak ma odgórnie ustalone projekty stworzone przez UX designerów (albo co gorsza przez grafików, którzy myślą tylko o tym, żeby ładnie wyglądało), to frontendowiec jest osobą, która zamienia to z designu na rzeczywistość i pierwszym testerem. Więc też powinien mieć jakiś zmysł UXowy.

Np. na designie może być jakaś wielkość i kolor fontu, bo tak się designerowi wydawało, że taka będzie dobra -- jednak frontendowiec testując to na kilku monitorach zauważa, że na jednym z monitorów litery są słabo widoczne (różnica w odzwzorowaniu kolorów między monitorami) albo wręcz za małe. Mając w dupie użytkownika frontendowiec położy lachę, mając to wyczucie, może coś z tym zrobić, albo ew. skonsultować to z designerem, co ma z tym dalej zrobić.

Poza tym - może się np. okazać, że zaprojektowany design jest zbyt ociężały pod kątem działania - i tylko frustruje. UX designer niekoniecznie to przewidzi, bo to złe działanie może wynikać z technicznych szczegółów implementacji.

Poza tym pewne rzeczy nie muszą być dospecyfikowane. Np. właściwość meta w HTML. Niektórzy programiści jak barany blokują tam możliwość zoomowania na mobilkach, co w większości przypadków jest bezsensowne, bo blokuje możliwość zoomowania na mobilkach.

Poza tym frontendowiec mając wiedzę techniczną może przewidzieć pewne rzeczy, z którymi może wyniknąć problem w przyszłości.

Więc myślę, że jakieś wyczucie na użytkownika jest tak czy siak potrzebne, nawet jeśli ekspertem od UX jest kto inny.

Jak Google wprowadzi w przyszłych standardach ES7...ES35 taki przystępny sposób programowania, że będzie on wygodniejszy od różnych frameworków. To też będziecie się trzymać ich bo tak wypada być cool na czasie? Przebudowanie języka może go na tyle ulepszyć że pisanie w nim będzie przyjemnością, do tego główny język jest zawsze wydajniejszy od frameworka.

nie chodzi o język, tylko o warstwę DOM. To by musiało zostać ulepszone, a nie język programowania.

Jak Google wprowadzi w przyszłych standardach ES7...ES35 taki przystępny sposób programowania, że będzie on wygodniejszy od różnych frameworków. To też będziecie się trzymać ich bo tak wypada być cool na czasie?

No chyba wtedy nie byłoby to już kól i na czasie...
A ty wtedy będziesz specjalnie programował w czymś, co jest niemodne, żeby przypadkiem nie być trendy i na czasie?

Przebudowanie języka może go na tyle ulepszyć że pisanie w nim będzie przyjemnością, do tego główny język jest zawsze wydajniejszy od frameworka.

No, a diesel jest szybszy od Mercedesa. Co ma piernik do wiatraka? Framework jest napisany w języku. Nie konkuruje z nim.

Jak Wiesio napisze parę funkcji pomocniczych do reagowania na zdarzenia to też napiszesz że to wolniejsze niż główny język? Przecież to absurd. Frameworki i biblioteki to po prostu zbiór takich funkcji pomocniczych. Wiesio napisałby to samo, gdyby miał czas i wyobraźnię.

A dużo się w JavaScript zmieniło od roku 2009, gdzie koleś tu wytykał wady JS na korzyść Javy.
http://ferrante.pl/frontend/javascript/setki-standardow-tysiace-problemow-i-tylko-jeden-javascript/

A czy wyobrażasz sobie napisać zaawansowaną grę 3d bez directx'a czy jakiegoś openGL? Frameworki mają ten plus że tak jak biblioteki graficzne nie ma znaczenia jaki jest sprzęt, będzie wyglądało i działało tak samo. Dla przykładu jakieś 2 lata temu, to co napisałem działało wszędzie oprócz safari. Uniknął bym tego gdybym użył jquery. Poza tym przyspieszają pracę. I nie jest to przyspieszenie rzędu 10% a paruset %. A chyba lepiej zapłacić programiście za 100 godzin niż 200 skoro efekt jest taki sam? Bebechy zleceniodawcy nie interesują bo się po prostu na tym nie zna. Mówisz o dodatkowym obciążeniu ale komputery też są dużo lepsze i to co kiedyś nie uciągnął by żaden pc teraz łyka laptop za 500zł z biedry. Poza tym to user chce fajerwerków. To user chce aby tu mu coś wyskoczyło, tu mu coś podświetliło. Dodatkowo jeszcze spójrz na czas ładowania strony SPA vs zwykłe requesty. Przy zwykłych requestach (zakładając że user nie keszuje) musi pobrać np. 5 plików css, 5 js'ów i 10 zdjęć. co daje 20 plików. Przeglądarka naraz łyknie 4 więc 5 razy musi odpalić się całe pobieranie, a to trwa. W SPA na początku pobierze tych plików 50, ale każde "odświeżenie" będzie trwało dużo mniej bo pobierze tylko json'a.

A czy wyobrażasz sobie napisać zaawansowaną grę 3d bez directx'a czy jakiegoś openGL?

to trochę inne przelożenie. DirectX i OpenGl to dość niskopoziomowe API, można to porównać bardziej do pisania w czystym API przeglądarkowym.

Użycie frameworka do stron to bardziej jak użycie biblioteki/silnika do gier.

Wibowit napisał(a):

Moim zdaniem pisanie bez żadnego frameworka czy biblioteki jest kompletną pomyłką. Podstawową zaletą frameworków/ bibliotek w JavaScripcie jest to, że to autorzy tych tworów dbają o kompatybilność ze standardami i przeglądarkami.

Uważam, że ten argument jest drugorzędny. Pierwszy i podstawowy sens korzystania z frameworków we FrontEnd to security, a szczególnie walka z XSS.
Próba zrobienia czegoś bezpiecznego w vanilla js lub jquery to po prostu spacer po polu minowym. W teamie większym niż zero osób się nie da. W końcu ktos się pomyli.