How hard would it be to modify the app so the server does the API request before rendering the page, rather than showing a loading indicator and filling in the content asynchronously? I prefer to just wait a little longer for the initial load to complete, so that the initially rendered page is already settled. But then, my perception is skewed, because most of the web development I've done has been targeted at blind people using screen readers (and I'm visually impaired, so I often use a screen reader myself). A screen reader typically starts reading sequentially through a page as soon as the page finishes loading. So for that use case, static is better. (And yes, client-side routing causes an accessibility problem.) But I wonder if most users prefer a page that returns immediately with a loading indicator, then fills in the content shortly after that.
With a Marko project not using our basic starter(@marko/serve) like our Webpack-Express starter it is a very easy one line change. You just change the render entry point to:
consthtml=awaittemplate.render(input);
However the basic project template I used in this demo is all preconfigured to work with streaming. You could make the <await> the topmost component on the page and remove the client-reorder and placeholder and it should wait to render anything and still benefit from streaming in the head of the document for quicker script loading, but that only works effectively in a simple case like this. And I'm just hacking it.
That being said getting started with a Webpack-Express project is just as easy using @marko
/create but it doesn't have the built-in routing but it gives you full control of the configuration.
And this might be a little exaggerated but this is why there is a preference for this loading pattern: markojs.com/#streaming. This is more or less the difference Marko's streaming/progressive rendering makes.
Granted, given what is going on in the official @marko/express, a production situation will likely need a few more lines to transfer $global for full functionality.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How hard would it be to modify the app so the server does the API request before rendering the page, rather than showing a loading indicator and filling in the content asynchronously? I prefer to just wait a little longer for the initial load to complete, so that the initially rendered page is already settled. But then, my perception is skewed, because most of the web development I've done has been targeted at blind people using screen readers (and I'm visually impaired, so I often use a screen reader myself). A screen reader typically starts reading sequentially through a page as soon as the page finishes loading. So for that use case, static is better. (And yes, client-side routing causes an accessibility problem.) But I wonder if most users prefer a page that returns immediately with a loading indicator, then fills in the content shortly after that.
With a Marko project not using our basic starter(
@marko/serve) like our Webpack-Express starter it is a very easy one line change. You just change the render entry point to:However the basic project template I used in this demo is all preconfigured to work with streaming. You could make the
<await>the topmost component on the page and remove theclient-reorderand placeholder and it should wait to render anything and still benefit from streaming in the head of the document for quicker script loading, but that only works effectively in a simple case like this. And I'm just hacking it.That being said getting started with a Webpack-Express project is just as easy using @marko /create but it doesn't have the built-in routing but it gives you full control of the configuration.
And this might be a little exaggerated but this is why there is a preference for this loading pattern: markojs.com/#streaming. This is more or less the difference Marko's streaming/progressive rendering makes.
There is a sample app (marko-progressive-rendering) that demonstrates the various rendering modes. It was written in 2016 (early Marko 3).
My attempt at an update to Marko 5 - the "Single-Chunk" rendering code is here.
Granted, given what is going on in the official @marko/express, a production situation will likely need a few more lines to transfer $global for full functionality.