Proč se cpe JavaScript na backend?

[Ondra Satai Nekola]

frontendak potrebuje neco na serveru tak tam vrazi nodejs s tema problemama co jste popsal.

jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.

je to nahoda nebo symptom?!!

Z tohoto mám dojem, že svoju úvodnú otázku ste nekládli preto, aby ste sa dozvedeli názori ľudí, ktorí uprednostňujú JavaScript ekosystém. Vyznieva to skôr tak, že na Vašom projekte sa používa JavaScript/TypeScript/Node.js a Vás to z nejakého dôvodu rozčuľuje. Preto tu hľadáte utvrdenie v tom, že "my backend-áci" sme nadradení a "oni frontend-áci" sú podradní.

Ak je to tak (a môžem sa samozrejme mýliť), tak zabudnite na "my" a "oni" a berte to ako príležitosť naučiť sa novú technológiu. Každý mainstreamový jazyk/ekosystém Vám dá niečo nové a žiadny nie je podradný. Obzvlášt JavaScript mi svojho času dal veľmi veľa.

Vyplatilo by se spis zkusit Brainfuck.

[Reklama]

[Standa Blábol]

Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin

Ten byl dobrej, před víkendem pobavilo. 

A copa te tak pobavilo?
Ted delam na backendu pro jeden portal, SSO auth keycloak, hibernate postgres, MVC a REST, takze moduly WebMVC, Security a JPA, start 4 sekundy na mem notebooku Lenovo P15 z roku 2022.

Je to ale krapet nezajimavy parametr, mam samozrejme zapnute Spring DevTools a ty meni classy za behu bez restartu, stara se o to VSCode plugin. Obcas to ten plugin otoci za cca 3 sekundy, to kdyz se hrabne do Beans dependency tree, jinak vetsinou ten class hotdeploy.

[Martin Poljak]

velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/

Jasně. JS je stále stejný blázinec jako byl vždycky. V realitě na to ale člověk narazí dost vzácně.

[speculatius]

velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/

Nie, nie je to aktuálne. Typovo bezpečný tripple equals operátor prišiel s nástupom CoffeScript-u asi tak pred 10 rokmi. Potom si to našlo cestu aj do samotného JavaScriptu, PHP a možno iných jazykov. V súčasnosti sa používa klasický double equals v TypeScripte, v prípade čistého JavaScript-u tripple equals. Obe možnosti sú typovo bezpečné.

Vždy ma zaráža, ako niekto odsúdi jazyk za nejakú jeho návrhovú chybu spred 30 rokov (v tomto prípade 32), ktorá je už dávno vyriešená. Mimochodom, veci ako implicitné castovanie robí aj klasické C, C++, PHP a iné jazyky. A tiež sa s tým už nejako vyrovnali (explicit contructors a podobne).

JavaScript priniesol naozaj veľa a ovplyvnil množstvo ďalších jazykov. Pomohol spopularizovať funkcionálne programovanie, lambda výrazy, myšlienku že všetko (vrátane funkcie či definície triedy) môže byť reprezentované ako objekt, bindovanie parametrov funkcí a podobne. To, že Java alebo C++ majú dnes niektoré tieto črty (napr. labmda výrazy) je podľa mňa do veľkej miery zásluhou práve JavaScript-u, Node.js a ľudí, ktorí ich priniesli aj na backend.

[Exceptions]

velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/

Nie, nie je to aktuálne. Typovo bezpečný tripple equals operátor prišiel s nástupom CoffeScript-u asi tak pred 10 rokmi. Potom si to našlo cestu aj do samotného JavaScriptu, PHP a možno iných jazykov. V súčasnosti sa používa klasický double equals v TypeScripte, v prípade čistého JavaScript-u tripple equals. Obe možnosti sú typovo bezpečné.

Vždy ma zaráža, ako niekto odsúdi jazyk za nejakú jeho návrhovú chybu spred 30 rokov (v tomto prípade 32), ktorá je už dávno vyriešená. Mimochodom, veci ako implicitné castovanie robí aj klasické C, C++, PHP a iné jazyky. A tiež sa s tým už nejako vyrovnali (explicit contructors a podobne).

JavaScript priniesol naozaj veľa a ovplyvnil množstvo ďalších jazykov. Pomohol spopularizovať funkcionálne programovanie, lambda výrazy, myšlienku že všetko (vrátane funkcie či definície triedy) môže byť reprezentované ako objekt, bindovanie parametrov funkcí a podobne. To, že Java alebo C++ majú dnes niektoré tieto črty (napr. labmda výrazy) je podľa mňa do veľkej miery zásluhou práve JavaScript-u, Node.js a ľudí, ktorí ich priniesli aj na backend.

Každý jazyk má svoje specifika, když tady někdo už poukazuje na nějaké specifičnosti javascriptu při porovnávání hodnot, chtěl bych ukázat, že jinde to je úplně stejný a prostě musíš ten jazyk znát.

Třeba java, ve vlákně mnohokrát doporučovaný na backend, ale má třeba takovéhle špeky,

Kód: [Vybrat]

Integer i = 100;
Integer j = 100;
System.out.println(i == j); // true

Integer i = 200;
Integer j = 200;
System.out.println(i == j); // false

Prakticky by mělo být úplně jedno v čem se to píše, řešit by se měly pouze ty vnější dopady volby jazyka, oni se pak některá prostředí vyloučí a jiná příjdou vhodnější. Odsuzovat někoho, že používá Javascript je strašně povrchní.

[Reklama]

[Franta Kučera]

Třeba java, ve vlákně mnohokrát doporučovaný na backend, ale má třeba takovéhle špeky,

Kód: [Vybrat]

Integer i = 100;
Integer j = 100;
System.out.println(i == j); // true

Integer i = 200;
Integer j = 200;
System.out.println(i == j); // false


Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).

Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.

[Exceptions]

Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).

Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.

nikoliv náhoda, ale jak správně píšeš, optimalizace, dokumentovaná ve specifikaci, probíhá unboxing malých 8-bitových čísel (-127 až 128). Ano, je to školácká věc, avšak dokáže potrápit kdejakého zajetého vývojáře, když nemá IDE.

Ano, stejně tak mi IDE řekne ty chyby s porovnáním v JS. O to právě vůbec nejde. Horší je, když se ten jazyk chová nedetermisticky v čase. Tohle se naučíš a nepříjde ti to.

PHP je na webu velmi rozšířené, přitom to je jazyk, které není schopný ani sjednotit argumenty a názvy funkcí, ještě se nesbavil memory leaků a jediný lék je pravidelný restarat interpreta, ve  výsledku to ale provoz nijak moc nevadí a lze s tím žít.

Tohle jsou argumenty, které můžeme my řešit u piva, ale pro aplikace to je jedno, je jedno jestli je jazyk více vláknový se zámky nebo to fejkuje přes event loop a asynchronní IO zase vlastně na té aplikaci a vývoji nemusí jít vůbec poznat (z pohledu času vývoje, náročnosti na zdroje, chybovosti atd. atd.)

Po těch letech vývoje mi je asi šumák v čem je BE/FE aplikace napsaná, důležité je, že jí bude možné dalších X let provozova a vývoj dokončit.

[snugar_i]

Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).

Ano, stejně tak je školácká chyba v JS používat ==. Javu mám docela rád, ale tohle je jedna z věcí, kde to na začátku trochu nedomysleli (spolu s kovariancí polí, Cloneable, synchronized a pár dalšíma).

[Standa Blábol]

Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).

Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.

nikoliv náhoda, ale jak správně píšeš, optimalizace, dokumentovaná ve specifikaci, probíhá unboxing malých 8-bitových čísel (-127 až 128). Ano, je to školácká věc, avšak dokáže potrápit kdejakého zajetého vývojáře, když nemá IDE.

Ano, stejně tak mi IDE řekne ty chyby s porovnáním v JS. O to právě vůbec nejde. Horší je, když se ten jazyk chová nedetermisticky v čase. Tohle se naučíš a nepříjde ti to.

PHP je na webu velmi rozšířené, přitom to je jazyk, které není schopný ani sjednotit argumenty a názvy funkcí, ještě se nesbavil memory leaků a jediný lék je pravidelný restarat interpreta, ve  výsledku to ale provoz nijak moc nevadí a lze s tím žít.

Tohle jsou argumenty, které můžeme my řešit u piva, ale pro aplikace to je jedno, je jedno jestli je jazyk více vláknový se zámky nebo to fejkuje přes event loop a asynchronní IO zase vlastně na té aplikaci a vývoji nemusí jít vůbec poznat (z pohledu času vývoje, náročnosti na zdroje, chybovosti atd. atd.)

Po těch letech vývoje mi je asi šumák v čem je BE/FE aplikace napsaná, důležité je, že jí bude možné dalších X let provozova a vývoj dokončit.

Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.

Nemyslim si, ze je sumak, co bezi na backendu, prave z toho duvodu dlouhodobe podpory.
Kdyz vezmu 20 let stare WAR tak ho na novem Tomcatu rozjedu bez potizi, max veci typu rename javax-jakarta, ktere jsou peclive popsane a jsou na to konverzni tooly.
Na javascript se podivam za dva mesice, npm upodate plne hlasek o deprecated modulech, CVEcka az na mesic, nektere modyly skoncily po roce vyvoj a mam nahradit alternativou, typicky se stejne jepicim zivotem.
Do JS/TS projektu se musi NEUSTALE hrabat a kdo chvili stal uz stoji opodal.

Pararelizace dtto, Java spolu se Spring podporou velice slusne ale tezkotonazni, NodeJS Async/Await je hnus vedoici k chaosu v kodu, nejlepsi mechanismus asi goroutines/channels. A java obdoba korutin "Project Loom - Virtual Threads" ma podporu v Java 21 a Spring Boot 3.2.

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

Takze mas castecne pravdu, pro male veci je celkem jedno, co je vespod a typicky se to naplaca v necem, co dostupny Lojza programator ovlada. Pokud potrebuju dlouhodobou stabilitu a udrzovatelnost, pak Java/Spring/MavenCentral/ApacheFundation. A pro masivni vykon kontejnery a mikroservisy, ty jednodussi treba v GO.

[to_je_jedno]

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

A hlavne uz pristi rok umre, uz dvacet let :-)

[Standa Blábol]

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

A hlavne uz pristi rok umre, uz dvacet let :-)

To si nemyslim.
PHP tu bude s nami i nadale, stejne jako krysy, tyfus a nestovice.

[Ondra Satai Nekola]

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

A hlavne uz pristi rok umre, uz dvacet let :-)

To si nemyslim.
PHP tu bude s nami i nadale, stejne jako krysy, tyfus a nestovice.

Variola eradikovaná byla, tak snad nějaká naděje je ;-)

[Exceptions]

Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.

Nemyslim si, ze je sumak, co bezi na backendu, prave z toho duvodu dlouhodobe podpory.
Kdyz vezmu 20 let stare WAR tak ho na novem Tomcatu rozjedu bez potizi, max veci typu rename javax-jakarta, ktere jsou peclive popsane a jsou na to konverzni tooly.
Na javascript se podivam za dva mesice, npm upodate plne hlasek o deprecated modulech, CVEcka az na mesic, nektere modyly skoncily po roce vyvoj a mam nahradit alternativou, typicky se stejne jepicim zivotem.
Do JS/TS projektu se musi NEUSTALE hrabat a kdo chvili stal uz stoji opodal.

Pararelizace dtto, Java spolu se Spring podporou velice slusne ale tezkotonazni, NodeJS Async/Await je hnus vedoici k chaosu v kodu, nejlepsi mechanismus asi goroutines/channels. A java obdoba korutin "Project Loom - Virtual Threads" ma podporu v Java 21 a Spring Boot 3.2.

O PHP nema cenu se bavit, to zoufale bylo, je a bude.

Takze mas castecne pravdu, pro male veci je celkem jedno, co je vespod a typicky se to naplaca v necem, co dostupny Lojza programator ovlada. Pokud potrebuju dlouhodobou stabilitu a udrzovatelnost, pak Java/Spring/MavenCentral/ApacheFundation. A pro masivni vykon kontejnery a mikroservisy, ty jednodussi treba v GO.

To je pouze tvůj pohled, že potřebuješ IDE. Je na každém v čem dělá, mně prostě stačí vim, IDE mě akorát vyrušuje od práce, příliš moc ikonek, funkcí, příliš pomalá odezva, nepotřebuji, ale je to pouze můj způsob práce, stejně jako je tvůj práce v IDE.

Šumák to je z pohledu "který jazyk je lepší", krátkou podporu můžeš mít i u javy, když zvolíš nějakou nevhodnou verzi. Stejně tak o dlouhodou podporu můžeš přijít použitím nedokumentovaných funkcí, hacků a jiných libůstek, opět to není o jazyku.

WAR je zkompilovaná aplikace, porovnávej to také s sestavenou aplikací, tj. javascript i s node_modules složkou. Vem si k 20 let starému warku zdrojáky a zkus to znovu sestavit, pravděpodobně skončíš úplně stejně jako s tím npm. Říkáš to, jak kdyby java neměla cve, vždyť skoro každý měsíc musíme dělat security buildy.

I v javě uděláš hnus, to není o jazyku, ale o tom jak programuješ, jak máš nastavenou architekturu, jak se snažíš erudovat a kontrolovat tým. Opět to není žádný argument pro ten nebo ten jazyk.

Hodnotíš to příliš z technického hlediska, které ale ve výsledku není tak moc podstatné. Argument, že java je pro dlouhodobé projekty je naprosto "validní", díky tomuhle argumentu ještě řadu aplikací udržujeme v java 8 a ještě nedávno jsme horkotěžko přepisovali věci z java 6, já si dlouhodobou podporu představuji jinak než trávit spoustu času na legacy ekosystémem, kdy postupně umírají i závislosti a musí se přepisovat a udržovat doma. Pak najednou lehkost Javascriptu dostává naprosto jiný rozměr, že.

[Martin Poljak]

Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.

Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.

[Ondra Satai Nekola]

Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.

Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.

Existuje celá řada důvodů, proč se střelit do nohy, rozepisovat se mi je nechce.