The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

Questa è una preoccupazione legittima.

Using JSP's also seems like a less contemporary approach to front-end dev, in light of how many JS frameworks are popular. I'm imagining it'd be tougher to field a team of front-end or full-stack engineers if we build with JSP's.

Se scegli tecnologie adatte per il tuo compito specifico in settori quali facilità d'uso, manutenibilità, gestione sensibile della complessità, flessibilità e adeguatezza per i requisiti funzionali e non funzionali specifici della tua applicazione, troverai persone che sanno come per sviluppare e mantenere il software che li utilizza.

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon?

Se, e quando, ciò accade, sarà un buon problema, perché allora avrai i soldi per sistemarlo. Ogni grande azienda ha dovuto farlo; hanno costruito il loro prodotto su una piattaforma che li ha immessi sul mercato rapidamente e lo hanno ricostruito (in alcuni casi, da zero) quando il numero di utenti è diventato enorme.

Detto questo, penso che tu possa fare alcune scelte sensate presto. A meno che i tuoi requisiti di sistema richiedano architetture grandi e sovraccariche (non lo fanno), evitarli e scegliere tecnologie più agili e flessibili ti offriranno generalmente migliori prestazioni generali e una migliore adattabilità.

Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

No. Tuttavia, dai un'occhiata a questo articolo di Basecamp .

Our app will be marketed to clients who are unfamiliar with technology. I think it's reasonable to assume that such clients will be disproportionately likely to have out-of-date browsers. Old browsers may have compatibility issues with JavaScript rendering -- and ever worse issues with the most modern JS frameworks.

Non ci sono più scuse per questo. Se i tuoi clienti desiderano utilizzare i computer nel 21 ° secolo, hanno bisogno di un browser moderno, ed è più facile che mai averne uno e consentirne il mantenimento e l'aggiornamento automatico e indefinito.

After doing some research on these issues, I've got four strategies in mind...

La via del futuro sono i cosiddetti microservizi e l'interfaccia utente lato client come Angular. E no, non penso che sia solo una moda passeggera. Gli utenti richiedono elevata interattività con le loro applicazioni software e questo accordo può darglielo. I tuoi servizi web JSON back-end possono essere costruiti con qualsiasi cosa tu voglia; Node.JS, API Web ASP.NET, qualunque sia. Mantenere questo tipo di modularità renderà possibile cambiare un componente senza influenzare gli altri.

Sebbene la domanda possa essere risolta e tu abbia deciso di accettare questa risposta, voglio evidenziare l'argomento da un'altra parte.

1) JSP come sistema di template

Come linguaggio di template, penso che le JSP siano buone come le altre. Potresti scoprire che Thymeleaf si adatta meglio alle tue esigenze, ma questo è soggettivo. Le JSP sono una tecnica vecchia o meglio matura per ottenere contenuti per il cliente. In questo è paragonabile a ASP o addirittura a PHP.

Lo svantaggio principale di JSP come lingua è che è basato su XML e come tale ha un sacco di overhead visivo o rumore. In tal modo è paragonabile a Chameleon (un motore di template Python). Ciò rende a volte difficile da capire.

Un modo molto più semplice per farlo è, ad es. Pebble .

2) Rendering lato server

A partire dal 2016 il rendering serveride non è morto. Al contrario, se prendi Twitter come esempio:

The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our users’ machines rather than our own.

Naturalmente, ci sono strutture client-side come: React , Angolare o anche Vue.Js . Ma quello che hanno tutti in comune è che sono gonfiati . E sto dicendo questo no, perché non mi piacciono, ma voglio sottolineare, che usare un framework Javascript come Angular ha un costo, che potrebbe non essere realizzato a prima vista - i nostri desktop sono veloci e la nostra connessione è stabile e anche veloce - ma se guardi il cellulare, l'intera immagine cambia.

Ci sono principalmente tre costi sui dispositivi mobili:

1) Rendering

2) Esecuzione

3) Scarico della batteria

Sbarazzarsi in una di queste categorie, ti fa perdere clienti. Eseguire più di questi è ancora peggio.

Quindi ci sono tre modi per risolvere questo problema:

1) Iniziare molto velocemente

2) Crea meno chiamate dopo che la pagina è stata inizialmente caricata come necessario

3) Riduci la fantasia senza rinunciare a un design accattivante

Questo è il punto in cui il rendering lato server viene ( di nuovo ) in gioco. Per ottenere la pagina inizialmente attiva e funzionante, è necessario fornire il maggior numero di informazioni (è necessario) al primo caricamento della pagina. Chi ha detto che il tuo server ha bisogno solo di rendere il tuo HTML? È possibile eseguire il rendering di una porzione di avvio di JS sulla pagina con un tag di script. Ovviamente ci è stato detto, anni fa, di separare Javascript nei propri file, ma, a causa delle prestazioni, devi sfocare un po 'le linee.

Quindi che dire dei JSP? Con il linguaggio delle espressioni e alcuni JSTL (ad esempio <c:if> ) hai tutto, ne avrai mai bisogno.

3) Riguardo alle tue preoccupazioni

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

Da quello che è stato detto: Sì, c'è un grande grado di verbosità se si desidera utilizzare eccessivamente tutte le offerte JSP di funzionalità, ma se si riduce il set di lingue, le JSP non sono poi così diverse dagli altri motori di template.

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon? Will the server get bogged down with all the rendering, if done in JSP's? Or are traffic concerns better addressed by load-balancing requests to the server and leaving the server-side rendering in place?

La domanda formula assunzioni sbagliate su come una pagina web viene assemblata e consegnata al cliente. In termini di 2000 c'era il grosso server web che serviva a tutte le centinaia di migliaia di utenti che un sito Web aveva a quel punto. Se avevi bisogno di più prestazioni scalare era la strada da percorrere. Ma come sappiamo oggi, questo funziona solo in misura limitata. Invece di scalare abbiamo ridimensionare , con server sempre più piccoli che si tolgono il carico.

Nel contesto del 2000 la tua domanda aveva un senso: se hai un server fat, che serve milioni di richieste e fa tutta la logica di business da solo, hai avuto un problema di prestazioni, ma non a causa delle tempistiche del sito web (ricorda: le JSP sono precompilate e questo rende le cose veramente veloci).

Oggi separa le funzionalità e le porzioni di refactor della tua applicazione in servizi separati (alcuni li chiamano microservizi , mi piace il termine servizi focalizzati o sistemi autonomi migliore.

Quindi bilancia il carico in base alla progettazione. E l'effetto dei modelli è ancora marginale.

Along the lines of the performance concerns above, if the app gets a lot of traffic and is rendering views server-side, won't our bandwidth usage go way up? We'll be deploying on AWS, which is semi-unfamiliar territory for me, but I'm presuming we'll pay according to how much bandwidth we consume. Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

Se la pubblicazione di contenuti gzipped mangia la tua banda con e quindi il tuo budget , hai chiaramente un'attività sbagliata .

Are there enough compatibility solutions in modern JS frameworks to resolve this concern? Or is server-side rendering the best-bet, in light of the likelihood of running on outdated browsers?

Risposta che porterebbe troppo fuori tema. Ma lasciatemi menzionare un bell'architettura che comprende il fatto che non tutti i tuoi utenti sono aggiornati o hanno disattivato JS; è una nuova versione del miglioramento progressivo: ROCA - http://roca-style.org/