Tworzenie single-page aplikacji bezpośrednio w Javie

5

Zapraszam do zapoznania się z experementalnym projektem opartym na technologii Server-Side Rendering.
https://github.com/vadimv/rsp
Project umozliwia tworzenie applikacij webowych w czystej Javie i w pewnym stopniu pozwala mieć mozliwosci, które normalne potrzebują uzywania client-side JavaScript frameworków.

1

O! To jest coś. Nie odpalałem, ale:

  • dość ciekawy pomysł,
  • całkiem ładny kod,
  • spoko dokumentacja,

Małe uwagi:

  • można by wywalić examples do osobnego/osobnych projektów,
  • rozumiem własny Either i Tuple2 (taki język, niestetety), ale daj temu Either jakiś prywatny konstruktor, czy coś - coby nie można było tworzyć innych klas niż Left i Right (taka ultrapoprawność),

Samo podejście ma oczywiście wiele ograniczeń, ale IMO, jest i tak lepsze w założeniach od niektórych popularnych jawowych frameworków.

0

@jarekr000000 Dziękuję za pozytywną ocenę i uwagi.

1

Jak mam w teamie frontendowca który ogarnia kwestie RWD, cssy, jsy to będzie umiał używać tego frameworka? Inaczej, dla kogo jest to narzędzie?

4

@Charles_Ray: są ludzie, którzy są w stanie zapłacić każdą ilością RAMu i czasem pracy byle tylko nie pisać w niczym innym niż w javie. Takie życie. Wśród takich ludzi jest jakiś nawet procent ogarniający CSS, HTML itd.
Do tej pory dla takich programistów było dostępne JSF, Gwt, Vaadin czy inne dramaty (gdzie najnowszy vaadin IMO ma jakieś elementy bycia uzytecznym).
To jest dla całkiem niezła alternatywa (albo solidny zalążek alternatywy).

Frontendowiec z doświadczeniem w React będzie w stanie kod zrozumieć IMO, ale raczej nie będzie mógł pracować ze względu na absurdalną kiepskość narzędzi javowych (podobnie jest np. w Vaadin). Np. rebuild projektu i restart servera, żeby zobaczyć przesunięcie przycisku o 2 pixele w lewo to zwykle jest za dużo na nerwy człowieka przyzwyczajonego do czegoś innego niż java. (Aczkolwiek ten aspekt jest trochę możliwy do optymalizacji).

Ale jak pisałem wyżej - javowcy z krwi i kości powinni być raczej zachwyceni.

4

Pomysł ciekawy, ale jestem na nie. I nie chcę być źle zrozumiany, ale kiedyś już coś podobnego budowałem. Autorem był Jacek Olczak, nazywało się to egg framework, a ilość problemów była zacna. Server side rendering, w którym ręcznie wyklepujesz strukturę HTML-a jest co najmniej upiorny.

3

Czesc!
Przez ostatni czas dodałem do projektu:

  • możliwość tworzenia “odłączanych” web stron
  • API do eventów stworzenia i zamknięcia stron
  • nowe treści do dokumentacji w README

Dla sprawdzenia podejścia server-state web pod kątem wydajności zdecydowałem użyć automatu komórkowego czyli Gry w życie Conwaya.

W trakcie testu jednoczesne odpaliłem 50 zakładek przeglądarki z działającymi w czasie rzeczywistym egzemplarzami gry na planszach 50x100, każdy generuje 5 nowych pokoleń na sekundę.

Odnotowano, że UI gry nadal działa dość zwinne.

Na laptopie z i5 CPU process serwera zużywa:

  • okolo 2.5G heap RAM
  • okolo 70% CPU

Resultat testu zaliczam za pozytywny.
Także jestem pod wrażeniem, jak dobrze działa GC potrzebując tylko około 1% zasobów CPU.

game_of_life_monitor.png

Link do kodu gry: https://github.com/vadimv/rsp-game-of-life

1
jarekr000000 napisał(a):

@Charles_Ray: są ludzie, którzy są w stanie zapłacić każdą ilością RAMu i czasem pracy byle tylko nie pisać w niczym innym niż w javie. Takie życie. Wśród takich ludzi jest jakiś nawet procent ogarniający CSS, HTML itd.

Do tej pory dla takich programistów było dostępne JSF, Gwt, Vaadin czy inne dramaty (gdzie najnowszy vaadin IMO ma jakieś elementy bycia uzytecznym).
To jest dla całkiem niezła alternatywa (albo solidny zalążek alternatywy).

Apache Wicket, to brakuje na Twojej liście

Taki vaaadin ale serwero-centryczny, albo JSF done rgiht
Jak dla mnie punkt podziału "obiekty programistyczne" / "wizualny HTML" ma w stosunku do JSF zrobiony milion razy lepiej (tam to w ogóle nie jest HTML) i to się naprawdę dobrze prowadzi backowi przyuczonemu do CSS, albo można dać frontowcowi po 15min wprowadzenia

Co do RAM: nie zawsze piszemy przeglądarkę pogody dla 10mln oglądających, czasem aplikację statefull dla kilkudziesieciu

0

Nowa wersja 0.6: https://github.com/vadimv/rsp

  • nowy Routing API
  • odnowioną dokumentację
2

Wersja 1.0 zawiera:

  • nowe komponenty ze wsparciem stanu
  • nowy API zarządzania stanem
  • wsparcie odtwarzania aktualnego stanu w pasku adresu przeglądarki i odwrotnie

Gra w przeglądarce jako przykład SPA na Javie:
screenshot-20230715104503.png

1

Pomysł niezły, wygląda spoko.

PS: Aczkolwiek testy w tym są względnie niskiej jakości, także tutaj u mnie minus.

1
jarekr000000 napisał(a):

Ale jak pisałem wyżej - javowcy z krwi i kości powinni być raczej zachwyceni.

Ja jestem zachwycony :D

2

O ile zawsze życzliwie się zainteresuję każdym nowym / nowoczesnym / współczesnym frameworkiem / biblioteką serverside, to na buildery do HTML-a jednak nie, choć próbowałem sam siebie przekonać :)
a) i tak javowiec nie ucieknie od wiedzy HTML-owej
b) ale nie wklei sprawdzonego fragmentu HTML-a do / z edytora htmlowego / tutorialu CSS od Meyesra
c) usztywnia do jakiejś wersji HTML-a i blokuje przed customowymi komponentami HTML 5

To już było, była w Apache taka libka, dawno jest "attic". Gdzieś koło 2000 mnie w próbach na krotko skusiła gwarancja "mieć zawsze domknięte tagi" *) To były czasy znacznej słabosci edytorów HTML, kusiło mieć "hardwarowe" wspomaganie, ale ilość wad przewyższyła wielokrotnie jedną zaletę

Pozwólcie, że dla mnie optimum separacji kod / html jest Wicket. HTML jest w zasadzie normalnym HTML (jeden atrybut więcej), który każdy webmaster ogarnie **). A skoro już przyjęliśmy a), że javowiec ma podstawy HTML-a ...
Czysto, ładnie, wiadomo gdzie co jest - i gdzie czego NIE MA.

Intensywna interakcja np Ajaxowa server - front dla mnie mentalnie nie robi problemu. W Twoim projekcie to (z dużym marginesem) jest zrobione podobnie, zdarzenia DOM jak nazywasz są okodowane po server-side. Dobry poziom dokumentacji a już bardzo dobry jak na projekt od singla.
W Wickecie nie ma wątpliwości gdzie jest stan, ani gdzie jest kod - wiadomo gdzie. Dla mnie Twoje zasady eventów DOM są przystępne.

*) ponieważ miliony much musza mieć rację, wiecie że w którymś nowszym HTML przyklepano niezamykanie kilku tagów? Horror. Złożoność parsera fiuuuu leci w stratosferę.
**) nawet jest określone, jak zamieścić w HTML np gotowe trzy przykładowe wiersze grida, nieskuteczne na produkcji, aby wembaster mógł optymalizować źródłowy HTML

1 użytkowników online, w tym zalogowanych: 0, gości: 1