201–210 of 225 posts
Earlier quoted context omitted.
I have heard great things about DRF, and often it is good to resist coloring outside the lines. That being said, your comment assumes that DRF has indeed thought of everything. All abstractions leak, some more than others. Clean escape hatches are very valuable.
I never said that you MUST be thinking about it wrong. I just said to make sure you're not thinking about it wrong. No framework has thought of everything.
Earlier quoted context omitted.
Just wondering, what do you use instead of Forms for non-Javascript websites?
For what it's worth you can still use DRF serializers instead of forms on non-JS sites. DRF can take multipart/form-data
Earlier quoted context omitted.
Personally, as a customer, the "new" way of doing it is irritating, usually somewhat broken, slow and usually unreliable. I wouldn't be surprised if non-techies couldn't give a toss if you're using a traditional MPA with a sprinkling of ajax for the bits that really need to be responsive or a total SPA. I'm beginning to suspect the only people who want a SPA are the programmers. Has anyone even got any proof that a S…
As a programmer, I absolutely hate SPA's. I've never used a good SPA, they're always slow, and behave strangely. I much prefer the traditional way. It's the same with Electron apps. I think it's just web developers who like SPA's
Earlier quoted context omitted.
The changes from Python 2.7 to 3.x are hardly so dramatic that it's like learning a new language. I'm pretty sure your performance issues can largely be addressed after proper investigation where the bottlenecks are. I do understand how nice it is to have a simpler architecture, but make sure it's worth all the work.
Well we can migrate to python 3 but this will be more investment in a stack that is more and more obsolete (Django) for SPA. Developers need also to learn the new best practices for python 3. At the end this will result in short term with python 3 code base written in python 2 style without the benefits of typing etc. Investment without benefits except keep our stack up-to-date. Each solution for Python/Django add co…
Sure....
Earlier quoted context omitted.
We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…
Dude moving to Python3 is easy . It is an order of magnitude easier than moving over to a new language.
My favorite opinionated boilerplate for new Django projects: https://github.com/pydanny/cookiecutter-django/ From the author of the great Two Scoops of Django series. https://www.twoscoopspress.com/products/two-scoops-of-django... Two great ways to avoid some newbie mistakes. Although some could argue diving into boilerplate without understanding it is in fact a newbie mistake itself.
Django’s documentation is still the best I have worked with so far of any software project I came across to date. It not only explains, it educates.
I find it some of the hardest documentation (close to AWS) to understand the best way to do something. I think it's great if you know what you're doing or you have a rough idea of what to do but need more information, but for someone new to the framework it makes me want to paper cut the webs of my fingers and bath my hands in vinegar because it would be less painful.
There are a lot of concepts to understand with a framework so my guess is that's actually your problem, but as far as documentation goes, Django's is pretty good.
Earlier quoted context omitted.
> To me, the Django project exudes the stubbornness of the developers who maintain it because rather than fixing these problems they've decided to write this page about how it's you, the user, who is wrong. I sometimes feel that, similar to how perl's motto is "There's more than one way to do it", some python developers have converged on an unofficial mottot of "You're doing it wrong".
Because... they are? I mean look, for the most part developers have optimized a happy path that is by far, one of the most productive ways to get anything done in the web dev world. If you're purposely going to go against that path for whatever reason, you're going to have to do the heavy lifting that the framework is doing for you. In the 9 years I've been using Django, I've rarely if ever come to a situation where…
The lack of self-instropection & hubris in some framework's devotees is astonishing. If someone is attempting to solve a problem, and their approach is not well-suited to the framework, perhaps it is the framework's fault? Perhaps suggest an alternative tool rather than telling the person they haven't come up with the 'best' approach (which is the version that the framework is well-suited to solve)?
I feel that a lot of the time this defensive "you don't understand the problem" conversations are from devs who have invested a lot of time in the framework & have internalised their expertise into their sense of self-worth, such that 1.) they don't have much experience with other frameworks/approaches which may be better suited to the questioner's problem; 2.) admitting to a failure or gap in the framework becomes equivalent to admitting to a personal failure.
I wish we had less ego in programming, and more decisive, clear declarations of intent and limitations in frameworks.
I've worked with django for a considerable amount of time now (~9 years), and I have found the documentation a joy to work with. The documentation generally covers each piece of functionality, and the source code is rich with documentation. When it comes to django itself, there are nuances, and yep, some of them probably can be smoothed over for developer experience, but developers must have knowledge over their tool…
Please don't ever use integers for ZIP codes. In Germany there are ZIP codes (Postleitzahlen) that start with a 0.
Please don't use examples on a 13-year-old community wiki as recommendations, period! See the many other comments I've made in this thread for how to handle elements of postal addresses in Django.