Varför inte göra allt i Vaadin(Java) istället för HTML+JS+PHP+CSS+SQL?

Så fort du behöver göra något som inte finns som färdiga UI-komponenter så kommer du behöva knacka HTML, JavaScript, och CSS oavsett, men då som "komponenter" inom ditt ramverk. Samma sak om du behöver göra SQL-frågor som inte går att uttrycka enligt ditt ramverk, eller kanske att du behöver integera med en befintlig databas på ett specifikt sätt.

Men ja, det finns ju ett antal olika ramverk man kan använda för att göra sitt jobb enklare, och om de gör ditt jobb enklare så bör du så klart använda dem. Just Vaadin har jag ingen åsikt om.

Sedan är det ju inte direkt så att alternativet till Java och Vaadin är PHP med manuellt knackad HTML/JS/CSS heller, det finns många andra språk och ramverk också.

Där har du svaret på din fråga. Du inser själv att det inte går att göra allt i Vaadin, därför måste man också använda andra tekniker.

Visst ditt hobbyprojekt laddar om så fort. Men när man börjar komma upp till enterprise-storlek på sina projekt så tar det längre. Vi provade göra en del av siten med Vaadin förut (för "alla utvecklare kan ju java redan"). Bara en liten del med ett par tio tusen rader kod. Varje refresh tog 2min+ att ladda om. Gav upp den idén på ett par veckor och gick tillbaks till beprövade frontend verktyg.

Låter som valfritt ramverk inom t.ex. Php/C#/Javascript, med skillnaden att det skrivs i Java istället?

Php har Laravel
C# har Blazor
Javascript har... massvis, t.ex. VueJS, Angular, React, you name it.

Vaadin verkar ju vara snarlikt Laravel ändå, där du skapar templates för hur komponenter ser ut, för att sedan bara placera ut dessa. Skillnaden tycks vara att Vaadin då skrivs i Java som inte riktigt anses vara ett "Webb-språk" jämfört med PHP som .. well, i princip samtliga webbutvecklare känner till Lite omständigt att byta språk när motsvarigheten finns i det befintliga.

Sen kan jag själv tycka att ett framework kan vara det bästa som uppfunnits när jag väl upptäcker det... tills ett problem uppstår och man börjar inse att dokumentationen kanske inte riktigt är där än Jämför Vaadins Stackoverflow med PHP/Javascript/HTML så ser du kanske vad jag menar?
Antal frågor under en viss tag i SO brukar vara en bra indikation på hur populärt ett språk/framework är
https://stackoverflow.com/questions/tagged/vaadin - 5 147 frågor totalt
https://stackoverflow.com/questions/tagged/laravel - 158 381 frågor totalt
https://stackoverflow.com/questions/tagged/vue.js - 65 874 frågor totalt
https://stackoverflow.com/questions/tagged/reactjs - 252 652 frågor totalt
https://stackoverflow.com/questions/tagged/angular - 233 936 frågor totalt
(Blazor var inte alls så populärt som jag trodde.. Asp.net/Asp.net core är mycket populärare för C#)

"Varför gör inte alla bara allt i [infoga favoritramverk/favoritspråk]?" är en fråga som man kan slåss om i alla tider.

Lite som att bråka om religion i många fall. Alla har sin uppfattning om hur projekt och arkitektur ska läggas upp, och då väljer man det som passar bäst för det ändamålet.

Varför inte bara köpa möbler från Ikea? Det finns en stor uppsjö av möbelkomponenter och kombinationer som gör att man kan möblera typ vilket hem eller kontor som helst, utan att behöva plocka fram typ såg, hammare, skruvmejsel, målarpensel, limpistol, etc, eller för den sakens skull behöva garva sitt eget läder.

Ikea är allt som behövs, kasta alla verktygen i sjön bara.

"If all you have is a hammer, everything looks like a nail"
Du har måhända den bästa ringnyckeln, men hur mycket hjälp har du av den när du behöver såga till något?

Det finns en rätt stor fara vid att låsa fast sig vid ett specifikt verktyg (ramverk i detta fall) då det inte finns någon garanti för att det ramverket kommer att överleva på sikt. Då står du där med en värdelös kodbas som behöver skrivas om från grunden i något annat språk/ramverk.

Webben bygger på HTML, CSS, och till stor del JavaScript och ju närmare källan du håller dig desto enklare är det att vara flexibel för förändringar (och om det är något vi vet är det att webben är väldigt förändringsbenägen).

React, som du nämner, är ett JavaScript-bibliotek vars stora "selling-point" är att det är effektivt när det kommer till att spara in resurser. T.ex. kan React se att en uppdaterad variabel (state) endast kräver att en pytteliten del av sidan behöver renderas om och ser därför till att sådant är fallet. Tidigare hade denna lilla ändring krävt att hela DOM-trädet behövts ritas om.

Sedan handlar det självklart om kunskap. Jag som främst jobbat med back-end (Java, C#, C++, etc.) har inget öga för design och lämnar därmed hellre över den biten till mer kunniga personer. Dessa personer har ofta vigt hela sitt yrkesliv till att lära sig tidigare nämnda utvecklingsstack och då finns ingen anledning för dom att lära sig Java som till 99 % bara används till utveckling i back-end.

Dessutom kommer det naturligt att bli ett glapp när webben utvecklas fram tills det att ramverk som Vaadin kommer ikapp och kan erbjuda samma funktionalitet.

Om man jobbar som ensam utvecklare, inte behöver ligga i framkant gällande nya tekniker och redan kan Java finns det självfallet en viss poäng med att istället använda Vaadin. Men det finns ju å andra sidan en viss tjusning med att lära sig nya språk och tekniker också, om inte annat bara för att få lite annat perspektiv på saker och ting. Kanske upptäcker du att språk X faktiskt erbjuder vissa funktioner som inte finns i språk Y och som är bättre lämpade till att lösa just ditt problem.

Att välja programmeringsspråk och plattform har extremt många fler och avsevärt viktigare aspekter. För enligt ditt resonemang så är assembly det bästa programmeringsspråket då där kan man faktiskt göra allt. Resultatet lär bli förjävligt att förvalta, tag otroligt lång tid att utveckla och ha en extremt hög andel av buggar. Men du kan ju faktiskt göra ALLT (om vi ignorerar eventuell ISA kompatibilitet, så även där kan man faktiskt inte göra "allt") så enligt det resonemanget så måste ju assembly vara det bästa programmeringsspråket för alla?

Sedan så håller ju inte ditt egna påstående då även med Vaadin så behöver man ofta kunna använda Javascript, HTML och CSS. Javascript för att kunna få åtkomst till tredjeparts bibliotek som kan vara kritiska. HTML för att skapa nya komponenter. CSS för att applicera styling.

Hur bra någonting är baseras inte på hur mycket det kan göra. Det baseras på hur bra det är på att göra det du vill göra. Är verkligen din ringnyckel den bästa för att den hanterar alla om det inkluderar följande.

Ringnyckeln hade ju varit så tung att den är helt obrukbar och tagit upp hela ditt hem. Har du något behov av att kunna arbeta med sådana muttrar? Hjälper det dig när du ska använda ringnyckeln?

Python och java kan man verkligen inte göra allt i. Väldigt sällan ett python projekt faktiskt är rent python utan oftast kopplar man in native dependencies från typ C/C++. Python presterar alldeles för dåligt för att köra ren python, primärt pga dess totala avsaknad av trådar. Det är totala motsattsen som är anledningen till att python är populärt. Det är just för att man inte kan göra allt, som exempelvis tråda eller manuellt minneshantera, det är så enkelt och har blivit populärt. Samma sak med Java, det kan göra mycket mindre än det som man hade i avsikt att plocka utvecklare ifrån, C/C++, men det är mycket enklare tack vare det.

Du kan säkert uppfylla dina projekts behov med Vaadin, gött om du gillar det och inget fel med det. Men det betyder bara att det är fallet för behoven i dina projekt, inte andras projekt. Skulle personligen vara lite skeptisk till att använda Vaadin för ett större långlivat projekt av flera skäl, och det är bara vad jag har sett baserat på vad jag skumläste på deras webbsida.

• Applikationslagret blir stateful. Verkar gå att arbeta bort genom att bryta ut HTTP sessionen, men även det har problem med exempelvis skalbarhet och HA.

• Du bygger ihop frontend och backend.

• Finner det osannolikt att OpenAPI kommer följas.

• Cache-Control lär inte fungera för client logik då det ligger i backend.

• Du behöver köra JVM.

• SEO är svårlöst.

• Färre informationsresurser.

• Högre risk att plattformen dör.

... och mycket mer.

Allt det ovan, precis som Vaadins fördelar, är bara av konsekvens om det spelar roll för projektet i fråga. Så i dina projekt kanske det inte spelar någon roll, men många av dem hade varit deal-breakers för exempelvis projektet jag jobbar med. All teknik har för och nackdelar, det viktiga vid beslut av vad man bör använda är att väga mellan de och inte blint tro att alla frågor har samma svar.

Om det i dina projekt är viktigare med lägre komplexitet gentemot fördelarna dem ger så är det en övervägning du klart kan tag. Men som jag upprepat flera gånger så är det olika beslut för varje projekt.

Mer personliga åsikter då.
Av de programmeringsspråk du nämnt så avskyr jag, ur ett rent språk perspektiv, PHP & Javascript. Betyder inte att det inte är rätt val i vissa fall. Men som programmeringsspråk är de så sjukt dåliga. Dåliga nog att man behöver bra skäl för att jag ska godkänna de för ett projekt. Än mindre sannolikt att man finner mig arbetande med de språken en längre period då jag troligen lär sluta, stor del av skälet till att jag nästan aldrig arbetar med web frontend. Så skriver inte det jag gör ovan för att jag älskar javascript, html och css precis. Java är inte horribelt, bara dåligt. Vill man köra JVM finns massor bättre ersättare som Kotlin, Scala & Clojure. Även då kan fortfarande java vara rätt svar.

PHP har hundratals legitima alternativ, ovanligt att ett populärt språk inte kan användas som ersättare.
Javascript har inte lika många alternativ då det har varit tills alldeles nyligen (prisa WASM) det enda native webbläsare stödjer. Men även innan dess fanns det gott om saker som transpilerar till javascript.
Exempel:

• WASM, lite knapert med ramverk bara.

• Elm

• Typescript

• Dart

• Thin client med runtime transpilering (Vaadin bor här)

och många fler.

Skillnad på om man ska göra en hemsida eller en skalbar applikation i form av microservice arkitektur. Ta Spotify som exempel, där har de till och med microfrontends där i princip varje api har ett eget GUI som t.ex. Playlisten är en egen frontend med backend med ett team som sköter allt gällande playlisten. Sen sätts allt ihop till ett gränssnitt med flera små beståndsdelar, vilket ger enkla möjligheter att byta ut vissa delar mot nya utan eller släppa nya features till t.ex. playlisten utan att hela applikationen berörs.
Skulle allt detta vara en gigantisk monolit där du måste deploya hela Spotify applikationen när du släpper en ny version, skulle det innebära att man gör en release max en gång i månaden istället för flera små om dagen/veckan.

Angular, React och Vue används inte till hemsidor utan de används oftast för applikationer där det är krav på separation av frontend och backend, ofta för man har flera olika teams som arbetar i projektet och behöver kunna deploya saker fritt från varandra.
Sedan också för att SPA generellt är mycket mer användarvänligt i en applikation som har mycket användarinteraktion. En hemsida som en blog sitter du bara och läser text, så där är det helt oväsentligt med ett frontend ramverk.

Tänk dig att surfa på reddit och varje gång du klickar på en kommentar så laddar hela sidan om för att hämta den. Gör du inte detta med ett SPA så får du en jäkla massa spaghetti JavaScript. Ett SPA underlättar att hålla någon struktur i din kodbas då du kan skapa små komponenter och återanvända, vilket är mycket svårare i vanilla JS eller med jQuery.