23 komentářů k článku JavaScript na serveru: Začínáme s Node.js:

    1. Jakub

      Re: proč takový zájem

      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…

      1. Tomáš Witek

        Re: proč takový zájem

        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ší?

        1. Node.js potenciál

          Re: proč takový zájem

          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.

          1. Tomáš

            Re: proč takový zájem

            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.

            1. Jakub

              Re: proč takový zájem

              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ď? :)

    1. Jakub

      Re: Alternativní instalace npm

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

  1. vetesnik

    Jenom taková technická

    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.

    1. Jakub

      Re: Jenom taková technická

      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.

  2. Michal Augustýn

    pár dotázek

    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 ;-)).

  3. echy

    Debug v Ubuntu

    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.

  4. ptica

    virtualmaster zdrazil?

    dari se mi naklikat petikacka na den, vps za rok za ~360, jak pise jakub v clanku ale ne. nevite, jak na to?

  5. vencax

    Nedari se mi debugovat

    Vypocet se zastavi na breakpointu, ale at dam continue, stepin, stepover,… nestane se nic. Ani na klient se nic neposle, takze se toci stale dal. Kdyz koukam na stdout node-inspectoru, tak do nej ty udalosti s browseru chodi (napr.: {„method“:“De­bugger.stepIn­to“,“id“:35} … Debugger.resumed : {}). Zkousim to na linuxu, v chromium browseru. Zkusil jsem to i v chromu, ale stejny vysledek. Netusi nekdo co delam blbe?

    1. vencax

      Re: Nedari se mi debugovat

      Sorry, nevsim jsem si prve postu od Vojta Grec. Kazdopadne pro ubuntaky PPA repo:
      sudo apt-get install python-software-properties
      sudo add-apt-repository ppa:chris-lea/node.js
      sudo apt-get update
      sudo apt-get install nodejs npm

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3373