nauka JS bez frameworków

Czy jest sens ograniczać się tylko do "czystego" JS? Czyli żadnych frameworków itp.

Nie

Na początek spoko. Możesz poznać sam język + różne przeglądarkowe API. Myślę, że warto umieć tworzyć kod bez frameworka.

Ale na dłuższą metę. Kiedy nawet opłaca się zrobić coś bez frameworka (nawet jeśli takie znasz)?

• jak masz potrzebę zrobienia czegoś prostego, to umiejętność zrobienie tego od zera może być przydatna. Nie każda stronka jest na tyle złożona, że musi mieć Reacta i tuzin innych bibliotek
• bez frameworka możesz z powodzeniem zrobić grę 2D
• jak robisz coś, co ma charakter biblioteki/widżetu (np. bibliotekę do wykresów, osadzalny edytor , whatever) i chcesz, żeby ludzie mogli to osadzać w swoich aplikacjach, niezależnie od tego, z jakiego frameworka korzystają. I chcesz, żeby to było lekkie i wydajne.

Ale z drugiej strony, dlaczego warto znać i pisać we frameworku:

• jak masz aplikację ze złożonym GUI (pomyśl o takim typowym SPA jak Facebook), to jednak React/Vue/Angular czy coś podobnego jest konieczne. Wtedy jeśli nie użyjesz żadnego popularnego frameworka, to albo zrobisz spaghetti, albo skończy się na tym, że żeby zachować porządek w kodzie, to zaczniesz robić własny autorski framework specjalnie pod tę aplikację (a kto wchodził w jakiś autorski firmowy framework pewnie się zgodzi, że zwykle takie rzeczy są kiepsko zrobione i odkrywają Amerykę reimplementując w gorszy sposób rzeczy, które są w popularnych frameworkach)
• bez znajomości popularnego frameworka ciężko będzie o pracę na frontendzie

Zależy do czego, jeśli do pracy to na frontendzie prawie zawsze wymagają np. Reacta czy Angulara. Jeśli JS na backendzie to też jakiś Node.

Ja bym powiedział że odpowiedź na każde pytanie w stylu Czy warto się uczyć <język programowania> bez framework'a, odpowiedź brzmi "Tak".

Raczej nie ma takich rozwiązań, które są tak dobre że używa się ich wszędzie. Języki programowania same w sobie są potężniejszymi, i same w sobie dużo bardziej wszechstronne niż jakakolwiek biblioteka lub framework napisany w nich.

Potem się tworzą tacy programiści speccjalnej troski, którzy nie rozróżniają feature'a frameworka od języka.

Napiszę, skąd takie pytanie.

Aktualnie przerabiam sobie taką książkę:
ECMAScript 6. Przewodnik po nowym standardzie języka JavaScript Autor: Nicholas C. Zakas

I przyznam, że to jest cholernie ciekawe! Chcę wejść głębiej w JS.

Tylko czy jest sens wchodzić w "gębie", jeżeli są frameworki.

kosmonauta80 napisał(a):

I przyznam, że to jest cholernie ciekawe! Chcę wejść głębiej w JS.

Tylko czy jest sens wchodzić w "gębie", jeżeli są frameworki.

Ale to nie ma nic do rzeczy. Weź sobie poprzeglądaj wątki dotyczące choćby Reacta. Większość problemów, jakie ludzie mają z Reactem, dotyczy naprawdę problemów ze słabą znajomością JavaScriptu (np. niezrozumienie jak działa asynchroniczność, zmienna this, domknięcia(closures) itp.). Jeśli chcesz być dobry we frameworku, to warunkiem wstępnym jest wiedza o JS.

Nauka frameworka nie zastąpi wiedzy o JavaScript.

To co React/Vue/Angular itp. ci zastąpią to raczej konieczność bezpośredniej pracy z DOM. To, że zamiast document.getElementById czy foo.addEventListener będziesz to robić we frameworku.

(z drugiej strony znajomość czystego DOM (i innych API przeglądarkowych) też się przydaje, bo inaczej do prostej stronki będziesz zaciągał framework. Plus pewnych rzeczy nie ma we frameworkach).

kosmonauta80 napisał(a):

Napiszę, skąd takie pytanie.

Aktualnie przerabiam sobie taką książkę:
ECMAScript 6. Przewodnik po nowym standardzie języka JavaScript Autor: Nicholas C. Zakas

I przyznam, że to jest cholernie ciekawe! Chcę wejść głębiej w JS.

Tylko czy jest sens wchodzić w "gębie", jeżeli są frameworki.

No oczywiście że tak. Frameworki działaja tylko w rejonie w którym zostały przewidziane przez swojego autora/autorów. Język działa wszędzie.

Jeśli ktoś pracuje w pracy/firmie nad jednym projektem, i tylko w jednej techonolgoii, i.e. ktoś pisze przez 2-3 lata tylko w Reacie, to łatwo mu mówić że JS bez Reacta nie ma sensu; wow, that's his job.

Ale podejdź do kogoś wszechstornnego, który w tym samym czasie pracował nad dziesiątkami projektów, każdy w innej technologii, i zauważysz że zasady języka działają wszędzia, natomiast zasady frameworka są adekwatne tylko tam gdzie jest użyty; a przy okazji sama zasadnośc takiego frameworka nie zawsze ma sens.

Plus to, że jak masz framework, to za rok wyjdzie nowa wersja, a za kilka lat wypadnie z mody. A JS przetrwał już ponad 20 lat (choć teraz coraz częściej uzupełniany TypeScriptem. Plus sam JS ciągle się rozrasta, jest coraz więcej ficzerów w samym JS. A to też trzeba umieć ogarniać, nauczyć się wykorzystywać nowe ficzery, ale też zorientować się, które są zbędne itp.).

@kosmonauta80: Przeciez 99% rzeczy na frontendzie robi się z frameworkiem chyba ze pracujesz u Janusza i klepiesz landing page, a framework to praktycznie js + dodatki zeby się lepiej pracowało. Jak myslisz ze nie ma js'a we frameworkach to sie mylisz.

Descendant napisał(a):

@kosmonauta80: Przeciez 99% rzeczy na frontendzie robi się z frameworkiem chyba ze pracujesz u Janusza i klepiesz landing page, a framework to praktycznie js + dodatki zeby się lepiej pracowało. Jak myslisz ze nie ma js'a we frameworkach to sie mylisz.

Tylko jeśli robisz aplikacje które są crudami i nie mają jakiejś większej logiki w sobie.

Prawa jakimi rządzi się frontend to te same prawa które działają na dowolne inne aplikacje, i składają się z domeny biznesowej, interfejsu (użytkownika lub programistyczny, UI lub API), i ewentualnie persystencji jeśli jej wymagają.

Jeśli twierdzisz że "na froncie wszystko się robi we frameworku", np React, to to znaczy ze Twoje aplikacje niemal w całości składają się z interfejsu użytkownika, i nie mają jakiejś większej logiki w sobie.

Napisz sobie dowolną dobrą bibliotekę albo dowolną aplikację która nie polega tak bardzo na UI, np aplikacje do modelowania 3d, edytor online podobny do octo.app, program graficzny online podobny do "Photoshopa online", arkusz kalkulacyjny online (jak Google spreadsheet), i kiedy wejdziesz w taki projekt w którym UI to jest może 10% aplikacji to może się zorientujesz jakie głupoty wygadujesz. Wytwarzanie oprogramowania to nie tylko stawianie projektów z react-scripts, podpięcie reduxa i axiosa i klepanie komponentów.
Ps: nie ma czegoś takiego jak npm install js-3d-editor ani npm install js-spreadsheet ;) musiałbyś je napisać sam.

Łatwo mieć taką oponie jak robisz aplikacje które nic nie robią tylko strzelają ajaxami i wyświetlający JSONy w tabelkach, albo kiedy jedyne wymagania od klientów to zmiany stylów albo zmiana endpointa pod który się strzela.

I tak bez czystego JS się nie obejdziesz, więc nie rozumiem sensu pytania.
Nawet tworząc w dowolnym frameworku będziesz używał odpowiedniego języka programowania.

Chodzi mi generalnie o to, czy jest sens poświęcać czas i energię na poznawanie większości elementów tego języka.

Na przykład:

• symbole
• iteratory/generatory
• prototypy
• klasy

Jeżeli chodzi o tematy typu asynchroniczność, to tutaj już nie mam wątpliwości

• klasy

Tak, są często używane (nawet zbyt często, ale co zrobić, ludzie je polubili i używają nawet wtedy, kiedy są niepotrzebne)

• prototypy

Tak, to podstawa, nawet jeśli dziedziczenie zwykle robi się za pomocą klas, to i tak warto wiedzieć, jak to działa.

Na przykład:

• symbole

Nad czym się zastanawiasz? Symbole akurat są proste. Wystarczy przeczytać artykuł, który podaje ich kilka cech (to, że są prymitywami, to że są unikalne, że mogą być używane jako klucze, że niektóre symbole są już zdefiniowane - well-known symbols itp.) i możesz używać (tylko jednak trzeba się nimi pobawić, bo mimo, że proste, to mogą zaskakiwać swoim działaniem na początku)

• iteratory/generatory

Tak, jeśli chcesz pisać kod, po którym ładnie można iterować albo który implementuje jakiś algorytm i emituje kolejne wartości z danego algorytmu... albo jeśli robisz coś, co działa asynchronicznie i emituje wartości asynchroniczne (async generatory można używać jako alternatywę dla bibliotek reaktywnych typu Rx.js. Tzn. trochę inny paradygmat, ale podobny efekt). Albo jeśli chcesz mieć pauzowalne funkcje itp.

kosmonauta80 napisał(a):

Chodzi mi generalnie o to, czy jest sens poświęcać czas i energię na poznawanie większości elementów tego języka.

Jeśli chcesz być dobrym(albo chociaż znośnym) programistą JSa - wtedy tak, warto jednak poświęcić czas i energię na poznanie języka, w którym się pisze.
Nawet więcej czasu bym poświęcił poznaniu języka niż nauce frameworków. Najlepiej w praktyce. Bo warto przeczytać coś, ale warto samemu czymś się pobawić. Najlepiej się można nauczyć robiąc po prostu projekt i używając jakichś ficzerów z języka, czasem aż nadużywając, aż człowiek zrozumie, że pewne ficzery są przydatne, ale mają swoje wady i trzeba wiedzieć kiedy i jak użyć).

Reasumując: w moim interesie jest, by każdego dnia poczytać książkę, jakiś artykuł, potestować coś w konsoli lub zrobić cokolwiek, co pogłębi moją wiedzę i zrozumienie tego języka.

Zauważyłem, że jak jadę do pracy, albo biorę prysznic, to myślę o kodzie JS (jak zrealizować pewien projekt). Dobry czy zły objaw? :D

kosmonauta80 napisał(a):

Zauważyłem, że jak jadę do pracy, albo biorę prysznic, to myślę o kodzie JS (jak zrealizować pewien projekt). Dobry czy zły objaw? :D

Dobry chyba.

Tzn nie wiem czy JS to dobry objaw, ale samo rozkminianie problemu chyba tak.

Czy warto uczyć się jazdy na motocyklu?

Wyjdź od celu - co chcesz umieć zrobić, a potem
dobierz narzędzia.