Pretty cool! I have done most of this in the past and the documentation here is pretty good!
I wonder how one will horizontally scale this app if need be. Would you separate out nginx onto a different instance and have it pass traffic back and forth between several instances running the django backend? Whatever the way to do it, it would be cool to see that added as an article here :)
Thanks for this! Looks useful, will be checking it out after the Christmas festivities.
Coming from academia/data science and learning this from the scratch, the python backend + js frontend boilerplates are quite cryptic. The tools for sure seem useful, but there's a lot to grasp for a noob - rabbits, celeries, and so on.
Agreed. A lot of boiler plates seems to back everything under the sun, when I really just want a simple reproducible template, maybe ever with docker support. This looks like it hits featureful without unnecessary complexity.
True, that was the purpose of this Django+React boilerplate. Provide minimal and easy to follow template. Additionally, every code added is documented in the series of articles so you can learn how it was done.
There is a docker-compose provided to set up and run this boilerplate application on single server machine. It can be easily adjusted to your needs.
In my experience as a user, everything that uses React is always an annoyance in one way or another. But I am happy to understand if there are legit use cases.
Yes, this boilerplate has two main goals: (1) it is a good starting point for developing the more advanced applications (2) it is provided for learning purposes, there are step-by-step instructions how the boilerplate was created. BTW, it is still under the development.
The boilerplate code runs with docker-compose on single server but in the future the frontend and backend can be easily divided, so separate teams can work on them.
It’s really difficult to keep your data in sync with the backend, especially at scale. They also fit in well in a micro service architecture, which solves a lot of comms and maintenance problems at scale.
The typical hn startup is expected to grow to that size, to an enterprise scale, so you’re not going to see a lot of people use Django.
Can you list one annoyance you see as a user with React?
The biggest challenge to using Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. Most parts of the site I want server-rendered, while in stateful parts I want React. So, let's say I have a site with 20 different React "apps" (i.e. stateful components) that I want to distribute amongst my various Django sections (Django "Apps" within the same project). And I want to do that with one webpackconfig. How do I tell my webpack where to put all those react bundles? The answer I've found is django-webpack-loader[1], however as you can see in the Issues section, one of the biggest limitations here is the inability to chunk React (and other issues).
Does anyone have a solution they like for this kind of isomporphic Django problem?
I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries.
You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
Yes. I have large portions of a server-rendered, django web application that uses react largely as you've described.
I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar)
Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls.
My goal was to minimize customization while retaining the "spirit" of both Django and react.
I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling.
It also makes it more likely the react app can be migrated to new versions of CRA.
The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*.
Key aspects of my implementation are:
- Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django.
- Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path.
- Customization of HtmlWebpackPlugin to modify CRA's:
- Out-of-box behavior of webpack bodyTags and headTags.
- webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev
While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file.
Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2]
I have not released my solution but I have stubbed out the problem and solution description [3].
If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4.
All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app.
Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA.
Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend.
I've worked with Django for 12 years and I don't know why you would want to use their awful templating language.
It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload.
And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).
I don't think django tempating is as bad as you've described but one reason is that a project is long-standing and dev resources are already familiar with it.
A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well.
The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
Totally agree with your assessment of Django in terms of its templating and SSR abilities. It's horrible and should be avoided at all costs.
However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
Yes I agree with you. My favourite stack right now is Django with DRF+Admin for backend, Typescript+NextJS (React) for frontend. I front the backend with Caddy, have django live on both admin.example.com and api.example.com with a couple of rewrites, and put cloudflare access in front of admin.example.com.
Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup).
The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
You should check out FastAPI. I’ve been a Django dev for years but now that all projects have pretty much moved to client side js + drf backend anyway I’ve been using FastAPI for new projects. The way it takes advantage of Python typing is a thing of beauty!
Yup I've used FastAPI and love it. I'm not entirely sold on it when it comes to dealing with the ORM though, and the lack of a Django-quality admin is kind of a bummer.
Honestly I don't really know how to summarize it. Django templates have a ton of gotchas. They have the dumbest safeguards, too, such as preventing you from using variables beginning with underscores.
Jinja templates at least let you use normal python syntax in the tags. You can easily do something like {{ items.filter("books")[:5] }} — in Django, you would have to write a special accessor or template tag to call filter("books") as it doesn't let you specify arguments to function calls, and you'd use the awful |slice:":5" to slice it.
But more than anything else, Django templates are not just untyped, they are untypeable. You can't really validate them. Best you can do is try to compile them in a CI job see if anything fails. Not to mention that the way you're outputting HTML essentially arbitrarily anywhere in the page means there is no way for the editor / tools / even yourself to know if some piece of code is syntactically or semantically valid in context. Got a list_item.html with a naked "<li>{{ item }}" inside? Why the fuck not! Could even be raw css or js outside a tag in your template, could be valid in some includes, invalid in some others. Everything goes. You can't even know whether a template is in use, as it's completely arbitrary code that calls these template inclusions, via string filenames (which therefore can be included however you want).
It's impossible to create these problems with react/typescript. And react heavily encourages code reuse: creating reusable components that are as small as possible. Django templates encourage copy-pasting.
I've spent many years working on django including production setups for 3 different companies. My strong advice is to only use Django for API calls (DRF) and the built in admin UI. Do not use Django for ANY client facing static site rendering.
1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy.
2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved.
3. Use https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis.
Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.
That's a nice idea for new projects but how would you handle a company with large existing Django sites that want to bring in one or two react-based SPAs?
We did this with Vue.js, not sure if it applies to React (I haven't used React).
The way we did it was to start with a few parts of the page that really benefited from having Vue.js, using a simple `script src=`. So no components or anything fancy. For this we just put the JS stuff using Django's template system.
Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN.
In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON.
In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
I’m currently building an SPA with the above approach and it most definitely isn’t “not using Django”. There’s plenty of Django if you use DRF. You’re also still exposed to templating if you use Django Admin like they suggest and I’m also doing.
Can you give me a solid usecase of why not to use djangos templating and use - as per your example - an SSG?
Seems like the usecases are edge cases. Why use Django just to make api calls when smaller and nimbler alternatives abound.
Its no wonder React devs command such a strong hourly fee. They'll mostly be fixing dung with more dung and hooks.
Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do. The code will be verbose but there is no magic or illusion. Anyone from junior intern to senior dev can understand the codebase without much help. Its not that big either.
Not the OP but this approach is great if you're starting a new project that is intended to grow.
Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production.
After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously).
Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around.
Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas.
For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home.
> my case against react when plain whole JS would do.
IME (not a senior dev) it's easier to turn the entire front-end over to React. I don't want to rebuild the wheel and write custom CSS every time I need a new component. I want to be able to plug in common components, with unsurprising and predictable props. If I'm already using React for dialog boxes, it may well as handle my click handlers as well. Then it can also grab data.
I agree with the spirit of avoiding more dependencies though and for this reason I try to avoid Redux. I find React absolutely invaluable for styling and reusable components however.
> I don't want to rebuild the wheel and write custom CSS every time I need a new component.
You are telling me it is worth migrating to a new architecture/build with all the overhead just so we can have less time writing custom css? Surely you jest. Devs should not define their jobs as cookie cutters. We use common stuff as a base to start work on the customized business facing solution yo.
I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic. It was a pleasure to read and figure out. I could throw an intern at it and he would figure it out. Verbose as hell too.
> I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic.
I've worked on plenty of those. I've handled more traffic with uglier shit, too. This isn't a performance thing, nor is it a premature optimization thing. It's about developer productivity.
Refactors are faster. Components are easier to break down. Bugs are easier to catch at compile time. Some classes of bugs are entirely avoided. A LOT of UI logic makes a ton more sense when written declaratively (as React forces you to), than imperatively. And none of that is even getting into the realm of how much easier it is to find devs who will work on a ReactJS codebase (and even more so, will be happy to do so).
My field Python experience surpasses my Typescript/React experience easily 50x. And yet, I'll be much faster at picking up a new client's React/TS codebase than their equivalent Python one. The productivity gains are real.
Absolutely. He’s talking about custom CSS which has already been written for the organization. You don’t want to have someone waste time duplicating the style. They may be against a deadline or have higher priority tasks.
Plus, you may have gotten lucky with that app, but that’s very often not the case.
> Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do.
I don't know your job, your coworkers or your context. You may be right… probably not, though. React is a powerhouse in terms of developer productivity.
I have 17 years of software engineering behind me, and while I dabbled in a lot of things, most of these years have been spent using Python (and Django). And the current typescript+react ecosystem is several orders of magnitude more productive than anything else I've ever used, be it in Python or any other language.
You say "overcomplication", but React is far, far simpler than Django's template system. You're basically throwing away a LOT of overly complex shit that is simply there to generate HTML in non-html. React generates HTML with actual HTML -- well, okay, JSX/TSX is not technically HTML, but it maps perfectly where it needs to, and still gives you that added layer of typing for extra safety. React can't generate invalid HTML, and if your app compiles, you won't ever have a client-side syntax error.
I can't stress how bad a tool Django templates are for the job of generating HTML.
Oh and JS without React? I mean, sure, if you're literally just adding a couple of dynamic elements on a mostly static site. If you're actually going to have JS-driven UI elements in a dynamic interface, just use React. Not saying you have to, but it's probably the correct choice.
There's a lot of purists out there who will cry foul at 50kb more of some gzipped code, but do you want to spend your time tweaking and manually testing imperative UI behaviour for all your little widgets and how they interact with each other, or do you want to be productive?
Feel free to email me more context on your situation and I can give you a more specific assessement … but my €.02 here is, spend some time learning react & typescript, and playing with the more useful bits of it (NextJS+Typescript). It's not time that will be wasted either way. Give it a week and re-assess.
I’m doing this and so far it’s great. I’m not using Gatsby or hosting the React app separately though... serving from the Django server is good enough for my use case.
> Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO.
"I don't want to go full SPA with Django as this defeats the purpose of Django IMO" -> What is this "purpose" ? Django is here to help me model my database, handle few permissions and bring few API up online, I see no problem with having a PWA in front of it. Are you trying to get all of your website server rendered ? In which case you could do that without having to worry about integrating it with Django... TBH after 5 years of react and 8 of Django, i'm just not mixxing them up except for the front-end calling a query on the back-end (which both can be served at the same domain using nginx) ;
When you say "tell webpack where to put the files" what do you mean exactly? I recommend just making one bundle per "app" (can be configured as different entry points in your webpack config), and then using the outputs as standard Django static files. I found django-webpack-loader to be a little to magical for my taste and solving a problem that didn't really exist for me (the need for refreshless hot reloading).
This is it. If you can’t connect to your database effectively and safety execute queries + migrations (looking at you people who write SQL queries by hand in Typescript) you’re just writing something that is one key stroke away from destroying your database.
> you’re just writing something that is one key stroke away from destroying your database.
Is it any more difficult to destroy your database in Django DSL than it is in raw SQL? We're using a lot of raw SQL at day job, and the two junior developers on our team who had no priory experience of working with SQL databases at all have picked it up just fine.
It just seems kind of like building a car by hand to me. Why would you want to use raw SQL when you can leverage the power of your favorite programming language? Isn't it cleaner to write a Model with Pythonic field constraints, methods, and subclassing? Don't get me wrong - knowing SQL is important for every developer, but one doesn't need to be an SQL expert to be a back-end development expert.
The ORM space is actually getting much closer. Both TypeORM and Objection.js are good options. But if you're talking about Django as whole then I totally agree.
I’ve considered them before along with Sequelize but their repos are chock-full of issues, and I’ve read some very negative opinions about all of them. They make me unsure that they’re production-worthy.
> unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS
In my opinion, JS development is unpleasant because of the many, many inconsistencies and corner cases that must be accounted for when writing code, the dumpster fire that is the npm ecosystem, and the lack of established frameworks like Django. Things like TypeScript make writing code less painful, but I only use JS when I have to (i.e. I need something to execute in a browser).
> something like nextjs - with built in frontend+backend is ideal.
This is completely subjective, and I would disagree.
even just wiring up a management command / cron job is a huge pain in javascript right now with the require vs import stuff. typescript makes it better, but until type script is more supported this type of stuff is going to continue to be an issue.
Look, this argument is always thought provoking, but not worth any devs time to execute. Django/Rails/Spring/.Net have years of combined dev experience. They contain almost all the things every web application needs, with highly adopted off the shelf plugins for everything else. When engineers fall for the trap of Flask/Express/Sinatra/Go they don’t realize they’ll either be a. Writing everything the above frameworks have by hand or b. Cobbling together a ton of different/non related tools that may not be battle tested. In either case they spend time writing features we solved 20 years ago. My favorite example of this is database connections/migrations/translations.
You suggested using nextjs for the backend. This weeks flavor of nextjs database connections is to be done with Prisma. Setting the two up together is no walk in the park. So great, you’ve spent a week setting up Prisma and the layers which connect it to your API. You’ll probably now task yourself with connecting the database to a GraphQL API with a Playground (another week). What about auth? Hand roll of reach some the suggested Auth0 library for nextjs. Another week of integrating. You can see the pattern. Meanwhile, the Django user has everything setup in day one, nextjs app for front end only deployed on day 2, and is building user features day 3.
We haven’t even talked about setting up request middleware, integration with logging tools, distributed tracing, exception aggregators, sending email, scheduled background tasks. Which you can spend another week for each or just go to your battle tested framework of choices’ doc page.
im very conscious that this may trigger a very opinionated war. so let me backoff for a moment.
My comment is in context of this project and not a generic statement. My startup is built entirely in python.
A boilerplate - by definition is a get started quickly tool for people that are (by choice or otherwise) not interested in going to the depths of a framework.
In that very particular context, a Nextjs based boilerplate will beat this one.
again, im not trying to crap over the OP's attempt. I seriously commend it. But if there's someone looking for a boilerplate to get something with a frontend/backend up and running quickly...i still do think doing it in one language/framework is much better.
P.S. And I do think TS is a fantastic language. But again, my point was not a purist Python vs TS/JS slugfest
But these templates you've linked to are frontend focused. Next doesn't really address the backend much at all. Most of what it does backend wise is to help the frontend (such as SSR).
If I needed a full webapp spun up quickly (db, auth, api emails, etc), I'd choose Django before Next.
Don't get me wrong, I like and use Next. But from what I can understand, it's just not as complete as Django, Rails, etc. I think the fact that template is using Firebase for its storage says a lot.
Next itself does not help you with Firebase or databases or any kind of persistent storage. It's entirely left up to you. That's a huge difference from Django, Rails, etc. The same is true of auth and many other things.
The nextjs one uses a third party (bigcommerce) as the back end.
Firebase is also a third party backend.
Any recommendations on one where you can own the backend yourself, like Django? Without composing all the pieces manually?
I'm currently running a Django backend, Vue frontend, and think Django is a fine tool -- but occasionally look for a nice cohesive Django alternative in the JS world.
I've bought a number of templates over the course of a year building my company's website.
The general result is that the code quality is very low and the class names are not specific enough, so you get bogged down in css when you try to customize things.
Fool me once ... fool me twice ... fool me three times ...
I'm very biased towards Python. I'm working on AutoML tools (created MachineLearning-as-a-Service web-service and open-source AutoML Python package). That's why I'm using Django. In my opinion it is very powerfull. There are for sure many people looking for easy start in Django+React setup, that's why I started writing tutorials.
fully agree - and in my first comment i do mention that if you are doing anything in math, then you NEED+HAVE to stay in python.
No choice - even if you love javascript ;)
Totally agree. Flask (or any other micro-framework) is great for beginners because there is very little configuration and it maps closely to the request-response cycle. But, if you are working on a real project and have to ask between a full-stack or micro framework, you probably don't even know the things you are missing by choosing a micro-framework. A lot of thought has been put into Django, most Flask setups I have seen are not at the same level of quality.
You should NOT use nuxt, react, gatsby in bussiness environment for anything but internal employee-facing applications.
Reasons being, that nextjs&friends(hydrated site alongside js-based navigation) make it:
a)impossible to do decent a/b testing;
b)impossible to do decent personalizations;
c)impossible to have decent page load times;
d)impossible to have any decent web analytics;
e) team is unable to understand what's going on with a page after looking into source code - devs get more control in expense of ppc teams, ux teams, cro teams, analytics teams, data teams, sysadmins, monitoring teams. This is the biggest killer argument even though a)-d) arguments might seem fancier at first. Sooo many devs just can't ever relate to this, because yes - reactgasm is a strong emotion. But you have to think about others. Devs can survive jquery. Marketer can not survive react.
So You just stick to css+html+vanilla js+web components(svelte or stencils or whatever). That is based on my 8+ years working as a marketer/product owner building billion-grade ecommerce projects.
As you have not spent too much time on elaborating your points but throwing out strong opinion to the wild, I will do more or less the same.
Which, if you look at it closer - "'dataLayer',4000," 4000 ms mean that you basicly make your website white blank for up to 4s while all the ab testing loading stuff is happening behind the scenes.
And this makes your initial load UX a very very awkward experience.
If personalization / ab testing is happining on load-time parameters (i.e. country), well, you are in a situation where I have mentioned hydrated site is out of options to be considered for the stack selection.
As for other points, let me elaborate on web analytics. Google Analytics default seup collect around 70-80% of transactions/events/pageviews data. If you want to fix this, you revert to server-side stuff, and that's where you meet js-based navigations.
Absolutely agreed. One thing that really concerns me is that the newest generation of web developers really has no idea that web development doesn’t need to be so bloody complex.
I’m working on a simple internal enterprise app for managing document workflow right now. It should just be a basic CRUD application maintained by 2-3 devs at most. Because of how it’s architected (extreme normalization on the backend, Vue used for every single simple component on the front end), we have a team of 15 devs on the project.
I had to update the options in a simple select drop-down menu last week. It took me a full day and modifying six files to get it right. 10 years ago it would have been a 20 minute task and two files.
It’s sickening because the entire team thinks this is normal.
There was a story on HN recently about a security breach on some website because of a hand written auth scheme. I was surprised with how many people just thought it was normal to hand roll auth stuff. I think it comes mostly from the server side JS crew but it is definitely disturbing the amount of wheels being reinvented out there
a) Haven't done much A/B testing in a while, but Optimizely has what seems like a huge library for React, which suggests this is false.
c) I can attest that this is complete bollocks, I have React apps in production that are blazing fast, and I have seen many others in the wild. I've also built a few prototypes in Next.js and got near-perfect speed scores without optimizing anything. I can only imagine it's gotten better in the last year or so.
d) I guess depends on definitions of "decent" analytics, but I've seen a few analytics solutions working with React in production and they worked more than decently.
As a closing thought, Facebook uses React all over the place. They are massive on personalization, analytics and A/B testing, for better and for worse, at hyperscale. I guess you think it's just the exception that confirms the rule?
Reply to a) No, it is not false at all. Let's skip the brands out of discussion. Client side a-b testing is impossible to be decent. Period. The fact that optimizely built something for react is not a valid argument.
Reply to c) Your react app is 30% slower that anything decent. Why would any bussiness owner would ever sign this off to happen in their acquisition funnel(i.e. where user experience is especially crucial)?
Reply to d) Decent is ~100% correctness and completeness versus ~70%.
Reply to "I guess you think it's just the exception that confirms the rule?" -> You keep mentioning companies and brands instead of implementations which suggest you have no experience on the implementation part. That is the thing - facebook does a/b testing server-side. And i'll just mention that facebook also used react to create their, arguably, second most important project - facebook ads manager. And it's a complete 'bollocks'(using your words) architectural decision to build such tool for react - it's a UX as terrible as it can get and i've used it for 5 years and I know at least 100 advertising agency employees who would sign this statement with their sweat and they are one of two. Just to give a counter-argument of the same origin as Yours one.
So am very thankful for constructive discussion - all your arguments are fair and well elaborated. Just you can't buy any of them. Really hope am not insulting with my strong opinions, always happy to discuss further!
> You keep mentioning companies and brands instead of implementations
This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.
> Client side a-b testing is impossible to be decent
OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
> Your react app is 30% slower that anything decent
How would you know, anyway? The web apps I've worked on (not app, in singular) are faster than just about anything "decent", faster than many SSR industry peers or competitors, and objectively so under many industry-standard performance tests.
You further resort to a personal attack by questioning my implementation or engineering chops without any evidence of them - just my evidence-based opinion that SPAs are not inherently slow at all (they really aren't).
I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist - surely that could be a telltale sign of a really poor engineer?
>> This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.
Facebook is a product of 100000 different implementations which might theoretically change daily. If we were discussing can we do thing X or Y with MySQL, and you'd say 'look - there is facebook, it's working, it means you can('t) do thing X or Y with MySQL' - that would not not be very specific. I'll add term 'architecture' to discussion.
>> OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
So, let's talk architectures. "Netflix, Facebook, Instagram, AirBnB" - if you can, please specify what architecture and for what purpuse they have implemented. And tell about the specific example. We will have something to discuss, now we just don't.
For instance, https://docs.developers.optimizely.com/full-stack/docs/optim... -> this is architecture of optimizely experiment for React. This is other feature https://www.youtube.com/watch?v=NRLhlTopFzw being showcased, but you can get a sense of how the SDK is being used. Let's say bussiness requirement is to run experiment where for 50% of traffic you show nothing at the top of the page, for other 50% you show country flag image and city flag(cout of arms) image. Site is built with next.js. The next day you throw next.js out and build your site from scratch on other page. How would you implement that?
>>How would you know, anyway?
a) You use common technical sense and realize that's the only way it can be;
b) If you don't trust your guts, you go and analyze performance tests: https://css-tricks.com/radeventlistener-a-tale-of-client-sid... and learn that react is 40x slower that the industry standard. Not stressing 40x, just - it's slower, was and will always be (except RenderToStaticMarkup and Server Side Components).
c) You go and check what world is using - https://w3techs.com/technologies/comparison/js-jquery,js-rea... , you realize that, statistically speaking, no one is actually using react, probably for a reason. (Ok ok, this argument is also a bit overstrech, and yet... :)
>> 'faster than many SSR industry peers or competitors'
'Not worse then most competitors' is not how you win in bussiness competition, is it? :)
>> You further resort to a personal attack
Honest apologies if that sounded that way. If I may - I take all that back.
>> I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist
Ok, now we talk. For the record - I write a lot of client-facing vue code, sometimes a bit of react. Love both, great developer experience, I call them both 'godsend' for frontend development.
Yes, I do turn radical when people start shouting 'react is the answer, what was the question'...
I love React and JavaScript but I completely disagree with this. I've moved to Django for my back-ends and it's an infinitely better experience than any Node.js-based backends. It provides a structure and set of facilities which are completely unmatched in the JS server world.
I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.
I was reading through the tutorial and it has you add CORS to enable api requests during development. I think using create-react-app's proxy feature might be a better fit:
As someone who has worked daily with React (and Django) for more than 5 years, I am always surprised to see how many boilerplates and tutorials include redux.
It’s a tool that solves very specific issues that most people won’t have and often adds quite a bit of complexity.
I like the way redux divide the code into actions and reducer. In my opinion the application code is clear with redux.
Off the topic, I mainly write in Python. I started programming in C/C++. I very often miss header files from C/C++ during Python programming. In C++ header files you have the full interface definition and it was easy to understand the code. Somehow, the redux and C header files are for me similar (in the sense of clear code).
I was definitely had the same feeling when writing redux! The separate of actions, types, and reducers is quite nice. You can still replicate these ideas with the Context API if you choose too.
The tutorial is still under the development and I will update the User model logic for sure (for payments and teams features). The 'wild' overwrite of User model was minimal to set email as required field in User model.
In case you're looking for something similar, but django-boilerplate doesn't adjust, try cookiecutter-react-django instead. It has Heroku deployment, and a minimalistic approach.
https://github.com/fabiospampinato/cash of you want to build website, vue.js if you want to build an app. In app world, vue.js (options api specifically, which is easier to understand for newcomers) can get up and running faster than react. After you master app development, it comes down to ecosystem/tooling (pros and cons here with both react and vue) and mostly - personal preference.
I admire the motivation here to offer a boilerplate to the community using these tools, but it feels like a lot of this has been solved by the Baas providers like AWS Amplify, Azure Static Web Apps, Firebase, etc.
These services all support your choice of front-end and back-end programming language. All these providers also allow hooks into features like security, database, apis, ci/cd, and so on. You would be in a serverless architecture also which provides scalability and keeps costs low up front. Not trying to discredit the author here, which is admirable in the intent, but feels like it's trying to solve for something that several other solutions exist for unless I'm missing something critical.
Serverless type things are totally fine if you’re into that. But it can be nice to just have a simple backend running on a server. No different services to think about, just simple code. For me Django is the way to go because I’ve been using it for years, for others it might be some other language/framework. You should most definitely continue to do you, but for me that’s what works.
Only SRR + some javascript (modals, effects, etc).
What I am missing? Serious question, Am I missing TOO much or maybe 20% productivity?
1. I am a one man shop doing Django sites, SRR only.
When I need to interact with front end for more "Reactivity" I use javacript + a view exporting json.
2. About admin: It is good for me or the operator but I dont feel like my user should be using it?
Then I do my own "admin" for the customer.
Please what I am missing?
The #1 I feel once you have 2-3 they may make sense (separating functions).
The #2 the community answer was : "Not for user, only staff or operator and not for general consumption"
If the site is mostly static then SPA isn't worth it. If you've got a lot of functionality SPA let's you make site way more interactive without hacks.
The best of both worlds is a static site sprinkled with React components where they make sense. Angular can't really do this, but react is designed to work in parts of pages.
So if your customer wants one really crazy sortable filterable list view you can do that in clean react code instead of a bunch of jacky jquery
after this week's release of React Server Components I'm feeling even more convinced that having 2 tools to tackle different ends of the problem is better than trying to make 1 tool fit everything.
Hey, thanks for comment and sharing the React Server Components news - have checked https://reactjs.org/blog/2020/12/21/data-fetching-with-react... . 18:02 - "server components can not have any interactivity". So essentially this is (something similar to) renderToStaticMarkup with some bells&whistles.
Would live to share quote from https://news.ycombinator.com/item?id=25358976: "I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance".
Am wondering if anyone tried to bundle vanilla js for dom manipulations alongside server-rendered react componenents which deliver html+css server-side. Where do you put js code inside the component folder? What are the patterns and best practices of using react only for html+css composition and using vanilla js for interaction? Thanks a lot for any tips!
I take a similar approach to you, and am also a solo dev. I would take a serious look at client-side frameworks if I was building something more appy than websity. It might also make more sense if I was working with others and there were separate front end and back end people so defining some kind of back/front end interface would make sense.
With regard to the admin, my experience is that usually the customer will have specific tasks that they need a workflow for, and the admin panel is often not a good fit for that (and things get messy quickly if you try to bend the admin panel to be something it isn't).
As someone with a similar skillset, I decided to use React for a the frontend for a new project as a learning experience, since I assumed I'm missing out on something by using JS + JSON from a Django view when something asynchronous or interactive was needed.
After a week of wasting time due to needless complexity caused by React (I don't want an SPA), I took React out of the loop and got on with actually developing features that are needed. I don't feel like anything is missing from the final product nor am I missing out on any productivity gains that would be realized after my initial learning curve.
I’m curious to hear what about creating a multi-page application you found to be limited by react. react-router solves this problem quite well. Personally I’ve had a lot of fun using create-react-app to quickly get rolling on side projects without worrying about the painful setup bits and the documentation is pretty good.
Having said that, I don’t know enough about your use case to say that react is a better choice.
Having a React / Vue whatever in addition to your Django server allow you to split the "View" from the "Model-View-Control" paradigm that Django respect, when you have django & react, Django is only "MC" and react becomes "V"
Simply put, when you are in the template paradigm you are producing HTML files, when you are using React you are generating HTML.
For instance, I'm not building up an "account" page, i'm building up a "detail" page that can be reused with a query that I'm passing in. That query is a function that defines the call to Django. Eventually I'm passing parameters to the component to drive it's behaviour.
I'd simply suggest you to go learn some react, it is difficult and it takes time, but it will allow you to see more solutions to problems that you might be handling in the "industrial" way (eg: writing 10 templates and having some jquery mixxed in the html)
I've been working with django and react for a while now, and i'm now used to 100% coverage without much hassle and very good productivity (dare I cite my boss :) )
It depends on your use case. I wrote many web apps w/ frameworks like Django before migrating to React several years ago. The point I wanted to add was, when I started using React, (after the very initial hump) it felt like a breath of fresh air. I didn't feel complicated or confusing, it felt like it was de-complicating everything I was doing. My point is, if it doesn't feel that way, you may not have the problems React solves well and probably aren't missing out.
It is always the same thing, someone comes and says, please use Django, then someone comes and say but I'm going to use React in the front, then someone comes and say, why would I need react?
A framework is an opinionated piece of code that helps several people understand the code everyone is creating.
If you are alone, the need for a front end framework is equal to 0
Embedded apps is the usual case, but I don’t see the point with anything else, with its limited concurrency, its highly insecure and poor user management.
Using SQLite on a production environment and only migrating up when you fill it up sounds like a big wtf
I've been evaluating potential replacements for the Django admin to provide a path for progressive evolution as apps outgrow Django, and have found https://marmelab.com/react-admin/Readme.html -- anyone got other generated admin platforms they like for handling CRUD / mutations?
I think the Django admin is great, I use it a lot and recommend it for new/small projects, but it's tightly coupled to the Django ORM which can be restrictive in some usecases.
- Should use the django-env package to have a generic settings file
- Models are incomplete
- Where does registration happen? In the backend? Fronted?
- Weird code around the user model
- Unused imports
Overall this needs some polish in order to be a strong boilerplate solution. I’d say request code reviews from the community in order to improve it. Also think about using cookie cutter for it as well.
118 comments
[ 3.3 ms ] story [ 175 ms ] threadI wonder how one will horizontally scale this app if need be. Would you separate out nginx onto a different instance and have it pass traffic back and forth between several instances running the django backend? Whatever the way to do it, it would be cool to see that added as an article here :)
Coming from academia/data science and learning this from the scratch, the python backend + js frontend boilerplates are quite cryptic. The tools for sure seem useful, but there's a lot to grasp for a noob - rabbits, celeries, and so on.
There is a docker-compose provided to set up and run this boilerplate application on single server machine. It can be easily adjusted to your needs.
Is there anything on the Demo page (https://boilerplate.saasitive.com/) that would be different?
In my experience as a user, everything that uses React is always an annoyance in one way or another. But I am happy to understand if there are legit use cases.
Otherwise django + react makes sense when there're different people (or teams) handling the frontend and the backend.
The boilerplate code runs with docker-compose on single server but in the future the frontend and backend can be easily divided, so separate teams can work on them.
The typical hn startup is expected to grow to that size, to an enterprise scale, so you’re not going to see a lot of people use Django.
Can you list one annoyance you see as a user with React?
Does anyone have a solution they like for this kind of isomporphic Django problem?
1. https://github.com/owais/django-webpack-loader
I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries.
You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
https://reactjs.org/docs/code-splitting.html
I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar)
Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls.
My goal was to minimize customization while retaining the "spirit" of both Django and react.
I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling.
It also makes it more likely the react app can be migrated to new versions of CRA.
The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*.
Key aspects of my implementation are:
While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file.Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2]
I have not released my solution but I have stubbed out the problem and solution description [3].
If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4.
All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app.
Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA.
Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend.
[1] https://github.com/gsoft-inc/craco
[2] https://github.com/gsoft-inc/craco/pull/203
[3] https://github.com/banagale/create-react-app-django
It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload.
And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).
A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well.
The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup).
The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
There are some new ones coming on the scene, like Dino and Tortoise, but nothing mature.
Jinja templates at least let you use normal python syntax in the tags. You can easily do something like {{ items.filter("books")[:5] }} — in Django, you would have to write a special accessor or template tag to call filter("books") as it doesn't let you specify arguments to function calls, and you'd use the awful |slice:":5" to slice it.
But more than anything else, Django templates are not just untyped, they are untypeable. You can't really validate them. Best you can do is try to compile them in a CI job see if anything fails. Not to mention that the way you're outputting HTML essentially arbitrarily anywhere in the page means there is no way for the editor / tools / even yourself to know if some piece of code is syntactically or semantically valid in context. Got a list_item.html with a naked "<li>{{ item }}" inside? Why the fuck not! Could even be raw css or js outside a tag in your template, could be valid in some includes, invalid in some others. Everything goes. You can't even know whether a template is in use, as it's completely arbitrary code that calls these template inclusions, via string filenames (which therefore can be included however you want).
It's impossible to create these problems with react/typescript. And react heavily encourages code reuse: creating reusable components that are as small as possible. Django templates encourage copy-pasting.
1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy.
2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved.
3. Use https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis.
Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.
Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN.
In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON.
In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
why?
Django's frontend rendering is still a major part of the framework, so advising everyone not to use it in a post about Django is a bit misgiving.
Having something cohesive is much more reliable than having some template there, some js there, some template there again.
If you stick up to one way of doing things, testing and debugging becomes trivial because you are not mixing up three different way of doing something
Can you give me a solid usecase of why not to use djangos templating and use - as per your example - an SSG?
Seems like the usecases are edge cases. Why use Django just to make api calls when smaller and nimbler alternatives abound.
Its no wonder React devs command such a strong hourly fee. They'll mostly be fixing dung with more dung and hooks.
Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do. The code will be verbose but there is no magic or illusion. Anyone from junior intern to senior dev can understand the codebase without much help. Its not that big either.
grrr
Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production.
After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously).
Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around.
Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas.
For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home.
https://www.getzola.org/
IME (not a senior dev) it's easier to turn the entire front-end over to React. I don't want to rebuild the wheel and write custom CSS every time I need a new component. I want to be able to plug in common components, with unsurprising and predictable props. If I'm already using React for dialog boxes, it may well as handle my click handlers as well. Then it can also grab data.
I agree with the spirit of avoiding more dependencies though and for this reason I try to avoid Redux. I find React absolutely invaluable for styling and reusable components however.
You are telling me it is worth migrating to a new architecture/build with all the overhead just so we can have less time writing custom css? Surely you jest. Devs should not define their jobs as cookie cutters. We use common stuff as a base to start work on the customized business facing solution yo.
I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic. It was a pleasure to read and figure out. I could throw an intern at it and he would figure it out. Verbose as hell too.
I've worked on plenty of those. I've handled more traffic with uglier shit, too. This isn't a performance thing, nor is it a premature optimization thing. It's about developer productivity.
Refactors are faster. Components are easier to break down. Bugs are easier to catch at compile time. Some classes of bugs are entirely avoided. A LOT of UI logic makes a ton more sense when written declaratively (as React forces you to), than imperatively. And none of that is even getting into the realm of how much easier it is to find devs who will work on a ReactJS codebase (and even more so, will be happy to do so).
My field Python experience surpasses my Typescript/React experience easily 50x. And yet, I'll be much faster at picking up a new client's React/TS codebase than their equivalent Python one. The productivity gains are real.
Plus, you may have gotten lucky with that app, but that’s very often not the case.
I don't know your job, your coworkers or your context. You may be right… probably not, though. React is a powerhouse in terms of developer productivity.
I have 17 years of software engineering behind me, and while I dabbled in a lot of things, most of these years have been spent using Python (and Django). And the current typescript+react ecosystem is several orders of magnitude more productive than anything else I've ever used, be it in Python or any other language.
You say "overcomplication", but React is far, far simpler than Django's template system. You're basically throwing away a LOT of overly complex shit that is simply there to generate HTML in non-html. React generates HTML with actual HTML -- well, okay, JSX/TSX is not technically HTML, but it maps perfectly where it needs to, and still gives you that added layer of typing for extra safety. React can't generate invalid HTML, and if your app compiles, you won't ever have a client-side syntax error.
I can't stress how bad a tool Django templates are for the job of generating HTML.
Oh and JS without React? I mean, sure, if you're literally just adding a couple of dynamic elements on a mostly static site. If you're actually going to have JS-driven UI elements in a dynamic interface, just use React. Not saying you have to, but it's probably the correct choice.
There's a lot of purists out there who will cry foul at 50kb more of some gzipped code, but do you want to spend your time tweaking and manually testing imperative UI behaviour for all your little widgets and how they interact with each other, or do you want to be productive?
Feel free to email me more context on your situation and I can give you a more specific assessement … but my €.02 here is, spend some time learning react & typescript, and playing with the more useful bits of it (NextJS+Typescript). It's not time that will be wasted either way. Give it a week and re-assess.
But it's the best of both worlds: Django SSR using statically typed JSX.
See for example my blog or business sites (on profile). Both SSRed by Django using React templates.
Then when the client loads, it gracefully "attaches" for dynamic interactive behavior as needed.
By far the biggest pain point is having to run node and python on the server. So I'm working on the best way to do that.
What we want from something like react after all is reactivity, and it's possible to get that if you were to use something like https://github.com/jonathan-s/django-sockpuppet
So if you've got an open mind and want to test it's there for the taking.
More details on this approach here: https://www.saaspegasus.com/guides/modern-javascript-for-dja...
something like nextjs - with built in frontend+backend is ideal.
Is it any more difficult to destroy your database in Django DSL than it is in raw SQL? We're using a lot of raw SQL at day job, and the two junior developers on our team who had no priory experience of working with SQL databases at all have picked it up just fine.
In my opinion, JS development is unpleasant because of the many, many inconsistencies and corner cases that must be accounted for when writing code, the dumpster fire that is the npm ecosystem, and the lack of established frameworks like Django. Things like TypeScript make writing code less painful, but I only use JS when I have to (i.e. I need something to execute in a browser).
> something like nextjs - with built in frontend+backend is ideal.
This is completely subjective, and I would disagree.
You suggested using nextjs for the backend. This weeks flavor of nextjs database connections is to be done with Prisma. Setting the two up together is no walk in the park. So great, you’ve spent a week setting up Prisma and the layers which connect it to your API. You’ll probably now task yourself with connecting the database to a GraphQL API with a Playground (another week). What about auth? Hand roll of reach some the suggested Auth0 library for nextjs. Another week of integrating. You can see the pattern. Meanwhile, the Django user has everything setup in day one, nextjs app for front end only deployed on day 2, and is building user features day 3.
We haven’t even talked about setting up request middleware, integration with logging tools, distributed tracing, exception aggregators, sending email, scheduled background tasks. Which you can spend another week for each or just go to your battle tested framework of choices’ doc page.
My comment is in context of this project and not a generic statement. My startup is built entirely in python.
A boilerplate - by definition is a get started quickly tool for people that are (by choice or otherwise) not interested in going to the depths of a framework. In that very particular context, a Nextjs based boilerplate will beat this one.
As an example, let me share a nextjs template that you can buy for 20$ https://themeforest.net/item/react-material-bootstrap-4-admi...
https://themeforest.net/item/react-next-modern-landing-page-...
again, im not trying to crap over the OP's attempt. I seriously commend it. But if there's someone looking for a boilerplate to get something with a frontend/backend up and running quickly...i still do think doing it in one language/framework is much better.
P.S. And I do think TS is a fantastic language. But again, my point was not a purist Python vs TS/JS slugfest
If I needed a full webapp spun up quickly (db, auth, api emails, etc), I'd choose Django before Next.
e.g. https://nextjs.org/commerce
here's one with Firebase auth, graphql, everything already setup https://themeforest.net/item/livani-react-next-ecommerce-sto...
Next itself does not help you with Firebase or databases or any kind of persistent storage. It's entirely left up to you. That's a huge difference from Django, Rails, etc. The same is true of auth and many other things.
Firebase is also a third party backend.
Any recommendations on one where you can own the backend yourself, like Django? Without composing all the pieces manually?
I'm currently running a Django backend, Vue frontend, and think Django is a fine tool -- but occasionally look for a nice cohesive Django alternative in the JS world.
The general result is that the code quality is very low and the class names are not specific enough, so you get bogged down in css when you try to customize things.
Fool me once ... fool me twice ... fool me three times ...
Reasons being, that nextjs&friends(hydrated site alongside js-based navigation) make it:
a)impossible to do decent a/b testing;
b)impossible to do decent personalizations;
c)impossible to have decent page load times;
d)impossible to have any decent web analytics;
e) team is unable to understand what's going on with a page after looking into source code - devs get more control in expense of ppc teams, ux teams, cro teams, analytics teams, data teams, sysadmins, monitoring teams. This is the biggest killer argument even though a)-d) arguments might seem fancier at first. Sooo many devs just can't ever relate to this, because yes - reactgasm is a strong emotion. But you have to think about others. Devs can survive jquery. Marketer can not survive react.
So You just stick to css+html+vanilla js+web components(svelte or stencils or whatever). That is based on my 8+ years working as a marketer/product owner building billion-grade ecommerce projects.
As you have not spent too much time on elaborating your points but throwing out strong opinion to the wild, I will do more or less the same.
Happy to discuss in comments though :)
Doesnt react have like a massive ecosystem of integrations around this ? for example Optimizely - https://docs.developers.optimizely.com/full-stack/docs/javas...
what do you think ? i mean i dont like kubernetes...but the ecosystem is already there right ?
Which, if you look at it closer - "'dataLayer',4000," 4000 ms mean that you basicly make your website white blank for up to 4s while all the ab testing loading stuff is happening behind the scenes.
And this makes your initial load UX a very very awkward experience.
If personalization / ab testing is happining on load-time parameters (i.e. country), well, you are in a situation where I have mentioned hydrated site is out of options to be considered for the stack selection.
That's when you either try to go this way with gatsby: https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript... .
That's when you are stuck with sapper: https://stackoverflow.com/questions/64507516/how-to-disable-... .
That's when you end up in tickets like this with Nextjs: https://github.com/vercel/next.js/issues/4381 . And never look back.
Take a look at my top comment of https://news.ycombinator.com/item?id=25342767 for more details.
I’m working on a simple internal enterprise app for managing document workflow right now. It should just be a basic CRUD application maintained by 2-3 devs at most. Because of how it’s architected (extreme normalization on the backend, Vue used for every single simple component on the front end), we have a team of 15 devs on the project.
I had to update the options in a simple select drop-down menu last week. It took me a full day and modifying six files to get it right. 10 years ago it would have been a 20 minute task and two files.
It’s sickening because the entire team thinks this is normal.
c) I can attest that this is complete bollocks, I have React apps in production that are blazing fast, and I have seen many others in the wild. I've also built a few prototypes in Next.js and got near-perfect speed scores without optimizing anything. I can only imagine it's gotten better in the last year or so.
d) I guess depends on definitions of "decent" analytics, but I've seen a few analytics solutions working with React in production and they worked more than decently.
As a closing thought, Facebook uses React all over the place. They are massive on personalization, analytics and A/B testing, for better and for worse, at hyperscale. I guess you think it's just the exception that confirms the rule?
Reply to c) Your react app is 30% slower that anything decent. Why would any bussiness owner would ever sign this off to happen in their acquisition funnel(i.e. where user experience is especially crucial)?
Reply to d) Decent is ~100% correctness and completeness versus ~70%.
Reply to "I guess you think it's just the exception that confirms the rule?" -> You keep mentioning companies and brands instead of implementations which suggest you have no experience on the implementation part. That is the thing - facebook does a/b testing server-side. And i'll just mention that facebook also used react to create their, arguably, second most important project - facebook ads manager. And it's a complete 'bollocks'(using your words) architectural decision to build such tool for react - it's a UX as terrible as it can get and i've used it for 5 years and I know at least 100 advertising agency employees who would sign this statement with their sweat and they are one of two. Just to give a counter-argument of the same origin as Yours one.
So am very thankful for constructive discussion - all your arguments are fair and well elaborated. Just you can't buy any of them. Really hope am not insulting with my strong opinions, always happy to discuss further!
This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.
> Client side a-b testing is impossible to be decent
OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
> Your react app is 30% slower that anything decent
How would you know, anyway? The web apps I've worked on (not app, in singular) are faster than just about anything "decent", faster than many SSR industry peers or competitors, and objectively so under many industry-standard performance tests.
You further resort to a personal attack by questioning my implementation or engineering chops without any evidence of them - just my evidence-based opinion that SPAs are not inherently slow at all (they really aren't).
I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist - surely that could be a telltale sign of a really poor engineer?
Facebook is a product of 100000 different implementations which might theoretically change daily. If we were discussing can we do thing X or Y with MySQL, and you'd say 'look - there is facebook, it's working, it means you can('t) do thing X or Y with MySQL' - that would not not be very specific. I'll add term 'architecture' to discussion.
>> OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
So, let's talk architectures. "Netflix, Facebook, Instagram, AirBnB" - if you can, please specify what architecture and for what purpuse they have implemented. And tell about the specific example. We will have something to discuss, now we just don't.
For instance, https://docs.developers.optimizely.com/full-stack/docs/optim... -> this is architecture of optimizely experiment for React. This is other feature https://www.youtube.com/watch?v=NRLhlTopFzw being showcased, but you can get a sense of how the SDK is being used. Let's say bussiness requirement is to run experiment where for 50% of traffic you show nothing at the top of the page, for other 50% you show country flag image and city flag(cout of arms) image. Site is built with next.js. The next day you throw next.js out and build your site from scratch on other page. How would you implement that?
>>How would you know, anyway?
a) You use common technical sense and realize that's the only way it can be;
b) If you don't trust your guts, you go and analyze performance tests: https://css-tricks.com/radeventlistener-a-tale-of-client-sid... and learn that react is 40x slower that the industry standard. Not stressing 40x, just - it's slower, was and will always be (except RenderToStaticMarkup and Server Side Components).
c) You go and check what world is using - https://w3techs.com/technologies/comparison/js-jquery,js-rea... , you realize that, statistically speaking, no one is actually using react, probably for a reason. (Ok ok, this argument is also a bit overstrech, and yet... :)
d) You can only know for sure by building stuff and comparing. You build https://turboeshop.com/fastestpageintheworld/ and https://gatsbyeshop.com and compare: https://imagebin.ca/v/5lrH1VnQBac7 .
>> 'faster than many SSR industry peers or competitors'
'Not worse then most competitors' is not how you win in bussiness competition, is it? :)
>> You further resort to a personal attack
Honest apologies if that sounded that way. If I may - I take all that back.
>> I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist
Ok, now we talk. For the record - I write a lot of client-facing vue code, sometimes a bit of react. Love both, great developer experience, I call them both 'godsend' for frontend development.
Yes, I do turn radical when people start shouting 'react is the answer, what was the question'...
I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.
https://create-react-app.dev/docs/proxying-api-requests-in-d...
It’s a tool that solves very specific issues that most people won’t have and often adds quite a bit of complexity.
Off the topic, I mainly write in Python. I started programming in C/C++. I very often miss header files from C/C++ during Python programming. In C++ header files you have the full interface definition and it was easy to understand the code. Somehow, the redux and C header files are for me similar (in the sense of clear code).
ie.
Their approach in accounts models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
Over the standard approach in their notes models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
[0]: https://docs.djangoproject.com/en/3.1/topics/auth/customizin...
https://github.com/ohduran/cookiecutter-react-django
These services all support your choice of front-end and back-end programming language. All these providers also allow hooks into features like security, database, apis, ci/cd, and so on. You would be in a serverless architecture also which provides scalability and keeps costs low up front. Not trying to discredit the author here, which is admirable in the intent, but feels like it's trying to solve for something that several other solutions exist for unless I'm missing something critical.
But I hope some of HNers illuminated me.
I don't do React/vue .
Only SRR + some javascript (modals, effects, etc).
What I am missing? Serious question, Am I missing TOO much or maybe 20% productivity?
1. I am a one man shop doing Django sites, SRR only. When I need to interact with front end for more "Reactivity" I use javacript + a view exporting json.
2. About admin: It is good for me or the operator but I dont feel like my user should be using it?
Then I do my own "admin" for the customer.
Please what I am missing?
The #1 I feel once you have 2-3 they may make sense (separating functions).
The #2 the community answer was : "Not for user, only staff or operator and not for general consumption"
I would glad hear your points.
Thank You
The best of both worlds is a static site sprinkled with React components where they make sense. Angular can't really do this, but react is designed to work in parts of pages.
So if your customer wants one really crazy sortable filterable list view you can do that in clean react code instead of a bunch of jacky jquery
a) react/svelte/next/nuxt/gatsby/sapper/angular for apps;
b) django/rails/express.js for sites;
after this week's release of React Server Components I'm feeling even more convinced that having 2 tools to tackle different ends of the problem is better than trying to make 1 tool fit everything.
Would live to share quote from https://news.ycombinator.com/item?id=25358976: "I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance".
Am wondering if anyone tried to bundle vanilla js for dom manipulations alongside server-rendered react componenents which deliver html+css server-side. Where do you put js code inside the component folder? What are the patterns and best practices of using react only for html+css composition and using vanilla js for interaction? Thanks a lot for any tips!
With regard to the admin, my experience is that usually the customer will have specific tasks that they need a workflow for, and the admin panel is often not a good fit for that (and things get messy quickly if you try to bend the admin panel to be something it isn't).
After a week of wasting time due to needless complexity caused by React (I don't want an SPA), I took React out of the loop and got on with actually developing features that are needed. I don't feel like anything is missing from the final product nor am I missing out on any productivity gains that would be realized after my initial learning curve.
Having said that, I don’t know enough about your use case to say that react is a better choice.
Having a React / Vue whatever in addition to your Django server allow you to split the "View" from the "Model-View-Control" paradigm that Django respect, when you have django & react, Django is only "MC" and react becomes "V"
Simply put, when you are in the template paradigm you are producing HTML files, when you are using React you are generating HTML.
For instance, I'm not building up an "account" page, i'm building up a "detail" page that can be reused with a query that I'm passing in. That query is a function that defines the call to Django. Eventually I'm passing parameters to the component to drive it's behaviour.
I'd simply suggest you to go learn some react, it is difficult and it takes time, but it will allow you to see more solutions to problems that you might be handling in the "industrial" way (eg: writing 10 templates and having some jquery mixxed in the html)
I've been working with django and react for a while now, and i'm now used to 100% coverage without much hassle and very good productivity (dare I cite my boss :) )
A framework is an opinionated piece of code that helps several people understand the code everyone is creating.
If you are alone, the need for a front end framework is equal to 0
I would maybe use this if it was Django and React only, there are many things in the tech stack which I just don't want to get into.
For example, I would be happy with sqlite instead of postgres. I'll migrate if sqlite ever gets near capacity.
Adding Postgres to a Django project is like 20min of config... And it doesn't really modify the API, it only supersets it.
Using SQLite on a production environment and only migrating up when you fill it up sounds like a big wtf
I think the Django admin is great, I use it a lot and recommend it for new/small projects, but it's tightly coupled to the Django ORM which can be restrictive in some usecases.
- Should use the django-env package to have a generic settings file
- Models are incomplete
- Where does registration happen? In the backend? Fronted?
- Weird code around the user model
- Unused imports
Overall this needs some polish in order to be a strong boilerplate solution. I’d say request code reviews from the community in order to improve it. Also think about using cookie cutter for it as well.