Vyšlo Deno 1.20, javascriptový webový framework založený na V8 od Googlu, jenž je náhradou Node.js. Hlavní změnou je o 60% rychlejší FFI do Rustu.
Deno vyvinul tým kolem Ryana Dahla, původního autora Node.js, s cílem vyvarovat se některých principiálních problémů původního frameworku. Deno upřednostňuje TypeScript a na nativní úrovni používá Rust místo C. Pracuje se na vrstvě kompatibility pro Node.js.
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
Nazývať to "webový framework" mi príde nešťastné... áno pridáva to aj veci ako typický framework, ale !!prvorade!! je to behové prostredie! Btw. zároveň už teraz vidíme že chyby v Node nie sú až tak chyby, a nakoniec v Deno zas len implementovali veci z Node, čo predtým nemali byť implementované (ako trebárs náhradu za package.json)
20. 3. 2022, 15:25 editováno autorem komentáře
@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
@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.
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/interpretaci 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ý.
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.
Mne sa ten koncept viac menej paci. Napriklad ze to ma security built in (contextIsolation v electron). A tiez, ze pouziva web api kde sa da. A ze da sa rovno pouzit balik githubu, bez centralneho repozitara.
Typescript je diskutabilny napad. Ze aka verzia bude pouzita napriklad? A tsconfig.json? A co ostatne JS jazyky? Tiez je to proti deklarovanej kompatibilite z browserom.
20. 3. 2022, 20:59 editováno autorem komentáře
ČLÁNKY DO MAILU