Tohle by mě zajímalo - mně se synchronní programování líbí. Připadá mi to značně přehlednější, jednodušší a spravovatelnější než "callback hell". Takže mě překvapuje, že někdo má jiný názor - mohl bys to rozvést?
Možná je to jednodušší a přehlednější, ale má to v časově náročnějších operacích vliv na výkon.
Představ si že máš v browseru jednovláknový synchronně zpracovávnaý skript, který přes ajax získává data/hodnoty z 20 různých zdrojů a zobrazí je v tabulce.
- synchronně: dáš volání do smyčky - zavoláš první, počkáš na výsledek, zobrazíš, zavoláš druhý.... za 20 sekund máš možná výsledek.
- asynchronně: dáš volání také do smyčky - zavoláš první a jen určíš, kdo bude nezávisle na hlavním vlákně čekat na výsledek a zobrazovat ho, zavoláš druhý... pokud bude jedno čekání na výsledek/hodnotu trvet cca sekundu jako v minulém případě, máš komplet hotovo dřív než za 1,5 sekundy
- Spustím si na každý request thread, který bude napsaný normálně synchronně a na konci posbírám výsledky...?
callback hell resi prave uz promisy ktere vypadaji "velmi synchronne"
No...a teď ještě dodělat podporu přímo do jazyka, aby promisy nebyly vidět....a máme z toho synchronní programování, kdy mě runtime odstíní od té asynchronní části...
No a já jsem se vyjadřoval k:
async/await je stejne jen glorifikovany cukr nad promissma ktery se snazi zalibit synchronnim programatorum.
Což mi připadá, že existuje něco jako "asynchronní programátor", který "má rád" asynchronní programování (aka callback hell). Tak se ptám na důvod, protože runtime mi může bez problému (např. syntaktickým cukrem nad promisama) od callback hell odstínit a ve výsledku píšu synchronně - a připadá mi, že to není "jen glorifikovaný cukr", ale přesně to, co výrazně zjednoduší a zpřehlední kód.