5 ms·

A huge part of the work I did the past year (and still do sometimes, email in my profile) was helping people transition from a full legacy django app to a light

A huge part of the work I did the past year (and still do sometimes, email in my profile) was helping people transition from a full legacy django app to a lightweight django backend with rest api and a react frontend. Django Ninja makes it especially pleasant. I think django should really embrace this in the future. Make it easier to drop the superfluous parts; forms, templates … I don’t know what that will look like but I don’t see a way back.

number6 3y ago
We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?
- nprateem 3y ago
  Mobile
- collyw 3y ago
  Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.
  - deleted 3y ago
    [deleted]
  - scrollaway 3y ago
    Github is moving to an SPA with init-time SSR.
- scrollaway 3y ago
  Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots). I don't need to sell you on the concept though I will address your comment in depth. In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ... The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve. But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour. GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for. But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding). As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).
lagt_t 3y ago
No thanks, I prefer to drop React and use django + htmx for ajax.
- scrollaway 3y ago
  Hey, if you're happy writing html using not-quite-jinja templates that are completely impossible to test, auto-format, or even sometimes syntax highlight... what can I say, power to you. You go, buddy.
  - fshr 3y ago
    You can integration test, you can use the debug plugin for htmx, you can format them with vs code extensions, and there is a highlighter available, though it’s not that important seeing as how each attribute is pretty simple.
kbrannigan 3y ago
What do people like torturing themselves by duplicating code. Wouldn't it be easier to just use node all the way. Writing hundreds of lines of JS to display a Table list, instead of HTML sprinkled with some JS
- scrollaway 3y ago
  A whole stack rewrite is not always (in fact very rarely) a good idea. The backend often drives a lot of logic; in a big rewrite, the less you rewrite the more likely you are to be successful. Too many big refactors fail because they aren’t done in value-adding steps. Also your second paragraph isn’t in line with your first … in react you don’t write “hundreds of lines of js” for a table. You write the html as js (jsx), and sprinkle the dynamic parts on top. It’s equivalent…
  - kbrannigan 3y ago
    I've seen, routing boilerplate, js to make the api requests, js to modify state(redux), unit tests, interfaces, until you get to the actual table.
globular-toast 3y ago
I've gone the opposite way. Started converting views to rest framework viewsets and building React components on the front end. It just created more problems. Now the React stuff is considered legacy and we're using HTMX and the bare minimum of vanilla JS when necessary.
- scrollaway 3y ago
  REST Framework is frankly... flawed. Full of good ideas, but in practice, it leads to development hell unless you're very rigorous with it. FastAPI is the gold standard, which in the Django works means Django-Ninja. If you've been building individual React components and integrating them without going the SPA route, then while there are some upsides to that, you are doing a lot of the effort but not getting most of the benefits. If you don't need an SPA, then you don't need an SPA. Nobody should be getting this development pattern shoved down their throats. But from what you describe, it sounds to me like you went with a bad approach altogether, so no kidding it created more problems. (Not to make it sound like a "no true scotsman" with the whole "bad approach" thing, but this is why it's important to get people who really know their shit in driving refactors like these, and can make a strong plan ahead of time, detailing what value is brought at each and every step)
  - globular-toast 3y ago
    The lesson learnt is that React is an "all or nothing" type thing. You'll notice "SPA" isn't mentioned at all on the React website, but there's lots of mentions of building components. There are lots of comments around places like HN of people learning the same lesson as me. We never scoped replacing our entire UI with React and entire backend with JSON API because it seemed like there was a smooth upgrade path, but there isn't really. As for people who know their shit, how do you think said people learnt their shit? Everyone can do what they already know. The interesting stuff is on the frontier of your knowledge. You learn by pushing that boundary and, when you fail, thinking about why it failed.
    - scrollaway 3y ago

number6 3y ago

We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?

nprateem 3y ago
Mobile
collyw 3y ago
Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.
- deleted 3y ago
  [deleted]
- scrollaway 3y ago
  Github is moving to an SPA with init-time SSR.
scrollaway 3y ago
Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots). I don't need to sell you on the concept though I will address your comment in depth. In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ... The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve. But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour. GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for. But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding). As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).

lagt_t 3y ago

No thanks, I prefer to drop React and use django + htmx for ajax.

scrollaway 3y ago
Hey, if you're happy writing html using not-quite-jinja templates that are completely impossible to test, auto-format, or even sometimes syntax highlight... what can I say, power to you. You go, buddy.
- fshr 3y ago
  You can integration test, you can use the debug plugin for htmx, you can format them with vs code extensions, and there is a highlighter available, though it’s not that important seeing as how each attribute is pretty simple.

kbrannigan 3y ago

What do people like torturing themselves by duplicating code. Wouldn't it be easier to just use node all the way. Writing hundreds of lines of JS to display a Table list, instead of HTML sprinkled with some JS

scrollaway 3y ago
A whole stack rewrite is not always (in fact very rarely) a good idea. The backend often drives a lot of logic; in a big rewrite, the less you rewrite the more likely you are to be successful. Too many big refactors fail because they aren’t done in value-adding steps. Also your second paragraph isn’t in line with your first … in react you don’t write “hundreds of lines of js” for a table. You write the html as js (jsx), and sprinkle the dynamic parts on top. It’s equivalent…
- kbrannigan 3y ago
  I've seen, routing boilerplate, js to make the api requests, js to modify state(redux), unit tests, interfaces, until you get to the actual table.

globular-toast 3y ago

I've gone the opposite way. Started converting views to rest framework viewsets and building React components on the front end. It just created more problems. Now the React stuff is considered legacy and we're using HTMX and the bare minimum of vanilla JS when necessary.

scrollaway 3y ago
REST Framework is frankly... flawed. Full of good ideas, but in practice, it leads to development hell unless you're very rigorous with it. FastAPI is the gold standard, which in the Django works means Django-Ninja. If you've been building individual React components and integrating them without going the SPA route, then while there are some upsides to that, you are doing a lot of the effort but not getting most of the benefits. If you don't need an SPA, then you don't need an SPA. Nobody should be getting this development pattern shoved down their throats. But from what you describe, it sounds to me like you went with a bad approach altogether, so no kidding it created more problems. (Not to make it sound like a "no true scotsman" with the whole "bad approach" thing, but this is why it's important to get people who really know their shit in driving refactors like these, and can make a strong plan ahead of time, detailing what value is brought at each and every step)
- globular-toast 3y ago
  The lesson learnt is that React is an "all or nothing" type thing. You'll notice "SPA" isn't mentioned at all on the React website, but there's lots of mentions of building components. There are lots of comments around places like HN of people learning the same lesson as me. We never scoped replacing our entire UI with React and entire backend with JSON API because it seemed like there was a smooth upgrade path, but there isn't really. As for people who know their shit, how do you think said people learnt their shit? Everyone can do what they already know. The interesting stuff is on the frontier of your knowledge. You learn by pushing that boundary and, when you fail, thinking about why it failed.
  - scrollaway 3y ago