[Bahamut]

Creating a universal JS app on the web has some extra cons too - not only is the code run on the server, but also a not insignificant JS payload is downloaded & executed on the client, as well as increased app complexity in order to maintain client/server separation at extension points.

One should be cognizant that one doesn't get benefits for free with the choice to go with universal JS.

[scottmf]

>as well as increased app complexity in order to maintain client/server separation at extension points.

Can you explain what you mean by this?

And are you comparing client-only vs universal, or client-only vs server-only?

Large JS can be solved with code-splitting. The necessary code is downloaded in chunks when needed.

[hoorayimhelping]

Not OP but think about the window object in the browser. In a client-side only JS application, you can assume that window will always exist. In a server-side PHP application, you never have to worry about interacting with window. In a SSR React application, you have to manage that complexity of window existing sometimes and it not existing other times if you want to share components between the client and the server.

[mercer]

So then there's:

- code-splitting needed for larger codebases

- taking the window object into account

Other stuff I can think of:

- more limited options for routing/etc. because you want to avoid having to maintain two codebases. This means you might have to use Redux+redux-router+whatever instead of express/hapi/etc. because you can't (?) run those frameworks client-side.

- less freedom to modularize state in your app, because last I checked it was still rather messy to ensure that all the separate data-loading events are taken care of server-side before everything is sent to the client. If you're a fan of the Redux approach this shouldn't be a problem though.

- Possible 'issues' with using ESNext features server-side without going through Babel.

All in all I think it's worthwhile and, nowadays, pretty doable to create a 'universal app'. But it has its own complexities and at least last time I tried, I could find very few examples of how to best do this, and we're probably still far away from a 'canonical' solution.

Furthermore, in practice I've found that in many cases it's not really worth the extra effort. If your app is large/complex enough to have a noticeable load-time, it's probably fine for the user to load the entire app first (it might even still be cached), and it's often the case that SEO is not really important.

In my experience, the few cases where a big-ish app needed to load stuff quickly involved going straight to some subpage in the app. In that situation I often found it easier to either just render that bit server-side the old-fashioned way, with its own logic (in which case React is still a good option).

[abritinthebay]

The data is transmitted yes. In practice, after gzip, this is negligible compared to say... any average image loaded on that page.