I'm not going to lie, when I hear "SPA", I don't think "fast"; I think "10s of megs of javascript, increasingly unresponsive browser tab".
Maybe that's an unfair genralisation from a small percent of poorly written SPAs, but that small percent have really had me hankering for multiple page websites with judicious use of JS.
I agree wholeheartedly. I know it's dismissed as a flippant response, but I believe a lot of the problem is people wanting things like React on their resumes, and so force fitting it because they don't have other opportunities. There's just so much bloat for things that should be HTML and some small amount of JS.
It's definitely unfair. But yeah, there's a lot of SPAs that are 1) not treeshaken, and 2) probably don't need to be SPAs.
things like loading a whole mapping library, when it's used on one page that maybe 10% of users will ever even load that page. or things like moment.js when all you want to do is get the last day of the month, but need to load that whole library.
then there's the whole, I'm just writing a restaurant website with 3 pages, but let's engineer it with a whole frontend framework and 4 dozen 600kb libraries.
There are a lot of real apps out there, usually in enterprise, or b2b, that the amount of that first page load is actually saved over the course of a users day, possibly an hour, because that app is their job essentially.
This is the job of the architect though right? If the architecture of the app is properly constructed, you shouldn't have the issue(s) OP pointed out.
IMHO in most of the large corporate environments where I've worked, managers are constantly bucking for a promotion. It always seems like the design and IA are left out in order to keep budgets low with a focus on delivery.
Yah, I definitely realise that the negative experiences have a larger impact on my perception of SPAs than the positive ones.
Traditional multipage apps don't get that same "bad rap" in my mind because, while the upper-bound on performance is likely lower than SPAs, the lower-bound is likely higher than SPAs.
I absolutely think fast. SPAs are for applications; I'll take a few second hit up front in order to have an application that doesn't load entire new pages anytime I perform a single action.
Never mind- Turbo Drive is the part of Turbo that enhances page-level navigation. It watches for link clicks and form submissions, performs them in the background, and udpates the page without doing a full reload. It’s the evolution of a library previously known as Turbolinks.
Can you post some good examples of non-single page applications with good usability and speed? Emphasis on >applications<, not websites serving mostly static content.
It feels like there should be an HTML-only feature for sourcing and replacing a subset of a page. A first-party "iframe" that acts like a div and reflows.
If one wanted to do server side rendering in Java with something like Turbo links, in 2020 - what would one use? JSP? Grails? JSF? Or just hit the bar instead? :-)
JSF really is meant for quickly building internal applications that don't have to withstand "web scale" loads. It's focused on churning out data driven applications quickly. Add something like Bootsfaces or Primefaces and you can produce these things in very little time. Thats not to say you couldn't use JSF to make a "Web Scale" project, but you would have to dive into your server pretty far to carefully watch state management and session creation. Not impossible, but just probably not its primary purpose.
For external facing applications that need to withstand a "web scale" load, Eclipse Krazo (aka MVC spec 1.2) and JSP are what you're looking for. These things are lightning fast and give you a lot of control over session creation by default. Render times are usually under a few ms. This is probably the fastest and least resource intensive stack available (no benchmark provided, take it for what you paid for the comment).
