Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 4.0 release candidate 1 released

djangoproject.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: Django 4.0 release candidate 1 released

#101

Post by pbowyer »

emacsen wrote: post #43
pbowyer wrote: post #27

Earlier quoted context omitted.

You shouldn't be downvoted for saying this. As a server-side developer of 20 years the server-side templating languages have a lot to learn from the frontend experience. And I say this as a user of Smarty, Jinja2 and now Twig & nunjucks. Template inheritance is fantastic. But... Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into co…

I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a develope…

Up the wrong tree :) Vue.py gives you a way to write Vue to run in the browser using a Pythonic syntax. I'm talking about running actual Vue code (or anything else in that style) server-side as Django templates.

Re: Django 4.0 release candidate 1 released

#102

Post by scrollaway »

candiodari wrote: post #59
scrollaway wrote: post #52

Earlier quoted context omitted.

To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth…

Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it? Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified. And then there's javascript ...

Python doesn't have the problem as much. It does to an extent, though it's getting better with type hinting nowadays.

I do prefer working with typescript than with python but I still rather work with Python than with django templates which are way worse.

Re: Django 4.0 release candidate 1 released

#103

Post by scrollaway »

Hamuko wrote: post #58
scrollaway wrote: post #53

Earlier quoted context omitted.

Just the one if you're using CRA. None if you're embedding react as is. The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with…

For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.

You're missing my point. I don't know if this conversation can go anywhere.

Re: Django 4.0 release candidate 1 released

#104

Post by smashed »

batiste wrote: post #61

Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down... FastAPI doesn't have those issues at all...

Please read this article:

https://rachelbythebay.com/w/2020/03/07/costly/

Re: Django 4.0 release candidate 1 released

#105

Post by dangerbird2 »

candiodari wrote: post #59
scrollaway wrote: post #52

Earlier quoted context omitted.

To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth…

Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it? Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified. And then there's javascript ...

It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself.

By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl

Re: Django 4.0 release candidate 1 released

#106

Post by mejutoco »

ekspreso wrote: post #71
mejutoco wrote: post #44

Earlier quoted context omitted.

I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)

Have you tried https://pebbletemplates.io/ for Java? I haven't used it extensively, so I can't speak how it compares to Django in larger setups.

Indeed! That is the one template language that looked like it might behave in the same way.

Re: Django 4.0 release candidate 1 released

#107

Post by mejutoco »

scrollaway wrote: post #52
mejutoco wrote: post #44

Earlier quoted context omitted.

I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)

To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth…

I basically agree. Templates are basically strings, while jsx is in the end a full programming language (js).

It has the downsides you mention (the error reporting is okayish I think). On the other side, you can write html directly (no classname, etc), and there is no transpiling/build tools/server-side rendering to add. String templates are also side-effect free.

For spa I would prefer React (with Typescript): for a request/response old-fashioned app, or something like htmx/hotwire text templates can be very productive. I see your point though.

Edit: extra points.

Re: Django 4.0 release candidate 1 released

#108

Post by sireat »

traverseda wrote: post #89
ksec wrote: post #82

Earlier quoted context omitted.

I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.

Python is a very popular language, and if you know Python Django is easy.

Django seems to add too much magic for me. It is mostly manage.py this manage.py that.

I can't grok it completely. All the books that I read on it skipped the architecture part.

Maybe there is a good guide to Django architecture - the big picture?

PS I am rather experienced in Python (Numpy, Pandas, Plotly, Flask, SQLAlchemy, FastAPI, BeautifulSoup are my bread and butter)

Re: Django 4.0 release candidate 1 released

#109

Post by derekjdanserl »

sireat wrote: post #108
traverseda wrote: post #89

Earlier quoted context omitted.

Python is a very popular language, and if you know Python Django is easy.

Django seems to add too much magic for me. It is mostly manage.py this manage.py that. I can't grok it completely. All the books that I read on it skipped the architecture part. Maybe there is a good guide to Django architecture - the big picture? PS I am rather experienced in Python (Numpy, Pandas, Plotly, Flask, SQLAlchemy, FastAPI, BeautifulSoup are my bread and butter)

You list a bunch of libraries, but Django is not a library. It is a framework.

The Django file structure, for example, is not exactly optional in Django. Realize FastAPI follows in the footsteps of Flask. Neither FastAPI or Flask are frameworks. As a FastAPI user myself, I do think it’s closer to a happy medium, but it’s nothing remotely comparable to Django.

When using Django, the best advice I have is to dive all the way in. Follow the docs and the best practices first. Besides, manage.py is just like having a well-developed kit of shell scripts/ in your repo.

Re: Django 4.0 release candidate 1 released

#110

Post by sireat »

derekjdanserl wrote: post #109
sireat wrote: post #108

Earlier quoted context omitted.

Django seems to add too much magic for me. It is mostly manage.py this manage.py that. I can't grok it completely. All the books that I read on it skipped the architecture part. Maybe there is a good guide to Django architecture - the big picture? PS I am rather experienced in Python (Numpy, Pandas, Plotly, Flask, SQLAlchemy, FastAPI, BeautifulSoup are my bread and butter)

You list a bunch of libraries, but Django is not a library. It is a framework. The Django file structure, for example, is not exactly optional in Django. Realize FastAPI follows in the footsteps of Flask. Neither FastAPI or Flask are frameworks. As a FastAPI user myself, I do think it’s closer to a happy medium, but it’s nothing remotely comparable to Django. When using Django, the best advice I have is to dive all t…

I am well aware that Django is a framework and yes it is quite strict about the way you set it up.

That is a reasonable price to pay for the batteries included approach.

What I am saying that I do not grok the big picture of Django flow.

For some reason I got up to speed with Laravel much faster and I do not write much PHP.

The books that I skimmed (like recommended Two Scoops of Django) just go into various things you can do but do not show the big picture.

Post reply on HN