Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

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

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?

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

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?

That is beautifully ridiculous! Thank you for doing that and sharing.

This shows how modern hardware is ridiculously powerful.

When will people stop doing this and just leave Doom alone?

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?

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?

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.

Shame Phoenix LiveView is missing from the comparison

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

> 600.000 divs/segundo

Basado