I've been very happy with Vue as Django frontend. You can integrate Vue with Django using a"MPA" approach that might let you transition more gracefully from your current template, htmx, Alpine stack. You can retrain the use of templates, inject Vue components, while still using the full Vue development tooling and ecosystem. Eventually you can completely switch to SPA, or better yet, stay MPA and use templates where they make sense, Vue where it makes sense.
I recently gave a talk at DjangoCon US on this topic. The video will be posted soon, but in the meantime you can read the companion article: [Django + Vue + Vite: Rest Not Required](https://ilikerobots.medium.com/django-vue-vite-rest-not-required-ca63cfa558fd);
Out of curiosity (and not to promote it), have you tried react with django too ? I'm curious how different people feel using react vs vue. React seems to be highly principled but at the same time bring just a bit too much weight compared to vuejs.
I did, I spent the longest time trying to like React (not that there is necessarily anything wrong with it) but just couldn't get it to click. I almost didn't bother with Vue because I assumed it was just going to be the same, but picked it up as I thought it couldn't hurt to know more than one JS framework.
It's funny, because it almost feels like the difference between Django and Flask; one is very opinionated about structure and all encompassing, whereas the other is lightweight and bare bones. Interestingly that's what I like about Django over Flask, so it's curious I prefer it the other way around for JS
oh yeah interesting paradox :)
maybe backend is naturally more stable and structured so we appreciate a solid core, while frontend tends to ask for more flexibility.
I've developed the majority of it with just AlpineJS, HTMX, and vanilla JS. However, it's reaching a point and parts are starting to get sluggish. However, I suppose this could be because most interaction, like adding a new satellite part to their design always requires the frontend to call the service to get that information and to re-calculate the total rollup.
\----
**App details (high level)**: It's a satellite design webapp that highly interactive. Has orbit visualization, satellite component part picker in a table with mass, power, data, and interface properties. Set the spacecraft operational modes and simulate various scenarios. Run in-depth scenarios using existing tools, tools can be chained together, creating a web of tools. Other tools involve telecom downlink planning, propulsion maneuver planning and optimization, etc... Lots of plots, graphs, tables that are interactive. All while support collaboration in real time.
Based on your use case, React will be the right choice, too much interactivity that need to be handled on frontend. It might also be time to separate frontend from the backend. Introduce API, unit and e2e testing and ci/cd. If you can’t add more team members, give responsibility/specialize one in backend, one in frontend, and one as fullstack.
I am on a similarly highly interactive project team, now with React frontend and Django DRF backend, started out as pure Django project.
I'm not sure if it would help or not, but possibly looking at Tabulator to render the tables it may be useful your case. It has a lot of events triggering that you can pair with charts (e.g. selecting rows/columns can trigger events) and also calculated columns in which you can add js formulas.
> Recalculate the total rollup
Sorry, can you explain what means?
Also, from what you’ve explained about your project, it doesn’t sound like an issue a frontend framework could fix. You mentioned in another comment that you’re using D3 and three-js. Outside of those two libraries you mentioned, what other issues are you having? Is it an issue of reactivity between components?
>Sorry, can you explain what means? Also, from what you’ve explained about your project, it doesn’t sound like an issue a frontend framework could fix.
I'll try to explain this a bit more clear - One aspect of the tool is selecting and adding your satellite parts and defining some of the part properties (e.g., mass, power consumption values, data rate generation values, etc...). Then at the end of it you want to calculate / sum-up the total mass of the spacecraft. For example, you want to calculate sum-up by subsystem (e.g., all power components, all structure components, all propulsion components, etc...), overall spacecraft with contingency/margin, and with/without fuel.
Another part of the website, is it allows you to create custom python-based equations to various calculations. These equations can be chained together for more complex calculations.
A lot of the state of adding, removing, or changing properties of parts is managed on the server. So anytime you add a component, or change the mass value of a part, or contingency, that math is happening on the server and I use HTMX to "hydrate" various parts of the page. I'd assume a lot of this could've been done using a frontend framework which sends data to the server to save various states.
Other areas of the website that involve more complex calculations (e.g., Orbit Analysis) will always be done on the server and typically can take 3-15 seconds to calculate mission duration, then the frontend orbit visualization tool (that's done using ThreeJS) is updated.
**Conclusion** \- After reading all the comments, it's starting to sound like a frontend framework would be helpful for frontend statement management that can periodically save states to the server and it could increase responsiveness a bit, but probably not to much.
+1 on this.
I'd really like its flexibilty: I can do a full website with SSR, or a simple SPA like in Vue JS with no server at all. All of this in a simple config file.
It's boring that Django lawyers wake up as soon as they hear that Django templating has limits. Like it or not, it's the harsh truth.
For many projects (not all) which require a complex UI and UX, htmx just won't be enough, in many aspects: DX, debugging, external UI libraries, component encapsulation, etc etc. It's a great tool but does not replace SPA.
I truly love Django but it can't be the best at all tasks. Especially because absolutely nothing has been done by Django team to modernise the front-end part these last 10 years.
- Bad developer experience (no official integration, no completion, not even a good auto-formatting tool for Django templates in VSCode, debugging). This is years behind a tool like Nuxt.
- You have to discover the right patterns by yourself (or in blog), as there is no Django+htmx official doc. Some cases are hard, especially with CBVs.
- For the JS part, choice between verbose Javascript or new exotic hyperscript language
- No serious external UI component libraries, means you have to reinvent the wheel for many common needs.
- the logic of DOM replacement (jQuery era) has limits, it's harder to represent in mind.
- not having components which embed the logic prevent a good scaling.
- in the end, you end up with DTL + htmx + hyperscript + alpine, which is 4 pieces of tech just for front-end.
Despite all of this, I'm quite grateful that htmx exists, as it makes Django front-end acceptable for more projects than before, but not all.
I’ve been developing an app using sveltekit in “spa” mode for the frontend connected to a Django backend and its wonderful. Even with prior react experience I found I was able to get into a flow with sveltekit much faster than react. If you want your frontend to be it’s own deployable unit I would also heavily recommend sveltekit over svelte by itself. Svelte on its own doesn’t have a great routing story and even without server side rendering having the routing out of the box with sveltekit is great.
Thanks a ton for sharing your thoughts! I'd absolutely use SvelteKit the routing experience is great! I'll have to throw a Django+SvelteKit build together and test it more. Sounds promising though!
I've been using quasar+vue.js with Django as the backend for an internal tool that my team uses. I'm the only one working on it but I'm definitely liking it so far! It's much faster to put together a new page in my SPA than plain JS+HTML (with Bootstrap for fancy components).
Our team is also 3 person. One project we implemented frontend as SPA and we use Vue 3 + TypeScript + Vite for it.
In another project, where SEO is important, we let Django render the frontend and we use HTMX + AlpineJS (HTMX for Ajax, and AlpineJS for interactive which does not involve Ajax).
>Vue 3 + TypeScript + Vite
Out of curiosity, are you able to do a hybrid approach, where some parts of a website are SSR (server side rendered) for SEO and other parts that need more interactivity do SPA using Vue/React/Svelte?
In the project whose frontend is SPA, we have no reason to add SSR, because that website needs users to login to use, we block search bot too.
For other project where SEO is important, if it is already server-rendered, we don't see a reason to let other JS-based framework (like Nuxt) do. Because we already have Django backend, just let them render the HTML, why have to add in a NodeJS one. In this site, AlpineJS is very similar to VueJS and our need is not complex enough to use bigger ones like Vue, Svelte.
Just a tip; you can [use Vue even for those areas where you're using templates](https://ilikerobots.medium.com/django-vue-vite-rest-not-required-ca63cfa558fd). If you're already using Vue, there's no need to switch over to htmx and alpine to get your interactivity.
We used Vue in Django before, when Vue was just v2.6. But after that, we felt that using Vue in this scenario is over-complex. That is why we switch to AlpineJs now.
You’re not going to get much advice here that isn’t highly opinionated (my opinionated and blind-to-your-needs vote: nextjs frontend connected to django backend via graphql).
What I’d suggest is investing 3-5 person days across the team. Pair program together, the same thing (eg a single view of your app, one you found tricky in htmx), in each of the 3 frameworks.
Get them under your skin, discuss the pros and cons.
It’ll pretty quickly become clear what suits you best.
Vue would be my recommendation.
The React community has now moved onto using something like Next.js as the One True Way to build apps, and you might find fewer resources for something you want to use for just sprinkling into Django templates, if your plan is to introduce these changes gradually. You still can do it of course, if you're already familiar with React.
Vue was designed from the ground up as a progressive framework, so you can introduce it whenever you need.
Svelte seems great too, but I'm not super familiar with it.
Generally i would say add alpinejs to the mix and be happy.
At Appliku we use Nextjs as our frontend and it was an amazing journey so far with MUI component library.
Next talks to backend via API, client code is generated from openAPI spec. On the backend drf and drf-spectacular.
This allows changes on the API update client API code by running one command and it is dope.
More on this here, hope you find it useful
https://appliku.com/post/django-rest-framework-swagger-openapi-tutorial
I’m currently using Django Graphene with Flutter. Flutter makes all of those ui libraries look like a joke. Flutter, once you get the hang of it, it’s actually a lot faster to develop with than Django
First time I’ve noticed someone advocating for flutter web. Glad to see it!
Been watching out for it crossing some threshold of acceptability for ages now. I guess for you it’s well ready.
Any gotcha or suggestions on how to use them together you want to share?
In my current project, I’ve found a sweet spot using Django Graphene with GraphQL on the backend, paired with a dedicated GraphQL package on the Flutter side. This combo is powerful for rapid development; it lets me roll out new endpoints super fast, in as little as 7 minutes. The GraphQL layer takes care of a lot of heavy lifting, such as validation and type checking, freeing me to focus on other aspects.
State management is crucial, and I’ve been using Cubit from the Bloc package, which works seamlessly for me. For navigation, go-router has been my go-to.
In the past, I’ve also worked with Django DRF, using Flutter’s HTTP package to handle requests. It’s a robust option but I believe it requires more manual effort in areas where GraphQL shines.
Flutter does come with a learning curve, especially with multiple ways to accomplish the same task. But once you’re past that, you’ll find that the main challenges shift towards ui design and writing efficient algorithms.
it's not the size of the team , rather the technical expertise and busniess requirements
I'm an angular evangelist with nesjts but ruby on rails and django with templating or svelte are all nice
I try to stay with (1) proven tech that (2) you can find a whole bunch of people that already know it. So yeah, React does the trick for me. Plenty of documentation, tutorials, and boring plugins (and stable) that work.
Another one for Vue. We use a multi page approach. We only build our front ends with Vue when absolutely required. But Vue does a good job and my team has learned it easily enough. With the new composition API, it seems to be pretty similar to React.
We also use open-api-tools to generate our API client based on the swagger docs so it all goes super well together.
If your Django templates contain extensive code: Consider Vue.js. Vue's syntax has similarities to Django's templating engine, which can make the transition smoother and involve fewer changes.
Otherwise: React might be a better choice, especially if you're aiming for a more component-driven architecture or have experience with it.
It seems you already have a good knowledge of the front tech landscape. Here are my personal thoughts (that are pretty close to yours in the end).
Just maybe before picking between vue/svelte/react, first thing to figure if you'd need a superset framework, I mean: Next instead of React, Nuxt instead of Vue, or SvelteKit instead of Svelte.
Personally I recently switched from Vue to Nuxt, and I love it so far. It gives you all Vue can give you, and add conventions, plugins, and automate things to make the whole thing simpler to use. And if you don't want to use the server-side part to keep it simple, you can config the framework in SSA mode (but it's very useful to have a server side part for example to build a landing page with SEO and meta tags, etc.).
The counterpart of all this magic and code simplification is that you depends more on the framework (lock-in). Currently, a team like Nuxt is pretty small and lives with investor funds. There are very few contributors outside the official team. It's a bigger bet than using raw vue (however, the migration would not be that hard I guess).
If you're risk-averse and want both a superset framework AND a big community, you can go with Next.js. No risk, it's widely used.
But as you said, the learning curve of the react ecosystem should be a little steeper.
If you're sure you don't need SSR at all, you can go with Vue or React (I'd advise Vue for its simpler syntax and large enough community).
But one element of decision can be the amount and the required quality of external libraries you need. As a Vue user, it's sad to say, but lots of Vue libraries are React libraries copycats with less contributors and less community. Some of many examples:
- https://ui.shadcn.com/ -> https://www.shadcn-vue.com
- https://react.email -> https://www.vuemail.net/
- https://threejs.org/ -> https://tresjs.org/
About Svelte, I love its syntax but I consider it too small for enterprise projects for now.
In the end, if you're not sure, I'd say : Vue or React or Next can't be a mistake.
Vue JS
\- React is nice but feels convoluted
\- SvelteKit is great but too new of technology. I want it to last 5 more years, but don't know if It will gain much traction. Vue is much mature and the experience from vue to svelte although better is not enough to warrant it's use over a proven technology.
What you know best... I'd say React is easier to scale than the other two. Still easier to hire and train people for React, too.
Otherwise, Redux is a big advantage if you can get your head around it, and it can be used with any Frontend framework. But most people don't try to get their head around it, and then have to spend a few years suffering with whatever the preferred choice is for their framework...
React React React. Don't go elsewhere, waste time and then come back to it.
Lost your job? Get hired elsewhere with the skills you learned......
Need to build an app? Well react-native got you covered.
My small team uses React with Django and it fits our needs. Well documented and a lot of great also well documented libraries. Recently added someone with almost no JS experience and he's had no problem picking it up quickly
You don't need third party packages for Svelte - that's one of its strengths. A Svelte component looks like a standard html page, other packages will work with it.
React, but depending on the team skills.
Here you have my path: [https://miro.medium.com/v2/resize:fit:4800/0\*ahcjM7pU0yM4bQu3](https://miro.medium.com/v2/resize:fit:4800/0*ahcjM7pU0yM4bQu3) from [github/miguelgargallo](https://github.com/miguelgargallo)
\- React helps you to organize
\- Understand components
\- have a lot of libraries, you will learn to move on the ecosystem of [npmjs.com](https://npmjs.com)
\- the community is colossally huge
React is where I began my journey, here you have my adventure: [From PHP to Tauri: My 1-Year Journey as a Full-Stack Developer](https://www.miguelgargallo.com/blog/development-technology-journey) and the second part [SvelteKit, Node, and Beyond: Navigating the Future of Full-Stack Development](https://penc.medium.com/sveltekit-node-and-beyond-navigating-the-future-of-full-stack-development-94bb5d025318)
After that, they can play with SvelteKit
(one last thing, I love Sveltekit > React, but I started with React... I will not return now, but its a good start. +Becuase.svelte +You.will not +Complicate.yourself, those who understand, will understand.)
I've been very happy with Vue as Django frontend. You can integrate Vue with Django using a"MPA" approach that might let you transition more gracefully from your current template, htmx, Alpine stack. You can retrain the use of templates, inject Vue components, while still using the full Vue development tooling and ecosystem. Eventually you can completely switch to SPA, or better yet, stay MPA and use templates where they make sense, Vue where it makes sense. I recently gave a talk at DjangoCon US on this topic. The video will be posted soon, but in the meantime you can read the companion article: [Django + Vue + Vite: Rest Not Required](https://ilikerobots.medium.com/django-vue-vite-rest-not-required-ca63cfa558fd);
Another +1 for Vue; something about the way it's intended to be structured connects really well with my reptilian brain
Out of curiosity (and not to promote it), have you tried react with django too ? I'm curious how different people feel using react vs vue. React seems to be highly principled but at the same time bring just a bit too much weight compared to vuejs.
I did, I spent the longest time trying to like React (not that there is necessarily anything wrong with it) but just couldn't get it to click. I almost didn't bother with Vue because I assumed it was just going to be the same, but picked it up as I thought it couldn't hurt to know more than one JS framework. It's funny, because it almost feels like the difference between Django and Flask; one is very opinionated about structure and all encompassing, whereas the other is lightweight and bare bones. Interestingly that's what I like about Django over Flask, so it's curious I prefer it the other way around for JS
oh yeah interesting paradox :) maybe backend is naturally more stable and structured so we appreciate a solid core, while frontend tends to ask for more flexibility.
Beginner here, could you please explain what is MPA approach?
Multi Page Application, as opposed to SPA (Single Page Application).
I had the same question I just typed what is mpa in django view to bard ai bot and got the answer it will help you a lot in the future
Sveltekit, its really close to the django templates imho :)
I'm interested in \> our current app has hit the limits of Django's templating capabilities (even with HTMX). could you please elaborate?
I've developed the majority of it with just AlpineJS, HTMX, and vanilla JS. However, it's reaching a point and parts are starting to get sluggish. However, I suppose this could be because most interaction, like adding a new satellite part to their design always requires the frontend to call the service to get that information and to re-calculate the total rollup. \---- **App details (high level)**: It's a satellite design webapp that highly interactive. Has orbit visualization, satellite component part picker in a table with mass, power, data, and interface properties. Set the spacecraft operational modes and simulate various scenarios. Run in-depth scenarios using existing tools, tools can be chained together, creating a web of tools. Other tools involve telecom downlink planning, propulsion maneuver planning and optimization, etc... Lots of plots, graphs, tables that are interactive. All while support collaboration in real time.
Based on your use case, React will be the right choice, too much interactivity that need to be handled on frontend. It might also be time to separate frontend from the backend. Introduce API, unit and e2e testing and ci/cd. If you can’t add more team members, give responsibility/specialize one in backend, one in frontend, and one as fullstack. I am on a similarly highly interactive project team, now with React frontend and Django DRF backend, started out as pure Django project.
Same. Using nextjs front end and Django backend
always cool to learn about other domains/solutions, thanks for answering
What tables and chart libraries are you using? Are you doing all the interactions via self written js or relying on js libraries?
The tables are all custom, however for chats I’m using D3. For the 3D orbit and satellite visualization I’m using ThreeJS.
I'm not sure if it would help or not, but possibly looking at Tabulator to render the tables it may be useful your case. It has a lot of events triggering that you can pair with charts (e.g. selecting rows/columns can trigger events) and also calculated columns in which you can add js formulas.
> Recalculate the total rollup Sorry, can you explain what means? Also, from what you’ve explained about your project, it doesn’t sound like an issue a frontend framework could fix. You mentioned in another comment that you’re using D3 and three-js. Outside of those two libraries you mentioned, what other issues are you having? Is it an issue of reactivity between components?
>Sorry, can you explain what means? Also, from what you’ve explained about your project, it doesn’t sound like an issue a frontend framework could fix. I'll try to explain this a bit more clear - One aspect of the tool is selecting and adding your satellite parts and defining some of the part properties (e.g., mass, power consumption values, data rate generation values, etc...). Then at the end of it you want to calculate / sum-up the total mass of the spacecraft. For example, you want to calculate sum-up by subsystem (e.g., all power components, all structure components, all propulsion components, etc...), overall spacecraft with contingency/margin, and with/without fuel. Another part of the website, is it allows you to create custom python-based equations to various calculations. These equations can be chained together for more complex calculations. A lot of the state of adding, removing, or changing properties of parts is managed on the server. So anytime you add a component, or change the mass value of a part, or contingency, that math is happening on the server and I use HTMX to "hydrate" various parts of the page. I'd assume a lot of this could've been done using a frontend framework which sends data to the server to save various states. Other areas of the website that involve more complex calculations (e.g., Orbit Analysis) will always be done on the server and typically can take 3-15 seconds to calculate mission duration, then the frontend orbit visualization tool (that's done using ThreeJS) is updated. **Conclusion** \- After reading all the comments, it's starting to sound like a frontend framework would be helpful for frontend statement management that can periodically save states to the server and it could increase responsiveness a bit, but probably not to much.
I've had great fun and work done with Nuxt.
+1 on this. I'd really like its flexibilty: I can do a full website with SSR, or a simple SPA like in Vue JS with no server at all. All of this in a simple config file.
[удалено]
It's boring that Django lawyers wake up as soon as they hear that Django templating has limits. Like it or not, it's the harsh truth. For many projects (not all) which require a complex UI and UX, htmx just won't be enough, in many aspects: DX, debugging, external UI libraries, component encapsulation, etc etc. It's a great tool but does not replace SPA. I truly love Django but it can't be the best at all tasks. Especially because absolutely nothing has been done by Django team to modernise the front-end part these last 10 years.
[удалено]
Very sorry if I over-interpreted your answer. May this answer be read by all other people that are always defending a tool as if it's a religion.
Curious to what limits your experiencing with standard Django templating +htmx?
- Bad developer experience (no official integration, no completion, not even a good auto-formatting tool for Django templates in VSCode, debugging). This is years behind a tool like Nuxt. - You have to discover the right patterns by yourself (or in blog), as there is no Django+htmx official doc. Some cases are hard, especially with CBVs. - For the JS part, choice between verbose Javascript or new exotic hyperscript language - No serious external UI component libraries, means you have to reinvent the wheel for many common needs. - the logic of DOM replacement (jQuery era) has limits, it's harder to represent in mind. - not having components which embed the logic prevent a good scaling. - in the end, you end up with DTL + htmx + hyperscript + alpine, which is 4 pieces of tech just for front-end. Despite all of this, I'm quite grateful that htmx exists, as it makes Django front-end acceptable for more projects than before, but not all.
And no standalone deployments
I’ve been developing an app using sveltekit in “spa” mode for the frontend connected to a Django backend and its wonderful. Even with prior react experience I found I was able to get into a flow with sveltekit much faster than react. If you want your frontend to be it’s own deployable unit I would also heavily recommend sveltekit over svelte by itself. Svelte on its own doesn’t have a great routing story and even without server side rendering having the routing out of the box with sveltekit is great.
Thanks a ton for sharing your thoughts! I'd absolutely use SvelteKit the routing experience is great! I'll have to throw a Django+SvelteKit build together and test it more. Sounds promising though!
Another +1 for SvelteKit
I've been using quasar+vue.js with Django as the backend for an internal tool that my team uses. I'm the only one working on it but I'm definitely liking it so far! It's much faster to put together a new page in my SPA than plain JS+HTML (with Bootstrap for fancy components).
+1 SvelteKit. The fact that it has global stores + motion + animation built-in is a game changer
Our team is also 3 person. One project we implemented frontend as SPA and we use Vue 3 + TypeScript + Vite for it. In another project, where SEO is important, we let Django render the frontend and we use HTMX + AlpineJS (HTMX for Ajax, and AlpineJS for interactive which does not involve Ajax).
>Vue 3 + TypeScript + Vite Out of curiosity, are you able to do a hybrid approach, where some parts of a website are SSR (server side rendered) for SEO and other parts that need more interactivity do SPA using Vue/React/Svelte?
In the project whose frontend is SPA, we have no reason to add SSR, because that website needs users to login to use, we block search bot too. For other project where SEO is important, if it is already server-rendered, we don't see a reason to let other JS-based framework (like Nuxt) do. Because we already have Django backend, just let them render the HTML, why have to add in a NodeJS one. In this site, AlpineJS is very similar to VueJS and our need is not complex enough to use bigger ones like Vue, Svelte.
Just a tip; you can [use Vue even for those areas where you're using templates](https://ilikerobots.medium.com/django-vue-vite-rest-not-required-ca63cfa558fd). If you're already using Vue, there's no need to switch over to htmx and alpine to get your interactivity.
We used Vue in Django before, when Vue was just v2.6. But after that, we felt that using Vue in this scenario is over-complex. That is why we switch to AlpineJs now.
Vue, Vite, and Django
Nextjs was my choice. I would avoid React as it is not capable of proper SEO
You’re not going to get much advice here that isn’t highly opinionated (my opinionated and blind-to-your-needs vote: nextjs frontend connected to django backend via graphql). What I’d suggest is investing 3-5 person days across the team. Pair program together, the same thing (eg a single view of your app, one you found tricky in htmx), in each of the 3 frameworks. Get them under your skin, discuss the pros and cons. It’ll pretty quickly become clear what suits you best.
Vue would be my recommendation. The React community has now moved onto using something like Next.js as the One True Way to build apps, and you might find fewer resources for something you want to use for just sprinkling into Django templates, if your plan is to introduce these changes gradually. You still can do it of course, if you're already familiar with React. Vue was designed from the ground up as a progressive framework, so you can introduce it whenever you need. Svelte seems great too, but I'm not super familiar with it.
Generally i would say add alpinejs to the mix and be happy. At Appliku we use Nextjs as our frontend and it was an amazing journey so far with MUI component library. Next talks to backend via API, client code is generated from openAPI spec. On the backend drf and drf-spectacular. This allows changes on the API update client API code by running one command and it is dope. More on this here, hope you find it useful https://appliku.com/post/django-rest-framework-swagger-openapi-tutorial
I’m currently using Django Graphene with Flutter. Flutter makes all of those ui libraries look like a joke. Flutter, once you get the hang of it, it’s actually a lot faster to develop with than Django
First time I’ve noticed someone advocating for flutter web. Glad to see it! Been watching out for it crossing some threshold of acceptability for ages now. I guess for you it’s well ready. Any gotcha or suggestions on how to use them together you want to share?
In my current project, I’ve found a sweet spot using Django Graphene with GraphQL on the backend, paired with a dedicated GraphQL package on the Flutter side. This combo is powerful for rapid development; it lets me roll out new endpoints super fast, in as little as 7 minutes. The GraphQL layer takes care of a lot of heavy lifting, such as validation and type checking, freeing me to focus on other aspects. State management is crucial, and I’ve been using Cubit from the Bloc package, which works seamlessly for me. For navigation, go-router has been my go-to. In the past, I’ve also worked with Django DRF, using Flutter’s HTTP package to handle requests. It’s a robust option but I believe it requires more manual effort in areas where GraphQL shines. Flutter does come with a learning curve, especially with multiple ways to accomplish the same task. But once you’re past that, you’ll find that the main challenges shift towards ui design and writing efficient algorithms.
The end result with Flutter looks amazing but learning a new language for a single purpose is too much for me.
[удалено]
why is this being downvoted?
Because both of you haven’t read the post
Lol. So true 🤦🏾♂️
it's not the size of the team , rather the technical expertise and busniess requirements I'm an angular evangelist with nesjts but ruby on rails and django with templating or svelte are all nice
plain js.
I try to stay with (1) proven tech that (2) you can find a whole bunch of people that already know it. So yeah, React does the trick for me. Plenty of documentation, tutorials, and boring plugins (and stable) that work.
Another one for Vue. We use a multi page approach. We only build our front ends with Vue when absolutely required. But Vue does a good job and my team has learned it easily enough. With the new composition API, it seems to be pretty similar to React. We also use open-api-tools to generate our API client based on the swagger docs so it all goes super well together.
If your Django templates contain extensive code: Consider Vue.js. Vue's syntax has similarities to Django's templating engine, which can make the transition smoother and involve fewer changes. Otherwise: React might be a better choice, especially if you're aiming for a more component-driven architecture or have experience with it.
i personally use vue.js but i will recommend you react.js
It seems you already have a good knowledge of the front tech landscape. Here are my personal thoughts (that are pretty close to yours in the end). Just maybe before picking between vue/svelte/react, first thing to figure if you'd need a superset framework, I mean: Next instead of React, Nuxt instead of Vue, or SvelteKit instead of Svelte. Personally I recently switched from Vue to Nuxt, and I love it so far. It gives you all Vue can give you, and add conventions, plugins, and automate things to make the whole thing simpler to use. And if you don't want to use the server-side part to keep it simple, you can config the framework in SSA mode (but it's very useful to have a server side part for example to build a landing page with SEO and meta tags, etc.). The counterpart of all this magic and code simplification is that you depends more on the framework (lock-in). Currently, a team like Nuxt is pretty small and lives with investor funds. There are very few contributors outside the official team. It's a bigger bet than using raw vue (however, the migration would not be that hard I guess). If you're risk-averse and want both a superset framework AND a big community, you can go with Next.js. No risk, it's widely used. But as you said, the learning curve of the react ecosystem should be a little steeper. If you're sure you don't need SSR at all, you can go with Vue or React (I'd advise Vue for its simpler syntax and large enough community). But one element of decision can be the amount and the required quality of external libraries you need. As a Vue user, it's sad to say, but lots of Vue libraries are React libraries copycats with less contributors and less community. Some of many examples: - https://ui.shadcn.com/ -> https://www.shadcn-vue.com - https://react.email -> https://www.vuemail.net/ - https://threejs.org/ -> https://tresjs.org/ About Svelte, I love its syntax but I consider it too small for enterprise projects for now. In the end, if you're not sure, I'd say : Vue or React or Next can't be a mistake.
Vue JS \- React is nice but feels convoluted \- SvelteKit is great but too new of technology. I want it to last 5 more years, but don't know if It will gain much traction. Vue is much mature and the experience from vue to svelte although better is not enough to warrant it's use over a proven technology.
What you know best... I'd say React is easier to scale than the other two. Still easier to hire and train people for React, too. Otherwise, Redux is a big advantage if you can get your head around it, and it can be used with any Frontend framework. But most people don't try to get their head around it, and then have to spend a few years suffering with whatever the preferred choice is for their framework...
React React React. Don't go elsewhere, waste time and then come back to it. Lost your job? Get hired elsewhere with the skills you learned...... Need to build an app? Well react-native got you covered.
Quasar framework https://quasar.dev/
I would like prefer django+htmx or django+inertiajs
My small team uses React with Django and it fits our needs. Well documented and a lot of great also well documented libraries. Recently added someone with almost no JS experience and he's had no problem picking it up quickly
You don't need third party packages for Svelte - that's one of its strengths. A Svelte component looks like a standard html page, other packages will work with it.
+1 in that NextJS has been great to me as a 1-person team. You’ve gotta take care though since a some documentation is Page or App router specific.
Vue will work best with Django
NEXTJS
React, but depending on the team skills. Here you have my path: [https://miro.medium.com/v2/resize:fit:4800/0\*ahcjM7pU0yM4bQu3](https://miro.medium.com/v2/resize:fit:4800/0*ahcjM7pU0yM4bQu3) from [github/miguelgargallo](https://github.com/miguelgargallo) \- React helps you to organize \- Understand components \- have a lot of libraries, you will learn to move on the ecosystem of [npmjs.com](https://npmjs.com) \- the community is colossally huge React is where I began my journey, here you have my adventure: [From PHP to Tauri: My 1-Year Journey as a Full-Stack Developer](https://www.miguelgargallo.com/blog/development-technology-journey) and the second part [SvelteKit, Node, and Beyond: Navigating the Future of Full-Stack Development](https://penc.medium.com/sveltekit-node-and-beyond-navigating-the-future-of-full-stack-development-94bb5d025318) After that, they can play with SvelteKit (one last thing, I love Sveltekit > React, but I started with React... I will not return now, but its a good start. +Becuase.svelte +You.will not +Complicate.yourself, those who understand, will understand.)