Ścieżka rozwoju, Czego uczyć się dalej oraz w jakim celu Opcje

[DanielG44K]

Witam,

strony internetowe projektuję profesjonalnie już dobre 3 lata. Uważam, że PHP, JS, Jquery, HTML, CSS ogarniam na poziomie zaawansowanym. Pytanie co dalej?

Nie ukrywam, że zanim wezmę się za C++/C# ( podstawy już mam, doświadczenia w kodowaniu - zero ) chciałbym się jeszcze trochę rozwinąć aby mieć na czym dorabiać zanim nauczę się innych języków oraz aby nie zostać z technologią w tyle.

Stąd moje pierwsze pytanie, mianowicie w jakim celu są wykorzystywane technologie AngularJS, ASP.NET, Node.js itd. itp.? Przeglądając oferty pracy programisty front-end'u często się z tymi terminologiami spotykam, jednakże przeglądając kursy, nie widzę miejsca w którym mógłbym je zastosować. Oczywiście tych bibliotek chociażby JS'owych jest o wiele więcej.

Znajdzie się miła duszyczka które pomoże rozwiać wątpliwości w jakim kierunku się rozwijać i czy ma to w ogóle sens? ( zakładam, że ma, dlatego napisałem ten post )

Pozdrawiam,
Daniel Galas

[Comandeer]

Tak samo mogę powiedzieć, że na najnowszych przeglądarkach tylko pracuję, więc nie potrzebuję całego crapu jakim jest zepto.

Witam w klubie (IMG:style_emoticons/default/wink.gif)

Właśnie nie. Jeśli statycznie jesteś w stanie opisać style cssa to możesz je wygenerować na podstawie drzewa komponentów i dodać do strony. Celem tego wszystkiego jest możliwość manipulacji wartościami cssowymi w kontekście. Żeby nie być przywiązanym do emów, procentów i innych takich rzeczy. Wtedy constraint based layouty są proste. Gdzieś facebook pokazywał jak chce opisywać komponenty cssem - jakaś wariacja jsxa. garden używają teraz już om (wrapper do reacta). Pozwala manipulować stylami tam gdzie się powinno to robić - w obrębie jednostki logicznej a nie ze względu na rodzaj technologii.

Tak, w React style są przekazywane jako POJO i to nawet nie jest takie głupie (swego czasu Absurd.js mnie urzekł (IMG:style_emoticons/default/wink.gif) ), ale to, co z tymi stylami jest później robione to już nie jest fajne. Bardziej bym już szedł w kierunku ICSS: https://github.com/css-modules/icss ale IMO to też przerost formy nad treścią.

Jasne, doskonale zdaję sobie sprawę z tego, że przy tworzeniu Sieci opartej na komponentach style powinny być powiązane z konkretnym komponentem i nie istnieć w globalnym scope. Ale da się to zrobić bez urzynania wszystkich korzyści, jakie daje CSS, sprowadzając go do atrybutu [style] - style[scoped], Shadow DOM, BEM itd. Na chwilę obecną daje to o wiele więcej możliwości niż to, co proponuje React: https://speakerdeck.com/vjeux/react-css-in-js

Nie twierdzę, że problem, na który zwrócił uwagę React nie istnieje - twierdzę, że próbuje się go rozwiązać od tyłka strony. Ja bym raczej szedł właśnie w architekturę BEM (kurka, muszę wreszcie to spisać jako artykuł (IMG:style_emoticons/default/biggrin.gif) ) i/lub Web Components. Tym samym można operować na stylach w obrębie danej jednostki logicznej I używanej technologii (IMG:style_emoticons/default/wink.gif)

Co do constraint based layouts: jeśli chce się użyć komponentu w szerszym kontekście, to i tak się nie uniknie potrzeby jego dostosowania do reszty pod względem wymiarów. Zostawienie tego JS-owi czasami jest bardziej kłopotliwe niż zrobienie tego od razu w CSS.

[solificati]

Tak, w React style są przekazywane jako POJO i to nawet nie jest takie głupie (swego czasu Absurd.js mnie urzekł (IMG:style_emoticons/default/wink.gif) ), ale to, co z tymi stylami jest później robione to już nie jest fajne. Bardziej bym już szedł w kierunku ICSS: https://github.com/css-modules/icss ale IMO to też przerost formy nad treścią.

Jasne, doskonale zdaję sobie sprawę z tego, że przy tworzeniu Sieci opartej na komponentach style powinny być powiązane z konkretnym komponentem i nie istnieć w globalnym scope. Ale da się to zrobić bez urzynania wszystkich korzyści, jakie daje CSS, sprowadzając go do atrybutu [style] - style[scoped], Shadow DOM, BEM itd. Na chwilę obecną daje to o wiele więcej możliwości niż to, co proponuje React: https://speakerdeck.com/vjeux/react-css-in-js

Nie twierdzę, że problem, na który zwrócił uwagę React nie istnieje - twierdzę, że próbuje się go rozwiązać od tyłka strony. Ja bym raczej szedł właśnie w architekturę BEM (kurka, muszę wreszcie to spisać jako artykuł (IMG:style_emoticons/default/biggrin.gif) ) i/lub Web Components. Tym samym można operować na stylach w obrębie danej jednostki logicznej I używanej technologii (IMG:style_emoticons/default/wink.gif)

Atakujesz chochoła, nieskończoną eksperymentalną implementację. Ani bem, ani komponenty też nie pozwolą operować na stylach - będziesz uwiązany do hacków z cssa. Rozwiązanie reacta (które zostało zainspirowane innymi) pozwoli kompilować property ogólnie dotyczące stylu, z zachowaniem semantyki JSa do CSS. Dokładnie to, co robiły najpierw templaty i teraz react z htmlem. Jeśli mam uzależnić coś od pozostałych styli to wolę to napisać explicite i w sposób deklaratywny a nie liczyć na nowe funkcje w css. Do tego mogę mieć wynikowy css bardziej optymalny a przede wszystkim lepiej wyscopowany. To czy wynik będzie w inline czy skompilowanym jednym pliku per strona to sprawa wtórna.