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

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