Teď je kolem toho haló, protože to oznámili na blogu, ale aktuálně je to uzavřená beta (na pozvánku). A že se na tom pracuje je zase známo delší dobu, takže aktuálně na tom nic moc nového není.
" A že se na tom pracuje je zase známo delší dobu, takže aktuálně na tom nic moc nového není."
Je známo komu? Mne třeba ne.
Jasně, teď se právě pracuje na Pythonu 3.12. Až ho vydají a ohlásí na blogu, tak o tom radši nepsat do novinek, protože to není novinka. Už se na něm přeci dávno pracovalo. Zasvěcení vědí. Vy vždy pobavíte.
2. 5. 2023, 19:48 editováno autorem komentáře
Je to známo tomu, kdo se o Deno zajímá. Nepostřehl jste z mého komentáře to nejpodstatnější – že je to zatím uzavřená beta na pozvánky. Až vydají Python 3.12, tak si ho hned v tu chvíli bude moci každý stáhnout. Za mne je dost podstatný rozdíl, jestli něco můžu začít hned teď používat, nebo jestli se na opravdové vydání teprve čeká a zatím je to jen pro zvané.
To, že vy nevnímáte rozdíl mezi „vydali jsme novou verzi, stáhněte si ji a používejte“ a „zpřístupnili jsme waitlist na novou verzi“, je váš problém.
Zprávička neříká, že ten projekt existuje. Zprávička říká, že Deno dostává KV-databázi. Jenže lokálně už ji má dávno a na Deno Deploy ji bude mít (veřejně dostupnou) až za nějakou dobu.
Voloviny tu řešíte akorát vy, já jsem jenom doplnil to, co ve zprávičce není a je to podle mého názoru důležité. Můj komentář možná pro někoho užitečný byl a pro někoho ne, zatímco váš komentář není užitečný pro nikoho.
Vaše "zprávička" nebyla vůbec k ničemu. Pokud je pro někoho zajímavá, šel si přečíst blog. Já sem stihl si přečíst originál a zjistit co je Deno deploy. Vaše zdejší argumentační cvičení jsou jen pro pobavení ,protože jsou manipulativní.
"To, že vy nevnímáte rozdíl mezi „vydali jsme novou verzi, stáhněte si ji a používejte“ a „zpřístupnili jsme waitlist na novou verzi“, je váš problém."
Já to chápu velmi dobře, bohužel zprávička o tom vůbec nebyla. Můžeme ale čekat diskuzi až do desáté úrovně vlákna, kde budete reagovat na všechno co se vám hodí, často úplně off-topic.
BTW Můj komentáře minimálně "pobavil" 19 lidí.
3. 5. 2023, 10:26 editováno autorem komentáře
Další zajímavost je, že moderní node.js je výkonově dohnal, Deno už není rychlík. Bun je ale oba těžce předbíhá, někdy i o řád :-)
Zfalšované asi úplně ne, spíš jsou pro benchmarky vybrané ne zcela realistické scénáře, ve kterých Bun zrovna exceluje: https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x-faster-than-nodejs-and-deno-45od
Realistické ano, jen možná ne úplně typické v běžných webových aplikacích. Bun má výrazně menší overhead requestu (časový i prostorový), takže se to projeví nejlépe v aplikacích kde se nedělají složité server-side výpočty. Typicky tenká API kolem databází (IoT, smart metering atd.) kde request je "zapiš tenhle float do databáze" nebo "dej mi číselnou řadu za poslední měsíc", ne tvorba XML.
Ne, vzniklo to proto, že JS dokáže efektivně využít výkon jednoho vlákna a navíc je možné psát kód, který běží jak na backendu, tak na frontendu. Když si zkusíš třeba Next.js framework, tak pochopíš, kolik to umí ušetřit práce. On totiž i frontend potřebuje svůj backend a ten nezbytně nemusí být ta hlavní business logika celé aplikace.
navíc je možné psát kód, který běží jak na backendu, tak na frontendu
Což se ale reálně dalo použít leda tak pro validační funkce a začíná to dávat smysl až se SSR a hydratací, což je záležitost posledního roku. Takže si spíš myslím, že to nebyl důvod vzniku – asi nikdo by nevydržel čekat na to 15 let.
IMHO to vzniklo proto, aby frontenďáci mohli psát taky beckendy bez potřeby učit se nový jazyk.
Tohle se vždy uvádí jako výhoda JS na serveru, a já to stále nechápu. Rozdíly mezi frontendem a backendem jsou úplně v něčem jiném, je to úplně jiný způsob myšlení – na FE máte jednoho uživatele, na BE máte spoustu souběžně aktivních uživatelů a musíte hlídat, aby se jim nepomíchala data. Na FE máte jedno vlákno, na BE musíte řešit konkurenční přístup. Na BE řešíte trvalé uložení dat a jejich efektivní načítání, na FE řešíte, jak data vhodně prezentovat uživateli. To, se na obojí použije stejný programovací jazyk, mi oproti těm koncepčním rozdílům připadá jako nepodstatná prkotina. Jako by někdo považoval za výhodu, že při řízení auta i při pilotování JumboJetu má stejný budík ukazující rychlost.
Na druhou stranu pro malé projekty a experimenty to asi smysl dává.
Mně JS na serveru začal dávat smysl (pro malé projekty a experimenty) právě až s příchodem Deno. Protože teprve s ním padla ta magická hranice, že napíšu prototyp na 20 řádků do jednoho souboru, napíšu deno run, a běží mi server – a nemusím instalovat závislosti a používat divné callbackové API nekompatibilní s tím, co znám z prohlížeče.
Ono nejde o "frontenďáky" ale hlavně o to, že když máte na projektu pár lidí a chcete, aby byli trochu univerzálnější než že umí "jenom" frontend a "jenom" backend, je docela fajn, když je ten jazyk, resp. platforma (jak se to vezme v tomhle případě) jenom jedna protože třeba kombinace Python/TypeScript nebo C#/TypeScript je za předpokladu, že to ten člověk fakt má umět rozhodně dražší než jenom třeba Node.js/TypeScript. A lidí, co by skutečně dobře uměli obojí je podstatně méně.
Nemluvě tedy o tom, že pak taky ve velké míře používáte stejné knihovny. Samozřejmě ty, které jsou užitečné v prohlížeči i na backendu. Ale ta množina se občas docela prolíná.
Já jsem pořád přesvědčený o tom, že samotný programovací jazyk, a dokonce i ty knihovny, jsou jen malá část toho, co v takovém případě potřebujete znát. A že pokud už někdo umí SQL a rozumí aspoň trochu relačním databázím; chápe, jak pracovat v multiuživatelském prostředí; ví, jak vypadá HTTP komunikace – pro takového člověka není problém naučit se psát v dalším jazyce. A pokud to neumí, tak nepatří do kategorie „fakt umět“ a může psát opravdu jen nějaké prototypy nebo malé projektíky.
Ti lidé stojí peníze. A hůře se shánějí. Nemluvě o tom, že se sice považuji za fullstackového vývojáře, ale i tak jsem za těch patnáct let nepotkal zrovna mnoho lidí, co by uměli na stejně kvalitní úrovni backend v jedné úlatformě, třeba v C# a frontend v jiné platformě, třeba JS/TS. Takových je prostě málo. Jenomže to je na projektech s menším počtem vývojářů docela problém.
Tohle je obecný princip.
Ano jeden jazyk/platforma by byl ideální, bohužel ne každý má ten luxus. Třeba já rád dělám UI/UX, naučil se Qt a za pár let mi do něj injektovali JS :D. Ale v pohodě, QtQuick dává smysl. Řešit UI je vždy těžký ať už na desktopu, embeded nebo webové. Kdo potřebuje opravdu dobré, rychlé a spolehlivé web UI, ten dnes má ale problém. Namísto programátora co válí JS/HTML/CSS a nějaké patterny a architekturu se hledá už jen React Devlopeři.
Mne príde že ten Deno je len tak nazvyš, nič nové nepridalo,, snáď až na pár drobností, ktoré sa v Node dali vyriešiť PR (a že už obe prezentované relevantné výhody prišli do Node), BunJS mi príde ako niečo, čo má väčšiu šancu nahradiť Node, pretože API má takmer zhodné, výkon omnoho lepšiu, a teda aj keď taktiež neprináša veľa nového, tak aspoň nepridali bariéru kompatibility... Popravde za posledný mesiac (30 dní) som počul "Deno" 2x, ale "Node" počujem každých pár minút, ak teda riešim niečo s JS. Mi príde že nakoniec celý humbuk stíhne a počase, keď Node okopíruje to málo, tak bude vlastne Deno mŕtvy.
Když psal Ryan Dahl Node.js, psal ho proto, protože nebyl spokojený s aktuálním stavem tehdejších populárních backendových řešení. Můžete kouknout na jeho první přednášku o tom, co měl Node.js řešit, proč je async-first a tak dále.
Node.js sice žádné novátorské myšlenky neměl, ale určitě zpopularizoval a uvedl do mainstreamu přístupy, které byly v dané době spíše okrajové. Účel tedy splnil.
Když psal Ryan Dahl Deno, psal ho proto, protože nebyl spokojený se stavem aktuálních populárních backendových řešení, včetně designových chyb v Node.js, které sám způsobil (jako byl NPM bundling, security model, a jiné).
Pokud Deno nakoplo Node.js správným směrem, pak jedině dobře, smysl to mělo a snad ještě mít bude.
3. 5. 2023, 09:46 editováno autorem komentáře
Async first neznamená, že daný framework umožňuje async (a už to vůbec neznamená, pro kolegu vedle, že framework musí podporovat specifická klíčová slova jako je async/await a podobné, Node.js dělal původně async skrze callbacky, což souviselo s použitím v8 a konvencemi v browseru) , ale že je od základů na tomto principu postaven.
V další větě explicitně zmiňuji, že Node.js novátorský nebyl, ale pomohl zpopularizovat myšlenky, které se v následující dekádě více rozšířily do mainstreamu backendového vývoje.
Node.js rozhodně s asynchronním programováním jako první nepřišel, a taky jsem nic takového nikde nepsal. Ach jo.
3. 5. 2023, 11:35 editováno autorem komentáře
To je pravda. A já bych ještě dodal, že napsat z gruntu celý systém od píky je pro jednoho člověka nebo malý tým těžký úkol, tak proč nevyužít něco, co už za vás zdarma kohorty programátorů napsaly.
Z původní Dahlovy prezentace to vypadá spíše na obrácený postup, kdy potřeboval na svoje řešení naroubovat runtime, který si s jeho myšlenkami bude rozumět, a V8 se hodil.
3. 5. 2023, 12:03 editováno autorem komentáře
Ake konkretne rieislo node.js problemy v case svojho vzniku? Ako fakt ma to zaujima, lebo v mojej bubline bolo vcase vzniku velmi poplarne RoR z heslom, ze server je lacnejsi ako programator. Uznavam, ze nodejs bolo v istom type uloh rychlejsie (IO) ale to mi prislo len pre to, ze mainstrem bol extremne pomaly aj voci existujucim alternativam.
Co sa taky zdielania kodu medzi FE a BE (spominaneho inde), tak som si ten hype zazil, ale tento pristup sa akosi potichu vytratil do stratena a dnes ho uz s ust evanielizatorov JS nepocut.
RoR je příšerný kus softwaru a to říkám jako někdo, kdo ten jazyk má fakt rád -- nebo spíš právě proto. Ostatně to, co jste v Ruby musel v té době komplikovaně řešit přes EventMachine fungovalo v Node.js tak nějak per design. Hlavně to řešil. To I/O je totiž docela podstatná část spousty úloh.
Ostatně ani výkon nijak zásadní nebyl. Jednak byl v té době rychlý sám o sobě (když už mluvíme zrovna o Ruby, třeba to rychlostí zrovna nevynikalo) a druhak škálovat šlo už v té době snadno takže kdyžtak spustit dalších pět instancí bylo to poslední zajímavé. RoR jsou moloch. To, co činilo a činí Node.js problematickým je jednak jistá zastaralost API a druhak obtížná spravovatelnost stoprocentně asynchronní codebase kombinovaná s čistým JavaScriptem, který tomu fakt moc nepomáhal. Proto od něj spoustu projektů uteklo (čemuž se moc nedivím).
3. 5. 2023, 11:49 editováno autorem komentáře
Hej, ale ako hovorim, ine etablovane platformy riesili asynchrone IO riesli davno pred tym.
Zaujimave vystlenie mal k tomu David Grudl https://www.youtube.com/watch?v=rXjHCFz0UTI - ta cast o tom ako sa technologie viac menej opakuju a su poplarne pre to, ze su hipsterske (mizerna podpora a nic tam nefunguje) no kazdy nieco nove priniesol (PHP -> RoR -> Nodejs -> ?Rust?).
První verze node.js byla pecka. Já vím, že hodně lidí to prostě nechápe nebo to srovnává s tím, co je teď, ale v té době to bylo něco nového - v podstatě to bylo o tom použít JS na serveru co byl JIT zkompilovaný pomocí V8, což byla tehdy super inovativní VM pro javascript, takže výkon per thread byl neuvěřitelný, když se to porovnalo třeba s pythonem nebo nějakým jiným dynamicky typovaným jazykem. Navíc JSON je v JS first class citizen, takže napsat výkonné služby konzumující JSON a odpovídající JSON byla úplná trivialita.
Já webové věci teda moc teď nedělám, ale fakt si pamatuju ty overengineered řešení v Javě co používali milion XML definic, entity frameworků a dalších overengineered sraček - node.js byl v porovnání s tím naprosto úžasný lightweight produkt.
Dnes už jsou věci zase dál, a to je jen dobře, ale rozhodně nezapomenu na ten první zážitek s node.js a ten pocit, že něco zase může být jednoduché.