@Dreszczyk: a teraz powiedz mi jedno - czy będą się dla ciebie liczyły nanosekundy przy wybieraniu pojedynczego elementu np ? chyba że w każdej aplikacji wybierasz 200-300 tys elementów w domie no to spoko
@lucku: Po pierwsze - różnica wielkości jQuery 1.9 - Sprint to 25kB. Nawet na łączu EDGE są to ułamki sekund, których nigdy nie zauważysz, bo twoje zależności ładują się sekundę. Po drugie - pisałem o wykonywaniu kodu, ty mylisz wykonywanie z pobieraniem. Po trzecie - jeśli czas ładowania bibliotek jest nieakceptowalny to są wzorce pozwalające tego uniknąć, np. AMD, które jQuery wspiera. Po czwarte, jQuery można pobierać z serwera CDN
@lucku: Gra nie warta świeczki. Nie rozumiem tego hejtu na jQuery - to sprawdzona biblioteka z dużym community i ofertą wtyczek. Po co kombinować z czymś innym, tylko dla jakiejś śmiesznego wzrostu wydajności, który i tak zniknie w porównaniu do czasu reakcji użytkownika lub odpowiedzi serwera. Popatrz na pierwszy lepszy test http://jsperf.com/sprint-js-add Hurr, durr, Sprint zdążył wykonać prawie 800k ops, a jQuery tylko 200k. No tak, bo na pewno potrzebuję
p0lski szon usuwający Instagrama po tym jak wyciekły jej maile z Epsteinem i teraz cały świat wie że jej "ciężką pracą", którą dorobiła się sławy było zwyczajne ku***nie się. ( ͡°͜ʖ͡°) #heheszki #epstein
https://github.com/bendc/sprint - podobno dużo szybsza alternatywa dla jQuery
@Dreszczyk: Jeśli nie robisz niczego głupiego (tj. nie robisz olbrzymich operacji w DOM w pętli), to kogo obchodzi wydajność jQuery?
Po drugie - pisałem o wykonywaniu kodu, ty mylisz wykonywanie z pobieraniem.
Po trzecie - jeśli czas ładowania bibliotek jest nieakceptowalny to są wzorce pozwalające tego uniknąć, np. AMD, które jQuery wspiera.
Po czwarte, jQuery można pobierać z serwera CDN
Popatrz na pierwszy lepszy test http://jsperf.com/sprint-js-add
Hurr, durr, Sprint zdążył wykonać prawie 800k ops, a jQuery tylko 200k. No tak, bo na pewno potrzebuję
źródło: comment_m1fdoZqUdfBA7XDZ0Lmh3CJgmX2R8BI6.jpg
Pobierz