Stos technologii dla małego systemu

Witajcie,
Jak już wspominałem, przyjąłem zlecenie na napisanie małego systemu do zarządzania małą, rodzinną firmą.

Zastanawiam się teraz w jakich technologiach zrealizować ten projekt, żeby działał dobrze i żebym się nie wpierdzielił w jakieś javascripty zbyt głęboko.

Czy lepiej zrobić REST API + Client czy monolityczna aplikacja MVC ?

Zastanawiam się czy API RESTOWE faktycznie jest potrzebne, czy raczej dla takiej aplikacji będzie to przekombinowanie. Jednak mam już wprawę w pisaniu takich API i w ten sposób mogę bardzo wyraźnie oddzielić backend od frontendu.

Opcje:

1. Spring MVC + Thymeleaf : szybki development, wygląd jest drugorzędny, mała elastyczność aplikacji
2. Springowe REST API + Client Angular/Vue/React, opcja fajna, z tym, że mam tylko podstawy HTML, CSS i JS zatem będę musiał się uczyć i lecieć metodą prób i błędów.
3. REST API + Client na desktopie (JavaFX albo pyQT pierwsze znam bardzo dobrze, drugie daję radę)
4. Czy może spróbować Vaadina? Chwalą się, że można klepać frontend nie znając frontendowych technologii.

Co sądzicie o tym?

Ja jako wielbiciel Reacta, wybrałbym opcję numer 2, jakiej wielkości jest to aplikacja? 5MD czy raczej 20MD?
Jeżeli jest to coś prostego do zrobienia i nie chcesz uczyć się JS, to wybierz opcję 1 - chociaż na twoim miejscu nauczyłbym się JS, naprawdę bardzo fajny język i ma chyba obecnie największe community.

@Aleksander Brzozowski: uczę się trochę tego JS, ale to powoli. Myślałem nad doborem drugiego języka i wahałem się między pythonem, a właśnie JS.
Chyba tak zrobię, bo JS na rynku jest pożądany zatem czasu nie stracę.

Myślisz, że długo mi zajmie, żeby się ogarnać trochę w Reactie?
CSS nie lubię, trochę umiem, HTML wiadomo jest prosty wielkich rzeczy tam nie ma, a JS no to jestem na etapie przerabiania książki. Z tym, że jestem Javowcem i programować umiem.

Jak znasz Javę to stanowczo odradzam JS'a. Proponowałbym Ci Angulara 6+, TS'a i cały ten framework jest dosyć podobny do Javy i Springa.

NeutrinoSpinZero napisał(a):

4. Czy może spróbować Vaadina? Chwalą się, że można klepać frontend nie znając frontendowych technologii.

Prawda. Choć mi w tym segmencie bliższy jest Apache Wicket. Inny w mojej opinii do "biznesówek' to JSF zwłaszcza dodając Primefaces.

Nie można być dobrym jednocześnie we froncie i backu, te technologie pozwalają wykonać dość znaczną aplikację dla "średniego biznesu" i nakłaniają do jakiej-takiej architektury. (Tu skrót MVC nie zawsze pasuje, np chłopaki z Vaadina mówią że jest najbliższy wzorcowi MVVC)

Jak rozumiem pytanie "mała aplikacja" to nigdy nie będzie hordy identycznych mikroserwisów uruchamianych i gaszonych w cloudzie. Modny podział na REST + Front traci jeden z głównych argumentów. Po drugie mała aplikacja biznesowa nie musi rzucać na kolana animacjami okien, "reaktywnością" itd...

Rzeczony Wicket ma type-safe konstrukcje i to się dobrze konserwuje.

Monolity naprawdę nie są złą babą jagą, którą się straszy dzieci.

Aha, sam sobie odpowiedz czy chcesz się przyłączyć do religii Single Page Application, czy zostaniesz przy klasyce.

Jak znasz Javę to stanowczo odradzam JS'a. Proponowałbym Ci (...) TS'a

TS to i tak tylko nakładka na JS i trzeba de facto poznać JavaScript, żeby napisać cokolwiek w TypeScript.

Szczególnie, jak ktoś ma background w Javie czy w C# (to trochę niepokojący trend, że ludzie, którzy przychodzą z tych języków myślą, że mogą "pójść na skróty" i wskakują od razu w TypeScript, a potem i tak się rozpieprzają na banalnych rzeczach typu let vs const albo jak działa this. Na dodatek TypeScript z definicji jest trudniejszy od JavaScript, więc nie dość, że mają problem z rzeczami z JSa, to jeszcze muszą się uczyć rzeczy z TSa).

A rzekome podobieństwo TypeScriptu do Javy to trochę pułapka.

Nie mówię, żeby nie używać TS, tylko raczej, że od JS się nie ucieknie za pomocą TypeScripta i warto mieć właściwy kontekst. A kontekst jest taki, że TypeScript to po prostu typowany nadzbiór JavaScriptu, a nie całkowicie odrębny język.

@CountZero: tak też myślałem, bo developerzy u mnie w pracy też klepią w Angularze. Tyle, że TS nie daje możliwości działania na znacznikach w czystym HTMLu bez frameworka.
Chyba zostanę przy Angularze, bo faktycznie mnie frontend przerasta w takim sensie, że ja nie chcę poświęcać swojego czasu na wygląd strony, bo to nie moja bajka. CSSy to dla mnie po prostu nuda :P

Myślisz, że szybko ogarnę tego Angulara? Samą koncepcję znam (struktura, komponenty, SPA itd.), bo trochę się interesowałem.

Wydaje mi się że na pewno szybciej niż jakbyś miał się uczyć frameworka opartego na js'ie, przynajmniej ja tak miałem. Chociaż przyznaje, że nie mam porównania do Reacta/Vue.js, jedyne w czym pisałem to tylko jeszcze w AngularzeJS.

Na przekór wszystkim wybrałbym opcje nr. 3. Sam robiłem JavaFX + REST API (SparkJava), w tym stosie i osobiście pracuje się mi przyjemnie. Poza tym nie wiem jak wygląda sytuacja w przypadku np. Angulara i obsługi urządzeń peryferyjnych jak np. skaner, drukarka. W przypadku wyboru JavyFX podpięcie bardziej "nieskopoziomych"/systemowych funkcji byłoby łatwiejsze o ile będzie taka potrzeba.