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
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.
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
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
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
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?
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
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
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
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
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.
Cloudflare D1 is SQLite within Cloudflare.
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
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?
Yes, you right hehe. I had fixed!
Shame Phoenix LiveView is missing from the comparison
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
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