Názory k článku
JavaScript na serveru: Začínáme s Node.js

Tak zatím jsem odpověď na otázku "proč způsobil node.js takový zájem" nedostal. Tak snad příště.

Neboli - má cenu se učit nový framework?

Ale uznávám, že aplikace http://nodeknockout.com/ nebo http://expressjs.com/applications.html jsou hezké.

Trochu jsem očekával, že tuhle otázku už si čtenář zodpověděl sám dříve, nad některým z úvodních článků o node.js.

Podle mne je hlavním důvodem, že činí tradičně složité programování asynchronních serverů a proudového zpracování směšně jednoduchým. Jsou další důvody - např. jeden jazyk na serveru i klientovi, či vysoká rychlost node.js při zachování nízké složitosti atp...

Někde na netu jsem se dočetl, že vyvojáři si stále neuvědomují hlavní výhodu node.js a právě proto vznikají frameworky jako Connect či Express, které většinou pouze kopírují již zavedenou technologii jako je např. RoR či Sinatra a nevyužijí tím hlavní potencionál node.js.

Viz. video: http://jdem.cz/hykg8

Souhlasíte s tímto názorem?
Můžete v dalším článku zabrousit do tohoto problému, nebo alespoň odkázat na článek, který tohle řeší?

Ano, převážně souhlasím. Node.js těží z Javascriptu, což je jazyk zajímavý, velmi silný a pěkný, ale dost atypický a způsoby, jak ho elegantně používat, se stále vyvíjejí.

Kopírovat Ruby svět (RoR, Sinatra) je přirozená první vlna vývoje - obě komunity jsou zaměřené na eleganci, jednoduchost a rychlost vývoje atd.

Nicméně všichni tak nějak cítí, že je potřeba najít nové paradigma. Ve světe client-side Javascriptu to byl jQuery, který si jako první uvědomil jednoduchost a expresivitu CSS selektorů a postupu "vyber DOM elementy a pak na ně aplikuj změny".

Je to otevřené téma, které je stále živé. Není na něj zatím definitivní odpověď (ve formě nového přístupu). Nicméně díky za podnět, v příštím díle (který bude primárně o Connect/Expressu) se o tom zmíním a naznačím i jiné, další možnosti.

Osobně v node.js nevidím potenciál.

Je tam spousta technologických problémů, které jsou dost spjaty s použitím interpretrem - V8. např. to, že je to single-threaded, což způsobí problém když GC začne uklízet. Jelikož zastaví hlavní thread a aplikace čeká. To způsobí, že odpověď se opozdí o několik stovek milisekund. Tohle to není vůbec problém v prohlížeči, ale na serveru je to celkem velký problém.

Nevyužívá ani dnes populární více jádrové procesory. Kvůli tomu, že je singe-threaded. Je sice možnost ho pustit tolikrát kolik má počítač jader a dát před to balancer, ale je to prostě další problém, který člověk musí řešit, tak obskurně.

Ať se snaží optimalizovat V8 jak chtějí stále to není nic moc v porovnání o ostatními jazyky. Je to stále dynamický jazyk a i když tam je JIT, takže výhoda proti ostatnímu jazykům v podstatě není.

Sám jazyk JavaScript. Má sice spoustu výhod a je v něm spoustu chytrých myšlenek, ale na druhou stranu je tam spousta věcích vyloženě nedomyšlených a způsobují dost problémy. Existuje sice hromada hacků jak tyto problémy obejít, ale kdo chce pořád programovat s hacky, aby mohl řešit problémy, které v ostatních jazycích nejsou?

např. globální kontext. Neexistují jmenný prostory ani moduly. Tohle sice řeší CommonJS, který představuje jakési jmenné prostory, ale osobně jejich implementaci nevidím moc šťastně. Komu se libí psát export. před vším co chce dát ven a pak když něco require tak tomu musí dávat jméno. Nemožnost mít dva soubory ve stejném prostoru apod.

Myšlenka asynchronního programování je super, ale node.js není řešení. Jelikož velký výhoda asynchronního programování je u serveru, kde je vyžadováno spousta spojení, což je třeba Comet server. Bohužel node.js jako Comet server je zcela nevhodný kvůli V8, která bude brzdit spojení kvůli GC. Napsal o tom např. autor sociální sítě Plurk, kde použili node.js a bylo to zcela nevhodné řešení, které nakonec přepsali do Javy. viz. zkušenost na jeho blogu http://amix.dk/blog/post/19577 Jedná se asi o jedno z největších produkčních nasazení node.js

Pokud někdo něco chce asynchronně programovat, tak ať sáhne po technologiích, které nemají takové problémy jako je např. pro Javu - Netty, EventMachine pro Ruby, Tornado pro Python atd. sice problém těchto jazyků je, že obsahují spoustu knihoven co mají blokující kód, ale pokud člověk ví co dělat, tak ví jakému kódu se vyhnout, aby nebyl blokující.

Možná node.js jednou bude stejně použitelný jako jiná řešení a momentálně bohužel není. Obsahuje spoustu chyb viz. memory leaky na zmiňovaném blogu, je dost mladý, nestabilní atd. toto se možná jednou vyřeší, ale chyby JavaScriptu bohužel ne. Možná přijde nový standard, který V8 bude podporovat, který vyřeší spoustu problému JavaScriptu, ale možná taky ne... Chápu, že tohle není problém pro všechny. Jsou lidi co mají JavaScript rádi a líbí se jím hacky jakým simulují objekty, jmenný prostory, dědičnost atd.

node.js je prostě buzz word a osobně jsem si myslel buhví co to je, ale po vyzkoušení a následném research zjišťují, že je to skutečně jen buzz word a nenašel jsem důvod proč node.js použít. Naopak jsem našel důvody proč se mu vyhnout.

Inu Tomáši - někdo má rád holky, jiný zase vdolky. Není nutné, aby celý svět používal jediný jazyk/framework.

Některé zmiňované problémy jsou vnímany jako přednost, např. C-část node.js single-threaded není, zakládá vlákna např. pro obsluhu blokujících IO, nicméně JS/V8 vás izoluje do single-threaded sandboxu - a je to dobře. Jiné jsou řešitelné a dostaneme se k ním v pozdějších dílech (multi-core procesory, moduly), jiné problémem nejsou (GC ve V8 je opravdu propracovaný, generační a v příští verzi asi i v separátním threadu).

Vás možná node.js neoslovil, ale MNOHO jiných kvalitních programátorů ano. A už to samo o sobě je příslibem toho, že nad node.js vznikne spousta zajímavých projektů a silný ekosystém. Ostatně - jsem si jistý, že před pár lety když nabíralo na popularitě Ruby (díky Railsům) tak se mu nadávalo ještě hůře. A kdo se směje teď? :)

Ano, to je dobrá otázka - kdo se směje?
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Díky za článek!

Když jsem onehdá Node.js instaloval, cvičení s `chown /usr/local` podle návodu autora npm se mi nelíbilo, ale fungovala rozumnější metoda popsaná zde: https://gist.github.com/579814#file_yet_another_option.sh

Díky za odkaz Karmi! Jsou další, alternativní způsoby, ale nechtěl jsem to pro začátek komplikovat...

Chci se jenom zeptat, na čem jsi to instaloval? Vypadá to na Mac OS X, ale jistý si nejsem. (Doufám, že nevadí, že tykám :).

Díky.
Oldřibřich.

Oldo - nevadí. :) Otisky obrazovky jsou z OS X, na kterém jsem instaloval. Kromě toho jsem instaloval také na Ubuntu a CentOSu. Pokud máš nějaké konkrétní otázky/problémy s instalací, klidně se můžeš zeptat tady v komentářích.

Super, díky, vyzkouším. :)

Díky za článek a opožděně i za pěknou přednášku na WebExpo Digest ;-)

1) Když je nativní vrstva nad V8 tak tenká, nechystá se i port pro Windows? (Ptám se proto, protože jsem líný Windows člověk a nechce se mi zaplevelovat systém Cygwinem.)

2) Není mi moc jasný "životní cyklus". Když "vše" běží v jednom vlákně, tak jak to přesně funguje? Pokud se každý request zpracovává v jiném vlákně, tak je určitě třeba nějak synchronizovat minimálně přístup ke globálnímu objektu. Nebo se vždy zpracovává max. jeden request (tj. uvnitř anonymní metody předané to http.createServer se nachází právě jeden request) ? Nebo se sychronizace vyřeší tím, že se běhové prostředí JavaScriptu forkne nebo "forkne"?
Možná by pomohl kratičký příklad, který by počítal celkový počet requestů a který ukazuje použití proměnné (v globálním objektu? jde to?), která je platná jen po dobu života jednoho requestu.

3) Sílu JavaScriptu vidím hlavně v tom, že je možné použít stejný jazyk pro frontend i backend. Na přednášce jsi dále zmiňoval možnost psát asynchronně, tj. předávat všude (anonymní), které představují continuation, a že je na to API od začátku navrženo.
Stejný způsob lze ale použít IMHO v dalších jazycích, které mají k dispozici asynchronní API, např. v C#/.NET. Nevím, jestli jsi viděl CTP C# 5, ale tam dokonce zavádí klíčová slova async a await, díky kterým ty ošklivé continuations vygeneruje přímo kompilátor a kód je tak o řád čistější. Tomu IMHO nemůže JavaScript konkurovat (a to říkám jako velký JavaScriptový větrák ;-)).

ad bod tři

jj, naprostej souhlas, ale stejně, js nás vždy překvapí: https://github.com/jed/fab ;)

https://github.com/jed/fab/blob/browser/demo.html

Objevil jsem náhodou http://jsapp.us/ - může se hodit pro zkoušení příkladů a vůbec hraní si v rychlosti s node.js

Jojo, viz zprávička o JSApp.us

Už nevím kde jsem tu informaci vygooglil, ale každopádně v Ubuntu pomůže překompilovat node.js s GCC_VERSION=44, pak debug mód šlape jak hodinky.

:-) text musí být dlouhý alespoň 4 znaky.