Hacker News Reader

Comment by locusofself | Hacker News Reader

I've been away from python for quite some time but enjoyed using django on a project 5-6 years ago. I thought it was really full-featured and fairly intuitive, but it seemed to rely heavily on what seems to be considered an older paradim of submitting forms, and getting sent to a new page, etc, vs the "Single Page Application" concept.

I know it was possible to do SPAs with django-rest or something, but I'm curious if Django has mostly stayed in this "older" paradigm or if its more .. modernized at this point?

View on HN

I'm relieved to see that the idea that SPAs are a "modern", better way of doing things seems to finally be fading a little bit.

My experience from lessons learned over the past ten years is that SPAs generally take longer to build, are usually slower to load, have much worse accessibility and are more expensive to debug and maintain.

For a great deal of web projects you're better off with the "old paradigm".

That said... I do think there's an argument to be made that Django should include core framework features that make working with SPAs easier, rather than farming that out entirely to Django REST Framework.

Django 4.2 does have one nod in that direction: https://docs.djangoproject.com/en/4.2/releases/4.2/#django-c... - "ManifestStaticFilesStorage now has experimental support for replacing paths to JavaScript modules in import and export statements with their hashed counterparts".

Why not just absorb DRF? Which as I understand is the leading choice for many, so I wonder if some effort should be dedicated to reducing fragmentation.

The problem with having things like DRF inside of Django core is that it reduces their speed of iteration.

Django releases a new version every six months. Packages that aren't part of Django core are free to release on a different schedule, which really helps when you're trying to innovate on something new.

In DRF's case it's now mature and stable enough that maybe that wouldn't be so much of a problem... but it's still not clear to me that having it in Django core would be a net benefit (aside from as a marketing thing) than having it live independently as it does today.

The problem with DRF being an external package is that it does thing slightly different than Django itself would do it.

DRF’s validators don’t implement `__eq__`, Serializers doesn’t implement `serializer._meta.fields` on the base class (you have to instantiate the serializer to access anything other than `declared_fields`), lack of async view support, and on and on.

I find DRF grating and would pay anything to have an official Django REST api contrib package.

Cripes. Whenever I post from my iPad I always seem to miss 2-3 autocorrect injected typos.

The old paradigm is new again. Combining Django with HTMX, you get the simplicity of rendering HTML on the server side and not deal with bloated and over-engineered Javascript frameworks. Flask/Django with HTMX and Tailwindcss is a fantastic combination and my current preferred stack. I also add Alpinejs to this mix for interactivity. Really enjoying the heightened productivity that this setup provides.

This looks really interesting. I haven't come across HTMX before, but I'll give it a look.

I tried out htmx + django a little but got stuck doing something more than trivial. Do you have an example of a starter project that has intermediate concepts demonstrated? Maybe this can help me get over the hump.

Another solid alternative to htmx is unpoly (https://unpoly.com/) and there's an exhaustive writeup on how to use unpoly with django as well here https://www.spapas.net/2023/04/04/using-unpoly-with-django/

Honestly, the SPA concept is flawed, and throws away all the good things that HTML gave you out of the box. I'm glad people are starting to come to their senses and are moving away from it.

Like everything, they are useful as a tool in certain contexts, particularly the application context.

Just don't try to pretend it's a "good for everything" tool.

Do you mind elaborating on the good things HTML gives you out-of-the-box that SPAs throw away?

Meaningful back/forward buttons, for one!

(I know this is not HTML per se, but it's by far my biggest pet peeve with SPA since forever, so I had to mention it.)

You only have to build the application once, for one thing. With SPAs you have to build the application on the backend and then build it again on the front end.

Not necessarily.

There's a brilliant project called Django Unicorn that aims to be the equivalent of Laravel Livewire for Django. You should take a look.

https://www.django-unicorn.com/

That and HTMX + Alpine.js are a strong combination.

(I also had a bash at building a similar tool for Django called Tetra but unfortunately haven't had the time needed to commit to it: https://www.tetraframework.com)

but how does it stack up against phoenix liveview? ;)

It’s probably slower.

Can you use HTMX + jQuery for the glue logic?

A few things:

    1/ "older" paradigm is still extremely useful in many cases
    2/ we also use Django as a backend for SPAs. Here with Vuetify
    3/ using the HTMX paradigm, you're both doing SPA and "older paradim of submitting forms"

SPA is just "a way" to do things. You're describing them as older/modern, but they're simply different approaches to achieve different things.

Django is ver good if you are writing non SPA with a SQL backend. If you are writing a SPA without a SQL backend (any of the noSQL DBs), it becomes much easier to just use flask/quartz/fastAPI, as you don't benefit from the Django niceties.

It’s fine even if you’re writing an SPA, the “niceties” don’t really get in the way at all.

and when you find yourself actually needing "niceties" they are right there waiting...

I've been trying those alternative libraries from time to time and there is always the thought "I wish I started this in Django" when project becomes more complex than a basic endpoint.

DRF works really well. You'll inevitably have some other pages that require non SPA, for example your login pages, signup and things like that. So regular Django forms come in handy there.

You might want to look into HTMX (https://htmx.org/). It's very popular in the Django community.

https://www.django-rest-framework.org/

Does SPA concept work well with search engines? I moved away from web development, but SPAs used to be very bad if you wanted to appear in Google search.

Btw I was looking into Django recently, they are still using the “older” paradigm you are referring to.

I think Google is capable of handling SPAs these days (it can execute js now), so works fine mostly (might still be better to serve full HTMLs to start with).

It technically can render javascript, but there's a performance penalty that negatively affects your crawl budget.

If you're twitter or facebook, or have enough domain reputation already that your crawl budget is big enough to offset, then it doesn't matter. If you are not already a big deal, then it takes a lot of off-site traction to overcome.

Practically speaking, for two otherwise-even sites just starting out, a statically rendered site has a pretty significant SEO advantage over a JS-only site.

(Which is why hydration is a thing)

You can server-side render the SPA. Not with Django, but with things like Nuxt or Next.

Then the SEO penalty is just the increased page size (maybe some extra loading time). But at least the content can be crawled normally.

For fancier, SPA style applications we utilize Strawberry to add GraphQL support into Django. It's pretty enjoyable to work with, but I would love for GraphQL to get more love from Django officially.

Subscriptions are still a bit thorny, but have come a long way now that ASGI and channels are a focus for the Django team.

You might not keep up with things on Twitter, but SPAs are out. It's really a relic of an older time.

Surely a better metric would be actual jobs as advertised on Indeed.com where there's a metric ton of React jobs which doesn't look like changing anytime soon regardless of what may be happening on Twitter.

Yea, React is moving to the server. Check out Remix, which pushes the more "old school" approach of doing forms. I think Next is coming soon with something for that.

What replaces them?

Why would you want to do SPA? What does it actually do to improve life for users?

Djangi can also work well with turbolinks

Reply on news.ycombinator.com