Názory k článku
Vyšlo Deno 1.20, javascriptový framework založený na V8

@bez přezdívky

Ne, nehodí. Klasické BE jazyky mají daleko větší sady nativních funkcí, se kterými je možno pracovat na daleko pokročilejších API. Musel byste srovnat JS s Javou nebo např. PHP. Pardon, to je k smíchu.

To, že se hodí pro API, které vlastně jenom přesýpají data z DB na front-end, budiž, otázka je, jestli kvůli tomu "zasvinit" backendy javascriptem. Javascript měl zůstat super vecičkou na hejblátka FE, bohužel lenost naučit se BE jazyk prostla do živelného pokusu vymyslet nový BE ekosystém. Uvidíme.

DISCLAIMER: Text je názorem pisatele.

A jaký je praktický rozdíl v tom, jestli je funkce "nativní" (přímo v knihovně jazyka), nebo jestli v "externí" knihovně jako třeba lodash? IMO žádný. Ne nadarmo se říká, že méně je někdy více.

Ve skutečnosti hlavní překážkou při uplatnění JS (plus jazyků do JS kompilovaných) na backendu je multithreading, který je v něm stále ještě hodně v plenkách a tvrdý procesorový výkon taky nebude u JS asi z nejlepších.

Teď v práci musím dělat BE v Kotlinu a oproti skvěle vymyšlenému Typescriptu je to fakt utrpení. Když jsem četl kapitolu o destructuringu v Kotlinu, tak jsem si myslel, že si dělají p**el a že tak zmršenou featuru nemohou myslet vážně. No, mysleli :-(

21. 3. 2022, 19:28 editováno autorem komentáře

BE byva IO intenzivni, multithreading moc nepotrebujete. Event loop, ktery je v JS narozdil od jinych jazyku vestavena featura, vyuzijete casteji.

21. 3. 2022, 21:23 editováno autorem komentáře

No este stastie ze tvorcovia httpd alebo nginx, ktore su hlavne o IO operaciach, sa tiez nevzhliadli cooperativnom multitaskingu vo vlastnej rezii, tak ako tomu je v pripade event loop javascriptu.

BE nie je len o mostiku medzi frontendom a databazou...

Me se Kotlin jako jazyk libi, nelibi se mi JVM platforma a s ni spojeny ekosystem spatne navrzenych knihoven.

a s ni spojeny ekosystem spatne navrzenych knihoven.
Přesně tenhle pocit mám z Javascriptu :-).

@L.

A jaký je praktický rozdíl v tom, jestli je funkce "nativní"

Tak třeba to, že je napsaný v jazyku jako jazyk sám - např. manipulace s poly je v případě PHP (BE) napsaná v C/C++. Za druhé je součástí jazyka, takže zítra prostě někdo jen tak nesmaže repozitář, jako se to stalo nedávno ... i když, teoreticky, může někdo smazat celý jazyk, ale to je asi méně pravděpodobné a taky to pak nevytváří nutnost mít v "node_modules" asi 2500 balíčků na každou jednu featuru a hlídat jejich verze a bugy (cheers to npm ...) Ano, chápu, je to i věc názoru. Však jsem to tam taky napsal ...

23. 3. 2022, 20:52 editováno autorem komentáře

Podle me se Java na handlovani dat typu slovnik a list vubec nehodi vubec. V JS je JSON v podstate, nativni format, existuje spousta skvelych knihoven na praci s daty, Underscore, Lodash, Rambda ... Mozna standradni knihovna Nodejs neni nic moc (zlepsuje se), ale vyber knihoven v NPM je mnohem vetsi. V tomhle ohledu konkuruje jen Python, Java urcite ne.

JSON není v JS „v podstatě nativní formát“, je to nativní formát – vznikl upřesněním (bohužel nedostatečným) zápisu javascriptových objektů. Bohužel JSON není vhodný formát na přenos dat. Ovšem protože je to nativní formát JavaScriptu, což je nativní jazyk prohlížečů, ujal se.

Jak to, že json není vhodný? Naopak, jeho jednoduchost zavdala velké oblibě a efektivitě, Zatimco kdo aspoň trochu nemusí, vyhne se kompilacim xml (apod.) velkým obloukem. Specifikace dat je externí zálezitost u obou, nebo nemusí. Obsah je stejně specifický.

Nechce se mi to hledat, co si pamatuji, JSON například umožňuje čísla neomezené velkosti, JS to neumožnuje...
https://gist.github.com/JosePedroDias/0bc225493329e877ec0c49212bab644e

https://stackoverflow.com/questions/23752156/are-all-json-objects-also-valid-javascript-objects

Co mě osobně vadí více je to, že v JSON nemůžu psát komentáře...

24. 3. 2022, 05:16 editováno autorem komentáře

@Radovan Tucek

IMHO to vypadá spíš na problém parseru JSONu v Javascriptu, než toho formátu jako takového. Což by zase jenom ukazovalo na to, že Javascript nebude moc vhodný jako BE jazyk ....

6. Numbers
The representation of numbers is similar to that used in most
programming languages. A number is represented in base 10 using
decimal digits. It contains an integer component that may be
prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. Leading zeros are not
allowed.
A fraction part is a decimal point followed by one or more digits.

https://www.rfc-editor.org/rfc/rfc7159#section-6

Mé znalosti historie Javascriptu jsou omezené, klidně mě někdo opravte, ale JS neměl být plnotučný serverový jazyk, ale byl to rychlý návrh na jednoduchý jazyk.

Co mě osobně vadí více je to, že v JSON nemůžu psát komentáře...

Tohle nechápu. Co vám brání napsat {"hele":"Můj komentář"} ?

24. 3. 2022, 10:02 editováno autorem komentáře

IMHO to vypadá spíš na problém parseru JSONu v Javascriptu, než toho formátu jako takového.
Ne, není to problém parseru, je to problém specifikace. Protože ta specifikace lže – zápis čísel ve většině programovacích jazyků, včetně JavaScriptu, vypadá jinak. Ve většině jazyků je u čísel nějak specifikován jejich rozsah, a u čísel v plovoucí řádové čárce se ve většině jazyků používá standard IEEE 754. Používá ho i JavaScript, pro všechna čísla – konkrétně používá 64bitové uložení („double“). Takže v JavaScriptu (stejně jako v jiných jazycích) můžete do zdrojového kódu napsat hodnotu, která se ale při překladu/inter­pretaci převede na jinou hodnotu. Co když ten samý zápis zapíšete v JSONu? Má se také převést, nebo se má striktně pracovat přesně s tou hodnotou, která je v JSONu zapsaná? A která by musela být v JavaScriptu musela být reprezentovaná jako BigInt v případě celých čísel, nebo ji JavaScript vůbec neumí reprezentovat, pokud by se jednalo o desetinné číslo. Někdo to bere tak a někdo jinak – protože specifikace to neřeší. Představte si, že by ten formát používaly pro komunikaci banky – pošlete z jedné banky peníze a na účet v druhé bance přijde jiná částka. Rozdíl by se prostě buď vypařil nebo vznikl z ničeho.

Tohle nechápu. Co vám brání napsat {"hele":"Můj komentář"} ?
To ovšem není komentář, je to property v objektu. Tím jste změnil strukturu objektu a například neprojde validací. Nebo takový komentář nepřipojíte k primitivnímu typu nebo k poli.

@Filip Jirsák

To je pořád problém parseru na jedné a druhé straně, ne transportního protokolu - ten jenom nese data. Pokud mají oba vaše systémy (parsery) na obou stranách stejnou představu o tom co je to BIgInt, tak nemáte problém. Pokud jeden neví co je to BigInt, tak napsat to do schématu vám stejně nepomůže.

Nebo takový komentář nepřipojíte k primitivnímu typu nebo k poli.

Jo takhle. Ano, to ano. Ovšem počítám, že od JSONu se čeká rychlá výměna předem specifikovaných dat. Na to je dobrý až až a jeho široké nasazení do dokládá.

Altan Sarnai:
Nebavíme se o transportním protokolu, ale o formátu pro uložení dat. A když formát pro uložení dat neříká, co ta data znamenají, je to dost vážný problém toho formátu. Není to problém parseru – když jeden parser bude parsovat čísla přesně tak, jak jsou zapsaná, a druhý parser je bude parsovat jako floating point double, oba dva pracují podle specifikace, ale stejný vstup budou interpretovat různě.

Pokud je ve standardu (jiném než JSON) uvedeno, že je něco 64bitový integer bez znaménka s nejvýznamnějším bitem vlevo, je to pro parser jasná informace a musí se postarat, aby uměl takové číslo parsovat a reprezentovat. Nebo třeba může deklarovat, že tento typ neumí a odmítat data, kde se vyskytuje. Problém JSONu je ovšem v něčem jiném – že různé parsery mohou stejná data interpretovat různě, i když oba pracují přesně v souladu se standardem. To, že na každé straně přečtete jiné číslo, je dost vážný problém.

Jak jsem psal, to, že se něco široce používá, nedokazuje, že je to dobré. JSON se široce používá jenom proto, že je to nativní formát webu a web je široce rozšířený.

Proste nie je. Json nenesie dostatok informacii k tomu aby bez zbytocnej magie rekonstruoval prenasany objekt do podoby identickej s povodnym objektom. To nedokaze ani samotny javascript.

Jak to, že json není vhodný? Naopak, jeho jednoduchost zavdala velké oblibě a efektivitě, Zatimco kdo aspoň trochu nemusí, vyhne se kompilacim xml (apod.) velkým obloukem. Specifikace dat je externí zálezitost u obou, nebo nemusí. Obsah je stejně specifický.
To, že je něco jednoduché nebo oblíbené, neznamená, že je to vhodné. Není vhodný například proto, že neumí spolehlivě přenášet čísla – jeden a ten samý údaj může každá strana interpretovat jinak. To mi u datového formátu připadá jako docela zásadní problém. Není vhodný pro to, že nemá rozumný jazyk na specifikaci schématu. Není vhodný proto, že se obecně nedá zpracovávat streamově – pokud je typ určený uvnitř dat (což je běžná věc), nikdo odesílateli nezabrání, aby typ odeslal až nakonec. Takže vy celou dobu, co přijímáte data, nevíte, co vlastně máte zpracovávat, musíte celý dokument uložit do paměti – a pak ho konečně můžete začít zpracovávat.

Mimochodem, o tom, jak výborný je JSON formát, svědčí vznik formátů jako JSON-with-comments, JSON5 nebo YAML, které explicitně odkazují na to, že se snaží odstranit nedostatky JSONu.

To, že je něco jednoduché nebo oblíbené, neznamená, že je to vhodné

No ... teoreticky samozřejmě ne nutně, prakticky to velmi postačuje, speciálně ve zdraví bezpečných případech

No jo, jsem rozmazlený z FP. Ale Rust se v tomto postupně zlepšuje, sice pomalu, ale jistě.