6 ms·

This is great, thanks for writing it! I have recently stepped out of the seemingly never-ending spiral of using React/Vue for everything frontend, and also dis

This is great, thanks for writing it! I have recently stepped out of the seemingly never-ending spiral of using React/Vue for everything frontend, and also discovered Django along the way. For building prototypes, Django is the fastest framework I've ever used. After building out prototypes in Django I've come to a realization that at most 10% of my websites need to be truly reactive to user interaction without page reload. Turns out when I dropped this requirement when building something, I can actually finish the projects I start. And also turns out for the end-user, they don't even notice page reloads for most sites.

jkcxn 7y ago
I totally agree. Full page rendered app are way easier to code. It's like an immutable function - request in, transform, html out. I think as soon as you want to add some niceties with React you end up setting up a load of front end stuff. You suddenly need APIs, create-react-app, webpack, babel, build scripts, redux, routing etc. And you also end up losing out on some of the Django side, forms+validation, templating, views, urls. And often you end up having business spilling over to your front end. I'm working on a project that lets you build your Django app like you normally would with templates and views but you get a React app and all the benefits of a single page app. You don't need to write any APIs or use redux etc. It will have a bunch of components built in and if you don't need any more then you don't even need to build the javascript yourself, you just include the already built file. At the moment I have a sort of Django Admin equivalent example working and I'm looking for some feedback. If you or anyone else has any ideas about it I would love to hear, feel free to PM me (email in profile).
- deleted 7y ago
  [deleted]
- davish 7y ago
  Looks like your profile just has an hnchat verification code, but would love to check out the project and help out if I can. It sounds really interesting!
- jedieaston 7y ago
  Is it in a state that you could do a Show HN? I want to see this, could be very useful for me trying to avoid writing JS ;)
- cugs 7y ago
  Interested in giving this a try; If you need testers, I'd be happy to try it out.
- andybak 7y ago
  Are you aware of pjax, turbolinks and (stepping up a bit from this really minimal baseline) intercooler.js? Curious how you feel your project fits in at this end of the ecosystem.
  - 1337shadow 7y ago
    There's also stimilusjs that works pretty fine with all that.
  - joss82 7y ago
    Intercooler is fantastic and integrates well with Django.
  - midrus 7y ago
    And my favorite: unpoly https://unpoly.com/ https://unpoly.com/
- osel 7y ago
  Would be keen to discuss/trial as well.
- irrational 7y ago
  >Full page rendered app are way easier to code This is basically web 1.0. It's like we've come full-circle: web 1.0 > web 2.0 > web 1.0 I'm not saying this is bad at all. I'm just amused that we are back to building web pages the way we did 10-15 years ago.
- deleted 7y ago
  [deleted]
- tkainrad 7y ago
  This sounds really interesting. For developers, this approach could be a compromise between no-code and, well, code.
- danzig13 7y ago
  Yes. My first job was ASP.NET Web forms and their APPSTATE really messed this up. Imagine full page reloads WITH state in between reloads.
Lunrtick 7y ago
I totally agree about not needing to make the whole page reactive, it definitely drops the amount of work required. Regarding the page loads, have you looked at Turbolinks? https://github.com/turbolinks/turbolinks/blob/master/README.md https://github.com/turbolinks/turbolinks/blob/master/README.... It's basically a drop in upgrade, makes the whole site feel like an SPA with none of the work. Lovely.
- chocolatkey 7y ago
  Django + Turbolinks + Stimulus.js (also by basecamp, intentionally works great with turbolinks) is my goto nowadays.
Scarbutt 7y ago
Now try Rails and get enlighten.
wiremine 7y ago
> For building prototypes, Django is the fastest framework I've ever used. I worked with Django full time for about 6 years. It scales up and out pretty well, too. There was a peer comment about Rails. I'm a big fan of Rails, and Ruby is one of my favorite languages. But one thing I've noticed is the lack of magic inside the Django codebase vs. Rails' codebase. Spelunking in the codebases feels night and day different: I found Django very intuitive and Rails... less so. I think that was a combination of my lack of skill with Rails' internals, and the different in languages and communities. Python (and Django) try to follow the Zen of Python. Rails felt like every other method was monkey-patched and reduced to a single line or two. It was odd: I think the expressiveness of Ruby was actually a negative at large scale (sort of like Lisp vs. Go) For 99% of use cases, you never need to get to this level of the frameworks, but it was an interesting experience.
- airstrike 7y ago
  I echo this sentiment. I've learned a ton of Python from reading the Django source code. There's definitely something to be said about the DSF and the many contributors over the years who've worked tirelessly to push the envelope with the framework (and the ORM, in particular) while also keeping the codebase sane. It's not all perfect, but it's about as good as it gets for FOSS with so many people chiming in over more than a decade
- debuggerpk 7y ago
  That is exactly my experience. RoR was too much magic for me.
  - hombre_fatal 7y ago
    To put a finer point on "magic", Rails requires a lot more knowledge about what's going on behind the scenes. One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus. Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc. You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing. To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground. I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064 https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other. And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.
arriu 7y ago
Django is fantastic, unfortunately its template language is not so great. Using Vue like this has allowed us to be far more productive than using either in isolation. Another tip would be to give django-admin a try when building dashboard projects (you can customize the look and feel quite a bit, ours are usually unrecognizable).
- 101404 7y ago
  I see that as a feature. Templates should not do much logic, so it's a good idea that the templating language is simple. But you can always switch it for Jinja2, just a line in the settings file.
aprdm 7y ago
Amen brother! Hope more people discover (or re-discover) this. DjangoREST is also a very solid framework if your use case is not a website and you get all the rest of Django for free...
virvar 7y ago
I work in the second largest region of my country, which is not where many of the hip tech firms are located. And it shows in the tech stacks around here, it’s mainly C#, JAVA and PHP and no one is really doing the no-page-reload front-ends, and no one seems to care. Startups in my area are actually doing better than they are in our main tech hub despite most of them using what Silicon Valley would call fairly boring and extremely old tech stacks such as ASP MVC.

jkcxn 7y ago

I totally agree. Full page rendered app are way easier to code. It's like an immutable function - request in, transform, html out. I think as soon as you want to add some niceties with React you end up setting up a load of front end stuff. You suddenly need APIs, create-react-app, webpack, babel, build scripts, redux, routing etc. And you also end up losing out on some of the Django side, forms+validation, templating, views, urls. And often you end up having business spilling over to your front end. I'm working on a project that lets you build your Django app like you normally would with templates and views but you get a React app and all the benefits of a single page app. You don't need to write any APIs or use redux etc. It will have a bunch of components built in and if you don't need any more then you don't even need to build the javascript yourself, you just include the already built file. At the moment I have a sort of Django Admin equivalent example working and I'm looking for some feedback. If you or anyone else has any ideas about it I would love to hear, feel free to PM me (email in profile).

deleted 7y ago
[deleted]
davish 7y ago
Looks like your profile just has an hnchat verification code, but would love to check out the project and help out if I can. It sounds really interesting!
jedieaston 7y ago
Is it in a state that you could do a Show HN? I want to see this, could be very useful for me trying to avoid writing JS ;)
cugs 7y ago
Interested in giving this a try; If you need testers, I'd be happy to try it out.
andybak 7y ago
Are you aware of pjax, turbolinks and (stepping up a bit from this really minimal baseline) intercooler.js? Curious how you feel your project fits in at this end of the ecosystem.
- 1337shadow 7y ago
  There's also stimilusjs that works pretty fine with all that.
- joss82 7y ago
  Intercooler is fantastic and integrates well with Django.
- midrus 7y ago
  And my favorite: unpoly https://unpoly.com/ https://unpoly.com/
osel 7y ago
Would be keen to discuss/trial as well.
irrational 7y ago
>Full page rendered app are way easier to code This is basically web 1.0. It's like we've come full-circle: web 1.0 > web 2.0 > web 1.0 I'm not saying this is bad at all. I'm just amused that we are back to building web pages the way we did 10-15 years ago.
deleted 7y ago
[deleted]
tkainrad 7y ago
This sounds really interesting. For developers, this approach could be a compromise between no-code and, well, code.
danzig13 7y ago
Yes. My first job was ASP.NET Web forms and their APPSTATE really messed this up. Imagine full page reloads WITH state in between reloads.

Lunrtick 7y ago

I totally agree about not needing to make the whole page reactive, it definitely drops the amount of work required. Regarding the page loads, have you looked at Turbolinks? https://github.com/turbolinks/turbolinks/blob/master/README.md https://github.com/turbolinks/turbolinks/blob/master/README.... It's basically a drop in upgrade, makes the whole site feel like an SPA with none of the work. Lovely.

chocolatkey 7y ago
Django + Turbolinks + Stimulus.js (also by basecamp, intentionally works great with turbolinks) is my goto nowadays.

Scarbutt 7y ago

Now try Rails and get enlighten.

wiremine 7y ago

> For building prototypes, Django is the fastest framework I've ever used. I worked with Django full time for about 6 years. It scales up and out pretty well, too. There was a peer comment about Rails. I'm a big fan of Rails, and Ruby is one of my favorite languages. But one thing I've noticed is the lack of magic inside the Django codebase vs. Rails' codebase. Spelunking in the codebases feels night and day different: I found Django very intuitive and Rails... less so. I think that was a combination of my lack of skill with Rails' internals, and the different in languages and communities. Python (and Django) try to follow the Zen of Python. Rails felt like every other method was monkey-patched and reduced to a single line or two. It was odd: I think the expressiveness of Ruby was actually a negative at large scale (sort of like Lisp vs. Go) For 99% of use cases, you never need to get to this level of the frameworks, but it was an interesting experience.

airstrike 7y ago
I echo this sentiment. I've learned a ton of Python from reading the Django source code. There's definitely something to be said about the DSF and the many contributors over the years who've worked tirelessly to push the envelope with the framework (and the ORM, in particular) while also keeping the codebase sane. It's not all perfect, but it's about as good as it gets for FOSS with so many people chiming in over more than a decade
debuggerpk 7y ago
That is exactly my experience. RoR was too much magic for me.
- hombre_fatal 7y ago
  To put a finer point on "magic", Rails requires a lot more knowledge about what's going on behind the scenes. One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus. Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc. You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing. To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground. I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064 https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other. And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.

arriu 7y ago

Django is fantastic, unfortunately its template language is not so great. Using Vue like this has allowed us to be far more productive than using either in isolation. Another tip would be to give django-admin a try when building dashboard projects (you can customize the look and feel quite a bit, ours are usually unrecognizable).

101404 7y ago
I see that as a feature. Templates should not do much logic, so it's a good idea that the templating language is simple. But you can always switch it for Jinja2, just a line in the settings file.

aprdm 7y ago

Amen brother! Hope more people discover (or re-discover) this. DjangoREST is also a very solid framework if your use case is not a website and you get all the rest of Django for free...

virvar 7y ago

I work in the second largest region of my country, which is not where many of the hip tech firms are located. And it shows in the tech stacks around here, it’s mainly C#, JAVA and PHP and no one is really doing the no-page-reload front-ends, and no one seems to care. Startups in my area are actually doing better than they are in our main tech hub despite most of them using what Silicon Valley would call fairly boring and extremely old tech stacks such as ASP MVC.