Még az ünnepek előtt jött valahol szembe a Vaadin (https://vaadin.com), ami első (és egyelőre sokadik) ránézésre is olyan frameworknek látszik, aminek használatát érdemes lenne fontolóra venni.
Amúgy sem szeretem a frontendet; JavaScripttől, CSS-től stb., kiráz a hideg.
De azt vettem észre, hogy kis fejlesztőcsapat lévén (van 1 db UX-es, de ő is inkább designer, mint fejlesztő, a többi lényegileg mind backend) számos belső tool-ra egyszerűen nem jut idő és energia frontendet fejleszteni, mert a Postman-nel való tutujgatás "elégségesen jó" megoldás.
Szóval első körben leginkább belső tool-ok UI fejlesztésére használnám, nem pedig a publikus oldalunkat akarnám újraírni benne.
A kérdés: használta-e valaki a Vaadin-t éles környezetben (nem példakódok otthon bizergetése), és ha igen, akkor mik voltak a tapasztalatok vele?
Mennyire egyszerű vele egy frontendet összehozni?
Mennyire bugos?
Hogyan lehet debugolni?
Milyen előnyöket/hátrányokat tapasztaltatok?
Stb. stb.
Köszi!
Hozzászólások
Erre fasza. Ha viszont bármi kis design kellene, akkor hirtelen előkerül a szekrényből a szopóroller.
Ha Java-hoz értesz és nem akarsz komplex UI-t, akkor jó. Minden más esetben érdemes inkább elfelejteni. A build erőforrásigényes; szerver oldalon keletkezik minden; a debug nehézkes, főleg, ha kliens oldalon van a szar; a kliens oldal majdnem olyan, mintha obfuscated kód lenne; a skálázhatósága egy darab monolit betonéval vetekszik.
Ha van valamennyi JS tudás, akkor már értelmesebb valami JS framework, basic UI, egyszerű event driven dolgokkal és akkor nem az van, hogy neked nincs rá időd és nem lesz ember, aki hozzá mer nyúlni, mert JS tudást sokkal könnyebb leakasztani, mint Vaadin tudást.
https://iotguru.cloud
nyöah, a frissebb Vaadinok azért nem ennyire szopások, de nagyrészt igen.
A Vaadin ~10-14 körül váltottak a GWT-ről, meg a widgetsetcompile-ról webcomponents-re, aztán onnan még valahova tovább, talán valami lit, meg vite nevű cuccot ír most a logba.
Lásd fent, ma már ez AFAIK nem teljesen igaz, de nagyrészt igen.
Utoljára a webcomponentes időben kellett ilyet, még custom webcomponentet is írtam anno. Nem volt a kedvenc dolgom, de azért nagyságrenddel jobb, mint régen.
A kliens JS kód meg akkor a webkomponensemtől függöt, ha jól emlékszem.
A plain vaadin jah. De mintha lehetne ilyen hybrid hilla / lit-es dolgokat csinálni vele egy ideje, így ha kinövöd az appodat, akkor szép lassan le tudod választani a frontendedet egy kezelhetőbb valamivé.
Gyors prototypeingra, vagy háttéralkalmazásokra jó. A random következő startupomat nem ebben indítanám.
Ha szépet akarsz, akkor keress valami kész template-et (pl), mert különben szopni fogsz vele. Debuggolni nem szopás a core vaadin-t, de meg kell szokni a logikáját. Ha 1-2 külső komponenst be akarsz húzni, az már lehet mókás: mostanában az echarts-os Vaadin integrációt túrtam picit, hogy pontosan mit is, és hogyan implementált a srác, ott azért kellett 1-2 órát nézni.
Ha szereted a kotlint, erre nézz rá: https://github.com/mvysny/karibu-dsl
en hasznaltam meg anno vaadin7-est elesben (bar csak 'belso' toolingra). Ket dolog volt, ami nem trivialis:
- vaadin-hoz sajat microservice-t csinal, security es stabilitas miatt; ugye senki se akarja egy UI-al bloat-olni a microservice-t, meg annak minden security bugjat behozni egy rest api-ba.
- a vaadin, legalabbis a 7-es, kulon-kulon tartja a client es a server state-t. Tapasztalatbol mondom, a backend developerek gyomra ezt nem veszi be, eredmenye pocsek UI, amikor pl. egy parezer elemu listat/tablazatot akarsz csinalni. Mert ott mar figyelni kell, hogy mi van meg szerveroldalon, es csak azt kuldje le kliensoldalra, ami lathato, ne mindet. Illetve, az, hogy valamit modositott a user a kliens oldalon, default-bol vagy propagalodik szerver oldalra, vagy nem, ennek minden komponens eseten utana kell nezni, mert aztan jon az, hogy abuzalnak barmit, aminek a mellekhatasa a propagacio szerver<->kliens kozott, aztan olyan gany fos kodot tudnak csinalni benne, hogy azt mar az uristen se tartja karban.
tl;dr: jo a vaadin, de ahogy it-ban mindent, erteni kell hozza, kulonben csak koklerkedes es ganyolas lesz belole.
Mostanában dolgoztam Vaadinnal. Végül is meg lehet ezzel is csinálni mindent. Volt néhány zavaró dolog. Ezeket is meg lehet szokni.
Viszont volt olyan is amivel szívtam néhány órát, mert uBlock megfogott időnként valamit belőle és időnként nem működött.
De valóban. Ha már kicsit is értesz JS-hez lehet jobb ha keresel mást.
Használhatsz designert (előfizetéses), de azzal jellemzően színes szagos, de nem túl bonyolult felületeket lehet összerakni gyorsan.
Vagy elkezdheted a komponenseket Java-ból megszólítani, amivel nagyot fogsz szívni, viszont eléred azon funkciókat is, amiket a desgner-es template rendszer nem fog biztosítani.
Sajnos a berántott JS-es környezet nagyon sűrűn változik, állandó küzdelem a kód naprakészen tartása. Legalábbis mi ebbe futunk bele elég sokszor.
Én biztos hogy nem Vaadinoznék, fentebb már jól leírták miért.
Inkább React vagy Angular vagy Vue vagy bármi valódi frontend eszköz. Ahhoz választasz egy komponens-készletet (mondjuk material design ui vagy fluent vagy bármi és akkor a ux designered azon készleten belül gondolkozhat.
Igazából kéne egy frontendes a csapatba de alap ui-t egy backendes is összekalapál szerintem.
Gábriel Ákos
Ha java-ban akarsz dolgozni, akkor még esetleg a SmartGWT-t is meg lehet nézni, mi sok sok évvel ezelőtt abban fejlesztettünk klasszikus desktop jellegű webes appot,
teljesen jól működött. A REST api-t megírtuk, a kliens kiegészítése baromi gyors volt, egy képernyőt pár nap alatt tudtunk e2e szállítani. Van LGPL verziója, hogy hogyan
néz ki, azt itt meg tudod lesni:
https://smartclient.com/smartgwt/showcase/
A 23/24-es Vaadin teljesen jól használható. Főleg a Spring Boot-os környezetre van kihegyezve, fullosan be lehet építeni még a View/Component osztályokat is, mint menedzselt cuccok. Szóval, kb. 1 év fejlesztés után én csak ajánlani tudom. Nyilván nem többszázezres weboldalakat kell benne csinálni, főleg max. párszázas felhasználói bázis a célközönség. Arra viszont szerintem kifogástalan.
A negatív hangvételű hozzászólásokból nekem az derül ki, hogy régen használtak a kollégák Vaadint, amikor még a felvetett problémák valósak voltak. A 7/8-as Vaadin óta azért komoly javulások következtek be...
GO GUNNERS!
Teljesen jó, ha inkább java-val foglalkoznál mint js hellel. Webes security jön oob elfogadható szinten.
Ha testre kell szabni a kinézetét, akkor ugyanakkora szívás/tanulás lesz, mint akármi más.
Session-ok eszik a memóriát backend oldalon, de ez nem téma ~10e userig.
Felgyorsult (ennek is) a kiadási ciklusa - gyakran kell verziót váltani, ami ha kifizetik jó.
Hogyan kezeli a Vaadin, ha a kliens átmenetileg leszakad? Tud újracsatlakozni és működni tovább? Például a mobil böngészők pillanatok alatt bontják a WebSocket kapcsolatokat (amint elsötétül a képernyő).
Csináltam egy szerver oldali webes "frameworkot", ami működési elvében hasonló lehet, és ezt a problémát nem tudtam jól megoldani. A böngésző elsötétítés kikapcsolására is olyan workaround van csak, hogy egy 1 pixeles videót kell indítani a háttérben.
(Táblás játékot csináltam meg onlinera, annyira minimalista kivitelezéssel, hogy csak a barátaimnak mutattam meg.)
A nap végén a vaadin mögött is csak html/css/js van.
itt kipróbálhatod: https://labs.vaadin.com/business/
én használok vaadinos saját appot mobilon is - nem egy leányálom, de nem is lehetetlen.
Elég hamar észreveszi ha elveszti a gazdáját, mert van heartbeat (lehet hangolni valamennyire), aztán próbálkozik. :)
Websocket-et szerintem nem használ.
Igen, a websocketet visszaszívom, megnéztem én is a network logot. Sima queryket küld minden interakcióra. Érdekes módon úgy láttam long poll sincsen, tehát a szerver nem is tud azonnal üzenni. Az is lehet, hogy ez beállítás kérdése.
Ha jól értem ez is úgy működik, hogy a szerver tárolja a kliens állapotát, tehát addig van esélye az oldalnak újraszinkronizálni, ameddig a szerver nem timeouttolta az objektumot? Utána csak refresh-hel tehető újra működővé?
(Kipróbáltam, de ezek a lényeges részletek nem derülnek olyan egyszerűen ki.)
igen, lásd: https://vaadin.com/docs/latest/advanced/server-push
https://vaadin.com/docs/latest/advanced/application-lifecycle#applicati…
Meg kellett néznem, 3 heartbeat ideje van ill a session exp. :)
Ezek szerint ez alap konfiggal például mobilon 15 perc pihenő után eldobja az oldalt. Desktopon ha a böngészőt nem zárjuk, akkor tudtommal mennek a timeout-ok a háttérben lévő lapokon is, az fenn tudja tartani a szerver oldali replikát.
A böngészőkben egyébként el lehet kapni a bezárás eseményt és egy utolsó jelzés küldésére is alkalmas ez a tapasztalataim szerint (Firefoxot, Chromiumot próbáltam ha jól emlékszem), Tehát ha rendesen lezárja a user az ablakot, akkor lehet küldeni üzit, amire reagálva a szerver is eldobja azonnal a tárolt példányt. De ha a mobil elsötétül, vagy ha elszáll az oldal desktopon, akkor arról nem kapunk eseményt, csak timeouttal lehet "felismerni".
Én arra akartam lőni, hogy ha valaki este suspendeli a gépét és reggel újra kinyitja, akkor működjön tovább a weboldal: ezt csak úgy lehet elérni, hogy a timeout több mint a suspend ideje.
A saját állapotmentés-visszaállítás lehet megoldás, ha nem túl sok helyen és nem bonyolult dolgot kell letenni és visszaállítani. (Helló mobilappok.)
Lehetne olyan session store-t is behegeszteni, ami elteszi az idle timeout előtt valami tartósabb tárba az állapotot, meg biztos vissza is lehetne állítani - nem biztos hogy mindig működőképesre -, de ezek olyan "varázslások", amik nem nagyon érik meg az időt energiát szerintem. A (tulajdonképpen) cache építéssel amúgy is jön egy csomó más probléma (verziókülönbségek, karbantartás, tárhely, érvénytelenítés). :)
Mondjuk én személy szerint hidegrángást kapok azoktól az oldaltól, ahol az URL-en (és az esetleges cookie-ban a sessionID-n kívül) mégtöbb helyen van valami állapot tárolva. Legyen szépen az URL olyan, amit el tudok küldeni bárkinek, s megfelelő jogok mellett majdnem ugyanazt látja, mint én. Pl.: https://hup.hu/comment/reply/node/180766/comment_forum/3048507
Nyilván 1-2 megnyitott modal ablak, vagy éppen egy szerkesztés alatt lévő rekord ebben nem lesz benne -> de azokat max újrakezdem, s egyébként se tárolja egy ~ui-sessionben a szerver / böngésző. Ha hosszú, legyenek a folyamatban köztes állapotok mentve, én meg tudjam bezárni a tabot/böngészőt, újraindítani a gépet, stb.
ember nincs aki ennek a tesztjét megfizesse
Gábriel Ákos
https://javadoc.io/static/com.vaadin/vaadin-platform-javadoc/24.0.0/com…
be tudod állítani, hogy legyen ws, működik is faszán.
Ha semmiképp sem szeretnél JS-t / TS(Typescript)-t tanulni, és megérteni a weboldalak működését, akkor megfelelő lehet. Kicsit olyan Vaadinban UI-t fejleszteni, mint JS-ben JVM back-endet fejleszteni.
Minél távolabb vagy a browser API + VM-től, annál nehezebb komplex feladatokat megoldani. Az alapok megtanulása nélkül (browser API, HTML, CSS) nehezen tudom elképzelni minőségi és könnyen karbantartható termék létrehozását. Prototipizálásra viszont teljesen megfelelhet egy ilyen tool.
Ami szempont lehet, hogy a szakmai tudás és szemlélet is bővül az UI alapok megtanulásával. Pl. egy UI fejlesztővel könnyebb kommunikáció, vagy akár más architekturális döntések meghozása Java-ban.
Szubjetkív preferenciám, hogy egyszerű alkalmazáshoz Typescript + React + Material UI + esetleg Redux elég. A FLUX megértése, alkalmazása - szerintem - érdekes és tanulságos.
Egyébként akár megpróbálhatod chatgpt-ben kigeneráltatni ugyanazt Vaadinnel és más Java-s vagy TS frameworkkel. Utána jobban meg tudod majd ítélni, hogy melyik szimpi.
Szerintem nagyon célterméktől függ. Ha egy általános X management szoftverről beszélünk (X alatt értem a raktár, könyv, helikopter, stb.) akkor simán lehet, hogy sokkal gyorsabban tudnak egy hasonló megoldással haladni, mintha párhuzamosan 2 nyelven kellene dolgozni. Egy játszós projektemben éppen egy Quarkus / Vue kombinációt használok, és azért nem előnyös, hogy 2 nyelv között kell oda-vissza ugrálnom, lehet, hogy amire nekem kell, arra egy Vaadin egyébként pont jobb lett volna.
Senki? Ön HIV Vaadin!
A Diktátor című film?