JAVASCRIPT - powrót do podstaw / co pominąć ?

0

Witam,
Od pewnego czasu ukierunkowałem się mocno na Front-end - można powiedzieć że bawię się przy tym fajnie i nie ma nudy.

Mam do osób które pracują w branży pytanie.
Zastanawiam się jednak czy wskakiwać od razu na JS i sobie go przypominać kierując się w strone frameworków.

Czy masterować wcześniej flexboxa i np cssgrida - którego przerobiłem, w podstawach umie używać. Jak to tego podejść żeby nie marnować cennego czasu ?
Dodam że ścieżkę z gita znam. Co według was warto pominąć bo i tak inna wersja tego samego będzie używana we frameworku - czy może warto znać wszystko, albo chociaż wiedzieć że istnieje i zrobić kilka podstawowych ćwiczeń z danych zagadnień.

3

Jakie jest pytanie?

3

Czy masterować wcześniej flexboxa i np cssgrida - którego przerobiłem, w podstawach umie używać. Jak to tego podejść żeby nie marnować cennego czasu ?

Do flexboxa jest fajna stronka, która tłumaczy to graficznie: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
i mnie to oszczędza czas, bo ciągle mi się mylą te właściwości, więc wchodzę na stronkę i patrzę, jaki efekt chce osiągnąć i jaka właściwość za to odpowiada.

Co według was warto pominąć bo i tak inna wersja tego samego będzie używana we frameworku - czy może warto znać wszystko, albo chociaż wiedzieć że istnieje i zrobić kilka podstawowych ćwiczeń z danych zagadnień.

Powiem tak - często widzę jak ludzie używają Reacta i mają problemy niby to z Reactem, ale w rzeczywistości ze zrozumieniem tego, jak działa JavaScript (szczególnie widzę problemy z this, domknięciami, asynchronicznością). Więc niby są "frameworki", ale i tak trzeba suchy JavaScript znać, żeby w nich działać.

Co według was warto pominąć bo i tak inna wersja tego samego będzie używana we frameworku - czy może warto znać wszystko, albo chociaż wiedzieć że istnieje i zrobić kilka podstawowych ćwiczeń z danych zagadnień.

JavaScript rozwijał się krętymi ścieżkami, więc np. nawet jak korzystasz const czy let, to i tak warto wiedzieć, jak działa var (choćby dlatego, że w starszym kodzie możesz się zetknąć z tym), niby jest async/await, ale warto znać Promise'y (szczególnie, że jednak Promise'y są potężniejsze i pewnych rzeczy z async/await nie zrobisz), niby są klasy, ale warto wiedzieć jak działają prototypy, bo to i tak na prototypach się opiera pod spodem. Albo (podając już przykład z konkretnej biblioteki, mianowicie z Reacta) - obecnie trendem jest robienie komponentów na funkcjach(i hookach), ale przez lata robiło się na klasach, więc warto też znać klasowy sposób, bo taki też spotkasz w projektach.

Czyli lepiej mieć świadomość różnych rzeczy, bo mogą się pojawić w kodzie albo dać o sobie znać w pośredni, tajemniczy sposób (coś ci nie będzie działać, a okaże się, że dlatego, że nie wiesz, jak coś działa pod spodem. Albo np. będziesz robić coś naokoło, bo nie będziesz wiedział, że można inaczej.

1 użytkowników online, w tym zalogowanych: 0, gości: 1