Conosco Svelte e React, se Svelte è più rapido, pulito e performante, React ha un eco-system che fa paura (ed è anche per questo motivo che si usa ancora React.js piuttosto che Svelte, Preact, Solidjs..
Tornando alla differenza con SvelteKit, non avendo avuto modo di utilizzarlo sarei curioso di saperne di più anche io...
Tornando alle differenze invece di CSR e SSR:
Storicamente, quando un utente ha aperto un'applicazione basata sul Web, l'HTML di cui è composta l'interfaccia utente e il suo contenuto (script JS annessi) venivano portati sullo schermo del dispositivo tramite il rendering lato server (SSR).
Come funziona SSR: Il browser invia una richiesta al server dell'app, che invia un file contenente i dati necessari per la riproduzione locale della pagina sul dispositivo dell'utente (HTML, CSS, JS, risorse esterne come MaterialUI o altri link esterni già renderizzati), quando l'utente clicca su un link che porta ad un altra pagina, si ripete l'operazione da 0, ossia si carica il file con il relativo contenuto ogni volta (che sia comune o meno alla pagina precedentemente caricata). In questo caso
il rendering delle pagine venivano effettuate server si
de. Di conseguenza, il DOM processing era lato server. Esempi di tecnologie SSR sono praticamente tutte quelle che non hanno framework orientate a componenti come React.js, esempi come JSP, ASP o altre simili...
Successivamente, però, dato che i dispositivi e i web browser diventavano sempre più potenti, le infrastrutture web potevano essere modificate in modo da "alleggerire" il carico di lavoro dei server (che ricordiamo mandano un bel pò di response pesanti con file monoliti processati ad ogni richiesta ricevuta).
E qui che nasce React.js e altri framework della famiglia CSR.
In CSR, il browser fa una richiesta iniziale di solito a una CDN (Content Distributed Network) o infrastrutture cloud più complesse piuttosto che a un server, che invia un "wrapper" di base che contiene tutti gli elementi HTML statici, CSS e file di supporto di una pagina Web o di un'applicazione. Questi elementi vengono quindi memorizzati nella cache dal browser, che successivamente effettua richieste API tramite AJAX per recuperare contenuti JavaScript dinamici resi sul browser utilizzando l'elaborazione DOM, in altri termini, il server ti manda solamente gli elementi da renderizzate, poi tramite il buffer del tuo browser ti crei il DOM e, quindi, la pagina HTML. Tant'è che tipo in React, come ben sai, i tag delle componenti non sono altro che classi che estendono React.Component (classi date dal server) e te la funzione di render la fai solamente quando hai caricato tale classi dal server sul web browser.
Per farti un esempio stupido:
Se voglio caricare una pagina con scritto Hello World in un div file:
1. SSR: Ti restituisce nel body della response un <div>Hello World</div>.
2. CSR: Ti da la classe Hello che estende React.Component (nel caso di React, poi le componenti sono definiti in base al framework che utilizzi), successivamente il tuo web browser carica questa classe nel buffer insieme agli oggetti (componenti) che ti definiscono il DOM processing (quelli che in pratica ti creano i tag HTML). Successivamente vengono applicate le regole grafiche interne alla classe o tramite file css esterni.
Per concludere, dato che Svelte è orientato a componenti (come React.js), credo che SvelteKit sia un framework che ritorni alle origini (se è SSR). Ovviamente ipotizzo mantenga alcune funzioni leggere o rendering parziali in modo da creare una sorta di rendering ibrido (SSR + CSR). Questo perché uno dei problemi che si può creare in CSR è che si ha una scarsa supportabilità nel caso utilizzi dispositivi con quantità minimale di buffer o con processori con scarse prestazioni, mentre in SSR sta il problema della latenza di comunicazione, in cui web app molto complesse hanno bisogno di tempi di rendering lunghi prima di poter essere mandate in response (cosi da aumentare il lag di caricamento di una pagina ad esempio).
) 