4 ms·
Just encapsulating css and js inside the html works perfectly fine. In a SPA you nowadays use history api for navigation and make dynamic dom changes on the fly
by holoduke 3y ago
Just encapsulating css and js inside the html works perfectly fine. In a SPA you nowadays use history api for navigation and make dynamic dom changes on the fly. You only have to make sure than you serve the minimum amount of js and css on an initial page load. Then when the page is loaded you load the rest. Slight inefficient cache model when lots of initial page loads from different urls, but usually that's never happening (people are entering a site at one specific url)
I have a SPA, full size is about 3mb of js files. Separate html files containing only that page are max 20kb. Super fast rendering. Nothing server side.
- tracker1 3y agoI often find splitting the difference is useful... embedding the CSS with the HTML, as different routes from the server, delivering the same html will still result in more cache being used, and lack of caching if a user shares/bookmarks something different from what a user may already have cached. async loading for routes and splitting on the bundler can help a lot as well. Similar to async load any graphing/charting libs only on components that need them too. In the end, it depends on what you are doing... if you're wanting to do paged records against a database, then client rendering can help... The direction of React server components, next.js and the like bridge these gaps well. Combined with edge services like deno deploy, cloudflare pages/workers and others make this even more of a no brainer for many use cases. There's also a place for pre-rendering most content... I don't know why any marketing or content sight like blogs wouldn't be static rendered at this point. JS enhancement for things like sharing or comments.