4 ms·

Hosting is separate from the framework, and the static site hosts you mentioned are just webserver + CDN packaged together with optional build/CI layer and some

Hosting is separate from the framework, and the static site hosts you mentioned are just webserver + CDN packaged together with optional build/CI layer and some extra APIs to handle form submissions and user logins. Considering the number of CDNs and 1-click hosting, and the ease of putting them together, it's all pretty much the same. The big difference is that these static site frameworks are using React/Vue/etc for the frontend templating and interactivity instead of a server-side language that has it's own templating and might require complex JS integration. But the trade-off is that you give up that server-side ability or have to use 3rd-party services like a headless CMS instead.

silviogutierrez 6y ago
Sort of, but not always. My blog at https://www.silviogutierrez.com https://www.silviogutierrez.com is React+Django strictly server side. I like JSX that much. Try loading it with JS disabled. Same at my business site: https://www.joyapp.com https://www.joyapp.com. It was a huge ordeal getting it setup (with React SSR, etc), but it's definitely doable. I've open sourced it but it sorely needs documentation (incoming): https://github.com/silviogutierrez/reactivated https://github.com/silviogutierrez/reactivated Basically, despite the tooling (not because of it), once you get going with JSX, TypeScript and the like, nothing else comes close. At least in my experience. But again, none of the above stops me from dumping that output into a single cache key per request. It's still dynamic, just cached robustly.
- dopeboy 6y ago
  I'm a fellow django + react developer. What are your thoughts around moving to Next.js?
  - silviogutierrez 6y ago
    In my opinion: nothing, and I do mean nothing, comes close to the productivity of Django + Forms + FormSets + Admin. I've tried everything under the sun[1] The model->form and presentation layer is so intuitive and robust that I'm surprised no JS framework has rebuilt it. Too much is focused around REST instead of domain specific inputs / outputs.[2] So yea, I've focused on making Django more React-friendly. I want to stick to it. [1] Ok, maybe Rails comes close. [2] https://news.ycombinator.com/item?id=21875331 https://news.ycombinator.com/item?id=21875331
switz 6y ago
Not quite. Next allows you to dynamically generate static content both at build time – and with this latest update – at _runtime_ as well. It generates code-split bundles for each page, enabling extremely thin pages to minimize the amount of content loaded with zero configuration. You nailed the big advantage though, more eloquently than I was able to articulate: a unified code-base for both initial rendering and interactivity. Next _also_ supports rendering things on the server if you'd like. So you're not giving up anything at all, there's no trade-off with respect to rendering patterns, unless you just prefer to use another language to build your 'frontend'. Hosting is 'separate', but the framework snugly fits into a modern hosting paradigm in a way that most others do not.

silviogutierrez 6y ago

Sort of, but not always. My blog at https://www.silviogutierrez.com https://www.silviogutierrez.com is React+Django strictly server side. I like JSX that much. Try loading it with JS disabled. Same at my business site: https://www.joyapp.com https://www.joyapp.com. It was a huge ordeal getting it setup (with React SSR, etc), but it's definitely doable. I've open sourced it but it sorely needs documentation (incoming): https://github.com/silviogutierrez/reactivated https://github.com/silviogutierrez/reactivated Basically, despite the tooling (not because of it), once you get going with JSX, TypeScript and the like, nothing else comes close. At least in my experience. But again, none of the above stops me from dumping that output into a single cache key per request. It's still dynamic, just cached robustly.

dopeboy 6y ago
I'm a fellow django + react developer. What are your thoughts around moving to Next.js?
- silviogutierrez 6y ago
  In my opinion: nothing, and I do mean nothing, comes close to the productivity of Django + Forms + FormSets + Admin. I've tried everything under the sun[1] The model->form and presentation layer is so intuitive and robust that I'm surprised no JS framework has rebuilt it. Too much is focused around REST instead of domain specific inputs / outputs.[2] So yea, I've focused on making Django more React-friendly. I want to stick to it. [1] Ok, maybe Rails comes close. [2] https://news.ycombinator.com/item?id=21875331 https://news.ycombinator.com/item?id=21875331

switz 6y ago

Not quite. Next allows you to dynamically generate static content both at build time – and with this latest update – at _runtime_ as well. It generates code-split bundles for each page, enabling extremely thin pages to minimize the amount of content loaded with zero configuration. You nailed the big advantage though, more eloquently than I was able to articulate: a unified code-base for both initial rendering and interactivity. Next _also_ supports rendering things on the server if you'd like. So you're not giving up anything at all, there's no trade-off with respect to rendering patterns, unless you just prefer to use another language to build your 'frontend'. Hosting is 'separate', but the framework snugly fits into a modern hosting paradigm in a way that most others do not.