51–55 of 55 posts
Earlier quoted context omitted.
I looked(admittedly briefly) and couldn't find the architecture explanation in the docs here: https://django-liveview.andros.dev/docs/
I apologize, I assumed the architecture would be understandable from the examples. I'll keep that in mind!
Earlier quoted context omitted.
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
Earlier quoted context omitted.
I apologize, I assumed the architecture would be understandable from the examples. I'll keep that in mind!
The docs lead to a 403, but I'd be curious to know how it is simpler. I believe the Phoenix version uses Erlang iolists and immutability to make diffing more efficient, and perhaps the Django version has something similar?
Though it doesn't answer your question, the link at least works :)
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 co…
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