Time to first byte about inertia-laravel

[sebastiandedeyne]

There is a loading indicator :D Inertia ships with nprogress under the hood, but you need to add it's CSS to your application yourself.

[reinink]

Thanks for the interest in Inertia folks!

I think if you want that kind of behaviour, then you're probably better off with a classic SPA that uses an API.

Inertia.js is designed to mimic a classic server-side app, where when a request comes in, you load the necessary data from the database (or elsewhere) and then pass it to the view, and then the view is rendered immediately.

There is a wonderful simplicity to this approach, and Inertia is targeting people who value that. In my applications I strive to have each page load happen within 100-300ms, which completely removes the need to show loading indicators to the user.

Hope that makes sense!

[adriandmitroca]

@reinink

Perhaps it could be useful to have some kind of preloader built in, as I can imagine that a majority vast of users could experience issue with the speed.

[georgehanson]

It sounds good in theory. But this would surely rely on the consumer of Inertia having to manually add the JSON response into the controller, which I think is a bit out of scope.

[rodrigopedra]

In my opinion, this approach would only bring any benefits if you lazy-load the data somehow. If you are calculating (accessing DB, etc) to populate the $data variable you would end doing those calculations twice, as you would have two requests.

Why not having two separated routes? One for rendering the page and the other only to retrieve the data?

something like this

// /page
return Inertia::render('Page');

// /api/page
return $data;

As you would make an ajax request from the page component anyway, the api route can be separated.

Just a suggestion, sorry if I misunderstood your idea.

[connecteev]

I second this. I installed both https://github.com/reinink/client-side-rendering-in-laravel and https://github.com/inertiajs/pingcrm
and it turns out pingcrm (built on infinityjs) is a lot slower to load each page.
Maybe it's because the pingcrm codebase needs to load more data, i'm not sure. Is it possible to make infinityjs / pingcrm as snappy as the client-side-rendering-in-laravel codebase?

[reinink]

Yeah, I don't agree that the vast majority of users could experience issues with speed.

You can build insanely fast apps with Inertia, you just need to make sure your controller responses are fast. (Which is the same thing you need to do when creating an API.)

Inertia works with code splitting, so you can already send the minimal JS bundle size possible. Yes, prefetching is cool, and maybe something we'll consider in the future, but I refuse to believe it's a requirement to create fast applications.

People have been building wicked fast server-side rendered applications for years. Inertia is basically the exact same approach, except EVEN FASTER, since you don't need to do full page reloads.

[adriandmitroca]

You are entirely right and it is hard to disagree, however, since this is entirely client-side rendered application you don't have built-in browser loading indicator, where you can't tell if website is currently loading new page or not, missing a native browser feature.

In my opinion, it would be a good practice and definitely valuable from UX perspective to have any kind of loading indicator built in, no matter how fast website is (plus there are always can be some more time-consuming parts in the app)

[reinink]

Yeah, lol, we need to update the docs to tell folks to include the nprogress css. 🤦‍♂

Even better, I want to remove nprogress entirely, and just build it into Inertia directly. See here: inertiajs/inertia#10