Maybe you were using React for something that isn't highly interactive and thus React was adding more friction than utility?

I think you are exactly correct, now I give it some thought.

When I do ReactJS I'm building much more powerful UI features. The Django stuff is just a bunch of forms and that is really easy to drive.

When to use the more powerful tools is an important (and tricky) lesson to master. Not every project needs React.

Lately I've been writing little personal projects using Vanilla JS. There's something rather therapeutic about limiting one's self to zero dependencies. I'm wildly surprised every time I come back to Vanilla JS to see just how many core features there are. I can do modules in the browser now! Yippee!

And beyond that, not even using JS and just using Django Templates or Jinja is great too.

But I write a lot of software that monitors and controls mobile robots in warehouses. For that kind of wild state management of 100+ data sources, all with their own incomplete states, controls, unpredictably erroneous behaviours, React + Redux is just a godsend.

One of the things that makes it hard to choose which technology you begin with is that small projects don't stay small, even if you thing they will. So the risk is I think "hey it's s small project, I'll whip it up in Django", and then of course in six months I'm cursing myself for not starting in React.

Yup. And there's no easy answer, I think.

I think that part of it is just experience. You'll slowly learn to better predict which projects are likely to grow, especially in a way that needs a more expressive foundation.

I also think that the, "aw crap I have to re-write this from Django Templates to React" isn't exactly a bad thing. You've probably learned a ton about the problem you're solving by focusing on the problem directly in front of you[1] rather than trying to plan for the future problems that you don't quite understand yet. So when you tear it down to build the next iteration, the code you're replacing wasn't the valuable part.

[1] Not all projects are organic. But the ones that are, really benefit from a, "get this out in 2 weeks and learn what we don't yet know about it" rather than spending months trying to perfect some product that we're mostly just guessing at.

Build one to throw away, you will anyway

- F. Brooks

I wish there was better story for integrating React with Django, so I can use Django for the simple views and React for the interactive stuff.

I'm likely giving a talk on this exact subject in January (depending on scheduling). If you're curious about the various approaches I've tried, you can reach me at this username in all sorts of places.

I think you'd use Django REST framework wouldn't you?

I recently just started replacing some jQuery functionality with React in a large Django project, using Django-Rest, it's actually been less complicated than I expected.

Why can't you just serve up your react js assets like any other js asset when using django?

Many "web apps" are just a bunch of forms, crud operations and occasionally static pages for eula, privacy policy, faq and other knick-knacks.

Oh Dan, my experiences are that eight companies out of ten are using react for _anything_.

There were times when javascript === jquery. Nowdays javascript === react.

At work we are building a simple CRUD admin with Jekyll and Vue as a jQuery replacement. No babel, no webpack, no router, no Vuex. The complexity has been reduced immensely.

Data still comes from an API, so the front end is still decoupled from the back end, and anyone that is not a JS ninja can still contribute to the codebase since the project structure is really simple.

This is an internal project so we can tell our users to use latest Chrome to avoid transpiling and such, but configuring webpack would still be possible.

I really recommend the approach.

A lot of people think getting the data from an API automatically means building a single-page-application while in fact you could use this approach with Jekyll to create a static site, or even use server side code to generate dynamic markup and still consume an API.

Agreed. But as soon as you hit any dynamic behavior, you kind of end up wishing you could "drop" into React.

That's why I built the following project: https://github.com/silviogutierrez/reactivated

It's very early on, but essentially, completely replaces the template rendering with React components. Still regular markup, but whenever you need dynamic behaviors, it's trivial. And it's all server side rendered.

So basically, looking at https://github.com/silviogutierrez/reactivated/blob/master/c...

You can see the traditional Django context becomes "Props" in the top level component. Then it's React all the way down.

Notes:

1. The most complicated part is the initial setup. You do need to run NodeJS, webpack + Django server. Working on improving that.

2. I like TypeScript and use it here. But theoretically it'll be optional. The Django+Python part is also statically typed using MyPy.

3. No instructions whatsoever yet. But you can see a live site using this stack here: https://www.silviogutierrez.com/ . Notice it's server rendered but has dynamic behaviors that are trivial in React but harder with jQuery + Django. Example: https://www.silviogutierrez.com/blog/making-cck-fields-read-... Look at the nested commenting and moving the form around. Very easy in React.

4. Because of the architecture, adding a much-better-turbolinks style Ajax is trivial. Click around the site above (loading indicator not yet added). The page is re-rendered entirely on the client but gets a server AJAX response.

Hope that's interesting info. If you'd like to try it out, definitely let me know. Once you overcome the setup hurdles, it's amazingly productive. As in, if all you wish to do is `{{ form }}` like old school Django, here's the equivalent sample template: https://github.com/silviogutierrez/reactivated/blob/master/c...

I have a similar project, that doesn't require you to setup webpack, and integrated beautifully with django

https://github.com/pycampers/react-pages

Neat! In this case, it took a lot of work to get the forms "fielded" in React world. So you can individually render fields, etc. But yea, setup is currently a pain.

I have a quite very crude implementation of form fields on my side, which annotates the type of formfield (as a string) along with several other useful things, like id_for_formfield, html_name etc.

--

In your https://github.com/silviogutierrez/reactivated/blob/master/c...

    import {Form} from '../components/Form';

I can't find `../components/Form`. Where is the source for that?

---

Here are the fields I was able to extract, meaningfully.

https://github.com/pycampers/react-pages/blob/417ec24129b80b...

It still doesn't seem enough for building anything serious though.

What’s the benefit of rendering on the client given you need to get the Ajax response anyway? Can’t the server just return the html of the page?

First, it's a true JSON response, which is much lighter.

Second: React does a DOM diff and only updates the components that changed. So it's super fast.

Third: when you DO need to use the raw JSON, you have access to it.

Fourth: rebinding behaviors (onClick) etc is done by React seamlessly. And again, uses the DOM diff to be efficient.

Have you measured the efficiency gains? On your site, you are making large scale changes as you click from link to link, so there isn’t much of the ui you aren’t re-rendering.

In the site you linked to, the scroll position gets messed up as you go back and forth between “pages” and click on links — problems that don’t occur when you fully re render a page.

Efficiency in coding: inmeasurable. For typical CRUD it's amazing once you get over the hump of setup.

Efficiency in speed: likely very little over just requesting the HTML via AJAX.

As far as scrolling/etc: that behavior is super buggy and I never really tested it. I "turned on" the turbolink-esque behavior as a test but it needs far more work.

In any case, one can just turn it off and revert to regular SSR behavior instead of the AJAX-ey one. I might even do that because, in general, I want my page to show the traditional loading icon in place of the favicon.

This article summarized some of the pitfalls: https://tinnedfruit.com/articles/create-your-own-dysfunction...

this is sooo cool. Can you build this for Flask as well - basically Jinja2. I do believe that Django can use jinja2 as well.

However, would like to compile all the reactjs stuff before including it in flask/django. You could look into the https://github.com/nozzle/react-static project to use their static compiler (which does React -> static html/js) to achieve this exact thing.

I was about the embark on making essentially this. A bit above turbolink.

Edit: try to make it server agnostic, if open source is your intention ( and not just personal website use case ).

Not a bad idea! In this case though, a major element I wanted from Django was the ability to use its forms "as is" with all the validation powers and ease of doing CRUD. Server agnostic would just be taking JSON -> React.

I've found that Vue included as a script tag and used without any build steps excels in this scenario.