61–70 of 92 posts
Isn't unicorn the ruby web server? Name collisions are kinda unavoidable, but I'd at least try to avoid them in the same space.
How painful if you had to have 2 friends with the same first name... Name collision is unavoidable and one of the many wrong battles to fight for, IMO.
I've done extensive development with Flask, Bottle, Django, Falcon, Django Rest Framework, Starlette, Sanic and FastAPI over about 13 years or so. These days I prefer to build my back end applications with nodejs, TypeScript and plain SQL (no ORM) talking to Postgres. I like Django but it pissed me off no end that it's called "batteries included", except that the very first thing you need to do with any Django projec…
It's 2023, people log in with e-mail addresses, and even if they log in with a username, make it case insensitive ffs
The very first thing I have to do with each project is completely rebuild the user system, and if you wait until later then it's too late and it's way more difficult to do (according to the docs themselves)
I've done extensive development with Flask, Bottle, Django, Falcon, Django Rest Framework, Starlette, Sanic and FastAPI over about 13 years or so. These days I prefer to build my back end applications with nodejs, TypeScript and plain SQL (no ORM) talking to Postgres. I like Django but it pissed me off no end that it's called "batteries included", except that the very first thing you need to do with any Django projec…
The built-in auth system is one of the things I dislike the most about Django. It's 2023, people log in with e-mail addresses, and even if they log in with a username, make it case insensitive ffs The very first thing I have to do with each project is completely rebuild the user system, and if you wait until later then it's too late and it's way more difficult to do (according to the docs themselves)
The moment you install Django, you have to add all the auth stuff to your todo list. If you're not a Django expert then its easily hours or days pointless work.
Pretty frustrating to instantly be given the large and for some people intimidating problem of implement signup/signin/forgot password/reset password and do it all properly, reliably and securely, even whilst Django smugly asserts that it's "batteries included".
You have to head off and find which auth plug in system to use, work out what is still maintained, which provides the features you need and then the task of integrating it with whatever front end you need to present to the user. All this you need to do if you are new to Django.
It's a huge gap in the Django offering, and makes Django look pretty out of date.
Django should come with a built in user flow that allows signup/signin/forgot password/reset password as well as related emails, and it should come with support for json web token and cookie session, plus example UI code for React, VueJS, plain HTML and maybe some of the other common JavaScript front ends too, as well as APIs for other front ends to use.
Why they don't provide this is hard to understand. It's just instant makework for developers.
Either this or drop the "batteries included" thing.
I wondered how Unicorn compared to htmx. They're giving an answer on their website: htmx and alpine.js are great libraries to provide interactivity to your HTML. Both of those libraries are generalized front-end framework that you could use with any server-side framework (or just regular HTML). They are both well-supported, battle-tested, and answers to how they work are probably Google-able (or on Stackoverflow). Un…
See also: Laravel Livewire ( https://livewire.laravel.com ) HTMX ( https://htmx.org ) Hotwire ( https://hotwired.dev/ ) Phoenix LiveView ( https://github.com/phoenixframework/phoenix_live_view )
My first thought when seeing their validation examples - when I build a Django app and add validations, I start off with a normal form that does a full submit. This is the easiest to get going. As requirements become a bit more complex, I might add JS validation so that a POST is not necessary. Looking at their validation examples: https://www.django-unicorn.com/examples/validation This does a POST each time, albeit…
> This does a POST each time, albeit automatically on typing. It still means a lag for a kind of validation that could have been done client side. If you can accept that lag, the tradeoff is that you only have to write the validation logic once, in one language. Furthermore, if your validation includes something like "check that this username isn't already registered" that requires server-side logic, you're stuck wit…
Django was a "batteries included" framework about 10 years ago. But the core team had very strong opinions about javascript, saying that picking a javascript framework should NOT be part of those batteries. Time has passed, and javascript is now part of every single website or app we build. Django still doesn't give any help to developers that wants to build a modern site. My opinion: They should go the Phoenix Live…
If they had chosen a JS framework as part of the batteries, that framework probably would've been deprecated by now. For instance, who still builds websites with Angular or Backbone/Marionette anymore? See also Rails, which did choose a battery quite early on: prototype.js. Well, that was a wrong decision, so they changed it to jQuery (which is now also deprecated; no idea what it supports nowadays) and also dropped…
Django was a "batteries included" framework about 10 years ago. But the core team had very strong opinions about javascript, saying that picking a javascript framework should NOT be part of those batteries. Time has passed, and javascript is now part of every single website or app we build. Django still doesn't give any help to developers that wants to build a modern site. My opinion: They should go the Phoenix Live…
If they had chosen a JS framework as part of the batteries, that framework probably would've been deprecated by now. For instance, who still builds websites with Angular or Backbone/Marionette anymore? See also Rails, which did choose a battery quite early on: prototype.js. Well, that was a wrong decision, so they changed it to jQuery (which is now also deprecated; no idea what it supports nowadays) and also dropped…