Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for "universal" pre-rendered static apps planned? #141

Open
JakubKoralewski opened this issue Feb 15, 2020 · 4 comments
Open

support for "universal" pre-rendered static apps planned? #141

JakubKoralewski opened this issue Feb 15, 2020 · 4 comments

Comments

@JakubKoralewski
Copy link

Is something like Nuxt's "universal" setting planned to be supported? Where a frontend app's all routes are rendered and saved to html files for faster loads?

@chinedufn
Copy link
Owner

Not necessarily planned at the moment - but definitely interested in supporting and/or making it easy to generate a static site for an application.

Right now to serve an application pre-rendered you need to be running a Rust server somewhere.

It would be nice if you had the option of generating a static site for your application instead.

At the moment you can accomplish a similar "fastest possible page load" by putting a CDN in front of the Rust server - but yeah not needing to have a server is a nice option.

Whether or not that would happy in this repository or left to user-land I'm not sure yet - but it's something that we'll want to think through.

My current priority is re-thinking state management and writing a crate around that - but this is definitely something we should be thinking about.

@llebout
Copy link

llebout commented Jul 14, 2020

To clarify if I misunderstood the post above, I would be interested in having SSR for every page, like to never have the client take over. The goal being, getting back to lightweight HTML-only websites of the PHP era with the least amount of JavaScript possible if at all.

Would that be possible? The new programming paradigms offered by modern frontend frameworks are interesting, but they imply an enormous cost on clients.

@chinedufn
Copy link
Owner

chinedufn commented Jul 15, 2020

At this very moment you can do SSR with Percy and not have any sort of client side code running. How / where could I make that more clear?

If we had anything around static-site generation (I haven't thought about it yet. Might be better in user-land for all I know) you would not need any client side code for that case as well.

More clearly.

Percy doesn't force you to have SSR or client side rendering. You use whatever you want.

The general philosophy of Percy is to give you libraries to use but make you fairly explicitly decide to use them (Percy just recommends to you how/where to do it).

This way you don't end up with the currently-common case of "I just want to do X but this framework is making ABCDEFGHI and J happen"

@oovm
Copy link

oovm commented May 16, 2021

I have some idea.

If we generate all static pages based on the route, we still need a runtime to handle events.

Visit each SSG (static-site generation) page, they only correspond to a different initial state, right?

To access any of these pages, introduce the same runtime, and then convert the page into PWA, the next rendering is just to read json to change the state.

Of course this means that each page must generate additional json metadata, and html is just an entry point, or a state snapshot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants