2013. július 10., szerda

A Dart elterjedésére szerintem nagyon jótékonyan hatna, ha összedobnának hozzá egy futtatókörnyezetet JVM fölé.

A Dart elterjedésére szerintem nagyon jótékonyan hatna, ha összedobnának hozzá egy futtatókörnyezetet JVM fölé. Annak ellenére, hogy a Dart-nak van saját futtatókörnyezete, lenen értelme egy ilyen párhuzamos projektnek, hiszen így beágyazható lenne a meglévő Java alkalmazásokba. Tehát rögtön futtathatnánk Dart-ot Androidon, Dart-ban bővíthetnénk a meglévő szerver oldali Java alapú rendszerünket, stb. Biztos sokan kezdenék el használni. Aztán utólag még mindig lehet dönteni, hogy maradnak JVM-en, vagy inkább raknak alá natív DartVM-et.

Igazából egy dart2java fordítónak szerintem legalább annyira létjogosultsága lenne szerver oldalon (+android), mint amennyire létjogosultsága van a dart2js-nek kliens oldalon.

#blog

8 megjegyzés:

  1. Szerintem ezek maximum addig hiányoznak, amít el nem készíted az első közepes/nagyobb alkalmazást Dart-ban.

    A dart2js speciális, mivel a böngészőket nem tudják a fejlesztők befolyásolni, de szerver oldalon mindenki azt választ amit akar, akár Dart VM-et is futtathatsz, kb. ugyanannyi az adminisztrációja, mint egy Java VM-nek vagy egy node.js-nek.

    Androidnál lesz ARM processzoros VM, remélem előbb-utóbb lesz natív Android API is hozzá.

    VálaszTörlés
  2. Androidnál az összes ilyen megoldással az a bajom, hogy hozzá kell fordítanod az app-hoz a vm-et, és nagy lesz az apk. Vannak ilyen cuccok V8-as JS engine-el, vagy Xamarin Mono runtime-al, de mindenhol 3M-nál kezdődik egy app, ami a szűkös tárhely mellett sok. Egy Java fordítóval Java-s méretű app-okat lehetne fejleszteni.

    Új projektnél pedig az egyik gond, hogy nem biztos, hogy akkor kezded a projektet. Egy ilyen fordítóval meglévő projektet is bővíthetnél Dart-al. A másik gond meg ugye, hogy a Dart VM azért még nincs ott, hogy rá merd tenni az életed. Ugyanakkor a JVM azért elég stabil, ki van találva clusterezés, minden.

    Hosszú távon szerintem sincs erre szükség, viszont rövid távon jó lenne, amíg nem ér oda a Dart VM, hogy nyugodt szívvel használd szerver oldalon, meg amíg nem lesz amúgy is beépített lehetőség Androidon.

    VálaszTörlés
  3. Sok minden említesz, kiemelném a klaszterezést, mint egy remek példát arra, hogy mi a nagy különbség a Java és a Dart (Google) világ hozzáállásában. A Java EE egyik nagy "sales pitch" pontja a klaszterezés volt, hogy az alkalmazásnak nem kell törődnie az elosztott memóriakezeléssel, azt majd a klaszter megoldja.

    Gondolom nem nagy titok, de a nagy cégek (FB, Google, Twitter...) nem használnak klaszterezést, hanem az egyes szerver processzek önállóan, autonóm módon tudnak működni. Ha kell állapotmegosztás, akkor az vagy különálló, in-memory vagy perzisztens adatbázison keresztül történik (amik már  alkothatnak klasztert, tetszés és implementáció szerint). A Dart fejlesztése a Google-ből jön, ahol,mivel nincs "klaszter probléma" (és nem is kell "eladni" terméket valamilyen megkülönböztető feature-rel), nem nagyon várnék klaszterezett Dart VM megoldást.

    Minden tapasztalat arra utal, hogy nem lenne semmi értelme, mert sokkal jobb megoldások vannak más architektúra rétegezéssel. A Dart szerver oldalon sohasem fog a JavaEE lecserélésére törekedni, mert egy teljesen más megoldást ad egy teljesen más kérdésre. Én elsősorban a node.js alkalmazások migrálását/csökkenését várom tőle, és a Java cuccok csökkenését csak sokkal később.

    VálaszTörlés
  4. Igazából a klaszterezést csak példának írtam. Az igazából a lényeg, hogy a Java egy bejáratott technológia, a Dart pedig nem, így szerintem sokan sokáig nem mernének Dart-ra mission critical rendszereket építeni. Ugyanakkor ha lenne egy Dart2Java fordító, akkor már nyugodt szívvel fejleszthetnél ilyeneket, mert futtathatod a jól bevált Jávás architektúrádon. Aztán ha elér oda a Dart, ki lehet alóla dobni a JVM-et a francba. De addig jól jönne, és sokszorosára gyorsulna a nyelv fejlődése, és elterjedése. Ezért érné meg még akkor is, ha tudjuk, hogy hosszú távon felesleges lesz a dolog.

    Amúgy a klaszterezéssel igazad van. Ez jól látszik az AppEngine architektúráján is. Amúgy nekem is sokkal jobban tetszik, mint a kesze-kusza mindenféle rejtett rétegekből felépített J2EE megoldások.

    VálaszTörlés
  5. Mi lenne a JavaVM előnye, ha a teljes kódot Dartban írod?

    VálaszTörlés
  6. Hogy a JVM már jól bevált, stabil cucc, a Dart meg még béta. Kritikus rendszert szerintem egyelőre nem merne nagyon senki Dart-ban (Dart VM-re) fejleszteni. A másik pedig, hogy így akár egy kész rendszerhez is hozzáfejleszthetsz Dart-ban, hívhatsz meglévő Java libeket olyan esetekben, ami Dart-ra nincs megvalósítva, stb. Kb. ugyanaz az előnye, mint a JS-el való együttműködésnek, csak itt szerver oldalon.

    VálaszTörlés
  7. Az első fele amit írsz, az csak bizalmi kérdés ("stabil", "kritikus"), amin szerintem nem egy dart2java fordító, hanem a nyilvánosan Dart projektek szaporodó száma fog segíteni. A node.js már régóta bebizonyította hogy életképes a szerver oldalon, mégis vannak megrögzött Java-sok, akik a mai napig nem tartják "elegendőnek". Nem várok más reakciót a Dart-tal kapcsolatban sem (vagy Ruby vagy Django vagy igazából bármi ami nem a megszokott JavaEE).

    A második fele, libek hívása: külön service-ként mindig lehet futtatni a JVM-et vagy bármilyen más programot. Protobuf támogatás és HTTP kommunikáció már van Dart-hoz, nincs akadálya a hatékony kommunikációnak. Nekem jelenleg csak a Lucene hiányzik, de azt meg lehet EleasticSearch-el helyettesíteni.

    VálaszTörlés
  8. Lehet ... Én akkor a megrögzött Java-s vagyok, akit jobban meggyőzne egy ilyen fordító. :)

    A másik, ami miatt nekem szimpatikus lenne, az az Android fejlesztés.

    VálaszTörlés