nedávno jsem mluvil s přítelem o vývoji UI. Byl také programátorem, protože programování bylo považováno za tajemné umění (když ti z nás, kteří to udělali, byli považováni za Gandalfa šedého čelícího Balrogu). Nebo možná, prostě jsme se tak viděli. Bez ohledu na, oba z nás byli Java programátoři pro velkou část té doby.
oba jsme si stěžovali, že to byl kontextový přepínač, který šel z kódování většiny našich projektů v Javě, a pak musel přepnout na JavaScript pro frontend.
na Základě rozhovorů, které jsem viděl on-line, několik čtenářů se zahřívá jejich klávesnice peskovat mě stěžuje na to, že se kód v Javascriptu. Udržujte své klíče v pohodě, my i naši spolupracovníci máme zkušenosti a rádi píšeme, JavaScript a některý z jeho rámců pro naše klienty. Ale použití JavaScriptu není vždy nejlepší přístup.
v tomto příspěvku Představujeme dva rámce, které vám umožňují kódovat uživatelské rozhraní v Javě: GWT a Vaadin.
kdy použít Javu pro vaše uživatelské rozhraní?
rozhovor se mi vrátil, když jsem mluvil s klientem-malým obchodem pouze několika programátorů a softwarového architekta, který také programoval. Rozhodli se, že nechtějí udržovat své projekty ve dvou samostatných jazycích. Jejich společnost měla standardizovaný na Javě, a chtěli použít stejné nástroje a myšlení, k vytvoření silné a moderní uživatelské rozhraní pro své webové aplikace.
u větších týmů jsem si všiml, že se zdá, že se tým odděluje, někteří se raději soustředí na front-end a jiní pracují většinou na back-end nebo na straně serveru. Když je práce schválena pro vývoj, často vidím, že stejní programátoři buď berou nebo dostávají většinu Front-endové práce JavaScriptu, a jiní berou back-end.
neříkám, že je to špatná věc; ve skutečnosti se zdá, že je to právě naopak. Každý se zdá být produktivnější ve své komfortní zóně, ale každý si je také vědom toho, co dělají všichni ostatní, a může do této zóny vstoupit, pokud je to nutné. Pro menší obchody to nepřipadá v úvahu. Stejný programátor často napíše kód celého projektu z uživatelského rozhraní do modelu.
naštěstí existují možnosti, pokud si přejete zachovat uživatelské rozhraní ve stejném jazyce jako back-end, pokud je tento jazyk Java. Promluvme si o několika z nich.
GWT
Google Web Toolkit nebo GWT je vynikající volbou.
měl jsem hodně úspěchů s GW na projektu jsem začal asi před 8 lety a stále udržovat. GWT mi umožnilo vytvořit logiku zobrazení pro jednostránkovou aplikaci zcela ve standardním kódu Java. Dodává se s Eclipse plugin. Nepoužil jsem to, protože jsem použil Netbeans pro své vývojové prostředí, ale protože Eclipse je standardem pro většinu týmů, mohlo by to být velmi užitečné.
byl jsem schopen rozdělit logiku pro widgety (například vlastní textové pole), do tříd nebo pomocných metod, stejně jako bych obchodní logiku na projektu na straně serveru. Díky dědičnosti jsem byl schopen snadno vytvořit několik widgetů, které měly podobné požadavky. O jediný skutečný pojem změna, kterou jsem musel řešit byl, že UI je mnohem více událostí, než většina webových služeb, nebo jiné server-side kód.
existují dvě hlavní nevýhody vidím GWT. Jedním z nich je čas kompilace. GWT přidá krok kompilace do procesu, který nějakou dobu trvá. Třídy GWT, které byly postaveny v Javě, musí být zkompilovány do knihoven JavaScriptu. Viděl jsem několik stížností na čas, který to trvá.
druhým je, že je to už docela dlouho, co GWT zaznamenala významnou aktualizaci. Od tohoto psaní byl 2.8.2 vydán před více než rokem v říjnu 2017. Tři roky předtím byl vydán 2.7.0, což je čtyři roky od doby psaní tohoto článku. Vidím příspěvky a komentáře o 3.0 coming out, včetně některých z před dvěma lety ptal, jestli plakátu měli počkat na verzi 3.0, aby vyšel před implementací velká změna (doufám, že plakát není stále čeká), ale nemohu najít žádné časové osy, jak, kdy, že vydání by mohlo být.
i když jsem velkým fanouškem rámce a považuji jej za dostatečně zralý, vím, že tato vágnost v možnosti budoucích vydání způsobuje, že někteří projektoví manažeři jsou spíše nervózní. Nikdo nechce být vázán na rámec, který na ně slepé uličky.
GWT je knihovna, kterou budu i nadále používat a navrhovat ostatním týmům, aby ji používaly, pokud splňuje jejich potřeby.
Vaadin
Vaadin je další skvělá volba.
původně jsem si myslel, že GWT je moje jediná volba pro psaní uživatelských rozhraní ve standardním kódu Java. Ale když jsem mluvil s tímto malým obchodem, který jsem zmínil výše, řekli mi, že se rozhodli použít Vaadin pro své projekty. Takže jsem se samozřejmě musel jít podívat. A jsem ohromen.
budu upřímný, od tohoto psaní jsem Vaadina ještě nepoužil k vytvoření projektu. Ale připravuji několik osobních projektů, pro které potřebuji přední konce a hodlám to použít. Pokud Vaadin splní své sliby, bude to dokonalý rámec pro tyto projekty.
Vaadin slibuje podporu jazyků, které běží v JVM, jako jsou Kotlin a Scala. Doufám, že to zahrnuje Groovy. Pokud čtete mnoho mých předchozích příspěvků, budete vědět, že jsem fanouškem tohoto jazyka, protože můžete rychle vytvořit kód, který lze snadno udržovat. To jsou pro mě důležité požadavky, zejména udržovatelnost. Nic neničí Projekt po silnici víc, než není schopen snadno udržovat kód, který již byl napsán.
Závěrečné myšlenky
máte mnoho možností při architektuře webové aplikace, pokud jde o technologii uživatelského rozhraní. Ať už projektujete projekt nebo produkční prostředí, musíte mít na paměti tolik požadavků.
dva požadavky, které musíte mít na paměti, jsou snadný vývoj a udržovatelnost.
- vývojové prostředí, ve kterém je obtížné pracovat, bude mít za následek mnoho překročení nákladů a bude velmi obtížné přivést nové programátory.
- projekt, který je obtížně udržovatelný, způsobí v budoucnu frustraci a ztratí více peněz.
na Základě vašeho týmu potřeb a požadavků, kompletní Java řešení, z uživatelského rozhraní k modelu, je nejen možné, ale skvělá volba pro rychlý vývoj a snadnou údržbu.
věřte v dobrý kód.