fetch a pořadí funkce

joml:
Ano, tak funguje AJAX.
V případě, že potřebuješ počkat, dáváš to do calbacků, zde tedy do THEN. v Jquery je to tuším done / fail / always.

Nevím, jestli Kcko myslel typově done / fail / always, každopádně přesné názvy jsou success / error / complete, ještě se občas hodí beforeSend. Každopádně ajax má spoustu nastavení...

jquery.ajax

RastyAmateur:
Nemyslel a ty jsou už deprecated. Myslel jsem callbacky promises.

Kcko:
sakra, tak to už jsem hodně pozadu :D Jaká je výhoda používat promise, když ajax to sám od sebe takto podporuje? Když tedy pominu, že jsou deprecated (dle mého názoru ještě nějakou dobu budou spolehlivě fungovat, ale tož moje potřeby coby amateur)

RastyAmateur:
Ano $.ajax sám o sobě vrací promisu.
A je přeci snažsí napsat něco jako


Rozdíl je v tom, že nemusíš všechno narvat dovnitř callbacku uvnitř $.ajax ale vystrčíš si to ven a můžeš to použít vickrát.
Asi to ještě funguje, ale už někdy kolem verze 1.8 psali, že to bude deprecated.



A promisy můžeš použít prakticky na cokoliv.

joml:
A proč jako? jQuery Ti něco udělalo?

joml:
:) o tomhle diskutovat nebudu, zadej si do googlu jQuery vs Vanila Js a nebude to tak jednostranné vid?

Btw co je stokrát pomalejší, ty jsi si to změřil?

joml:
ako je to pravda i nepravda,... záleží vždy jak je to napsané, a na čo sa jQuery použije,... ale i v javascriptu sa dá napsať kód tak aby pristupoval do DOMu tisíc krát, a naopak aj jQuery môže pristupovať i raz v takej situácii. Je to len o tom jak to použije programátor/kóder.

samozrejme jQuery bude častejšie pomalší, ale často krát to môžu byť rozdieli omnoho omnoho menšie, než sa tu spomína, avšak môžu byť situácie, kde naopak to môže byť aj milion krát pomalšie. jQuery je dobrá knihovna, když sa správne a rozumne používa.

„avšak môžu byť situácie, kde naopak to môže byť aj milion krát pomalšie“
Nemůže. Nejlepší řešení v nativní JS může být v nejhorším případě stejně tak pomalé jako nejlepší řešení v jQuery. Naopak to ale neplatí.

„jQuery je dobrá knihovna, když sa správne a rozumne používa.“
jQuery je dobrá knihovna, to určitě. Obzvlášť v minulosti, v době kdy mezi prohlížeči byly značné rozdíly, měla značný úspěch kvůli tomu že tyto rozdíly řešila a sjednocovala chování. Programátor tak nemusel řešit podporu napříč prohlížeči a mohl se věnovat tvorbě toho zajímavého. A smysl má i dnes. Najít nejlepší možné řešení problému s použitím jQuery bývá jednodušší než s čistým JS. Proto se může stát, že stránka s jQuery bude efektivnější než ta bez. Ale to je jen kvůli tomu, že programátor není schopen lepší řešení nalézt.

joml:
pár jsou 2. v jQuery jsou 2 metody? Ano i kvůli ajaxu, protože má velmi variabilní použití.
Ty umíš napsat z hlavy metodu obdobnou metodě např. fadeIn, fadeOut animate ... ?
Práce s frontou ve Vanil
Umíš traversovat stromem všemi směry?
Umíš pracovat s DOMem (mazat, klonovat, přesouvat ...)?
Jsi si jist, že umíš správně používat všechno tak, aby to bylo všude funkční? Jsou totiž rozdíly mezi napr. IE 9 a 10 (a zcela jistě i mezi jinými prohlížeči).
Umíš to napsat správně všechno tak, aby to bylo rychlé, nestávaly se memory leaky?

Silně o tom pochybuji. Dneska to není všechno o rychlosti.

joml:
:) vzhledem k tomu jak odpovídáš, je mi jasné odkud vítr vane, hodně zdaru s Vanilkou.

Keeehi:
ja psal o jquery nie o vanillajs

samozrejme ze vanillajs je vzdy rychlejsia, ale zalezi o kolik a ci ma zmysel sa s nou patlat, kdyz za pomoci jquery jde vytvorit totez mnohem jednoduchsie a pri tom rozdiel vo vykone je zanedbatelny.

joml:
Nevím jak to cítí Kcko ale já z tvého projevu mám pocit že jsi pokročilý začátečník co si o sobě dost myslí. Co si sice přečetl nějaké články ale čtvrtinu z nich pochopil špatně protože zatím netuší, co za tím stojí.

joml:
Ano, došli
Nebo to bude možná tak, že jako dlouholetý člen této diskuse a člověk co má už toho poměrně dost za sebou co se týká webového vývoje nemá potřebuje se tu hádat s někým koho i Keeehi označil jako nafrněného začátečníka.

Hlavně tvoje argumentace ve smyslu je dosti k smíchu a je vidět, že o tom nemáš ani páru a na odborné úrovni nemá cenu diskusi vést.
Já: Umíš traversovat?
Ty: Umím console.log

Já: Víš co je memory leak.
Ty: Ne, ale nejsem noob a mám mozek.

Já: FadeIn / Fadeout a dalších hafo animačních helperů z jQ
Ty: Umím tymer a nějakou opacity. (To že si myslíš, že to umíš, neznamená, že to umíš a že to skutečně napíšeš tak dobře, aby to bylo rychlé a funkční).


Budu si myslet, že to je ještě nezralé a nahypované mládí, dospěješ, vyzraješ a za pár let se nad tímto taky pousměješ.

Měj se.

Nějak se to zvrhlo do další debaty na téma jQuery.
Ani nevím, jestli to vůbec souvisí s původní otázkou, ta nevypadá, že by řešila rozdíl oproti jQuery.

Přesto:

Kcko:
„Btw co je stokrát pomalejší, ty jsi si to změřil?“
Aby to bylo fér, skutečně jsem párkrát řešil odbourání jQuery jako rychlostní optimalizaci (tzn. kód byl pomalý, příčinou bylo jQuery a přepsání na nativní JS to vyřešilo/zlepšilo).

Keeehi:
„Obzvlášť v minulosti, v době kdy mezi prohlížeči byly značné rozdíly, měla značný úspěch kvůli tomu že tyto rozdíly řešila a sjednocovala chování.“
Taky mám ten pocit.
Na druhé straně ve spoustě případů časem důvod použít jQuery odpadl, protože stejnou schopnost získal i nativní JS.

(Například původně asi hlavní tahák jQuery byla schopnost procházet DOM přes selektory jako v CSS. Ale na tohle se už dnes v JS dá prakticky 1:1 použít querySelector/-All a bude to rychlejší.)

Mlocik97:
„samozrejme ze vanillajs je vzdy rychlejsia“

To není tak docela pravda. Platí to tak, jak to napsal Keeehi:
„Nejlepší řešení v nativní JS může být v nejhorším případě stejně tak pomalé jako nejlepší řešení v jQuery.“

Nicméně to předpokládá programátora, který dokáže vymyslet řešení, které se alespoň blíží tomu optimálnímu.
U podprůměrného programátora není problém, aby jím vynalezené řešení v nativním JS bylo pomalejší než to už připravené v jQuery.
(doplněno:)

Tohle je mimochodem obecný argument pro použití už hotového řešení. Udělat vlastní „optimalizované“ řešení nejenže trvá déle, ale navíc výsledek může být horší než to už připravené a odladěné řešení.
Prostě, vždycky je potřeba vědět proč to dělám. Ale to není až tak překvapivý poznatek :-)

Joker:
nehovoril som o neoptimalizovanych a nespravnych rieseniach... asi som to cele mal formulovat inak... vanillajs je vzdy rychlejsia, ak je spravne pouzita (resp. vzdy, ak to robi tym istym postupom ako riesenie v jquery, samozrejme když nekto vytvory kod, ktory bude pre preklopenie slova pouzivat 7 cyklov, 12 arrayov a 20 ifov, tak to je ina). Ale jak uz hovorim, zalezi aky je velky rozdiel. A ci ma zmysel investovat cas do objavovania niecoho, co uz je hotove, i kdyz tvoja vlastna verzia by bola o 5ms rychlejsia. Ono neoplati sa vzdy psat vse vo vanillajs, lebo to spomaluje vyvoj, a vyhoda vo vykone je fakt zanedbatelna,

Joker:
Aby to bylo fér, skutečně jsem párkrát řešil odbourání jQuery jako rychlostní optimalizaci (tzn. kód byl pomalý, příčinou bylo jQuery a přepsání na nativní JS to vyřešilo/zlepšilo).

Ahoj.
Ano samozřejmě, když je jQuery jen wrapper nad nativním JS, který slouží spíš k ulehčení práce a k psaní méně kódu (zmiňované funkce fadeIn, ale defakto dost věcí z API).
Tady jde o to, že autor topicu má na celý věc velmi zastřený pohled, který je dán jeho neznalostí, nezkušeností a úrovní začátečníka.

Já nepíšu v JQ $(prvek).attr('id'), ale napíšu $element[0].id (nebo v elementu this.id).
Tam kde nepotřebuju neustále hrabat na JQ použiji nativní JS, ale tenhle nesmyslný hejt mě už dávno nebaví.

V JQ jsou napsány pěkné pluginy, dobře se s ním pracuje a když ho člověk používá s rozmyslem a ne jako prase, tak rozhodně pomalé není. Na každém webu najdu 100 horších věci, než je průměrně napsané JQ.


EDIT:

Můžeš ukázat konkrétně, co zrychlilo používání aplikace, přepsáním JQ na nativní JS? Jestli to je skutečně nějaká prasárna, kterou by středně znalý programátor nenapsal, nebo to je něco co je skutečně v JQ špatně napsáno?

Kcko:
"...dobře se s ním pracuje a když ho člověk používá s rozmyslem a ne jako prase, tak rozhodně pomalé není. Na každém webu najdu 100 horších věci, než je průměrně napsané JQ."

čistá pravda,...

Mlocik97:
„nehovoril som o neoptimalizovanych a nespravnych rieseniach“

Vtip je v tom, že u složitějšího problému skoro nikdy nenapíšete optimální kód.
Například teoreticky ideální kód třeba webového prohlížeče napsaný v assembleru bude rychlejší než kód stejného prohlížeče třeba v C#.
Jenže prakticky, vzhledem k tomu, jaký objem práce, kódu a míst pro potenciální chyby by znamenalo psát webový prohlížeč v assembleru, máte v C# mnohem větší šanci se tomu ideálnímu kódu přiblížit.

Kcko:
Byly to celkem obyčejné konstrukce typu $("#prvek"), $(".trida"), $("table td[foo=bar]"), jqueryPrvek.attr("foo"), apod.
Problém byl, že se to dělalo hodněkrát.

„Já nepíšu v JQ $(prvek).attr('id'), ale napíšu $element[0].id (nebo v elementu this.id).“
No jasně.
Takže $("#prvek") nahradím na document.getElementById, $(".trida") a $("table td[foo=bar]") na querySelectorAll a v kódu se primárně nepředává jQuery, ale DOM elementy a jQuery se vytvoří až v případě potřeby.
Tím na spoustě míst vznikne situace, že se vytváří z DOM elementu jQuery kvůli jednomu volání, které by zvládl i ten DOM element.
Například $(prvek).attr("foo"), takže se to už rovnou může nahradit na prvek.getAttribute.

No, a po chvíli nahrazování zjistím, že už vpodstatě žádné jQuery nezůstalo.

Joker:
Vtip je v tom, že u složitějšího problému skoro nikdy nenapíšete optimální kód.
Například teoreticky ideální kód třeba webového prohlížeče napsaný v assembleru bude rychlejší než kód stejného prohlížeče třeba v C#.
Jenže prakticky, vzhledem k tomu, jaký objem práce, kódu a míst pro potenciální chyby by znamenalo psát webový prohlížeč v assembleru, máte v C# mnohem větší šanci se tomu ideálnímu kódu přiblížit.

No a jak porovnávaš assembler a C#,... presne rovnako je to pri komplexnejších bazmekov když porovnáme vanillaJS a jQuery. Optimalizácie je dobré riešiť, avšak už je zbytočné šetriť každú milisekundu... počítače sú dnes natolik výkonné, že je nezmysel kvôli optimalizácii si stažiť kód... ale zas naopak je nezmysel psát v jQuery niečo, čo vo vanillaJS jde o nič zložitejc ale výkonovo je to neporovnatelne horší pre jQuery. Tzv. treba vedieť nájsť zlatý stred medzi "optimalizovaným a výkonným kódom" a "prehladným a jednoduchým kódom".

jQuery bych se nebál používať, ale pokial viditelne stránka na ktorej je použitý jde tak pomaly, že kým vykreslí tabuľku, tak ty stihneš vypiť kávu a ešte sa aj osprchovať, tak pak samozrejme je to špatné použitie jQuery, len je otázka či bez jQuery by taký človek to vedel napsať výkonnejšie... nováčik totiž používa jQuery len preto že je to lachšie, a sprasí nejaký kus kódu v nezáujmu jak je to optimálne,... profesionál použije jQuery pre zrýchlenie produkcie/vývoju, ale vie veľmi dobre čo daný kód v jQuery robí na pozadí, a jak sa to chová, vie veľmi dobre jaký by bol ekvivalent vo vanillaJS.

chyba nieje knihovna/framework, ale to jak ho programátor/kóder používa.

Najoptimálnejšie riešenie vo vanillaJS je vždy rýchlejšie než v jQuery, avšak pre nekritické funkcie je použitie jQuery namieste, když to zjednoduší a zrýchly vývoj, zprehladný kód, a rozdiel nebude nejak razantne veľký. Treba proste hladať strednú cetu medzi výkonom a čitateľnosťou kódu. Prečo inak sa drivery píšu v Assemblery a v C, ale trebárs nejaké relatívne nedôležité aplikácie v "pomalej" Jave? Neviem si predstaviť vyvýjať hru typu League of Legends v Assemblery, a naopak neviem si predstaviť driver napísaný v Jave. Obdobne to platí pre knihovny a frameworky v JS. Treba sa len naučiť kde a jak čo použiť. jQuery tu má miesto rovnako ako vanillaJS. Jde len o to nájsť správnu cestu, zlatý stred medzi výkonom a efektivitou a rýchlosťou vývoja, prehladnosťou kódu atd.

Mlocik97:
Ano, něco takového jsem myslel výše větou:
„Prostě, vždycky je potřeba vědět proč to dělám.“

Abych se vrátil k tématu, zrovna třeba u promise mi přijde fajn využít jQuery, jelikož nativní promise nefunguje v žádném IE a to mi pořád ještě přijde dost na to to úplně ignorovat.

Joker:
> Byly to celkem obyčejné konstrukce typu $("#prvek"), $(".trida"), $("table td[foo=bar]"), jqueryPrvek.attr("foo"), apod.
> Problém byl, že se to dělalo hodněkrát.
No takže problém autora, že si to neumí uložit do proměnných (a tím odpadne vícevolání toho samého), případně špatné selektory, ale to opět není problém JQ.

„Takže $("#prvek") nahradím na document.getElementById, $(".trida") a $("table td[foo=bar]") na querySelectorAll“
Tohle interně JQ přeci provádí také ne (minimálně tam kde to prohlížeč podporuje => querySelector).

Pořád si myslím, že pokud jde o běžnou webovou aplikaci, a ne o něco, kde jde skutečně o výkon a čas, tak je JQ v pohodě.
A na ty JS aplikace bych stejně sáhl po něčem jiném (TS, React, VUE atd, ale já nejsem odborník na JS, k tomu by se mohl vyjádřit @Radek9)

Jinak jsme se dost odklonili od původního tématu a myslím si, že je škoda pořád nosit dříví do lesa (= bavit se o JQ vs JS, je toho plný net, at si každý používá co mu vyhovuje).

Kcko:
„No takže problém autora“
Ne, byl to problém toho, že ty jQuery konstrukce prostě byly pomalejší.
Optimalizace spočívala v nahrazení volání jQuery odpovídající konstrukcí v nativním JS.

„Tohle interně JQ přeci provádí také ne“
Ano, plus nějakou režii okolo. Proto je pomalejší.

„Pořád si myslím, že pokud jde o běžnou webovou aplikaci, a ne o něco, kde jde skutečně o výkon a čas, tak je JQ v pohodě.“
Přesněji pokud je to kód, který se vykoná jednou nebo v několika málo cyklech.
Ale i na jinak docela prostinké stránkce může být místo, kde se procházejí stovky nebo tisíce prvků (například mám tabulku, v každé buňce je <select> a položky jsou ovlivněné něčím jiným na stránce).
A pak už přestane být jedno, jestli jeden cyklus trvá třeba 2 ms nebo 10 ms.