Technologie pro webovou aplikaci

[Mirek Prýmek]

Snadná administrace je naopak jednou z výhod node.js. Je to jen jeden proces. Když chcete, aby se po pádu restartoval, spustíte ho pomocí forever. To je vše.

No já jsem spíš myslel takové věci jako ladění výkonu, nasazení v clusteru, debug apod. Tím, že něco nastavím a spustím celá ta legrace teprve začíná

[Reklama]

[andy]

Jak by mělo vypadat netragické ORM?

Nevím. V Haskellu existují bindingy na SQL, které se docela přibližují tomu, co by se mi líbilo, ale stejně to pořád není úplně ono (buď to nemá dost funkcionality, nebo je kolem to ho strašného boilerplate, a navíc to není úplně intuitivní).

a motivace to přepsat moc není (protože to funguje).

no tak kde je problem?

Když chci přidat další funkcionalitu, tak se bojím a nechce se mi Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.

Zvažoval jsi Elm? Vyřadil jsi ho na základě něčeho konkrétního? (pokud už jsem se tě na to ptal, tak sorry, jsem hlava děravá )

Pux by měl být elm-like binding na react. Elm konkrétně jsem nezkoušel, ale co jsem četl, tak je to dobré intro do FP...a tím to tak končí. Nemá to TypeClassy, což mi osobně připadá jako docela problém.

Četl jsem o praktickém provozu Node.js dost škaredé věci...

Bylo by něco konkrétního? Kolega na to chce právě přepisovat něco rozsáhlejšího, tak by mě to zajímalo...

Podivej se na velke projekty, co pouzivaji za technologie.

Jenže velké projekty mají typicky slušné financování, takže to ti lidé pak napíšou třeba v té Javě se spoustou mezivrstev, kvantem modelů apod. To IMO není zrovna cesta pro malé projekty... PHP, Django, Ruby mě osobně připadají strašně nepohodlné...

SPA a REST připadají jako hodně velký krok vpřed a mám pocit, že se konečně ty webové aplikace dají nějak rozumně uchopit...

[Mirek Prýmek]

Pux by měl být elm-like binding na react.

Pokud to správně chápu na první pohled, tak se tím myslí asi spíš Elm 0.16. To bylo fakt FRP, hodně jako React. Od 0.17 Elm prošel dost zásadní změnou, která není úplně jasná, když v tom neděláš (úplně bez urážky, to určitě chápeš), ale v 17ce se fakt píše líp. Viz http://elm-lang.org/blog/farewell-to-frp Přijde mi, jakoby Elm pokukoval po užší spolupráci s Elixirem/Phoenixem, což by bylo megacool

Elm konkrétně jsem nezkoušel, ale co jsem četl, tak je to dobré intro do FP...a tím to tak končí. Nemá to TypeClassy, což mi osobně připadá jako docela problém.

Jako haskellistu by tě to mohlo štvát, to určitě. Ale je to myslím vědomej krok - nejspíš proto, aby se jazyk nekomplikoval, a mně osobně to zas tak moc neva - v té konkrétní doméně webovýho programování se bez nich dá obejít a tam, kde to fakt nejde (např. obecná fce toString) má runtime "výjimky" - on může dělat a dělá věci, který bys v jazyce neudělal

Kdyby typeclassy měl, mohl bys dělat větší abstrakce a měl bys míň boilerplate, ale otázka je, jestli to stojí za to Neumím to vysvětlit, musel bys to vyzkoušet sám (docela doporučuju). Pro haskellistu to asi bude trochu opruz z těch omezení, ale na druhou stranu, podle mě má Elm větší šanci získat větší publikum, právě proto, jak moc se Evan soustředí na jednoduchost, přístupnost a user friendliness.

Četl jsem o praktickém provozu Node.js dost škaredé věci...

Bylo by něco konkrétního? Kolega na to chce právě přepisovat něco rozsáhlejšího, tak by mě to zajímalo...

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Nechci o Node nic tvrdit, zkušenosti nemám, ale k čemukoli z JS světa bych byl extra podezřívavej a před nasazením si to teda pořádně proklepl... Jako Python a Ruby jsou sice taky nic moc světy, ale aspoň mají nějakou historii a spousty instalací, že jo, tak se člověk asi tak nespálí...

[Mirek Prýmek]

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Jo, tak jsem to kupodivu našel (level: Google master! ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a

[zboj]

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Jo, tak jsem to kupodivu našel (level: Google master! ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a

Node.js je sračka, ale ta základní myšlenka je dobrá - NIO a jedno vlákno, co víc si přát. Akorát teda mnohem lepší je analogická implementace v C (libevent), C++ (má lambdy), případně s využitím GCD (má lambdy jen při překladu clangem a bez kqueue je pomalé, ale jinak nejlepší) nebo rovnou v Go, které je v tomto ohledu asi nejlepší.

BTW jak se řeší NIO v FP?

[Reklama]

[gll]

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Jo, tak jsem to kupodivu našel (level: Google master! ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a

Tomu člověku vadí, že existuje mnoho knihoven a frameworků, které ho nikdo nenutí používat. To je daň za popularitu. Porovnává node.js s blokujícími framweorky jako Flask a Django. Problémy s callbacky a asynchronním handlováním chyb, na které si stěžuje, v těchto frameworcích logicky neexistují. V neblokujícím IO je na tom python hůř. V pythonu existuje několik navzájem nekompatibilních event loopů. S každým z nich musíte používat jen s ním kompatibilní knihovny. V node.js je neblokující vše.

[gll]

Node.js je sračka

Všude píší, že je to sračka, a lidi to přesto používají. Takový SW nemůže být špatný.

[andy]

BTW jak se řeší NIO v FP?

Runtime GHC (Haskell) má green thready, takže to typicky spustíš s N OS threadama, kde N~počet corů a mezi tím ti tak nějak migrují green thready, takže sice píšeš "blocking", ale ve skutečnosti to je všechno non-blocking. Kupodivu v FFI je možnost volat i long-blocking operace, má to trochu vyšší režii, ale funguje to docela v pohodě.

Purescript pro změnu má Aff monad, který elegantně abstrahuje javascript-callback-hell, takže se píše normálně sekvenčně. Něco ve stylu teď nových asynchronních funkcí (?), ale řekl bych, že lepší...

Kdyby typeclassy měl, mohl bys dělat větší abstrakce a měl bys míň boilerplate, ale otázka je, jestli to stojí za to Neumím to vysvětlit, musel bys to vyzkoušet sám (docela doporučuju). Pro haskellistu to asi bude trochu opruz z těch omezení

Já si to bez typeclass nějak fakt neumim představit...v haskellu to používám docela hodně. Jako on purescript taky neni nějaká extra výhra, chvíli jsem se v tom snažil a moc mě to nepřesvědčilo (Generika na houby, ani tím pořádně nejde napsat JSON serializaci, ten Record system v konečném důsledku moc nepřináší (v novém purescriptu je to prý přes nějaký generický newtype lepší) a extensible effects jsou sice hezké, ale nevím pořádně na co...

podle mě má Elm větší šanci získat větší publikum, právě proto, jak moc se Evan soustředí na jednoduchost, přístupnost a user friendliness.

To bez pochyby ano, a je to jen dobře, ale asi to publikum nebude úplně od haskellistů

[čumil]

node a sračka ? a kde ste na to přišli ?
Rychlí jako ďábel (proti PHP, ruby a pythonu), asynchronní ...
Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení, v clusteru to je pak ještě jiná.

Ruby a podobný joky ... to radí jen šílenec, ruby už skončilo.
Teď je doba JS a Javy.

A Haskell ? Jednu dobu sem byl velkej fanda FP ... ale bohužel, v praxi je dost nahovno, kdo nevyzkoušel na něčem trošku složitějším než school level srandě, nepochopí ...
Nebylo by to tak strašný kdyby existoval pořádný systém na handling side efektů a ne ty komedie co sou dneska... žejo io monado, zdravim tebe.

[andy]

A Haskell ? Jednu dobu sem byl velkej fanda FP ... ale bohužel, v praxi je dost nahovno, kdo nevyzkoušel na něčem trošku složitějším než school level srandě, nepochopí ...
Nebylo by to tak strašný kdyby existoval pořádný systém na handling side efektů a ne ty komedie co sou dneska... žejo io monado, zdravim tebe.

Hele já chápu, že tam jsou omezení - když má člověk blbý use case s GC, tak prostě fakt někdy řešení neexistuje, stejně tak, pokud by člověk šel na krev s výkonností - ale mám v tom napsaný jeden projektík, který vůbec není school-level a psát to v čemkoliv jiném, tak to potřebuje asi výrazně víc lidí a času. Co máš konkrétně na mysli?

Jinak komedie side-efektů ve srovnání s Java/JS má znamenat co? Purescript tohle umí a přišlo mi, že to, co to přinese, za přidanou komplexitu nějak moc nestojí...

[Mirek Prýmek]

BTW jak se řeší NIO v FP?

Runtime GHC (Haskell) má green thready, takže to typicky spustíš s N OS threadama, kde N~počet corů a mezi tím ti tak nějak migrují green thready, takže sice píšeš "blocking", ale ve skutečnosti to je všechno non-blocking.

Erlang to má stejně.

Já si to bez typeclass nějak fakt neumim představit...v haskellu to používám docela hodně.

Hele, já to neumím přesně vyargumentovat, nejsem haskellista, takže do té praxe dost nevidím. Ale tak laicky bych řekl, že tam hrají roli dvě věci:

1. problémová doména - co si budeme povídat, weby nejsou žádná raketová věda, máš nějaké datové struktury a chceš je nějak zobrazit, máš nějaké události a chceš je poslat na backend a zpátky. To je celý. 3D raytracing tam psát nebudeš. Pokud nemáš možnost dělat nějaké wifikundační abstrakce, tak je prostě dělat nebudeš a nezblázníš se z toho. Sem tam to znamená, že musíš nějaký kód vzít a zkopírovat jinam a při refaktoringu máš víc práce než kdybys měl k dispozici lepší abstrakci. Ale tak co no, i tak je to lepší než se střelit do nohy nebo programovat v JS

2. Nevím, jestli Haskell má něco podobného, ale v Elmu sem tam nějakou abstrakci zastanou "neúplné recordy" (teď nevím, jak se to oficiálně jmenuje) - prostě řekneš, že typ je {a|s : String, t: Int} - tj. record, který má položky s a t plus možná něco navíc, co tě v té fci nezajímá (to je to "a").

Taky mám pocit, že ten typový systém je i v nějakých detailech trochu volnější než u Haskellu, ale konkrétní příklad teď fakt nedám. Myslím, že jde třeba udělat fce typu "a -> b" (a ani b nijak nespecifikuju) a překladač se s tím nějak popere. To myslím v Haskellu nejde, ne? Teď si fakt nejsem jistej a nechce se mi to už takhle v noci zkoušet a zkoumat. Spíš si to fakt zkus, ty to posoudíš líp než já, já to beru jenom fakt pragmaticky jako menší zlo než JS a nijak moc se nad tím nezamýšlím, dokud to dělá to, co od toho potřebuju

ani tím pořádně nejde napsat JSON serializaci

Elm má (de)serializaci JSONu moc pěknou: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode a http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Encode

[to_je_jedno]

Když chci přidat další funkcionalitu, tak se bojím a nechce se mi Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.

ses si jisty, ze problem je v pouzite technologii? Neni to spis tvuj vlastni mrdník a absence kvalitnich testu od jednotkovych po integracni?

[andy]

Když chci přidat další funkcionalitu, tak se bojím a nechce se mi Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.

ses si jisty, ze problem je v pouzite technologii? Neni to spis tvuj vlastni mrdník a absence kvalitnich testu od jednotkovych po integracni?

Testů tam moc nemám, ale obávám se, že bych se bál úplně stejně, i kdyby tam ty testy byly (a nemám tým lidí, aby mi je udržoval). Popravdě testovat mi připadá rozumné algoritmy/parsing, ale věci typu "vezmi data, pošli je někam", tam toho moc na testování není. Shodou okolností v tom projektíku je napsaný parsing nějakého "kalendáře", kolem kterého je tuna testů (protože bez toho by to vůbec napsat nešlo) a do toho se mi šahat nechce už vůbec.... (lex/bison parsing je fakt lahůdka obzvláště na jazyk, který nebyl designován s tím, aby byl takhle parsovatelný...resp. u kterého se o designu nedá moc mluvit)

Spousta věcí, která se běžně řeší testama, je v těchhle jazycích tak nějak zadarmo.... takže když provedeš refaktoring, tak nemusíš přepisovat tunu testů. Z druhé strany, ty angular aplikace mají tendenci tak nějak špagetovatět. Kdybych tam měl různou spoustu testů, tak si sice můžu být rozumně jistý, že nic nerozbiju, ale něco tam změnit pořád není zrovna jednoduché; btw, tohle evidentně není jen moje zkušenost, když Angular2 je zpětně nekompatibilní změna jedničky.

[to_je_jedno]

Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.

Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.

[andy]

Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.

Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.

Primární problém je v použité technologii. Když jedna technologie vyžaduje 4x víc práce na to, aby to bylo nějak udržovatelné než druhá, tak je problém v té první technologii. A vybírat si jazyk/framework na základě rychlosti vývoje, udržovatelnosti apod. není politika.