Komentáře k článku

Jaxer aneb pokročilý JavaScript na straně serveru

Společnost Aptana vydala nedávno Jaxer 1.0, ostrou verzi svého „ajaxového serveru“. Základem je zdrojový kód Firefoxu 3 s doplněným rozhraním k databázím a souborovému systému. To umožňuje psát aplikace v JavaScriptu i na straně serveru, zbavit se přeskakování mezi jazyky a opakovaně využít část zdrojového kódu na obou stranách (např. validace). Přestože to není jediný pokus o server-side JavaScript, pravděpodobně patří k těm nejvíc životaschopným.

Zpět na článek

10 komentářů k článku Jaxer aneb pokročilý JavaScript na straně serveru:

  1. benzin

    A jak je to s vykonosti?
    Jak je to s vykonosti takto napsane aplikace?
    Jak je to s se schopnosti vyporadat se s mnoha requesty zaroven?
    Ma nejakou podporu pro konverzace, kratsi nez session, ale delsi nez request?
    Man toto prostredi nejakou podporu pro rozlozeni pres vice Nodu (server se sklada fyzicky z vice stroju)?
    Existuje nejaka podpora pro volani nativnih funkci systemu (napr. kdybych to chtel propojit s OO pro prevod doc do pdf)?

    P.S.: Bude tohle mit pokracovani?

    1. Ladislav MrňákAutor příspěvku

      Re: A jak je to s vykonosti?
      Výkonnost je podle jejich testů mezi php a rails. JavaScript na serveru se zkompiluje a pak opakovaně používá. Se zlepšující se rychlostí javascriptu v prohlížečích se to bude dál zlepšovat.

      Podpora pro více fyzických strojů tam je. A existuje tam JaxerManager, který podle potřeby spouští a vypíná jednotlivé jaxery (obsluhující požadavky). Jestli jde volat nativní funkce nevím, je možno zpracovat místo html souboru např. php soubor.

      Konverzace kratší než session ale delší než request – té otázce moc nerozumím.

      Pokračování asi napíšu, jak budou přibývat zkušenosti.

      1. benzin

        Re: A jak je to s vykonosti?
        Tipicky se ve webovych aplikacich objevuji casti do kterych kdyz uzivatel vstoupi pouziva se pro jim aktivovane akce kontext teto casti.

        napr. uzivatel vstoupi do diskuse a chce, pak klikne na tlacitko edit a chce editovat tuto konkretni diskusi.

        Pristupy jak to udelat sou v zasade 3.
        1) ulozime pri vstupu do diskuse prave aktualni diskusi do session a pak vsechny akce berou id diskuse ze session – obrovska nevyhoda, ze uzivatel nemuze byt ve vice nez jedne diskusi zaroven (ale i tak se tento pristup pouziva)
        2) Ke kazdemu tlacitku pridame bud hidden field nebo URL parameter diskussionId = idDiskuse a do kazdeho requestu prenasime informaci o diskusi kterou chceme aktci ovlivnit
        3) Pri vstupu do diskuse zalozime konverzaci do ktere ulozime identifikator diskuse. Tento objekt ulozime na session a pak predavame na tlacitka identifikator kontextu, nebo identifikator kontextu pridame do cesty ke strance.

        1) konverzace ma delku session a muze byt jenom jedna na session
        2) konverzace ma delku requestu a pri zakladani nove se inicializuje parametry prenesenymi z predchoziho requestu (coz muze vest k predavani strasne spousty ruznych parmaetru obzvlast kdyz mezi dve stranky vlozime nejakou novou pro nejaky predvyber)
        3) konverzace ma delku delsi nez request ale kratsi nez session. Mezi requesty se prenasi identifikator konverzace a ta si drzi vsechny parametry v sobe.

  2. Kája

    Jak to vypadá s ECMAScript 4/JavaScript 2?
    Jak je to s podporou ES 4? Sice přesně nevím, co všechno zahrnuje JS 1.8, ale zajímalo by mě, jestli jde/půjde používat namespace, třídy, určení typu atd.

    A bohužel se mi zdá, že životaschopnost tohoto řešení začíná a končí u problému "sehnat hosting", protože přestože ES 4 je už velice schopný jazyk, tak pak stejně člověk řeší "kde pro mou aplikaci sehnat místo", a protože jak na potvoru "cena vždycky hraje roli", bude to faktor, který toto řešení zřejmě pošle k ledu. I když je to skutečně škoda.

    1. Ladislav MrňákAutor příspěvku

      Re: Jak to vypadá s ECMAScript 4/JavaScript 2?
      Zrovna jsi vyjmenoval věci, které se tvůrci JavaScriptu rozhodli (byli donuceni) vyřadit (kvůli Microsoftu). Ale mně tohle zrovna moc nevadí. Na JavaScriptu se mi líbí ta flexibilnost. V 90. letech udělali jazyk, který se od té doby nezměnil (ve smyslu, že IE blokuje/blokovalo novinky), a přesto se na tom dělají pořád nové formáty jako JSON, knihovny a úpravy, funkce se jednoduše předává jako argument (žádné ukazatele na funkce, delegáty apod.) a tak by se dalo pokračovat ještě hodně dlouho. Třídy a hromady klestí okolo jsem stejně vždy nesnášel.

      Hosting už určitě někde na světě existuje, i když samozřejmě nesrovnatelně s PHP. Ale lze si udělat virtuální server u poskytovatele. A Aptana se snaží prosadit svůj Cloud (http://aptana.com/cloud).

  3. Anonym

    Js & jaxer
    Hned na zaciatku napisem ze cim viac sa zacina javascript presadzovat a aj vyskytovat na miestach kde doteraz nebol tym viac ho nemusim a myslim si ze je to slepa cesta.
    K Jaxeru.Mna by skor zaujimala stranka bezpecnosti.Vzhladom na to ze javascript bezi na strane klienta (teraz mam na mysli cast ktora vyvola request na server) neni problem si zistit nazvy funkcii (aj ked bude dany script obfusknuty) a potom v pohode volat zaujimave funkcie na servery (myslim niekto cudzi,tretia strana).Ak XSS je na beznych strankach nebezpecny tak na jaxerackom serveri/stranke to bude peklo.Jedine kde by som sa odvazil jaxer nasadit tak to je as intranet.

    1. Ladislav MrňákAutor příspěvku

      Re: Js & jaxer
      Na straně klienta běží pouze proxy funkce (vytvořená Jaxerem), takže na klientovi není známé, co je uvnitř té serverové funkce. Z této serverové funkce lze následně volat libovolné jiné funkce, jejich název klient nezná. Je to popsáno ve spodní části článku (Kategorie dostupnosti zdrojového kódu).

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=2932