[HN Gopher] Doom in Django: testing the limits of LiveView at 60...
       ___________________________________________________________________
        
       Doom in Django: testing the limits of LiveView at 600.000
       divs/segundo
        
       Author : andros
       Score  : 158 points
       Date   : 2025-12-28 08:10 UTC (3 days ago)
        
 (HTM) web link (en.andros.dev)
 (TXT) w3m dump (en.andros.dev)
        
       | ksec wrote:
       | In the blog post it uses "600,000 divs/second!" and "10,000 divs
       | using its template engine" while the heading uses 600.000.
       | 
       | I assume the difference in usage of full stop / period or comma
       | is accidental?
        
         | andros wrote:
         | Yes, you right hehe. I had fixed!
        
       | agentifysh wrote:
       | if only i could run django on cloudflare workers
       | 
       | guess i could run it on a dedicated server
       | 
       | would be nice if we can get django and liveview working without a
       | server
        
         | leobuskin wrote:
         | you can do it on wasmer's workers, their last wasm/python
         | approach is pretty solid (compatibility, performance). it's sad
         | to say, but after 4 years of "beta" Python support on CF
         | workers - it's still ugly. I dunno who was responsible for such
         | a neglect, but even with the last changes - total fiasco
        
           | gscho wrote:
           | Why is it "ugly"?
        
         | evilmonkey19 wrote:
         | I wish we could host Django apps with the tasks and everything
         | on Cloudflare workers. Also it would be nice to have a DB like
         | SQLite within Cloudflare.
        
           | yoavm wrote:
           | Cloudflare D1 is SQLite within Cloudflare.
        
           | BiteCode_dev wrote:
           | Why, because it's free?
        
         | isodev wrote:
         | Bunny has very solid edge runtime if you manage to squeeze it
         | into wasm or "magic containers" so it's just a pod
         | 
         | https://bunny.net/cdn-lp
        
         | slig wrote:
         | Should be possible with this, no?
         | 
         | https://developers.cloudflare.com/containers/
        
         | fulafel wrote:
         | They just announced many improvements to Python workers earlier
         | this month: https://blog.cloudflare.com/python-workers-
         | advancements/
         | 
         | https://github.com/G4brym/django-cf has a template (among other
         | things) to get started
         | 
         | Another option is the containers stuff mentioned in sibling
         | comment but it's not so FaaS.
        
         | _boffin_ wrote:
         | We ran Django on AWS Lambas years ago. Wasn't fun and caused
         | headaches, but worked
        
       | pawelduda wrote:
       | Shame Phoenix LiveView is missing from the comparison
        
         | leobuskin wrote:
         | It's only django-related third-party packages comparison (and
         | SSR itself), would be a bit strange to compare with a different
         | language/stack and/or framework
        
           | isodev wrote:
           | With focus on LiveView, I think it's interesting to see how
           | the runtime influences the results. Django and Phoenix have a
           | very different concurrency model
        
       | kvakvs wrote:
       | Since Doom renders the image with vertical columns of pixels
       | (floor, lower wall, portal if exists continues rendering the
       | other sector, then upper wall then ceiling) and since browsers
       | are very good at drawing the sprites out of larger textures...
       | You could send vertical divs shaded with the sector light level
       | and picking the correct textures. Instead of hundreds per column
       | you will have like 5 divs on average per column and they will be
       | textured shaded and scaled by the browser?
        
         | ffsm8 wrote:
         | I believe he stated in the beginning pretty clearly that the
         | point of this exercise was to stress test the Liveview
         | performance.
         | 
         | Making this more efficient would be kinda counter productive
        
           | jasonjmcghee wrote:
           | I agree, but it certainly wasn't performant (in the video).
           | 
           | I'd be curious to see what parameters are required for a
           | smooth / playable demo.
           | 
           | Or am I missing something?
           | 
           | (Slow input with no interpolation?)
        
             | andros wrote:
             | To improve fluidity, all you have to do is change the
             | frames per second or the resolution, although the goal is
             | not to make it playable. :D
        
           | andros wrote:
           | That is!
        
           | omoikane wrote:
           | I think the proposal here is to optimize for bandwidth by
           | minimizing number of divs, because there are fewer divs per
           | column per frame. It might actually turn out to be more work
           | for the browser because it has to layout the columns with
           | divs that are not uniformly sized.
        
         | oersted wrote:
         | At that point just run the browser on the server and use proper
         | cloud gaming tech to stream the screen and have low-latency
         | interactivity.
        
           | andros wrote:
           | If it's streaming at 60 fps, the bottleneck is in the
           | browser, which is doing what it can :)
        
             | maccard wrote:
             | My phone and TV can go to 120hz, and my PC can go to 240
             | with adaptive sync. There's still plenty of room to
             | improve.
        
         | Jare wrote:
         | IIRC someone did exactly that around 15 years ago, a game
         | renderer using div strips, first with Wolfenstein and then
         | Doom. It may have been "Jacob Seidelin" who was very active
         | experimenting with early HTML5 tech, but I've lost all links or
         | they've vanished from the web - I only keep two screenshots I
         | used in a lecture back then.
        
       | rockyj wrote:
       | Very impressive! Worth noting that HTMX also has a WebSocket
       | extension - https://v1.htmx.org/extensions/web-sockets/ so one
       | could potentially also do "live views" in more performant
       | runtimes like JVM or Node.js
        
         | andros wrote:
         | My first version of Django LiveView used HTMX. WebSocket
         | connectivity is one aspect; there is another part of logic and
         | architecture where it falls short.
        
           | BiteCode_dev wrote:
           | Can you tell us more? Espacially, how does they both fair
           | with auth.
        
             | andros wrote:
             | There is native middleware in Channels. I have it
             | documented with a brief example in the documentation, and I
             | also mention some security measures.
        
       | crimsonnoodle58 wrote:
       | So SSR is 50ms and LiveView is 10ms, what test was being
       | performed to achieve these timings? Rendering a sample page or
       | rendering doom?
       | 
       | Also LiveView is described as "Build rich, dynamic user
       | experiences with server-rendered HTML without writing a single
       | line of JavaScript." and their example uses django templating to
       | render the HTML that is returned.
       | 
       | So what are we really measuring here? The speed up seems to
       | solely come from WebSockets, and maybe skipping some Django
       | middleware. Anyone care to elaborate?
        
         | aeonfox wrote:
         | I assume Django LiveView is directly inspired by Phoenix
         | LiveView. It's essentially diffing template expansion on the
         | backend and sending patches to the frontend via websockets
         | where JS then applies the patches. Clicks and other
         | interactions are also transmitted to the backend where state
         | for the socket is updated and the template is reevaluated,
         | hence completing the loop.
        
           | andros wrote:
           | The concept is correct, but it's a bit simpler Its
           | architecture is explained in the documentation, that's why
           | it's so fast!
        
             | zie wrote:
             | I looked(admittedly briefly) and couldn't find the
             | architecture explanation in the docs here: https://django-
             | liveview.andros.dev/docs/
        
               | andros wrote:
               | I apologize, I assumed the architecture would be
               | understandable from the examples. I'll keep that in mind!
        
       | scop wrote:
       | Tangential question: is it common for frameworks to use the same
       | name as a package from another framework? I had never heard of
       | Django LiveView, but have used Phoenix's Liveview and assumed
       | that's what it was. Not sure if I like that? I.e. does it imply
       | some sort of endorsement or partnership? I do like that Laravel
       | went with Livewire to distinguish it.
        
         | andros wrote:
         | There are two things I'm really bad at: invalidating the cache
         | and naming frameworks. It has that name because it's very
         | inspired. It's an adaptation of Django.
        
           | elzbardico wrote:
           | And well done! I really prefer very descriptive names, even
           | at the expense of originality than some ridiculous invention
           | like "Nano Banana".
        
             | ameliaquining wrote:
             | IIUC the "Nano Banana" name was originally used on LMArena
             | when the model had not yet been announced; the purpose of
             | the name was therefore to be as opaque as possible. I
             | assume they hadn't originally intended to keep using it
             | after the announcement, but it unexpectedly took off among
             | users.
        
       | pallar wrote:
       | > 600.000 divs/segundo
       | 
       | Basado
        
       | hoistbypetard wrote:
       | That is beautifully ridiculous! Thank you for doing that and
       | sharing.
        
         | andros wrote:
         | Thank you for this comment :)
        
       | lukevp wrote:
       | It definitely isn't running at 60 fps in the video. Is this css
       | performance or something? Or this not really running as fast as
       | it's stated?
        
       | elzbardico wrote:
       | This shows how modern hardware is ridiculously powerful.
        
       | andypants wrote:
       | This is more like HTMX+websockets than phoenix liveview.
       | - It's not stateful       - There's no html diffing       -
       | Handlers return target+fragment instead of updating state
        
         | andros wrote:
         | Each user has their ID in the backend; you can save their
         | status... if you want.
        
       | jkhall81 wrote:
       | When will people stop doing this and just leave Doom alone?
        
         | pak9rabid wrote:
         | Never I hope
        
       ___________________________________________________________________
       (page generated 2025-12-31 23:00 UTC)