We make an app, not a website. SSR has no benefits to us, but lots of downsides. And it makes code more complicated.
Out of curiosity, what's the advantage of using Next.js for kap? Thanks!
Super fast hot code reloading, free upgrades to latest Babel & webpack features, no custom webpack config.
It also enforces good conventions and increases productivity.
@sindresorhus from my read of the code kap isn't using SSR, it is using a static export and electron-next to load the exported files. Can you give some more insight into what specifically you think should be disabled?
@bringking It is definitely rendering on the server. We have to litter the code with const remote = electron.remote || false; all over the place so it won't crash when rendered on the server. https://github.com/wulkano/kap/blob/ef31a376ef63e0efc27de439b44a791f203fd1ed/renderer/pages/_app.js#L7
Also see:
@sindresorhus thanks for the clarification, I need to dig in more to understand SSR in the electron context
You might want to have a look at https://github.com/zeit/next.js/#3-with-no-ssr @bringking and @sindresorhus
馃 if relying on dynamic imports to disable SSR that'd require moving all logic out of the renderer/pages files and have each page basically just dynamically import a component encapsulating what used to be on the page.
Kap will also have to roll something else (an App component?) to replace the built in functionality of _app.js right? That'll be difficult to work around since even if that was done, dropping that App component on each page won't have the same behavior as next's _app.js being a shared instance across all pages.
@issuehunt has funded $80.00 to this issue.
Most helpful comment
It also enforces good conventions and increases productivity.