Vanilla JS czy jquery

Question

Hej, Co teraz lepiej znać przy szukaniu pracy? Chodzi mi o portfolio napisanych projektów przy użyciu Vanilla JS czy jquery

Comments

Czemu nie potrzebujesz jQuery? (artykuł autorstwa samego Comandeera )

Answer 1

Jeśli znasz czysty JS to nie będziesz mieć problemów z jQ. Inaczej sprawa wygląda w drugą stronę. Widziałem już dużo osób "znających jQ", a mających duże problemy z czystym JS.

Na dobrą sprawę jedyne co fajnego na obecną chwilę jest w jQ to:

• biblioteka ajax
• kolekcja elementów
• obsługa DOM

i... tyle. Całą resztę znajdziesz w JS. Bibliotekę AJAX możesz dołączyć osobno, a kolekcję elementów jakoś "przeżyć" operując na pętlach. Jeśli chodzi o jQuerowy selektor elementów to jest querySelectorAll, który nie posiada wszystkich patentów, jakie są w jQ, ale w 99% przypadków daje radę. Jeśli chodzi o "DOM-owe" funkcje, jakie posiada jQuery - bez nich też da się żyć, bo przy dobrze zbudowanym kodzie nieczęsto jest sytuacja podróżowania po drzewie (wystarcza .closest(), a on też jest w vanilli). Animacje najlepiej robić w CSSie.

Można żyć bez jQ w dzisiejszych czasach.

Odpowiadając na pytanie: zdecydowanie vanilla.

Jeśli chodzi o framework, to najwięcej ofert pracy jest dla React, ale ja osobiście bym się tym nie sugerował. Fakt, że nie tak dawno temu na topie był Angular wskazuje, że trendy się szybko zmieniają. Dwa, że - chcesz być kolejnym z wielu, czy specjalistą w czymś mniej popularnym? To już kwestia psychologiczna.

Comments

O co chodzi z "kolekcjami elementów"?

---

Podbijam pytanie

---

Podstawa działania jQuery :P

W momencie pobrania elementów np. $('.foobar') otrzymujemy w zamian obiekt jQ, który jest kolekcją elementów DOM, na której możemy wykonywać metody, np. $('.foobar').hide();

W normalnym DOM musielibyśmy pobrać elementy, a następnie obrobić je w pętli for.

W jQ wykonujemy funkcję na wszystkich pobranych elementach, lub na jednym (zależnie od funkcji).

---

Warto zaznaczyć, że kolekcja elementów HTML to nie tablica z nimi. Zwróc uwagę na ilość dostępnych metod dla kolekcji i dla tablicy.

Użycie jQuery pozwala Ci w pewnym sensie zlekceważyć formę, w jakiej dostaniesz pobrane elementy. Przykładowo metoda hide, z komentarza @Schizohatter - pod spodem jQuery wykonuje pętlę na liście złapanej przez selektor i na każdym pojedynczym elemencie wykonuje resztę operacji. Ty jedyne co zapiszesz to krótkie $( 'some_selector' ).hide();:

https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1d66b6f3c285a12f0ce/src/css/showHide.js#L34

function showHide( elements, show ) {
	var display, elem,
		values = [],
		index = 0,
		length = elements.length;

	// Determine new display value for elements that need to change
	for ( ; index < length; index++ ) {
		elem = elements[ index ];

P.S. Funkcja showHide przypinana właśnie jako metoda hide w momencie rozszerzania API biblioteki: https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1d66b6f3c285a12f0ce/src/css/showHide.js#L84

---

Pięknie napisane. Można przekonwertować kolekcję HTML na tablicę przy pomocy Array.from

---

const $ = sel => ({
    els: [...document.querySelectorAll(sel)],
    
    each(call) {
    	this.els.forEach(el => call(el));
    	return this;
    },
    
    hide() {
      this.each(el => el.style.display = 'none')
      return this;
    },
    
    filter(condition) {
    	this.els = this.els.filter(condition)
    	return this;
    }
});

A w czym coś takiego (na szybko napisanego) jest gorsze od jQuery? (Wsparciem dla starszych przeglądarek zajmie się babel). Strasznie prosto się dodaje nowe funkconalności...

---

A w czym coś takiego (na szybko napisanego) jest gorsze od jQuery?

Kto napisał, że jQuery jest tu w czymś lepsze? Padło pytanie

O co chodzi z "kolekcjami elementów"?

Więc odpowiedzieliśmy. Tematów z porównaniami jQuery do Vanilla - choćby na tym forum - jest ostatnio trochę. Nie ma sensu rozwodzić się tutaj co jest lepsze/szybsze, bo te kwestie były już poruszane w innych pytaniach :)

Poza tym, napisałeś mini API, które robi jakąś część tego, co jQuery. Ok, jak najbardziej pod względem performance'u powinno to być szybsze i przede wszystkim zajmować mniej kodu. Jednak idąc tym tokiem - pewnie z większości bibliotek i frameworków można wyjąć przydatne funkcjonalności i spróbować zapisać je tak, aby działały wydajniej. Nawet kosztem usunięcia dodatkowych bajerów, z których nie chce się korzystać, a są wbudowane i wpływają na pogorszenie wydajności.

---

IMO nie ma sensu używać jQuery:

• biblioteka ajax

Jest przecież fetch API z całkiem niezłym wsparciem 

• kolekcja elementów
• obsługa DOM

 

Mój kod (chyba) rozwiązuje te problemy. W razie czego implementacja nowych funkcji 5min góra.

---

W zasadzie w większości przypadków przydałaby się jeszcze ta funkcja:

    on(type, listener) {
      this.each((el, i) => el.addEventListener(type, listener.bind(this, el, i,)))
    	return this;
    }

    

---

IMO nie ma sensu używać jQuery:

Powiedz to zespołom, które utrzymują jakiś starszy projekt, albo nawet dość młody lecz w zaawansowanej fazie rozwoju. Owszem, jak napisałem, można przejrzeć projekt (są pewnie do tego pomocne narzędzia choćby w IDE), zebrać funkcjonalności jQuery, z których rzeczywiście się korzysta i napisać ich lepsze odpowiedniki w Vanilla. Jednak, jak myślisz komu będzie się chciało to robić? Ludzie są wygodni (choć programista powinien myśleć bardziej praktycznie i szukać lepszych rozwiązań, jeśli ich wdrożenie jest opłacalne), jeśli kod działa i zamiast 10 linijek mogą napisać jedną, to naturalne że wezmą bibliotekę - choćby ze względu na duże wsparcie. Zwłaszcza, że jest ona jedną z najpopularniejszych o ile nie "naj" we frontendzie. Owszem można by wypuścić zminifikowaną pod względem funkcjonalności i ilości kodu wersję lub choćby mocno podzieloną na moduły - o ile jQuery nie jest tak dostępne, nie sprawdzałem. Nie mniej programiści (naturalnie nie wszyscy - ja np. w jQuery napisałem kilka linijek) są przyzwyczajeni do jej istnienia i wyplewić teraz fakt, że bez jQuery "da się żyć" jest trudno. :) AngularJS choćby ma wbudowane jqLite, który jest kastratem pełnoprawnego jQuery. Na zewnątrz można nie być tego świadom, ale najczęstsze przypadki użycia obsługuje i framework w swoim core z niego korzysta.

Podsumowując. Zgadzam się, że jQuery jest w obecnych czasach mniej przydatne i można w krótkim czasie napisać potrzebne API i oszczędzić kilobajtów. Ale wypada patrzeć szerszym kątem i wziąć pod uwagę, że przez swoją popularność biblioteka ta jest rozsiana po całej sieci i moim zdaniem wątpliwe jest, aby dało się ten fakt zmienić. Oczywiście, projekty "do szuflady" można pisać na własnych narzędziach - wtedy przy okazji więcej się nauczysz. Nie mniej, w projektach zawodowych trzeba uwzględnić członków zespołu, a przede wszystkim potrzebę wsparcia aplikacji. Natomiast, gdy wprowadzisz własne narzędzia do projektu to może nie każdemu będzie się chciało to utrzymywać.

---

Mam ograniczoną ilość internetu mobilnego, to pewnie dlatego mam JQ  za złe że, tyle waży . Swoją drogą stron z jQ są czasami strasznie !optymalizowane. 

---

Mogę generalizować, ale nie obrażając nikogo - jeśli do prostych zastosowań ktoś zaciąga jQuery, to nie spodziewajmy się, że zwróci również uwagę na optymalizację aplikacji.

---

W zasadzie w większości przypadków przydałaby się jeszcze ta funkcja:
 

on(type, listener) {
  this.each((el, i) => el.addEventListener(type, listener.bind(this, el, i,)))
    return this;
}

W większości przypadków to się stosuje event delegation a nie iterowanie i przypinanie listenera do każdego elementu.

---

event delegation już zrobione

---

W większości przypadków to się stosuje event delegation a nie iterowanie i przypinanie listenera do każdego elementu.

A później przychodzi pracować z Custom Elements… ;)

 Jest przecież fetch API z całkiem niezłym wsparciem 

Jest, ale jest do bólu low-levelowy. Bez zrobienia wokół tego własnej biblioteki praktycznie nieużywalny.

Osobiście jakoś ostrożnie podchodzę do kodu bez warstwy abstrakcji – choćby to nawet miał być jQuery. 

---

@Comandeer jak zrobić rejestracje modułów w tym? 

Answer 2

React lub Angular

Vanilla JS ES6

ewentualnie TypeScript

To są nowości które warto znać. Inna sprawa ze na początek pewnie będzie ci łatwiej sie dostać do firmy wymagającej tylko jQuery i utrzymującej jakieś oprogramowanie które już funkcjonuje na rynku od kilku lat. Musisz sam sie zapoznać z ofertami pracy w twoim regionie. 

Jeśli zastanawiasz się co pokazać w portfolio a wiedze masz zarówno z czystego JSa i jQuery pokaż jedno i drugie ;)

Answer 3

Ogólnie to czysty JS po prostu trzeba znać, jednak ręczna manipulacja DOMem, czy to przy pomocy JSa, czy jQuery to głupi pomysł. Do czegokolwiek większego co łączy się z backendem należy używać jakiegoś systemu szablonów/komponentów (obojętne czy to React, Angular, czy jeszcze co innego). Ręczna manipulacja DOMem, raz że niewygodna, jest silnie narażona na dziury w bezpieczeństwie - firmy które opierają swoje aplikacje na jQ polecam omijać szerokim łukiem ;)

Tutaj prosty przykład poddatności jQuery na XSS:
 

$(`<img src=x onerror="console.log(document.cookie)" />`)

CodePen: https://codepen.io/caderek/pen/GOBGKK?editors=0012

Jasne, można wszystko ręcznie zabezpieczać, ale nie widzę w tym sensu to raz, a dwa - nie upilnujesz tego w kodzie mającym więcej niż 10 linijek.

Także podsumowując - jQuery przy obecnych alternatywach uważam za raczej bezużyteczne - ze względu na bezpieczeństwo (inne wady już pomijam).

Comments

Ad.1) :D Czekałem na argument "głosowania nogami" - tylko jakby wyselekcjonować wszystkich "godnych" to nie byłoby kim robić tych wszystkich projektów ;) Dodatkowo ludzie to nie jedyny czynnik, dla którego chcesz / musisz być na projekcie (zobowiąznia biznesowe, potencjał projektu itp).

Ad.2) CR jest zawodne, reviewer może być zmęczony, może się spieszyć, wreszcie - może zwyczajnie nie zauważyć. Dla mnie dobry programiasta powinien automatyzować co się da - argument na poziomie "nie piszmy testów, na CR się błedy wyłapie" (tak wiem, przesadzam - specjalnie).

Ad.3) Tak, na pewno jest wiele przypadków, gdzie trzeba używać jQ - ale o nich nie piszę, to chyba jasne. Co do "niebezpieczeństwa jQ" - może zastosowałem skrót myślowy w pierwszym poscie, ale wierzę, że po wyjaśnieniach już rozumiesz o co mi chodzi.

---

Eh, Twoim głównym argumentem jest, że przy projekcie pracują skrajnie niekompetentne osoby i ich niekompetencja przeważa na kształcie finalnego produktu. Na szczęście mój światek developerski wygląda zupełnie inaczej. I na tym chyba wypada zakończyć.

---

Na szczęście mój światek developerski wygląda zupełnie inaczej. 

Odnoszę zgoła odmienne wrażenie wnioskując po pytaniach jakie mi zadawałeś :D
A tak z ciekawości - czemu "nie licząc inputu ze strony usera"?

---

Odnoszę zgoła odmienne wrażenie wnioskując po pytaniach jakie mi zadawałeś :D

LOL, teraz to pojechałeś już równo. Jeśli sugerujesz, że ja lub moi koledzy nie znamy się na podstawach bezpieczeństwa, to trafiłeś jak kulą w płot. Po prostu zauważyłem przykład od czapy, to zapytałem – tyle.

 A tak z ciekawości - czemu "nie licząc inputu ze strony usera"?

Bo brak walidacji inputu ze strony usera ugryzie zawsze, niezależnie od technologii. Więc albo pokazujemy sensowny przykład, który pokaże niebezpieczeństwo jQuery, albo dojdziemy ostatecznie do wniosku, że problem leży po stronie interfejsu białkowego. 

---

LOL, teraz to pojechałeś już równo. Jeśli sugerujesz, że ja lub moi koledzy nie znamy się na podstawach bezpieczeństwa, to trafiłeś jak kulą w płot. Po prostu zauważyłem przykład od czapy, to zapytałem – tyle.

Ok, może niepotrzbna szpila - może tymi pytaniami chciałeś po prostu pociągnąć mnie za język.

dojdziemy ostatecznie do wniosku, że problem leży po stronie interfejsu białkowego

Tak, taki jest właśnie mój wniosek (wydawało mi się, że jasno się wyrażam). Wszystkie błedy w oprogramowaniu spowodowane są czynnikiem ludzkim.
Podsumowując:
uważam, że używanie jQuery, gdy mamy możliwość skorzystania z lepszych alternatyw (pilnujących choć części bezpieczeństwa za nas) jest co najmniej nierozsądne - pracy nie należy sobie dokładać (jak nie trzeba), czynnika ludzkiego nie należy lekceważyć (obojętnie czy mówimy o niekompetencji, pośpiechu, przemęczeniu czy jeszcze czymś innym).