Co vám vadí na JavaScriptu v roce 2018?

[kkt1]

Možná je doba 32-jádrových procesorů, ale také je doba 32 tabů v prohlížeči otevřených současně. A to se vsadím, že většina uživatelů má tak 4, možná 8-jádro. Proč by tedy měla mít jedna stránka k dispozici více vláken?

Třeba proto, aby se ty podúlohy na té jedné stránce při nějakém čekání vzájemně neblokovaly.

Souhlas, ale na to není potřeba více vláken.

Vice vlaken obecne ma vzdy smysl. Co kdyz amd/intel uvede treba 1024core cpu? Budeme si porad rikat ze single thread je vporadku?

[Reklama]

[Scripter]

Možná je doba 32-jádrových procesorů, ale také je doba 32 tabů v prohlížeči otevřených současně. A to se vsadím, že většina uživatelů má tak 4, možná 8-jádro. Proč by tedy měla mít jedna stránka k dispozici více vláken?

Třeba proto, aby se ty podúlohy na té jedné stránce při nějakém čekání vzájemně neblokovaly.

Proč by se měly blokovat? Pleteš si concurrency s paralelismem.

[jean]

Javascriptu jsem na chut neprisel, ale Javascript VM a browser jako runtime pro beh frontend aplikaci transpilovanych ze silne typovejch jazyku je bezva. Java ani .Net nastroje pro debug/tuneni se na Chrome DevTools nechytaji. Navic JS appky dokazi bejt svizny, pokud programator vi co dela.

[neznamy]

Jako programator, ktery posledni rok pise pouze javascript se nestacim divit co se tady pise za bludy.

1) v javascriptu se dnes pomalu dela vse, 70% veskereho frontendu (zbytek je kotlin/swift na mobilech), a taky v podstate valna vetsina microservicu na backendu. jen u klasickych monolitickych backendu se pouziva spring/net/symphony.

Node.js je v mnoha ohledech velmi rychly.

Jsem zhrozeny ze vetsina programatoru zde nechape jak funguje a jak se da implementovat async - (epoll & friends, pripadne jen jako user friendly frontend na klasickem multithreaded backendu podobne jak to je v browseru). ze vy ste kluci nikdy nepsali multi threaded appky a nechali ste nakou knihovnu nadtim vasim sync psanym backendem aby se s tim poprala? nojo klasika.

rozlisujte callback, a async callback dekuji.

v expressu muzete async/await psat bez jakekoliv koy.js.

async/await je stejne jen glorifikovany cukr nad promissma ktery se snazi zalibit synchronnim programatorum.
Vznika tak naprosto zabavny kolotoc abstrakce, kdy HW-> asynchronni, OS nabidne thready aby to vypadalo jako synchronni pro uzivatele -> multithreaded browser nabidne asynchronni js interface -> ES6 nabidne synchronne vypadajici async/await s try catch. je to genialni nebo dementni? sam nevim.

peo typy v js je typescript.

modulovy system je jiz vyresen a v browseru implementovan (import z es6) v nodu pod flagama zatim (meli by si uz pohnout). transpilace babelem je uzbtemer nepotrebna pro ecma featury, potrebujete ho jenom na framework specific syntax. ano webpack ma priserny interface zdroje a dokumentaci.

co je na js nahovno jsou akorat legacy veci a zoraseny truthy tsble, null/undefined, debilni +, a ten nesmysl s prototypama na ktery dnes muze srat a delat jen v classes ktere sou sane.

[neznamy]

Jako programator, ktery posledni rok pise pouze javascript se nestacim divit co se tady pise za bludy.

1) v javascriptu se dnes pomalu dela vse, 70% veskereho frontendu (zbytek je kotlin/swift na mobilech), a taky v podstate valna vetsina microservicu na backendu. jen u klasickych monolitickych backendu se pouziva spring/net/symphony.

Node.js je v mnoha ohledech velmi rychly.

Jsem zhrozeny ze vetsina programatoru zde nechape jak funguje a jak se da implementovat async - (epoll & friends, pripadne jen jako user friendly frontend na klasickem multithreaded backendu podobne jak to je v browseru). ze vy ste kluci nikdy nepsali multi threaded appky a nechali ste nakou knihovnu nadtim vasim sync psanym backendem aby se s tim poprala? nojo klasika.

rozlisujte callback, a async callback dekuji.

v expressu muzete async/await psat bez jakekoliv koy.js.

async/await je stejne jen glorifikovany cukr nad promissma ktery se snazi zalibit synchronnim programatorum.
Vznika tak naprosto zabavny kolotoc abstrakce, kdy HW-> asynchronni, OS nabidne thready aby to vypadalo jako synchronni pro uzivatele -> multithreaded browser nabidne asynchronni js interface -> ES6 nabidne synchronne vypadajici async/await s try catch. je to genialni nebo dementni? sam nevim.

peo typy v js je typescript.

modulovy system je jiz vyresen a v browseru implementovan (import z es6) v nodu pod flagama zatim (meli by si uz pohnout). transpilace babelem je uzbtemer nepotrebna pro ecma featury, potrebujete ho jenom na framework specific syntax. ano webpack ma priserny interface zdroje a dokumentaci.

co je na js nahovno jsou akorat legacy veci a zoraseny truthy tsble, null/undefined, debilni +, a ten nesmysl s prototypama na ktery dnes muze srat a delat jen v classes ktere sou sane.

[Reklama]

[michal2]

Proč by tedy měla mít jedna stránka k dispozici více vláken?

Protože se tam chtějí upravovat fotky ( https://www.photopea.com/ ), hrat hry s 3D grafikou a narocnou AI a provozovat tabulkove procesory s narocnymi formulemi. A brzy bude nekdo chtit clientside strihat video a provadet vedecke vypocty. Ale ja beru JS jako univerzalni jazyk. Kdybych bral JS jen jako jazyk pro clinet side webovou samohanou, tak bych pro nej mel jinou vytku, ze neni univerzalni ale jen pro tu samohanou.

[Pep]

Proč by tedy měla mít jedna stránka k dispozici více vláken?

Protože se tam chtějí upravovat fotky ( https://www.photopea.com/ ), hrat hry s 3D grafikou a narocnou AI a provozovat tabulkove procesory s narocnymi formulemi. A brzy bude nekdo chtit clientside strihat video a provadet vedecke vypocty. Ale ja beru JS jako univerzalni jazyk. Kdybych bral JS jen jako jazyk pro clinet side webovou samohanou, tak bych pro nej mel jinou vytku, ze neni univerzalni ale jen pro tu samohanou.

Na takové věci máme WebAssembly.

[neznamy]

prectete si neco o web workerech.

[Jano7]

v expressu muzete async/await psat bez jakekoliv koy.js.

Natívna podpora pre middleware sa plánuje pre Express 5.

V Koa to máme takto krásne jednoducho:

Kód: [Vybrat]

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3000);


modulovy system je jiz vyresen a v browseru implementovan (import z es6) v nodu pod flagama zatim (meli by si uz pohnout).

No veď to, v Node to ešte nie je stále ready.

a ten nesmysl s prototypama na ktery dnes muze srat a delat jen v classes ktere sou sane.

Prototype sa dá ignorovať, ale straší to v Mozille dokumentácii, napr. Date.prototype.getDate(). Nielenže JavaScript má class, ale dajú sa jednoducho vytvárať objekty pomocou JSON syntaxe. A to môjmu Java mozgu istý čas trvalo pochopiť, že je možné vytvárať objekty takto krásne priamočiaro, bez všetkej tej ceremónie.

[andy]

async/await je stejne jen glorifikovany cukr nad promissma ktery se snazi zalibit synchronnim programatorum.

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?

Vznika tak naprosto zabavny kolotoc abstrakce, kdy HW-> asynchronni, OS nabidne thready aby to vypadalo jako synchronni pro uzivatele -> multithreaded browser nabidne asynchronni js interface -> ES6 nabidne synchronne vypadajici async/await s try catch. je to genialni nebo dementni? sam nevim.

Mně by se líbil runtime, který na N OS threadech (N ~ počet CPU) poběží M "app" threadů, které se z programátorského hlediska budou jevit jako synchronní (tzn. nebudu řešit async/await), ale runtime to bude dělat asynchronně (bude to řešit za mě). Nemá to tak Go?

[asd]

Nielenže JavaScript má class, ale dajú sa jednoducho vytvárať objekty pomocou JSON syntaxe. A to môjmu Java mozgu istý čas trvalo pochopiť, že je možné vytvárať objekty takto krásne priamočiaro, bez všetkej tej ceremónie.

No a přitom pořád stejně pracuješ s prototypy... Javistům to obecně trvá chvilku dýl, ale když si to po chvíli všechno "sedne", tak si to pravděpodobně ještě oblíbíš.

[agent]

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 

[Puff]

Mně by se líbil runtime, který na N OS threadech (N ~ počet CPU) poběží M "app" threadů, které se z programátorského hlediska budou jevit jako synchronní (tzn. nebudu řešit async/await), ale runtime to bude dělat asynchronně (bude to řešit za mě). Nemá to tak Go?

Go nebo třeba GCD.

[Michal2]

prectete si neco o web workerech.

Ty se hodí v případě, že chci spustit nějaký delší výpočet a pak získat výsledek. Když chci 60FPS, tak potřebuji sdílenou paměť, synchronizační primitiva,...

[nojo]

v expressu muzete async/await psat bez jakekoliv koy.js.

Natívna podpora pre middleware sa plánuje pre Express 5.

V Koa to máme takto krásne jednoducho:

Kód: [Vybrat]

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3000);


modulovy system je jiz vyresen a v browseru implementovan (import z es6) v nodu pod flagama zatim (meli by si uz pohnout).

No veď to, v Node to ešte nie je stále ready.

a ten nesmysl s prototypama na ktery dnes muze srat a delat jen v classes ktere sou sane.

Prototype sa dá ignorovať, ale straší to v Mozille dokumentácii, napr. Date.prototype.getDate(). Nielenže JavaScript má class, ale dajú sa jednoducho vytvárať objekty pomocou JSON syntaxe. A to môjmu Java mozgu istý čas trvalo pochopiť, že je možné vytvárať objekty takto krásne priamočiaro, bez všetkej tej ceremónie.

to mate mirne casove popleteny, javascript mel objekty vzdy, akorat nebyl class-based (class tam jsou az od nedavna jako doplnek). tzn objekty se tvorily vzdy literalne, NASLEDNE vznikl JSON ktery to ma primo v nazvu "javascript object notation" - dalo by se rici "javascript object creation notation" abychom byli presnejsi.