[davnicwil]

This is cool, and you make it clear it's an experiment, but I'd just like to ask you in a bit more detail on the part about not just using React SSR directly because you felt you were just reimplementing Next - to me most of the value Next brings is abstracting away the isomorphic stuff, making everything work the same on client and server in a seamless 'app-like' structure.

But since you don't need the client, you don't need any of that, right? Seems like without having to structure the server code in the same way you'd structure client code, things just get a lot simpler and the native React SSR stuff should be fine to use directly. Just curious which other features of Next you found you wanted for a server-only app?

[danielstocks]

Good question. I think that relates to the “developer experience” point I was trying to get across: Things like file-system routing (eg. drop a JavaScript or Markdown file in /pages) and overall a Webpck/Babel setup along with the build/export scripts that just work out of the box. Regardless I still think you have a valid point and yes this is experimental and not something I would generally advise.

[davnicwil]

Got it - so literally just for the higher level 'rails like' dev experience and nothing 'react-y' per se? Thanks!

I actually thought it might have something to do with data loading, so it was a slightly leading question as I'm very interested in that stuff - I have a library react-frontload [0] that does client & server data loading that could feasibly be used in a server-only context, and am always looking for ideas on different usecases etc.

[0] https://github.com/davnicwil/react-frontload

[cormacrelf]

> file-system routing

Ah yes, there are some interesting new frameworks built around this concept. PHP.js comes to mind.

> yes this is experimental and not something I would generally advise.

I know what you mean, but it is still funny, given how long this was the way nearly 100% of web development was done for about 15 years.