Can You Afford It? Real-World Web Performance Budgets

Well, you don't need a SPA to do that at all. You don't have to do the validation client-side, you can still get the server to do it with some extremely simple javascript.

You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation errors and replace it in the DOM.

Virtually instant feedback, no page reload, no 30 second initial SPA load.

In ASP.Net MVC, for example, this is as trivial as changing the `Layout` property of the page in the controller, the full layout for GETs, no layout in POSTs.

Technically you don't even have to support progressive enhancement, but it's so trivial in most frameworks you may as well.

I believe Rails has a built in turbo feature which essentially does this and more.

Example ts code, though usually put more in to disable double clicks and add a loading spinner:

    onSubmit = (e: JQueryEventObject) => {
        e.preventDefault();
        let $form = $(e.currentTarget);
        $.ajax({
            type: $form.attr("method"),
            url: $form.attr("action"),
            data: $form.serialize()
        })
        .done(() => {
            //do something
        })
        .fail((e) => {
            if (e.status == 400) {
                $(".js-form-wrapper").html(e.responseText);
                this.wireUpControls();
            } else {
                //handle error
            }
        })
    }

And wire it up on initialize with:

    $("#your-form").submit(this.onSubmit);

His argument is based on an example where he puts JS in , when it's been a recommendation for ages to put JS at the very end of .

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action.

As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away.

As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app.

I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.

No, you need to assess where your customers are and focus there. Just because a market is growing, it doesn't mean that market contains customers for your product. That depends on numerous variables including pricing.

The US will add ~$570 billion to its GDP this year. That's equal to 25% of India's entire economy. An increasingly large part of Europe is back to generating solid growth again. Even Japan is showing signs of life. You don't need to focus on 2G markets if there are few customers there for your products.

It's also funny how many of my friends use $TrendyJSFramework for a portfolio site! Personally prefer to have all my content statically served unless I'm building some sort of an interactive single page application.

I run https://discoverdev.io for which I wrote my own SSG framework in python+jinja, I spit out html and push it to netlify's CDN network. It's smooth, I don't have to worry about scaling and it works like a charm! (I could still do a lot of optimisation wrt image compression and minification though)