Ś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]

Co rozumiesz pod pojęciem "szablonów HTML-a"? Bo jeśli Twiga czy wąsy, to prawdę mówiąc nie rozumiem oburzenia na CSS. Jeśli natomiast coś, co robi Angular (HTML jako widok i szablon równocześnie), to jestem tego przeciwnikiem.

A teraz inaczej: a co Ci daje wygenerowanie stylów inline przez Reacta, jak nie super ubogą protezę, która nawet nie umie reagować na takie zdarzenia jak :hover? Rozwiązujemy jeden problem, wpakowując się od razu w kolejny.

Tak, style powinny być dołączane do komponentów, ale IMO jako CSS, bo to daje największe możliwości na chwilę obecną. I czy ja wiem czy em itd są takimi protezami? https://css-tricks.com/rems-ems/ → każdy moduł się ładnie skaluje samodzielnie do całego systemu, równocześnie pozostając de facto autonomicznym. I zanim mi powiesz, że to jest strona a nie aplikacja: a czym się różni strona od aplikacji na poziomie GUI? Bo jak dla mnie niczym - to wciąż HTML + CSS. W aplikacji jedynie mamy do tego potężną logikę w JS.

Wydaje mi się, że dyskutujemy na całkowicie dwóch różnych poziomach. Ty mówisz jakie problemy próbuje rozwiązać React (i co do tego jakie to są problemy się zgadzam, natomiast nie zgadzam się ze sposobem ich rozwiązania, mimo wszystko upatrując rozwiązania w WC), ja mówię o tym jakie problemy wprowadza rozwiązanie Reacta. Mam równocześnie wrażenie, że Ty mówisz to jednak bardziej z pozycji backendowca, ja z "mocnego frontu".

[solificati]

Mam równocześnie wrażenie, że Ty mówisz to jednak bardziej z pozycji backendowca, ja z "mocnego frontu".

Ano, backendowiec, który wrzuca projekty w clojurescripcie. Serio, pozostań przy śledzeniu blogów o tym czy em już jest ok czy nie, kiedy i gdzie będzie calc i co będzie potrafił robić. Te wszystkie problemy zostały już rozwiązane w innych technologiach, to Ty się upierasz, że należy je rozwiązywać technologią nieprzystosowaną do tego. Style w reactie mogą być aplikowane inline tak jak może być wygenerowany styl dla strony - wiem bo tak robię za pomocą gardena i reagenta. Mogę mieć hover czy cokolwiek innego dziwnego z cssa. Jedynie względem reacta mam nadmiarowe style, bo mam dla wszystkich komponentów możliwych do wystąpienia (co i tak jest małą liczbą w porównaniu do ogólnych praktyk, gdzie cssa masz tyle ile będzie potrzeba na wszystkich stronach razem). Mogę stylem dowolnie manipulować, niezależnie od implementacji przeglądarek. Mogę zrobić autolayout, mogę dobierać wymiary zależnie od stanu, mogę kolorować w dowolny sposób bez obkładania się tysiącem selektorów albo tricków w postaci :nth-last-child(n+3), etc. Przede wszystkim, styl może być zależny od danych, bez nadmiarowego kodu. Serio, to jest handlebars/mustashe po raz kolejny. Tak jak wtedy 'mocni frontendowcy' musieli napisać swój pierwszy {{#list tak teraz, muszą napisać swój pierwszy autolayout. I apropo mocnego frontu jeszcze - w clojurescripcie robimy to jeszcze lepiej. Nie mówiąc o templateach, to robimy o wiele lepiej.