Na jQ stoi internet. Zawsze będzie potrzebny ktoś kto tym kodem będzie musiał się zajmować. Cały czas jQ jest dobrym pierwszym kitem do pracy z JS i cały czas warto rozwijać swoje umiejętności poznając jak jesteśmy w stanie uzupełnić swoją wiedzę tym skryptem. Jasne że do tworzenia nowoczesnych rozwiązań, zaawansowanych struktur i ogólnie wygody pracy najlepiej nauczyć się jakiegoś nowoczesnego frameworka, jednak większości juniorów bardzo trudno będzie bez dobrego zrozumienia vanila js uzyskać zadowalające efekty przy użyciu takich zaawansowanych narzędzi. Największą zaletą jQ jest jego poziom wejścia i to jak dużo może dodać zrozumienia samego procesu web developmentu w rozwoju samego developera który z tym paszkwilem przeszłości pracuje. jQ się nie lubi ale powinno się rozumieć ;)
Pamiętajcie, jak pisać stronki to przede wszystkim tylko na tabelach, stylujemy w tagach html, wtedy wszystko jest na miejscu nie trzeba szukać w tym style.css 1800 linijek. Wymiary stronek koniecznie w pixelach, a nie jakieś wyimaginowane remy emy. Javascriptu używamy żeby wklejać znaczniki w tekst i żeby zerować style css. Nie muszę chyba mówić, że wszystko na końcu pliku index.html, a nie jakieś oddzielne pliczki. Jak używamy bibliotek to pamiętajcie żeby cały kod wrzucić to wiadomo że wam nie zniknie. Hmm co tam jeszcze z tych dobrych praktyk mogę wam polecić... Róbcie sobie kopie plików i wrzucajcie na ftp index_1.html i tak dalej. No także pozdrawiam.
Mysle ,ze ważne argumenty dla kogos kto np tak jak ja właśnie uczy się fronendu. Słyszałem sporo o jQuerry ale chociaz jeszcze nie tknąłem prawie js to chyba to bedzie dla mnie must have.Dzieki i pozdrawiam
Akurat ja bardzo lubię jQuery; i choć częściowo się zgodzę, że nie jest już potrzebne; to nadal używam. Przede wszystkim dlatego, że ma bardzo przyjemną składnie, a napisanie w nim czegoś zajmuje mniej linijek niż vanilia javaScript. I jest też dzięki temu bardziej czytelne. Dlatego; po okresie, gdzie zgodnie z nowymi zaleceniami starałam się nie używać jQuery; wróciłam do niego i zdecydowanie wole go, niż vanilia javaScript. Zresztą, nie spotkałam się chyba z projektem, gdzie jQuery nie było użyte, chociaż by do jakiegoś maleńkiego fragmentu kodu. I w sumie traktuje jQuery właśnie jako uproszczony jeszcze bardziej js. Ale, nie będę ukrywać, że wpływ na moją opinię może mieć też sentyment. jQuery bardzo mi pomógł w nauce frontendu, javaScriptu i programowania. Genialna dokumentacja i prostota to jego ogromne zalety. Zresztą, jak się ostatnio okazało, nie tylko mnie. A z opinią, że ktoś zrozumiał javaScript, dopiero kiedy zaczął pracę z jQuery; spotykam się coraz częściej.
sprytnie, ale wtedy przeszukiwanie pod DOM jest tylko w kontekście globalnym (document). można zrobić metodę do szukania po sub-drzewie - będzie wydajniej. const $ = (selector, parent = document) => parent.querySelector.call(parent, selector);
Bardzo chciałbym przestać używać JQuery, czasem nawet się udaje, ale akurat większość projektów przy których pracuję już go używa. Często też nie ma czasu na szukanie bibliotek napisanych w vanilla JS, kiedy już znajdzie się dokładnie to czego potrzeba, ale wymagające JQuery.
Zaczynam przygodę z Front-Endem i nie mam zamiaru. Uważam, że to co przedstawiłeś w tym odcinku to oczywistość - jQuery jest zastępowalne, samo w sobie nie jest konieczne, więc nie widzę potrzeby (bez jakiegoś przymusu osób trzecich), by tę "gałąź" opanowywać.
A ja chciałbym zapytać czy Tree Shaking powoduje, że mogę używać jQuery bez strachu przed spadkiem wydajności bo zostanie tylko użyta funkcja/kod którego potrzebuje, a reszta zostanie "wywalona" z projektu?
Hobbistycznie siedzę w stronach od 2009 roku. Dopiero bardzo niedawno temu zacząłem na tym zarabiać, traktować to zawodowo i uczyć się od lepszych od siebie (kursy, tutoriale, dokumentacje), a nie tylko eksperymentować. Nigdy mnie nie ciągnęło do jQuery, wolałem backend, a po JS sięgałem, gdy musiałem. Dziś przychylniej spoglądam na frontend, ale jQuery dalej nie chce mi się uczyć. :P
Spoko odcinek. Właśnie dostałam projekt, do którego wykorzystano jQuery, trochę się więc właśnie zderzyłam z tym, co napisałeś - musiałam go przynajmniej liznąć. I mam do Ciebie pytanie właśnie w tym kontekście. Co myślisz o mieszaniu czystego JS'a i jQuery w jednym pliku. Czy oprócz tego, że paskudnie wygląda ^^' wpływa to jakoś na wydajność?
W takim razie nawet tego nie ruszam :D A ostatnio zająłem się budowaniem strony z komponentów napisanych w samym js, plus API (te z odcinka z figmy, postanowilem je wykorzystać), i dopiero teraz zrozumiałem o ile wcześniej mogłem bardziej zainteresować się js
Drobna poprawka, powinno być .classList a nie ".classList()". To nie metoda tylko obiekt typu :DOMTokenList. W kontekście jQuery warto powiedzieć o jego autorze: John'nie Resig'u. Bo napisał ciekawą książkę - zwłaszcza jeśli ktoś chce się podszkolić z czystego JavaScript'u. jQuery uczyć się nie warto, ale warto zrobić własną bibliotekę a'la jQuery, implementując chociażby te funkcjonalności poruszone w tym odcinku - dla sprawdzenia samego siebie i udowodnienia sobie iż nie mamy potrzeby stosować już jQuery :) (uwaga: opcja dla mających czas i chęci!) Nie poruszył Pan jednak najważniejszego chyba wykorzystania jQuery: $(document).ready(() => {}) na to również są aktualne (już wtedy) metody (eventy): window.onload = () => {} lub window.addEventListener('DOMContentLoaded', () => {}); oraz tego co dalej będzie trzymało jego zwolenników, czyli np. uproszczone wywołanie AJAX $.ajax(...) co również sprowadza się do dzisiejszego: fetch, lub jeszcze bardziej zaawansowanej biblioteki "axios" - zamiast jQuery "Gówno-burza" będzie trwała jeszcze długo, Panie Romanie. Ponieważ główne powody stosowania jQuery to: 1. Nie lubie JavaScript'u 2. Nie mam frameworka tylko chce coś "na szybko" 3. Stosuje bootstrapa a tam mi kazali to dodać 4. Znalazłem kontrolkę xyz do frameworka zyx i ona wymaga jquery ... etc. PS. jQuery to nie tylko uproszczone API i selektory, to również rozpropagowanie IFFE (za pomocą sposobu deklarowania plug-inów), oraz podwaliny pod AMD [ ale to też nie daje argumentu za nauką tego. Te rzecza (modularyzacja) to teraz standard (no poza AMD, bo nie ma co się męczyć tylko CommonJS (Node) FTW !) ]
Nauka jQuery może być przydatna, ale jeśli potrafimy już dobierać biblioteki do potrzeb. Myślę że nie ma sensu od niego zaczynać swoich przygód z frameworkami/bibliotekami. Przykładowo do małych projektów, do których instalujemy Bootstrapa, musimy też zainstalować jQuery aby wszystko sprawnie działało - skoro więc już musimy go zainstalować, to po co dodawać inną bibliotekę zamiast wykorzystać tą która już jest? Poza tym, faktycznie, querySelector oraz querySelectorAll działa bardzo sprawnie, ale ma jeden znaczący minus - przy jQuery zapis typu $('element').funkcja(); z automatu zaaplikuje funkcję do złapanych elementów. Przy querySlectorAll('element') dostajemy tablicę elementów a potem funkcję trzeba aplikować do każdego elementu z osobna w pętli. Ale fakt, wszystko co kiedyś ułatwiało jQuery, dzisiaj da się niewiele większym nagładem pracy zrobić w czystym JS, a wyjadność kodu może być znacznie wyższa.
Nie jestem osobiście zwolennikiem jQuery (znam go od bardzo dawna) ale ma wciąż plusy. Chodzi o krótkie łapanie bez sprawdzania błędów. Robiąc $('.item') od razu możemy przypisać zdarzenie bez sprawdzania, tj: $('.item').on('click', fn);. Tego nie da się zrobić tak prosto w czystym js, bo robiąc: document.querySelector('.item').addEventListener('click', fn) może wywalić błąd gdy elementu nie znajdzie. Natomiast dla document.querySelectorAll('.item') trzeba jechać po pętli każdego elementu. Kolejnym plusem jQuery jest to że można dodać zdarzenia do elementów, które jeszcze nie powstały. Gdy dodamy je za pomocą jQuery w DOMie to automatycznie zostaną przydzielone im zdarzenia. Ogólnie, krótsze nazwy. Elelemnt poprzedni to prev a nie previousElementSibling Minusem biblioteki jest to, że jest przeładowana pod względem tego co aktualnie można już robić natywnie w JS. BTW. getBoundingClientRect jeżeli chodzi o pozycje X, Y to dokładnie chodzi o pozycje tak zwanego viewportu (okienka, który aktualnie widzimy w przeglądarce, więc mogą być wartości ujemne).
mam lekki offtop, w odcinku z pytaniami na juniora, trapi mnie pierwsze pytanie. "co robisz jeśli masz zrobić moduł w aplikacji z wykorzystaniem biblioteki której nie znam". Moim zdaniem otworzyłbym dokumentacje, rzucił okiem co to za biblioteka, po co istnieje, co się w niej robi. Z drugiej strony na podstawie jakiegoś prostego tutoriala, zrobiłbym w niej coś łatwego, żeby poznać podstawy na przykładach. Z trzeciej strony zobaczyłbym w google, czy ktoś przypadkiem nie robił już coś podobnego. Pytanie, brzmi jaka jest prawidłowa odpowiedź. PS. Potrzebujemy odcinka o SEO i SEM
Chyba ktoś zapomniał o pierdyliardzie pluginów do jquery :) prawda jest taka ze jquery był jest i bedzie bo najzwyczajniej w świecie idelanie spełnia to czego potrzebuje interakcja pod zwykłe www i jest tani w developowani. React, vue, angular i reszta są idealne ale to aplikacji, użycie ich na siłę prowadzi jedynie do podrażania kosztów wykonania i utrzymania projektu.
Ja polecam alternatywę jQuery, bardzo minimalistyczna paczka oferująca prawie identyczne API: cash.js ( github.com/kenwheeler/cash ). Dobre rozwiązanie kiedy już jesteśmy przyzwyczajeni do jQuery, a zaczynamy nowy - mały projekt, dla którego nie warto dodawać frameworków typu React etc :)
Czasami jesteś zmuszony w pracy korzystać z jQuery, bo: stary kod (np. w AngularJS) albo R shiny, jedyny framework w R, który korzysta z jQuery. (Ja w pracy np. używam shiny i R).
jedyne zastosowanie u mnie biblioteki iquery to żeby w navigacji po naciśnięciu pokazywały się itemy listy :d. Jeśli ktoś uczy się narazie html5 css-grid/flexbox i preprocesory to może sobie poużywać chwilowo jquery żeby nierobić sobie zamieszania dodjąc ogrom javascriptu :D bo to znowu calkowicie inna składnia i następna masa informacji do nauki a lepiej użyć jquery zamiast na hover rozwijać listę lbo za pomocą checkboxa
@@marcinbaazy1692 przy takiej liczbie elementów na stronie wydaje mi się że nie są potrzebne aż tak wysokie wartości zindex. Może to po prostu przyzwyczajenie 😁
Roman - dobrze wyjaśnione, uważam jednak że ten odcinek raczej tyczy się projektów które piszemy sami oraz mamy do wyboru własne biblioteki. Globalne platformy ecommerce (prestashop), systemy blogowe (wordpress) mają wbudowane jQuery jako wymagane biblioteki. Ja uważam że można się tego nauczyć bo i tak może trafić się projekt przy którym będzie to konieczne. Z racji tego że jQuery jest dość łatwe - lepiej je znać! A co do kodu który piszemy sami i mamy wybór - decyzje sam podejmie koder.
@@helloroman Fakt, lecz jak sam widzisz, takie platformy korzystają z jQuery, zarówno jak i wiele wtyczek, szablonów które są generowane dla takich platform (magento, prestashop, wordpress, joomla, drupal itp itp). Bardzo dobrym podejściem jest korzystanie z czystego jsa oraz dobranie bardziej funkcjonalnych bibliotek. Czasem jednak niesie to ze sobą dodatkowe bibloteki które i tak muszą się wczytać wśród innych do projektu co ma wpływ na optymalizację takiego projektu. Jeśli piszemy coś sami - uważam że warto skupić się na porządnym kodzie js lub użyciu efektywniejszych biblotek. Uważam że jQuery będzie jeszcze długo gościło na wielu projektach bo jest po prostu " Łatwe i znane". :)
jQuery na ten moment nie jest potrzebny tak jak był kiedyś, tym bardziej, że większość przeglądarek bazuje teraz na silniku Blink (włączenie z najnowszym MS Edge), tak naprawdę to jedynie Mozilla jeszcze robi coś po swojemu a reszta to nisza...
Myślisz,że ten rynek w IT się jakoś wyrówna? Jest pełno ofert na mid/senior ale bardzo ciężko dostać się gdzieś na juniora. Pracodawcy coraz więcej wymagają na juniora, coraz ciężej się przebić i znaleźć pracę. Robi się hype na programowanie, bootcampy, kursy, pokazywanie ofert typu 10k, 20k albo 30k miesięcznie za klikanie w komputer wow itd. Trochę robienie ludziom papki z mózgu, zostaniesz programistą albo nikim itd. Jak sądzisz, czy coś się zmieni za dłuższy czas czy tylko coraz trudniej będzie ze znalezieniem pierwszej pracy i podnoszenie wymagań na stanowisko juniorskie?
A ja w przeciwieństwie do pozostałych komentujących nie wiem o czym mowa. Widziałem ludzi, z tak chujowymi projektami, że ja osobiście wstydziłbym się to komukolwiek pokazywać, nie wspominając już o tym, żeby dołączać do portfolio.
@@bbb0599 Każdy język to zło jak się nie umie go używać. Połowa tych ludzi którzy narzekają na PHP nawet nie potrafi uzasadnić dlaczego ten język jest zły, pewnie mówią tak bo to modne bo ktoś na grupce na Facebooku rzuci hasło że PHP to gówno. :)
1. Jeżeli ktoś musi pracować z przestarzałym kodem: youmightnotneedjquery.com/ 2.1 Learning curve to termin naukowy i jako taki może jak najbardziej znaczyć przetłumaczony na krzywą uczenia się. 2.2 Jednak tutaj zastosowanie jest bardziej idiomatyczne / potoczne gdzie proces / postęp nauki byłby faktycznym tłumaczeniem. Bardziej martwiłbym się o gównoburzę. 3. A skoro mowa o gównoburzy - jeszcze żadnej tutaj nie widziałem. Szczerze mówiąc, to jest chyba pierwsze wideo gdzie w stu procentach zgadzam się z Romanem.
Wydaje mi się, że jQuery warto się uczyć tylko ze względu na to, że jeśli będziemy zmuszeni do pracy w kodzie gdzie jest jQuery to wtedy dobrze jest wiedzieć co i jak. Ale szczególnie się na tym nie znam, może mnie ktoś poprawi :).
@@helloroman Słusznie. Dzięki za odpowiedź, bo moja wypowiedź wyżej to był mój jedyny argument to liźnięcia jQuery :D A strasznie się wahałem czy warto JQ sie uczyć, czy po prostu skupić się na JS'ie i innych framework'ach.
$ powstało też by pisać mniej kodu, WP ma wbudowane $, wiem nie lubisz WP, choć nie wiem czemu, robisz przez API do REACTA i masz "jakość" SPA, a klien tworzy jak w dawnym WP.
sam wordpress wraz z jego dokumentacją wręcz straszy antywzorcami tylko po to by utrzymać kompatybilność ze swoimi pluginami i kompatybilność wsteczną. taka prawda, że większość ludzi wykorzystujących WP/jQ nie obchodzi to, że tworzą legacy a uczyć nowych rzeczy im się nie chce. nawet w wordpressie da się tworzyć dobrej jakości kod np. używając biblioteki timber i autoloadingu z composera przez PSR-4.
Ten aj w robocie same jq używam bo strony na wp/joomla / presta robione =/ ehh ale ten es6 znam ale jako ze uzywam tylko jq to lipa ..... pora douczyc sie czegos jak nic
heh, jeden odcinek o przyspieszeniu kodowania za pomocą skrótów klawiszowych itd. a teraz pisz 3 linijki w czystym JSie zamiast jednej krótkiej komendy w jQuery, która wszędzie i zawsze działa. No i co najlepsze kodować w vanija JS oraz jQuery mogę nawet na kalkulatorze, a w twoich metodach potrzebuję całe środowisko by kompilować kod... babel, nod itd. Nie, jestem starej daty, przez 10 lat używam jQuery i dobrze mi z tym ;)
@@helloroman uwierz, że długo. Niech zgadnę - miałeś okazję pracować tylko w nowoczesnych software houseach pracujących na najnowszych technologiach? Niestety to jest tylko ułamek rynku web developerki i ogólnie programowania. Legacy codów, których najzwyczajniej w świecie nie opłaca się przepisywać na nowo jest znacznie więcej. WIęc o pieniądze niech się kolega Wojtek nie martwi.
jankes83 o stronach we flashu też mówili że nie miną. Jeśli czegoś można być pewnym w tej branży to zmian - jeśli ktoś tego nie widzi, to za pare lat sie moze zdziwic.
jQuery jest useless mniej wiecej od wyjścia ES6. Nigdy tego nie lubiłem, niestety jest w podstawie programowej... Z jQuery jest jak z bootstrapem. Stara gwardia przyzwyczaiła sie do używania i tylko dlatego to istnieje. Jedyne co mnie boli, to że przez własną nieudolność uczenia się "nowych" rzeczy jak ES6+, Flex / Grid, starsi programiści upierają się i na siłę szukają plusów, których NIE MA xD I teraz nasuwa się wniosek i pytanie: Po co includowac bibliotekę, która po za wagą nic do projektu nie wnosi? Tak jak wspomniałeś - znajomość jQuery przydaje się tylko i wyłącznie w pracy przy starszych projektach. Dzięki za filmik, będę miał do czego się odwołać w dyskusji z jQuerowymi świrami :D
Może dlatego importują bootstrapa do projektu, bo po co wymyślać koło na nowo? No może faktycznie bootstrap to trochę przerośnięta krowa, ale są inne biblioteki (gridowe), które można zaimportować. Nie rozumiem ideii pisania własnego grida za każdym razem. To samo tyczy się stylizacji alertów, tooltipów itd itp. W dodatku wspomnę, że bootstrapa można okroic z rzeczy jakich się nie potrzebuje ;) i robi się z tego dość lekka libka
Ale wiesz, że bootstrap jest zbudowany na flexie i tak czy inaczej wymusza korzystanie z niego? Co innego proponujesz do szybkiego budowania responsywnych serwisów?
@@michalbacinski6700 bo teraz jest moda na to żeby bezmyślnie korzystać z coraz to nowszych technologii. Jeśli jakas biblioteka/framework jest starszy niż 5 lat to znaczy że to staroc nie nadająca się do niczego xd
@@jankes83 Jest zbudowany na gridzie, więc to już powinno same w sobie dać do myślenia :D Dla mnie liczy się jakość, a nie ilość. Równie dobrze po co pisać kod skoro można skorzystać z wiga, albo postawić portal w kilka dni na Drupalu / Worpressie :) Bootstrap był lekiem na braki w cssie 2/3 lata temu. Nie widzę dalszego sensu korzystania z biblioteki, którą w 100% wyparły funkcje bazowego języka.
@@michalbacinski6700 Coś w tym jest, ale nie do końca jest to wymyslanie koła na nowo. Zastępowanie kilku linijek cssa całym kombajnem to przerost formy nad treścią. Oczywiście jeśli importujac bootstrapa nie mamy na celu jedynie ostylowac kilku kontenerów, to może ma TO jakiś głębszy sens :D Nie wiem, korzystałem dopóki nie poznałem flexa :)
@@Pirr Powiem ci, że jeszcze nie wiem jednak pytałem się nauczycielki z zawodowych kilka miesięcy temu i mówiła, że podstawa przewiduje również jQuery Teraz będę szedł do 2 klasy technikum to się czegoś więcej dowiem
@@szymonjurczak6718 Spokojnie. Ja jestem tez w TI 4 klasa aktualnie będzie. W szkole nauczyłem się jedynie podstawowego html i CSS. Takiego że umiem przepisać polecenia z egzaminu :D. Ja i PHP nawet nie ruszyliśmy. Aktualnie do końca wakacji chcę zacząć ten js. Kończę CSS i akurat będę się mocował:p
@@Pirr Szczerze ci powiem akurat znam SQL'a od 2 klasy gimnazjum więc się szczególnie nie boję i raczej będzie to utrwalenie wiadomości co będę się uczył programowo ;P Się nie mogę doczekać aż się zaczną zajęcia z tworzenia witryn bo będzie można sobie moją i tak wątłą średnią fajnie podciągnąć xD
Jeśli chodzi o silnik Sizzle, to będzie on za jakiś czas ubity → facebook.com/groups/217169631654737/permalink/2268763249828688/?comment_id=2268787003159646&reply_comment_id=2268845943153752&comment_tracking=%7B%22tn%22%3A%22R%22%7D
skubany, wyczytałeś mi w myślach temat. Ostatnio ogarniam jquery i się zastanawiam nad sensem tego przedsięwzięcia. Spuszczać się nie będę nad jquery, ale zapoznam się, bo niektóre rzeczy robi się dużo szybciej niż w vanillii.
@@helloroman chodzi mi tylko o ilość kodu, a nie o jakieś mechaniki. Np. dynamiczna nawigacja dla one-page zajęła mi dużo mniej kodu w jquery niż to samo w vanillii, ale mówię to wszystko z perspektywy juniora. Więc jak uda mi się zrobić coś mniejszym kosztem to jestem bardziej usatysfakcjonowany. Ewentualnie mogę coś źle robić w JS, że mi tyle kodu zajmuje ;p
Pisanie własnej biblioteki, żeby się nauczyć jak najbardziej, ale do tworzenia projektów komercyjnych już niekoniecznie. Życie jest zbyt krótkie, żeby cały czas na nowo wymyślać koło. Poza tym frameworki oprócz przyspieszania pracy narzucają też pewien schemat dzięki czemu wdrażanie się w projekt jest dużo łatwiejsze dla nowych osób, np. programista Vue zatrudniony do pracy w tym frameworku wdroży się dużo szybciej, niż miałby miesiącami analizować jak działa customowy framework danej firmy. W dodatku żmudna nauka poszłaby na marne po zmianie pracy.
@@stivenhunt395 Może i tak, ale opieranie się tylko na gotowych rozwiązaniach prowadzi w drugą skrajność, że ktoś dołącza jakąś potężną bibliotekę tylko w celu zrobienia jakiejś pierdoły, która wcale tego nie wymagała.
Stiven Hunt vue, react też na początku istnienia były customowymi framerowkami. Są bardzo dobrze napisane, szybkie i wygodne, dlatego ludzie zaczęli masowo je poznawać. Wcześniej już istniał Angular to po co ktoś pisał nowy framework skoro już był Angular. To przecież wynajdywanie koła na nowo. Kolega kiedyś napisze super bibliotekę do jsa, wszyscy będą ją znali i nie będzie customowa :P
@Mr. Kumalaba Zgadza się, czasami lepiej napisać customowe funkcjonalności. Ważne, żeby zachować zdrowy rozsądek. Trzeba wziąć pod uwagę wiele czynników, bo popadanie w jedną lub drugą skrajność nie jest dobrą rzeczą. @szczeczaczoszczeczek Vue i react powstały dlatego, że angular na początku swojego istnienia nie był zbyt przyjemnym frameworkiem, był ciężki i słabo zoptymalizowany. Dlatego powstał vue, który był szybkim i lekkim frameworkiem idealnym do mniejszych aplikacji.
Pokaż mi jak pisać w react żeby nie mieszać htmla z javascriptem. Albo jeżeli do widoku nie chce używać js tylko wykorzystać silnik szablonów języka backendowego. Gdzieś przeczytałem, że frameworki js są jak skrzynki z narzędziami a jquery to scyzoryk i to wg mnie świetnie porównanie.
W React nie mieszasz HTML'a z JS bo w React nie piszesz HTML'a 😎 JSX to JavaScript który wygląda jak HTML, ale w gruncie rzeczy to JS. Poza tym - co w tym złego? Nawet z silnikiem szablonów potrzebujesz JS'a w wielu miejscach.
jak chcesz mieć elegancko rozdzielony html i javascript to polecam obczaić vue, tam jest to bardzo fajnie pomyślane a do tego sama nauka vue sprawia przyjmność
@@helloroman No i właśnie w tych miejscach możesz pisać w czystym js albo w jquery jeżeli chcesz pisać szybciej i przyjemniej. Jquery jest świetny jeżeli potrzebuje dodać trochę js tu i ówdzie.
@@SnoopieManPL Znam, lubię i piszę w Vue. Z rozdzieleniem jest lepiej niz w react ale i tak dużo mu brakuje pod tym względem. Wywodzę się z backendu i rozumiem potrzebę używania jquery.
Jeśli z jakiegoś dziwnego powodu miałbyś ochotę pisać w React bez używania JSX to przecież możesz to robić, więc o jakie mieszanie HTML chodzi, skoro JSX celowy zabieg by zyskać na przejrzystości. pl.reactjs.org/docs/react-without-jsx.html
Pierwszy film w którym daję unlike, Okey JQ ma kupę vulnów i ograniczeń (mimo że jest dalej rozwijane), natomiast jest jeden bajer który zawsze "kocham" w programowaniu - narzucanie stylu. Uwaga Roman w kwestii biznesowej się z Tobą zgadzam JQuery jest do dupy ;) Ale w kwestii Pasji, kreowania swojego stylu oraz tworzenia swoich projektów - Niech Każdy tworzy według swojego stylu. Fakt faktem patrzę trochę też z boku bo nie jestem typowym programistą ;) W mojej nerdzkiej branży utarło się że używa się assembly, C, C++ i pythona. A ja używam assembly, C++ i Ruby'iego zamiast pythona i nikt mnie nie chce ukrzyżować dlatego że zamiast pythona używam Rb, albo dlatego że nie piszę w czystym C, bowiem shellcode da się też fajnie napisać w C++, a Ruby ma cały framework do pisania expów który jest swoją drogą popularny wśród sysadminów oraz niestety wśród script kiddie, ze względu na gotową bazę exploitów(do której czasem się dorzucę). Wydaje mi się że takie narzucanie -> Czego warto, czego nie warto powinno mieć określony background - Pasja i styl - Weź wszystko, Biznesowo - Ucz się tego co Ci się przyda. W filmie nie uwzględniłeś pasjonatów i zajawkowiczów ;) Miłego
Jest według mnie jeszcze jeden powód, gdzie JQuery może być potrzebne - wsparcie dla starych przeglądarek. Z racji np. polityki 'korporacji' w jakiej się pracuje (np. umnie) niektóre aplikacje web'owe muszą mieć wsparcie dla ie9, które z kolei nie wspiera es6, więc JQuery jest dobrą opcją, gdyż spełnia całe zapotrzebowanie tych aplikacji. Fakt, że raczej używa się tego w przeplocie (czytaj. tylko tam gdzie tego potrzeba, i za bardzo nie ma sensownego rozwiązania). [Jakby się ktoś pytał to już rok walczę z zakończeniem wsparcia dla ie9]. Czy warto się uczyć ? Samemu z siebie, jeżeli mamy taką chęć to nikt nie broni, ale też jak przyjdzie coś w nim zrobić to też nie ma tragedi, ponieważ łatwo da się go zrozumieć. Fakt, że lepiej na siłę go wszędzie niepchać, gdyż to zawsze jest dodatkowa biblioteka do zaciągnięcia, a zawsze lepiej dociągać tylko tyle ile potrzeba, by nie obciążać strony.
es6 można przetranspilować do es5, brakujące metody np some, filter, etc są gotowe moduły, tzw polyfille. Nie widzę sensu żeby pisać nowych featerów w jQuery.
Tylko są przypadki, że po przetransponowaniu ten kod staje się mało czytelny. Co do zastępczych modułów, to jak już i tak jest na stronie dociągnięty jQuery, a my mamy tam dodać jakiś dodatkowy element to lepiej moim zdaniem go użyć niż walczyć z Service Policy, które blokuje cdn'y lub wrzucać bezpośrednio na stronę treść modułu.
@@KiszuPL A po co kod po transpilacji ma być czytelny? A co do modułów trzeba używać webpack-a, parcela i wszystko masz w jednym pliku, ew. pochunkowane. Bibliotek w cdn-ów się przeważnie nie używa w dużych projektach
@@vrn91 Zauważ, że nie każdy (albo nie zawsze) robi 'przy dużym projekcie', albo ma komfort wyboru / konfiguracji środowiska w jakim przyjdzie mu rzeźbić.
Na jQ stoi internet. Zawsze będzie potrzebny ktoś kto tym kodem będzie musiał się zajmować. Cały czas jQ jest dobrym pierwszym kitem do pracy z JS i cały czas warto rozwijać swoje umiejętności poznając jak jesteśmy w stanie uzupełnić swoją wiedzę tym skryptem. Jasne że do tworzenia nowoczesnych rozwiązań, zaawansowanych struktur i ogólnie wygody pracy najlepiej nauczyć się jakiegoś nowoczesnego frameworka, jednak większości juniorów bardzo trudno będzie bez dobrego zrozumienia vanila js uzyskać zadowalające efekty przy użyciu takich zaawansowanych narzędzi. Największą zaletą jQ jest jego poziom wejścia i to jak dużo może dodać zrozumienia samego procesu web developmentu w rozwoju samego developera który z tym paszkwilem przeszłości pracuje. jQ się nie lubi ale powinno się rozumieć ;)
Pamiętajcie, jak pisać stronki to przede wszystkim tylko na tabelach, stylujemy w tagach html, wtedy wszystko jest na miejscu nie trzeba szukać w tym style.css 1800 linijek. Wymiary stronek koniecznie w pixelach, a nie jakieś wyimaginowane remy emy. Javascriptu używamy żeby wklejać znaczniki w tekst i żeby zerować style css. Nie muszę chyba mówić, że wszystko na końcu pliku index.html, a nie jakieś oddzielne pliczki. Jak używamy bibliotek to pamiętajcie żeby cały kod wrzucić to wiadomo że wam nie zniknie. Hmm co tam jeszcze z tych dobrych praktyk mogę wam polecić... Róbcie sobie kopie plików i wrzucajcie na ftp index_1.html i tak dalej. No także pozdrawiam.
Jestem swieży jeśli chodzi o programowanie, ale czy to ironia?
@@szkau7833 tak XD, to dokładnie to czego nie robić.
@@TheMoviesfable U mnie w technikum i. też tak uczą więc to chyba norma XD
Kurde! Jakie to jest z życia wzięte :D
Czy mógłby Pan na 100k subskrybcji zapuścić włosy? :D
Mysle ,ze ważne argumenty dla kogos kto np tak jak ja właśnie uczy się fronendu.
Słyszałem sporo o jQuerry ale chociaz jeszcze nie tknąłem prawie js to chyba to bedzie dla mnie must have.Dzieki i pozdrawiam
Wow, moja propozycja przeszła do odcinka dzięki Adam!
Jaka jest ulubiony package egzorcysty?
nodemon
Igor Święs doskonałe
Akurat ja bardzo lubię jQuery; i choć częściowo się zgodzę, że nie jest już potrzebne; to nadal używam. Przede wszystkim dlatego, że ma bardzo przyjemną składnie, a napisanie w nim czegoś zajmuje mniej linijek niż vanilia javaScript. I jest też dzięki temu bardziej czytelne. Dlatego; po okresie, gdzie zgodnie z nowymi zaleceniami starałam się nie używać jQuery; wróciłam do niego i zdecydowanie wole go, niż vanilia javaScript. Zresztą, nie spotkałam się chyba z projektem, gdzie jQuery nie było użyte, chociaż by do jakiegoś maleńkiego fragmentu kodu. I w sumie traktuje jQuery właśnie jako uproszczony jeszcze bardziej js.
Ale, nie będę ukrywać, że wpływ na moją opinię może mieć też sentyment. jQuery bardzo mi pomógł w nauce frontendu, javaScriptu i programowania. Genialna dokumentacja i prostota to jego ogromne zalety. Zresztą, jak się ostatnio okazało, nie tylko mnie. A z opinią, że ktoś zrozumiał javaScript, dopiero kiedy zaczął pracę z jQuery; spotykam się coraz częściej.
Masz zamiar może tworzyć swoje odcinki w formie podcastu?
8:14 Nie potrzeba nawet do tego biblioteki :)
const $ = document.querySelector.bind(document);
sprytnie, ale wtedy przeszukiwanie pod DOM jest tylko w kontekście globalnym (document).
można zrobić metodę do szukania po sub-drzewie - będzie wydajniej.
const $ = (selector, parent = document) => parent.querySelector.call(parent, selector);
jak chcesz wbić kij w mrowisko musisz mówić, że twoje zdanie jest jedynym słusznym :D, a tak na serio to dzięki za ciekawy punkt widzenia
6:23 dałeś mi do myślenia roman, że nie trzeba być dobrym z matmy, żeby zostać programistą.
"Lubię gnój, ale w kupkach" - kudos dla mamy
Mama słynęła z zajebistych powiedzonek 😂
( Tymczasem za 5 lat ) Na co komu React jak mamy Web Components
?
hehe, a jquery dalej bedzie na 90% www :D
Bardzo chciałbym przestać używać JQuery, czasem nawet się udaje, ale akurat większość projektów przy których pracuję już go używa. Często też nie ma czasu na szukanie bibliotek napisanych w vanilla JS, kiedy już znajdzie się dokładnie to czego potrzeba, ale wymagające JQuery.
zrób odcinek o Bootstrapie
Rozwinąłbym nawet ten pomysł - odcinek prezentujący wady i zalety Bootstrapa, Bulmy, Foundation, Material Design itd. a czystego kodu
O tym jak zbędny jest w 2019 roku gdy mamy dostępnego grida
O Bootstrapie to strata czasu.
nikt powazny chyba nie korzysta z bootstrapa na produkcji? Dobre to jest do stworzenia mockupu albo cos.. chociaz i tak wg mnie szkoda czasu.
na studiachwymagany będzie
tak samo jak Python
oraz jQuery
Zaczynam przygodę z Front-Endem i nie mam zamiaru. Uważam, że to co przedstawiłeś w tym odcinku to oczywistość - jQuery jest zastępowalne, samo w sobie nie jest konieczne, więc nie widzę potrzeby (bez jakiegoś przymusu osób trzecich), by tę "gałąź" opanowywać.
A ja chciałbym zapytać czy Tree Shaking powoduje, że mogę używać jQuery bez strachu przed spadkiem wydajności bo zostanie tylko użyta funkcja/kod którego potrzebuje, a reszta zostanie "wywalona" z projektu?
Hobbistycznie siedzę w stronach od 2009 roku. Dopiero bardzo niedawno temu zacząłem na tym zarabiać, traktować to zawodowo i uczyć się od lepszych od siebie (kursy, tutoriale, dokumentacje), a nie tylko eksperymentować. Nigdy mnie nie ciągnęło do jQuery, wolałem backend, a po JS sięgałem, gdy musiałem. Dziś przychylniej spoglądam na frontend, ale jQuery dalej nie chce mi się uczyć. :P
Spoko odcinek. Właśnie dostałam projekt, do którego wykorzystano jQuery, trochę się więc właśnie zderzyłam z tym, co napisałeś - musiałam go przynajmniej liznąć. I mam do Ciebie pytanie właśnie w tym kontekście. Co myślisz o mieszaniu czystego JS'a i jQuery w jednym pliku. Czy oprócz tego, że paskudnie wygląda ^^' wpływa to jakoś na wydajność?
Nie wydaje mi się, żeby wpływało, ale sugerowałbym stopniowy refactor
W takim razie nawet tego nie ruszam :D A ostatnio zająłem się budowaniem strony z komponentów napisanych w samym js, plus API (te z odcinka z figmy, postanowilem je wykorzystać), i dopiero teraz zrozumiałem o ile wcześniej mogłem bardziej zainteresować się js
Drobna poprawka, powinno być .classList a nie ".classList()".
To nie metoda tylko obiekt typu :DOMTokenList.
W kontekście jQuery warto powiedzieć o jego autorze: John'nie Resig'u.
Bo napisał ciekawą książkę - zwłaszcza jeśli ktoś chce się podszkolić z czystego JavaScript'u.
jQuery uczyć się nie warto, ale warto zrobić własną bibliotekę a'la jQuery,
implementując chociażby te funkcjonalności poruszone w tym odcinku - dla sprawdzenia samego siebie
i udowodnienia sobie iż nie mamy potrzeby stosować już jQuery :)
(uwaga: opcja dla mających czas i chęci!)
Nie poruszył Pan jednak najważniejszego chyba wykorzystania jQuery:
$(document).ready(() => {})
na to również są aktualne (już wtedy) metody (eventy):
window.onload = () => {}
lub
window.addEventListener('DOMContentLoaded', () => {});
oraz tego co dalej będzie trzymało jego zwolenników, czyli np. uproszczone wywołanie AJAX
$.ajax(...)
co również sprowadza się do dzisiejszego: fetch, lub jeszcze bardziej
zaawansowanej biblioteki "axios" - zamiast jQuery
"Gówno-burza" będzie trwała jeszcze długo, Panie Romanie.
Ponieważ główne powody stosowania jQuery to:
1. Nie lubie JavaScript'u
2. Nie mam frameworka tylko chce coś "na szybko"
3. Stosuje bootstrapa a tam mi kazali to dodać
4. Znalazłem kontrolkę xyz do frameworka zyx i ona wymaga jquery
... etc.
PS. jQuery to nie tylko uproszczone API i selektory, to również rozpropagowanie IFFE
(za pomocą sposobu deklarowania plug-inów), oraz podwaliny pod AMD
[
ale to też nie daje argumentu za nauką tego.
Te rzecza (modularyzacja) to teraz standard (no poza AMD, bo nie ma co się męczyć tylko CommonJS (Node) FTW !)
]
Nauka jQuery może być przydatna, ale jeśli potrafimy już dobierać biblioteki do potrzeb. Myślę że nie ma sensu od niego zaczynać swoich przygód z frameworkami/bibliotekami.
Przykładowo do małych projektów, do których instalujemy Bootstrapa, musimy też zainstalować jQuery aby wszystko sprawnie działało - skoro więc już musimy go zainstalować, to po co dodawać inną bibliotekę zamiast wykorzystać tą która już jest?
Poza tym, faktycznie, querySelector oraz querySelectorAll działa bardzo sprawnie, ale ma jeden znaczący minus - przy jQuery zapis typu $('element').funkcja(); z automatu zaaplikuje funkcję do złapanych elementów. Przy querySlectorAll('element') dostajemy tablicę elementów a potem funkcję trzeba aplikować do każdego elementu z osobna w pętli.
Ale fakt, wszystko co kiedyś ułatwiało jQuery, dzisiaj da się niewiele większym nagładem pracy zrobić w czystym JS, a wyjadność kodu może być znacznie wyższa.
Nowy obiektyw ? :O Jest różnica !
Nie jestem osobiście zwolennikiem jQuery (znam go od bardzo dawna) ale ma wciąż plusy. Chodzi o krótkie łapanie bez sprawdzania błędów. Robiąc $('.item') od razu możemy przypisać zdarzenie bez sprawdzania, tj: $('.item').on('click', fn);. Tego nie da się zrobić tak prosto w czystym js, bo robiąc: document.querySelector('.item').addEventListener('click', fn) może wywalić błąd gdy elementu nie znajdzie. Natomiast dla document.querySelectorAll('.item') trzeba jechać po pętli każdego elementu.
Kolejnym plusem jQuery jest to że można dodać zdarzenia do elementów, które jeszcze nie powstały. Gdy dodamy je za pomocą jQuery w DOMie to automatycznie zostaną przydzielone im zdarzenia. Ogólnie, krótsze nazwy. Elelemnt poprzedni to prev a nie previousElementSibling
Minusem biblioteki jest to, że jest przeładowana pod względem tego co aktualnie można już robić natywnie w JS.
BTW. getBoundingClientRect jeżeli chodzi o pozycje X, Y to dokładnie chodzi o pozycje tak zwanego viewportu (okienka, który aktualnie widzimy w przeglądarce, więc mogą być wartości ujemne).
za same suchary dałabym ci nagrodę!
mam lekki offtop, w odcinku z pytaniami na juniora, trapi mnie pierwsze pytanie. "co robisz jeśli masz zrobić moduł w aplikacji z wykorzystaniem biblioteki której nie znam". Moim zdaniem otworzyłbym dokumentacje, rzucił okiem co to za biblioteka, po co istnieje, co się w niej robi. Z drugiej strony na podstawie jakiegoś prostego tutoriala, zrobiłbym w niej coś łatwego, żeby poznać podstawy na przykładach. Z trzeciej strony zobaczyłbym w google, czy ktoś przypadkiem nie robił już coś podobnego. Pytanie, brzmi jaka jest prawidłowa odpowiedź.
PS. Potrzebujemy odcinka o SEO i SEM
.
.
Z jakich źródeł najlepiej jest się nauczyć JavaScripta? W3schools, udemy, czy może coś innego?
Kurcze, jakość kozak. Masz jakiś nowy obiektyw?
Chyba ktoś zapomniał o pierdyliardzie pluginów do jquery :) prawda jest taka ze jquery był jest i bedzie bo najzwyczajniej w świecie idelanie spełnia to czego potrzebuje interakcja pod zwykłe www i jest tani w developowani. React, vue, angular i reszta są idealne ale to aplikacji, użycie ich na siłę prowadzi jedynie do podrażania kosztów wykonania i utrzymania projektu.
Dobrze, że wspomniałeś o legacy code, bo to zmienia zasady gry.
Ja polecam alternatywę jQuery, bardzo minimalistyczna paczka oferująca prawie identyczne API: cash.js ( github.com/kenwheeler/cash ).
Dobre rozwiązanie kiedy już jesteśmy przyzwyczajeni do jQuery, a zaczynamy nowy - mały projekt, dla którego nie warto dodawać frameworków typu React etc :)
Czasami jesteś zmuszony w pracy korzystać z jQuery, bo: stary kod (np. w AngularJS) albo R shiny, jedyny framework w R, który korzysta z jQuery. (Ja w pracy np. używam shiny i R).
Super odcinek, dzięki
4:35 "Na jednej przeglądarce coś tam działało, na internet explorerze nie działało nic" XD
2:58 Przekaz jest na tyle dobry że nawet młodsi ;)
jedyne zastosowanie u mnie biblioteki iquery to żeby w navigacji po naciśnięciu pokazywały się itemy listy :d. Jeśli ktoś uczy się narazie html5 css-grid/flexbox i preprocesory to może sobie poużywać chwilowo jquery żeby nierobić sobie zamieszania dodjąc ogrom javascriptu :D bo to znowu calkowicie inna składnia i następna masa informacji do nauki a lepiej użyć jquery zamiast na hover rozwijać listę lbo za pomocą checkboxa
learning curve - chyba dosyć dobrze pasuje 'próg wejścia' :-)
Siema ;) przeglądam Twoją nową stronę i chciałem zapytać w jakim celu używasz wartości rzędu 1000 - 9999 dla z-index?
Tomek Em żeby być pewnym że żaden inny element nie pojawi się nad nim i go nie zakryje.
@@marcinbaazy1692 przy takiej liczbie elementów na stronie wydaje mi się że nie są potrzebne aż tak wysokie wartości zindex. Może to po prostu przyzwyczajenie 😁
Roman - dobrze wyjaśnione, uważam jednak że ten odcinek raczej tyczy się projektów które piszemy sami oraz mamy do wyboru własne biblioteki. Globalne platformy ecommerce (prestashop), systemy blogowe (wordpress) mają wbudowane jQuery jako wymagane biblioteki. Ja uważam że można się tego nauczyć bo i tak może trafić się projekt przy którym będzie to konieczne. Z racji tego że jQuery jest dość łatwe - lepiej je znać! A co do kodu który piszemy sami i mamy wybór - decyzje sam podejmie koder.
Jeśli ktoś faktycznie korzysta z Prestashop i Wordpressa to tak. Ale wiesz, że są lepsze/nowsze alternatywy dla tych rozwiązań?
@@helloroman Fakt, lecz jak sam widzisz, takie platformy korzystają z jQuery, zarówno jak i wiele wtyczek, szablonów które są generowane dla takich platform (magento, prestashop, wordpress, joomla, drupal itp itp). Bardzo dobrym podejściem jest korzystanie z czystego jsa oraz dobranie bardziej funkcjonalnych bibliotek. Czasem jednak niesie to ze sobą dodatkowe bibloteki które i tak muszą się wczytać wśród innych do projektu co ma wpływ na optymalizację takiego projektu. Jeśli piszemy coś sami - uważam że warto skupić się na porządnym kodzie js lub użyciu efektywniejszych biblotek. Uważam że jQuery będzie jeszcze długo gościło na wielu projektach bo jest po prostu " Łatwe i znane". :)
"Lubię gnój, ale w kupkach"
jQuery na ten moment nie jest potrzebny tak jak był kiedyś, tym bardziej, że większość przeglądarek bazuje teraz na silniku Blink (włączenie z najnowszym MS Edge), tak naprawdę to jedynie Mozilla jeszcze robi coś po swojemu a reszta to nisza...
kiedy odcinek o wyciekach pamięci w web aplikacjach których cykl życia jest dłuższy niż kilkanaście minut ?
Synonim dla "krzywa uczenia" czy "learning curve"? Może "bariera wejścia"?
O! Próg wejścia będzie git, dzięki ♥️
Myślisz,że ten rynek w IT się jakoś wyrówna? Jest pełno ofert na mid/senior ale bardzo ciężko dostać się gdzieś na juniora. Pracodawcy coraz więcej wymagają na juniora, coraz ciężej się przebić i znaleźć pracę. Robi się hype na programowanie, bootcampy, kursy, pokazywanie ofert typu 10k, 20k albo 30k miesięcznie za klikanie w komputer wow itd. Trochę robienie ludziom papki z mózgu, zostaniesz programistą albo nikim itd. Jak sądzisz, czy coś się zmieni za dłuższy czas czy tylko coraz trudniej będzie ze znalezieniem pierwszej pracy i podnoszenie wymagań na stanowisko juniorskie?
Póki będzie tylu chętnych na junior front enda, to wymagania będą tylko rosnąć. Trzeba się teraz czymś wyróżnić
programowanie nie kończy się na tworzeniu stronek.
A ja w przeciwieństwie do pozostałych komentujących nie wiem o czym mowa. Widziałem ludzi, z tak chujowymi projektami, że ja osobiście wstydziłbym się to komukolwiek pokazywać, nie wspominając już o tym, żeby dołączać do portfolio.
@@flajingdragon4680 To się akurat zgadza, tylko że po ofertach pracy widać dobrze że programowanie to praktycznie tylko webdev. I wszyscy w to walą.
@@daro0352 front/back end dev. to najlepsza praca imo.
nie jest zbyt ciężka, wymagająca a zarobki są niczego sobie.
To jaka gownoborze zacząć po tym odcinku 🙄 Dajcie pomysły
CSS2 jest lepsze niż też dżEjkuery całe
@@TomAd313 +1
@@bbb0599 Uwielbiam tych wszystkich junior frontend developerów którzy piszą kod po kursach i myślą że są programistami. :D Conajmniej śmieszne.
@@bbb0599 Każdy język to zło jak się nie umie go używać. Połowa tych ludzi którzy narzekają na PHP nawet nie potrafi uzasadnić dlaczego ten język jest zły, pewnie mówią tak bo to modne bo ktoś na grupce na Facebooku rzuci hasło że PHP to gówno. :)
1. Jeżeli ktoś musi pracować z przestarzałym kodem: youmightnotneedjquery.com/
2.1 Learning curve to termin naukowy i jako taki może jak najbardziej znaczyć przetłumaczony na krzywą uczenia się.
2.2 Jednak tutaj zastosowanie jest bardziej idiomatyczne / potoczne gdzie proces / postęp nauki byłby faktycznym tłumaczeniem. Bardziej martwiłbym się o gównoburzę.
3. A skoro mowa o gównoburzy - jeszcze żadnej tutaj nie widziałem.
Szczerze mówiąc, to jest chyba pierwsze wideo gdzie w stu procentach zgadzam się z Romanem.
Wydaje mi się, że jQuery warto się uczyć tylko ze względu na to, że jeśli będziemy zmuszeni do pracy w kodzie gdzie jest jQuery to wtedy dobrze jest wiedzieć co i jak. Ale szczególnie się na tym nie znam, może mnie ktoś poprawi :).
Prawda jest taka, że jeśli dobrze znasz JS, to nawet jak wpadniesz do projektu z jQuery, to z dokumentacją ogarniesz wszystko raz dwa.
@@helloroman Słusznie. Dzięki za odpowiedź, bo moja wypowiedź wyżej to był mój jedyny argument to liźnięcia jQuery :D A strasznie się wahałem czy warto JQ sie uczyć, czy po prostu skupić się na JS'ie i innych framework'ach.
$ powstało też by pisać mniej kodu, WP ma wbudowane $, wiem nie lubisz WP, choć nie wiem czemu, robisz przez API do REACTA i masz "jakość" SPA, a klien tworzy jak w dawnym WP.
sam wordpress wraz z jego dokumentacją wręcz straszy antywzorcami tylko po to by utrzymać kompatybilność ze swoimi pluginami i kompatybilność wsteczną. taka prawda, że większość ludzi wykorzystujących WP/jQ nie obchodzi to, że tworzą legacy a uczyć nowych rzeczy im się nie chce. nawet w wordpressie da się tworzyć dobrej jakości kod np. używając biblioteki timber i autoloadingu z composera przez PSR-4.
No a co z frazą: do more, write less?
Ja includuje jQ tyko dlatego, że np jakaś biblioteka do modali ma taką zależność.
No wtedy się pisało stronę pod wszystkie rodzaje przeglądarek. Katorga. I zawsze IE wszystko psuło.
I tak w sobotę ktoś napiszę że nauczył się jQuery 🤦♂️
Czym nagrywasz?
A6300 Sigma 16mm/1.4 Rode videomic pro
2020 Bootstrap 5 rezygnuje z jquery
Też czytałem i sie ucieszyłem ♥️ oby tylko nie był w alphie tyle czasu co 4 :D
Traversing nie jest tak łatwy w czystym JS jak to jest w jQuery. Zamiast jednej linijki tony kodu.
Bez przesady
Ten aj w robocie same jq używam bo strony na wp/joomla / presta robione =/ ehh ale ten es6 znam ale jako ze uzywam tylko jq to lipa ..... pora douczyc sie czegos jak nic
heh, jeden odcinek o przyspieszeniu kodowania za pomocą skrótów klawiszowych itd. a teraz pisz 3 linijki w czystym JSie zamiast jednej krótkiej komendy w jQuery, która wszędzie i zawsze działa. No i co najlepsze kodować w vanija JS oraz jQuery mogę nawet na kalkulatorze, a w twoich metodach potrzebuję całe środowisko by kompilować kod... babel, nod itd. Nie, jestem starej daty, przez 10 lat używam jQuery i dobrze mi z tym ;)
Przy okazji dodając całą bibliotekę kiedy korzystasz zaledwie z 0.5% jej możliwości :)
Wojtek jak Ci dobrze to mi nic do tego. Pytanie jak długo jeszcze ktoś Ci będzie chciał płacić za takie podejście.
@@helloroman Myślę, że do momentu gdy jQuery jest podstawowo wrzucony do WPka i wymaga go np. Bootstrap. Mogę spać spokojnie ;)
@@helloroman uwierz, że długo. Niech zgadnę - miałeś okazję pracować tylko w nowoczesnych software houseach pracujących na najnowszych technologiach? Niestety to jest tylko ułamek rynku web developerki i ogólnie programowania. Legacy codów, których najzwyczajniej w świecie nie opłaca się przepisywać na nowo jest znacznie więcej. WIęc o pieniądze niech się kolega Wojtek nie martwi.
jankes83 o stronach we flashu też mówili że nie miną. Jeśli czegoś można być pewnym w tej branży to zmian - jeśli ktoś tego nie widzi, to za pare lat sie moze zdziwic.
jQuery jest useless mniej wiecej od wyjścia ES6. Nigdy tego nie lubiłem, niestety jest w podstawie programowej...
Z jQuery jest jak z bootstrapem. Stara gwardia przyzwyczaiła sie do używania i tylko dlatego to istnieje.
Jedyne co mnie boli, to że przez własną nieudolność uczenia się "nowych" rzeczy jak ES6+, Flex / Grid, starsi programiści upierają się i na siłę szukają plusów, których NIE MA xD I teraz nasuwa się wniosek i pytanie: Po co includowac bibliotekę, która po za wagą nic do projektu nie wnosi?
Tak jak wspomniałeś - znajomość jQuery przydaje się tylko i wyłącznie w pracy przy starszych projektach. Dzięki za filmik, będę miał do czego się odwołać w dyskusji z jQuerowymi świrami :D
Może dlatego importują bootstrapa do projektu, bo po co wymyślać koło na nowo? No może faktycznie bootstrap to trochę przerośnięta krowa, ale są inne biblioteki (gridowe), które można zaimportować. Nie rozumiem ideii pisania własnego grida za każdym razem. To samo tyczy się stylizacji alertów, tooltipów itd itp. W dodatku wspomnę, że bootstrapa można okroic z rzeczy jakich się nie potrzebuje ;) i robi się z tego dość lekka libka
Ale wiesz, że bootstrap jest zbudowany na flexie i tak czy inaczej wymusza korzystanie z niego? Co innego proponujesz do szybkiego budowania responsywnych serwisów?
@@michalbacinski6700 bo teraz jest moda na to żeby bezmyślnie korzystać z coraz to nowszych technologii. Jeśli jakas biblioteka/framework jest starszy niż 5 lat to znaczy że to staroc nie nadająca się do niczego xd
@@jankes83 Jest zbudowany na gridzie, więc to już powinno same w sobie dać do myślenia :D
Dla mnie liczy się jakość, a nie ilość. Równie dobrze po co pisać kod skoro można skorzystać z wiga, albo postawić portal w kilka dni na Drupalu / Worpressie :) Bootstrap był lekiem na braki w cssie 2/3 lata temu. Nie widzę dalszego sensu korzystania z biblioteki, którą w 100% wyparły funkcje bazowego języka.
@@michalbacinski6700 Coś w tym jest, ale nie do końca jest to wymyslanie koła na nowo. Zastępowanie kilku linijek cssa całym kombajnem to przerost formy nad treścią.
Oczywiście jeśli importujac bootstrapa nie mamy na celu jedynie ostylowac kilku kontenerów, to może ma TO jakiś głębszy sens :D Nie wiem, korzystałem dopóki nie poznałem flexa :)
Ale as firmy które nadal używają jq …
Dlaczego nie warto uczyć się jQuery? Bo nie ma czasu.
Kiedy jestem przyparty do muru i dostanę na ryj jQuery na egzaminie z kwalifikacji na TI xD
Szymon Jurczak Dalej 1.x czy dali chociaż aktualną 3.x?
@@Pirr Powiem ci, że jeszcze nie wiem jednak pytałem się nauczycielki z zawodowych kilka miesięcy temu i mówiła, że podstawa przewiduje również jQuery
Teraz będę szedł do 2 klasy technikum to się czegoś więcej dowiem
@@szymonjurczak6718 Spokojnie. Ja jestem tez w TI 4 klasa aktualnie będzie. W szkole nauczyłem się jedynie podstawowego html i CSS. Takiego że umiem przepisać polecenia z egzaminu :D. Ja i PHP nawet nie ruszyliśmy. Aktualnie do końca wakacji chcę zacząć ten js. Kończę CSS i akurat będę się mocował:p
Jeszcze SQLem będą Was katować, więc... jQ to nie jest najgorsza rzecz, jaka Was czeka ;)
@@Pirr Szczerze ci powiem akurat znam SQL'a od 2 klasy gimnazjum więc się szczególnie nie boję i raczej będzie to utrwalenie wiadomości co będę się uczył programowo ;P Się nie mogę doczekać aż się zaczną zajęcia z tworzenia witryn bo będzie można sobie moją i tak wątłą średnią fajnie podciągnąć xD
Jeśli chodzi o silnik Sizzle, to będzie on za jakiś czas ubity → facebook.com/groups/217169631654737/permalink/2268763249828688/?comment_id=2268787003159646&reply_comment_id=2268845943153752&comment_tracking=%7B%22tn%22%3A%22R%22%7D
Thx!
skubany, wyczytałeś mi w myślach temat. Ostatnio ogarniam jquery i się zastanawiam nad sensem tego przedsięwzięcia. Spuszczać się nie będę nad jquery, ale zapoznam się, bo niektóre rzeczy robi się dużo szybciej niż w vanillii.
Na przykład?
@@helloroman chodzi mi tylko o ilość kodu, a nie o jakieś mechaniki. Np. dynamiczna nawigacja dla one-page zajęła mi dużo mniej kodu w jquery niż to samo w vanillii, ale mówię to wszystko z perspektywy juniora. Więc jak uda mi się zrobić coś mniejszym kosztem to jestem bardziej usatysfakcjonowany. Ewentualnie mogę coś źle robić w JS, że mi tyle kodu zajmuje ;p
Zapomniałeś o AJAX. Niepotrzebne z dzisiejszym fetch ;)
a jeszczenie lepiej axios. ;)
Fetch nie działa na IE ;)
Padam na cycki. AJAX to jest nic innego jak nazwa dla asynchronicznych aplikacji. Asynchronous JavaScript ... 😂😂😂😂😂
@@MadBunnyRabbit chodziło mi o XMLhttprequest. Właśnie do tego było $.ajax()
@@ignacywapno9120 www.npmjs.com/package/whatwg-fetch - ale to działa :)
W moim mniemaniu refactor jquery na czysty js to strata czasu. Juz lepiej zostawic tak jak jest. Szkoda czasu i "piniendzy"
To zależy co ma się dziać dalej z projektem
2:38 zabrakło mi timera z piRomana XD
Najlepiej napisać własną bibliotekę. Ja się właśnie za to biorę.
No nie powiedziałbym, że najlepiej :D Ale na pewno się dużo nauczysz
Pisanie własnej biblioteki, żeby się nauczyć jak najbardziej, ale do tworzenia projektów komercyjnych już niekoniecznie. Życie jest zbyt krótkie, żeby cały czas na nowo wymyślać koło. Poza tym frameworki oprócz przyspieszania pracy narzucają też pewien schemat dzięki czemu wdrażanie się w projekt jest dużo łatwiejsze dla nowych osób, np. programista Vue zatrudniony do pracy w tym frameworku wdroży się dużo szybciej, niż miałby miesiącami analizować jak działa customowy framework danej firmy. W dodatku żmudna nauka poszłaby na marne po zmianie pracy.
@@stivenhunt395 Może i tak, ale opieranie się tylko na gotowych rozwiązaniach prowadzi w drugą skrajność, że ktoś dołącza jakąś potężną bibliotekę tylko w celu zrobienia jakiejś pierdoły, która wcale tego nie wymagała.
Stiven Hunt vue, react też na początku istnienia były customowymi framerowkami. Są bardzo dobrze napisane, szybkie i wygodne, dlatego ludzie zaczęli masowo je poznawać. Wcześniej już istniał Angular to po co ktoś pisał nowy framework skoro już był Angular. To przecież wynajdywanie koła na nowo. Kolega kiedyś napisze super bibliotekę do jsa, wszyscy będą ją znali i nie będzie customowa :P
@Mr. Kumalaba Zgadza się, czasami lepiej napisać customowe funkcjonalności. Ważne, żeby zachować zdrowy rozsądek. Trzeba wziąć pod uwagę wiele czynników, bo popadanie w jedną lub drugą skrajność nie jest dobrą rzeczą.
@szczeczaczoszczeczek Vue i react powstały dlatego, że angular na początku swojego istnienia nie był zbyt przyjemnym frameworkiem, był ciężki i słabo zoptymalizowany. Dlatego powstał vue, który był szybkim i lekkim frameworkiem idealnym do mniejszych aplikacji.
Pokaż mi jak pisać w react żeby nie mieszać htmla z javascriptem. Albo jeżeli do widoku nie chce używać js tylko wykorzystać silnik szablonów języka backendowego. Gdzieś przeczytałem, że frameworki js są jak skrzynki z narzędziami a jquery to scyzoryk i to wg mnie świetnie porównanie.
W React nie mieszasz HTML'a z JS bo w React nie piszesz HTML'a 😎 JSX to JavaScript który wygląda jak HTML, ale w gruncie rzeczy to JS. Poza tym - co w tym złego? Nawet z silnikiem szablonów potrzebujesz JS'a w wielu miejscach.
jak chcesz mieć elegancko rozdzielony html i javascript to polecam obczaić vue, tam jest to bardzo fajnie pomyślane a do tego sama nauka vue sprawia przyjmność
@@helloroman No i właśnie w tych miejscach możesz pisać w czystym js albo w jquery jeżeli chcesz pisać szybciej i przyjemniej. Jquery jest świetny jeżeli potrzebuje dodać trochę js tu i ówdzie.
@@SnoopieManPL Znam, lubię i piszę w Vue. Z rozdzieleniem jest lepiej niz w react ale i tak dużo mu brakuje pod tym względem. Wywodzę się z backendu i rozumiem potrzebę używania jquery.
Jeśli z jakiegoś dziwnego powodu miałbyś ochotę pisać w React bez używania JSX to przecież możesz to robić, więc o jakie mieszanie HTML chodzi, skoro JSX celowy zabieg by zyskać na przejrzystości.
pl.reactjs.org/docs/react-without-jsx.html
Masz zdj kiedy miałeś dłuższe włosy?
Mam wiele :D nie pokażę
@@helloroman kurcze, no trudno obejde się smakiem ;-;
Like za TDSOTM!
Ugi bugi?
Bugi woogie :D
No i miesiąc nauki, jak krew w piach...
+1 za pink floyd
Pikey sie cieszy
Miroslav przestan walic dislajki pod tym filmem
😂😂😂
'JQUERY TO BARDZO ZNANA I N O W O C Z E S N A BIBLIOTEKA JAVASCRIPT'
hello roman #69: *istnieje*
Czwarto-klasiści: haHAhahh HAHhHA hHA H AHHAH HA!
dużo w tym racji
Pierwszy film w którym daję unlike, Okey JQ ma kupę vulnów i ograniczeń (mimo że jest dalej rozwijane), natomiast jest jeden bajer który zawsze "kocham" w programowaniu - narzucanie stylu. Uwaga Roman w kwestii biznesowej się z Tobą zgadzam JQuery jest do dupy ;) Ale w kwestii Pasji, kreowania swojego stylu oraz tworzenia swoich projektów - Niech Każdy tworzy według swojego stylu. Fakt faktem patrzę trochę też z boku bo nie jestem typowym programistą ;) W mojej nerdzkiej branży utarło się że używa się assembly, C, C++ i pythona. A ja używam assembly, C++ i Ruby'iego zamiast pythona i nikt mnie nie chce ukrzyżować dlatego że zamiast pythona używam Rb, albo dlatego że nie piszę w czystym C, bowiem shellcode da się też fajnie napisać w C++, a Ruby ma cały framework do pisania expów który jest swoją drogą popularny wśród sysadminów oraz niestety wśród script kiddie, ze względu na gotową bazę exploitów(do której czasem się dorzucę). Wydaje mi się że takie narzucanie -> Czego warto, czego nie warto powinno mieć określony background - Pasja i styl - Weź wszystko, Biznesowo - Ucz się tego co Ci się przyda. W filmie nie uwzględniłeś pasjonatów i zajawkowiczów ;) Miłego
Jest według mnie jeszcze jeden powód, gdzie JQuery może być potrzebne - wsparcie dla starych przeglądarek. Z racji np. polityki 'korporacji' w jakiej się pracuje (np. umnie) niektóre aplikacje web'owe muszą mieć wsparcie dla ie9, które z kolei nie wspiera es6, więc JQuery jest dobrą opcją, gdyż spełnia całe zapotrzebowanie tych aplikacji. Fakt, że raczej używa się tego w przeplocie (czytaj. tylko tam gdzie tego potrzeba, i za bardzo nie ma sensownego rozwiązania). [Jakby się ktoś pytał to już rok walczę z zakończeniem wsparcia dla ie9].
Czy warto się uczyć ? Samemu z siebie, jeżeli mamy taką chęć to nikt nie broni, ale też jak przyjdzie coś w nim zrobić to też nie ma tragedi, ponieważ łatwo da się go zrozumieć. Fakt, że lepiej na siłę go wszędzie niepchać, gdyż to zawsze jest dodatkowa biblioteka do zaciągnięcia, a zawsze lepiej dociągać tylko tyle ile potrzeba, by nie obciążać strony.
es6 można przetranspilować do es5, brakujące metody np some, filter, etc są gotowe moduły, tzw polyfille. Nie widzę sensu żeby pisać nowych featerów w jQuery.
Tylko są przypadki, że po przetransponowaniu ten kod staje się mało czytelny.
Co do zastępczych modułów, to jak już i tak jest na stronie dociągnięty jQuery, a my mamy tam dodać jakiś dodatkowy element to lepiej moim zdaniem go użyć niż walczyć z Service Policy, które blokuje cdn'y lub wrzucać bezpośrednio na stronę treść modułu.
@@KiszuPL A po co kod po transpilacji ma być czytelny? A co do modułów trzeba używać webpack-a, parcela i wszystko masz w jednym pliku, ew. pochunkowane. Bibliotek w cdn-ów się przeważnie nie używa w dużych projektach
@@vrn91 Zauważ, że nie każdy (albo nie zawsze) robi 'przy dużym projekcie', albo ma komfort wyboru / konfiguracji środowiska w jakim przyjdzie mu rzeźbić.
@@KiszuPL spoko, nie mówię żeby o istniejących projektach tylko nowych i świadome lub nie używanie jQuery
dzięki za uratowanie dupy
Jak dla mnie bomba. Fuck it I go learn react