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

Unicorn – A full-stack web framework for Django

django-unicorn.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Unicorn – A full-stack web framework for Django

#51

Post by whstl »

sjamaan wrote: post #37
EmilStenstrom wrote: post #29

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…

More recently in Rails: Sprockets, then Webpack, then Vite.

Migrating a small website from one to the other is trivial.

Migrating a large enough website was for my team a multi-month affair involving hours-long debugging sessions, opening tickets in multiple Github projects and contributing to the projects.

Decoupling different software components is a good thing.

Re: Unicorn – A full-stack web framework for Django

#52

Post by ocimbote »

tedunangst wrote: post #7

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.

Re: Unicorn – A full-stack web framework for Django

#54

Post by thraxil »

sgt wrote: post #44

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 with that POST request and lag anyway.

Re: Unicorn – A full-stack web framework for Django

#55

Post by doix »

I guess the biggest problem/downside/flaw with this is that you wait for a response from the backend to update the UI. Which is mostly fine, but I've come to expect either a round trip to the server, or instantaneous updates.

This is the uncanny valley for me, it's neither the old school web or "SPA land" (for a lack of a better term). In the todo example, I write some garbage and press "Add", there is absolutely 0 feedback anything happened. I then press it again. About 100ms later, the first thing I typed appeared, then slightly later it got replaced with nothing.

I have no idea how I'd fix that in this framework, there's too much magic for me to figure out where I'd insert a "fix" for this. I'd probably start writing my own javascript to disable the button while it's submitting (which isn't great, but better than today), at which point the "magic" is lost.

Re: Unicorn – A full-stack web framework for Django

#57

Post by entropyneur »

doix wrote: post #55

I guess the biggest problem/downside/flaw with this is that you wait for a response from the backend to update the UI. Which is mostly fine, but I've come to expect either a round trip to the server, or instantaneous updates. This is the uncanny valley for me, it's neither the old school web or "SPA land" (for a lack of a better term). In the todo example, I write some garbage and press "Add", there is absolutely 0 f…

I've only learned about Unicorn from this HN post, so take it with a grain of salt, but this appears to be addressed by the framework itself: https://www.django-unicorn.com/docs/loading-states/

Re: Unicorn – A full-stack web framework for Django

#59

Post by Alifatisk »

bdcravens wrote: post #11
jer0me wrote: post #2

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 )

Stimulus Reflex (Ruby), which predates Hotwire, also deserves a mention, though most of its momentum seemed to stall when Hotwire was announced. https://docs.stimulusreflex.com/

Yes, StimulusReflex deserves some highlight because they were one of the first to introduce this approach!

Re: Unicorn – A full-stack web framework for Django

#60

Post by ubercore »

entropyneur wrote: post #57
doix wrote: post #55

I guess the biggest problem/downside/flaw with this is that you wait for a response from the backend to update the UI. Which is mostly fine, but I've come to expect either a round trip to the server, or instantaneous updates. This is the uncanny valley for me, it's neither the old school web or "SPA land" (for a lack of a better term). In the todo example, I write some garbage and press "Add", there is absolutely 0 f…

I've only learned about Unicorn from this HN post, so take it with a grain of salt, but this appears to be addressed by the framework itself: https://www.django-unicorn.com/docs/loading-states/

Update state isn't quite the same, though -- take the word counting example. That's not easily solvable as far as I can tell.
Post reply on HN