Milyen webes technológiát választanál ${current_year}-ban?

A kérdés kifejtve: zöldmezős web UI projekthez milyen technológiát választanál és miért? Bármilyen vélemény, tapasztalat, stb jöhet. Nem kell megijedni, ha esetleg flame vihar alakul.

Személy szerint a Java közeli dolgokat kedvelem leginkább, és nagyon nem szeretem a dinamikusan típusos nyelveket. Ezért a JavaScript leváltásán gondolkodom. A szokásos megközelítésem, hogy szerver oldalon fut a UI logika is, és a JS tényleg csak egy vékony megjelenítő réteget ad (mint például ebben a technológiában: https://vaadin.com/ ). A UI vanilla HTML "kézzel" írva, szerver oldali template-tel készül a letöltött változat, és azonosítók szerint JS-hez linkelve kapja a dinamizmust ha kell.

De elgondolkodtam rajta, hogy egy elkövetkező projekten szakítok ezzel a megközelítéssel, és heavyweight klienst írok, ami egy API-n kommunikál a szerverrel - ahogy az szokásos. De azért JS-ben nem programoznék, ott még nem tartunk :-). Vagy valamelyik típusos plusz réteget adó változatot választanám (pl. TypeScript és társai), vagy pedig Java-t interpretálnék a JS engine-en belül valamelyik transpiler megoldással. De az utóbbit még sosem csináltam, ezért kérdezem, hogy van-e valakinek tapasztalata ilyennel?

A szerver felől jövő eseményeket mindenképpen kezelni kell, erre a long polling-hoz képest van valami modernebb megoldás már?

Tehát alapvetően a kliens oldali programnyelv, keretrendszer és a szerverrel való kommunikáció módja (milyen fajta kapcsolat, lekérés HTTP,WebSocket stb és hogyan van kódolva az adatcsere(XML, JSON, Java szerializáció, kézzel tákolt, executable JS)) az amire kiváncsi vagyok.

Tudom, hogy manapság nem divatos a megközelítésem, ezért aztán a teljesen eltérő megközelítésekre is kiváncsi vagyok, illetve a durva kritikát is tűröm. \Flame ON, kezdődhet szócsata! Popcornt mindenki készítse be!

Hozzászólások

Szerkesztve: 2020. 06. 28., v - 23:36

Attól függ mihez. Realtime-nak becézett, de a lényeg, hogy relatíve sűrűn & gyorsan változó tartalmú alkalmazásról van szó? Mekkora adatmennyiséggel? Milyen jellegű adatokkal? Tök nyilvános amúgy is minden, csak egy n+1-ik lehetséges formában szeretném közreadni, vagy esetleg védeni is kell? stbstbstb. Minden ezeken a kérdéseken múlik amik újabb és újabb szűrőként megjelennek a tervezés során. Ha kifogytunk a kezdeti kérdésekre szánt időkeretből, vagy véletlen kifogytunk volna az értelmes kérdésekből és összeállna a shortlist még mindig lehet szűkíteni az amúgy rendszeresen egyetlen kiindulási alapként használatos finomító tényezőkkel:

 - milyen kész/előrágott elemek jöhetnek szóba, esetleg a kereket is fel kell ismét találni és meg kell írni minden komponensből egy sajátot..

 - mihez értenek a meglevő(?)/felvenni kívánt(piacon elérhető) emberek

 - milyen kimenő,bemenő,közbenső adatokkal & formátumokkal dolgozunk

 - pontosan milyen célcsoport(ok) fogják ezt az egészet használni?

Manapság  legritkábban végiggondolt: való egyáltalán a felhasználói kliens böngészőbe? Lehet, hogy az adott felhasználási területen sokkal kézenfekvőbb egy cli tool+ arra natív kliens gui.

stbstbstbstb

**

újraolvasva tényleg definiálni próbáltál valami, de: web UI projekt ez még mindig bármi is lehet :)

https://goo.gl/muWzKz (digitalocean)

 - milyen kész/előrágott elemek jöhetnek szóba?

Bármi ami royalty nélkül ingyen használható, azaz lényegében a szabad szoftveres megoldások.

 - mihez értenek a meglevő(?)/felvenni kívánt(piacon elérhető) emberek

Főleg Java, de ha nem óriási a távolság, akkor nem gond újat tanulni.

 - milyen kimenő,bemenő,közbenső adatokkal & formátumokkal dolgozunk

SQL DB, bináris formátumok, amikhez van Java library.

  - pontosan milyen célcsoport(ok) fogják ezt az egészet használni?

Mérnökök, de nem informatikusok.

 

Tetszik a gondolkodás, de az irányok végéről hiányoznak a konkrétumok, hogy akkor konkrétan mégis milyen technológia?

> Manapság  legritkábban végiggondolt: való egyáltalán a felhasználói kliens böngészőbe? Lehet, hogy az adott felhasználási területen sokkal kézenfekvőbb egy cli tool+ arra natív kliens gui.

Igen, ezzel egyetértek, de sajnos ez a kérdés a legtöbbször nem mérnöki szinten dől el, hanem egyszerűen ez az igény és kész...

Szerintem kb. a Webassembly-t irtad le.

Ém egy céges kis belső tool-t irtam próbaképp .Net Core + Blazor Webassembly (C#) felhasználásával, gyakorlatilag JS nélkül (azt hiszem kb 15 sor JS kód van az egészben).

Jól működik, cross platform, stb.

A Blazor nagyon jól ki van találva (legalábbis nekem kézre állt).

Ajánlom, hogy vess rá egy pillantást.

https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-now-avai…

Ha van idő kísérletezgetni, érdemes lehet megnézni a Rustot is. Gyors és biztonságos, cserébe (főleg eleinte) sokat kell vele küzdeni, hogy hajlandó legyen lefordulni a kódod.

Psszt, elárulom az IP-címemet: 192.168.0.14

Szerkesztve: 2020. 06. 29., h - 10:20

Ha egyedül csinálod és profeszionális dolgora kell, akkor azzal csináljad, amihez kb leginkább értesz - feltéve ha jó eséllyel alkalmas a stack a probléma megoldására.

Ha csapatban csinálod és professzionális dologra kell, akkor azzal, amihez leginkább ért a csapat (feltéve hogy kb alkalmas a választott stack rá). Így keresed a legtöbb pénzt alacsony kockázat mellett: Nincs/kevés idő a betanulás és nem fog agyvérzést kapni a többség/mindenki.

Ha hobbizol, akkor amihez kedved van. Az se baj, hogy sose készül el! :)

Személy szerint java/spring + angular (typescript) kombóval mennék. http, json ha meg kell push, akkor websocket.

 

Vaadin/GWT meg hasonlókkal van tapasztalatom (~1 év) de azt látom, hogy a frontend-backend elkezd összenőni és rövid időn belül olyan szinten kezelhetetlenné válik, hogy egy frontend csere utána már kb szinte az egész alkalmazás komplett újraírását jelenti (jelentette volna). A piacról se fogsz könnyen leakasztani olyat, aki ért hozzá ÉS akar is ezzel foglalkozni - nem túl értékes az a tudás, amit ez ad. Sajnálatos módon egy Indiába outsourceolt projekt visszavételét sikerült megnyernem, de a "helyi" erők is ugyanezeket a hibákat követték el folyton. Ettől függetlenül sem szimpatizálok ezzel a "fordítsunk Javaból JS-t" dologgal. Debuggolás, stb... $0.02

Spring backend + Angular vagy Spring backend + React -ot javasolnek, ehhez talalsz legelobb frontendest. A transpiler megoldasoknak az az elonyuk ami a hatranyuk is: nem JS-ben van irva, ha meghal, kisebb esellyel talalsz konyhakesz javitast/javitott valtozatot, rengeteg vele a szopas. Persze, ha profi JS-es vagy, es kened-vagod mi tortenik a bongeszoben, mi mire fog fordulni, akkor erre is vezethet az ut, de en nagyon nem javaslom.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-