Sounds like you're confusing the purpose of the web framework. Don't try to force front-end specifics into a primarily back-end focused web server. Just because you create web templates for the back-end to RENDER does not mean you need to force it to push out VueJS. In theory VueJS should be able to run behind Apache stand-alone and make requests to your Python API which could be an entirely different codebase. No ambiguity if you did it this way instead, and some web frameworks let you serve up static files / HTML. If your JS front-end app is mostly static, you can just serve it up, and serve up basic HTML from the controller.

I understand the benefits of keeping front-end separate from back-end.

- Separate teams working on front-end and back-end independently

- Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?)

- and much more

Knowing all that, I chose to mix up VueJS with Django solely to optimise for speed in a single person company. Thanks to this setup,

- Authentication is handled via Django sessions (didn't have to spend time on JWT tokens)

- I don't need to setup deployment pipeline, monitoring, testing for 2 applications.

- Keep working on a single codebase and quickly iterate (slightly debatable, but still).

While the setup is not ideal for everyone, it certainly has advantages that I value at my current stage. If you're curious this is the application: https://reviewnb.com

> Authentication is handled via Django sessions (didn't have to spend time on JWT tokens)

That's intriguing, wondered how that'd work out with a SPA. I'm not big on SPA's currently they only make sense for certain type of websites to me, don't mind them if they're done correctly though. But hey if what you've done works for you that's good to me, until I have to touch that code :) Hopefully it's not too awful, it just sounds a little bit out of the norm, but I'd lie if I said I've never done out of the norm solutions...

> Front end bundle can be served fast and cheap via CDN (only the naive serve static files with gunicorn/uwsgi right?)

Not just a CDN, for internal apps I seve all static files through Apache or nginx. I rather let a normal web server do it's job. I trust a C backend to serve static files more efficiently than some web framework, but that's just my personal view.

Using Django sessions in an SPA is actually very easy. It just works, the browser handles the cookies for you. The only thing that developers has to do is to remember to include CSRF header with unsafe requests (such as PUT or POST), this is usually done by adding some kind of a pre-send hook in your request library of choice. There is a section in Django docs that explains how to do just this.

I suggest you check out this development in Responder then –released in v0.1.0 40 minutes ago :)

https://github.com/kennethreitz/responder/issues/53

I'll continue helping Kenneth with this, cause that's a pain point I also want to solve for myself.

On a related note, I tried to build something similar for Django in the past. (it worked, but it's somewhat under construction again due to changes in Django 2)

https://github.com/metakermit/django-spa

Out of curiosity, what kind of “first class support” would you expect from a Python framework? You can write your React app as a fully decoupled codebase and then use any Python framework that serves HTTP for the API backend. The only other potentially useful feature might be server side rendering of (some of) your components, but you would have to do that in Node anyway.

(disclaimer: I don't know how this looks) if you follow the old-school web app model, you're working on the basis of stateless requests. This means that if you want to make a multi-page form, you have to build up coordination mechanisms between pages.

In something like an SPA, you end up having frontend state, but you're lacking the corresponding backend state. There are a lot of times where I've wanted to do something in the backend like:

    first_response = await render('first_form.html')
    if is_valid(first_response):
       final_confirmation = await render('second_form.html')

(This is obviously more conceptual than actual code, since actual code would require suspending python VMs for some unknown future)

In a framework that is more amenable to the fact that frontend clients have state, you should be able to write out multi-request flows more easily. Perhaps with some base notion of a request trace (with the understanding that the frontend also need to send extra info to identify itself).

Websockets are something interesting, but it doesn't quite enable this. And it won't be easy to get right. Failure cases in particular will require some coordination.

The backend request handling layer pretty much has to be stateless if you want to horizontally scale it anyway. Granted, it’s really helpful to have good abstractions for managing session state, but multi-request flows are just a sequence of requests that you have to handle statelessly anyway, even if that involves maintaining, fetching, and sometimes caching session state and other data more explicitly. I see value in having mechanisms for doing that easily (e.g. my request handler function taking a “state” argument that’s automatically populated from a session state store based on a request trace, JWT, cookie, or other mechanism), but I don’t see how those mechanisms would require tightly coupling your frontend and backend aside from enforcing the session protocol.

beyond the session protocol, you have to think about the bundle of state you need to carry between requests in a _clean_ way (preferably something that goes beyond "stuff it in the session dict", because that's basically global variables). You also most likely want ways to do things like fetch non-stale versions of objects from the DB, help with certain data assertions, etc.

You don't need to have a stateless backend for horizontal scale, you can have relatively smart routing, or relying on stuff like the database to help you with the coordination. Especially if you do things like say "this session is held to for up to an hour" you could even consider suspending VMs! If you have the resources to do so, that is.

I think that "coupling frontend and backend" is not really what is being requested here, but more about providing functionality that lets you build rich backends based on the fact that our frontends are way richer than they used to be

I'm somewhat torn about that idea. Here's why.

My story is that I composed a django+angular app. Rather than replace the jinja templates, I treated them as a noop and wrapped the angular in verbatim blocks. Was a rather trivial bit of code and "Just Worked."

For the same reason we look to circumvent jinja templates now is broadly why I don't think python web frameworks should be in the business of servicing one particular SPA framework. I can see some slight benefits in e.g. integrated routing support, maybe some level of model integration, but I'm hard pressed to think of how one could gain _huge_ conveniences without a real reorientation of how I look at the separations between the python and JS sides of things. (which is largely why I'm curious if I _am_ looking at all this in a very amateurish way)

Anyway, I should probably take this as a reason to learn more than nothing about Rails, since all of the above may be answered by seeing what their end product looks like.

> I spent quite a bit of time setting up my Django app to serve VueJS (replacing the built-in Jinja templates). Once ready, it became a powerful application with ORM, middleware and all other Django goodies coupled with modern JS framework on the frontend.

Have you thought about writing this up? I'd be interested in reading how you went about it.

Rails 5 already has webpack support and React support.

https://github.com/rails/webpacker https://github.com/reactjs/react-rails

Can use it pretty much fully in place of the asset pipeline.

Can use standard ERB and spice it up with React using a simple tag with the component name and props as a hash.

Builtin Django templating isn't Jinja thought...

Ohh please. No mixing of NPM with Django.