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

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

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

OK, to teraz pytanie: w jaki inny sposób, nie licząc inputu ze strony usera, taki kod do jQuery przemycić? 

---

Chociażby przesyłając komuś zainfekowany link.

---

Niby jaki?

---

Chociażby tak: link

---

No ale to wciąż jest pchanie całkowicie nieprzefiltrowanego inputu ze strony usera, czyli po prostu proszenie się o kłopoty.

Poza tym wystarczy zrobić $( location.hash ) i wymuszać traktowanie hasha jako odwołania do elementu o konkretnym [id]. Nie widzę najmniejszego zastosowania dla innego rodzaju danych przekazywanych w hashu – a przynajmniej nie w kontekście odwoływania się do DOM.

---

To jest tylko głupi, oczywisty przykład wskazujący na lukę - zwykle wykorzystanie XSSa jest bardziej subtelne. Piszesz "wystarczy to i to", "kto normalny tak robi" - no ty może jesteś taki świetny, że masz zero takich luk, ale jaką dasz gwarancję, że wypatrzysz wszyskie luki innych, nie zawsze ogarniętych, programistów? Ludzie są zdolni, nie ma co dawać dziecku naładowanej broni do ręki ;)

---

Ale tak można zrobić z każdym jednym frameworkiem. React też ma mechanizmy do omijania filtrowania HTML-a – nie jest naładowaną bronią?

Jak ktoś zatrudnia ludzi, którzy mają totalnie wywalone na podstawowe zasady bezpieczeństwa, to bynajmniej nie jQuery jest winny temu, że aplikację shakowano. Skończmy w końcu zwalać na narzędzia problemy spowodowane indolencją developerów.

---

Już nie raz nasłuchałem się, jak koledzy łatali dziury spowodowane jQuery - większość zuważyli i załatali tylko dzięki temu, że aplikacja miała ścisły zewnętrzny audyt bezpieczeństwa (system bankowy).

---

Skończmy w końcu zwalać na narzędzia problemy spowodowane indolencją developerów.

Sory, ale masz trochę niepoważne podejście - jeśli coś da się zabezpieczyć za pomoca lepszych narzedzi, to nalezy ich używać.

---

I znowu wywalasz kontekt z moich wypowiedzi i twierdzisz, że mam niepoważne podejście…

Nigdzie nie napisałem, że nie należy używać lepszych narzędzi. Niemniej twierdzenie, że jQuery jest dziurawe jak sito na podstawie przykładów od czapy, jest równie niepoważne. Jak ktoś potrzebuje zewnętrznego audytu bezpieczeństwa, żeby błędy tej klasy wykryć, to raczej nie powinien pracować przy kodach wymagających wysokiego poziomu bezpieczeństwa.

---

Ok, czepisz się przykładu z czapy, choć wyraźnie napisałem, że to tylko przykład z czapy (choć założę się, że tego typu błędy są dość częste). Inny przykład to np przetwarzanie danych z przychodzących z zewnątrz - z zewnętrznych api (nieumyślne błędy lub celowe ataki), z naszego backendu (tak samo) - nie można polegać, że te dane zawsze są bezpieczne i dobrze obrobione. Frontend powinien być drugą linią obrony (a jQuery ze swoim parsowaniem w selektorach, .append, .html itd dokłada nam dodatkowej pracy i naraża na błędy). Lista potencjalnych ataków XSS jest dosyć długa: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

---

Inny przykład to np przetwarzanie danych z przychodzących z zewnątrz - z zewnętrznych api (nieumyślne błędy lub celowe ataki), z naszego backendu (tak samo) - nie można polegać, że te dane zawsze są bezpieczne i dobrze obrobione.

No ale znowu pokazujesz przykład, w którym to nie jQuery zawodzi a błąd walidacji! Jak nie sprawdzisz, co Ci przyszło z serwera, tylko od razu obrobisz, to znów się prosisz o kłopoty.

Tak, jQuery nie ma wbudowanego filtrowania, ale to nie znaczy, że ma to usprawiedliwiać odrzucenie podstawowych zasad bezpieczeństwa. To, że React nam przefiltruje HTML, nie znaczy, że mamy wyłączać myślenie – bo dam se rękę uciąć, że jakiś sposób z tych opisanych na OWASP też tam zadziała.

---

Nigdzie nie twierdzę, że mamy wyłączyć myślenie - jestem po prostu realistą (lub można powiedzieć - wykazuję zdrowy pesymizm). To nie jest tak, że biadolę - "ojej, przez jQ nie da się prawidłowo zwalidować danych" - owszem, można zrobić super bezpieczną aplikację, ale wymaga to wiedzy i dyscypliny, a "ktoś potrzebuje zewnętrznego audytu bezpieczeństwa, żeby błędy tej klasy wykryć, to raczej nie powinien pracować przy kodach wymagających wysokiego poziomu bezpieczeństwa" to myślenie życzeniowe. Jeśli mam być odpowiedzialny za projekt i mieć zespół kilku deweloperów o różnym poziomie doświadczenia i wrażliwości na te sprawy, to jQ mówię po prostu nie - minimalizuję ryzyko.

---

I nie widzisz nic złego w tym, że niekompetentne osoby pracują przy systemach bankowych? Nie widzisz nic złego w tym, że w Twoim zespole będą osoby, które myślą, że "bezpieczeństwo" to nowy kierunek na studiach?

Bo ja widzę. I bardzo szybko bym wyeliminował takie osoby z mojego zespołu. I dopiero to jest minimalizacja ryzyka.

---

1. Nie zawsze masz na to wpływ
2. Nie zawsze wiesz o tym, że coś będzie zepsute, zanim zostanie zepsute
3. Nawet mając w zespole samych wymiataczy - po co się z tym męczyć?

---

ad. 1) Jak jako lider zespołu nie mam żadnego wpływu na to, to zmieniam pracę na taką, gdzie byłbym prawdziwym liderem zespołu.

ad. 2) Code reviews są od tego, by takie sprawy załatwiać wewnętrznie. Poza tym wysoka świadomość bezpieczeństwa = mniejsze ryzyko zepsucia. Wtedy "czuje się", co może co zepsuć.

ad. 3) Bo system ma kilka lat i przepisanie go na nową technologię jest nieopłacalne. Bo np. wybrana technologia nie ma domyślnego filtrowania, ale ma inne rzeczy, które są potrzebne do realizacji celów biznesowych. Poza tym to już nie jest argument o niebezpieczeństwie jQuery.

---

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).