[HN Gopher] CSS is DOOMed
___________________________________________________________________
CSS is DOOMed
Author : msephton
Score : 100 points
Date : 2026-03-28 20:39 UTC (2 hours ago)
(HTM) web link (nielsleenheer.com)
(TXT) w3m dump (nielsleenheer.com)
| Levitating wrote:
| Is CSS that awesome? It's still a language designed for styling
| webpages with 30 year of added features. I'd argue something
| purpose built would be a much better tool for the potential
| usecases people try to use CSS for now.
|
| I guess I am asking, if modern CSS is so awesome, it's awesome
| compared to what exactly?
| oopsiremembered wrote:
| I think the argument lies in its flexibility and versatility
| (regardless of it being the most efficient or effective tool
| for this one particular task).
|
| Duct tape is awesome for the same reason -- even though there
| are several effective use cases for duct tape where a different
| tool would technically be "better" for the job.
| Levitating wrote:
| But you don't choose CSS, it's the only tool in the toolbox.
| As long as you stick to the Web.
| sbarre wrote:
| What kind of system would you propose (or do you envision) for
| applying visual styling to HTML markup in modern web pages
| today?
|
| You can keep it high level but your comment makes me think you
| have something in mind, and I'm honestly curious.
| Levitating wrote:
| I am not sure what a purpose-built tool would look like, but
| the CSS-like language you see in UI frameworks like GTK is
| tailored for styling actual UI's.
|
| In CSS on the web, just centering a div has historically been
| a problem. We have flexbox now, but what if CSS was designed
| with our current needs from the get-go?
| micromacrofoot wrote:
| compared to old css, it just keeps getting better
| 0x737368 wrote:
| With how these things are going, soon hackers will be challenging
| themselves to run Crysis on calculators and microwaves
| oopsiremembered wrote:
| I think we're going to get to the point where AI will try to
| run Doom on humans.
| OrangePilled wrote:
| This page could use some "Practical CSS scroll snapping":
| https://css-tricks.com/practical-css-scroll-snapping/
| division_by_0 wrote:
| I was amazed when I first came across CSS scroll snapping. It's
| great for creating immersive experiences where one part of the
| page fills the entire screen while native browser scrolling
| still works.
| OrangePilled wrote:
| When done right, I oddly find it immersive too. But know some
| people aren't fond of scrolling being tampered with.
|
| The post here could really use it though. The main content is
| pushed to the bottom of the page!
| sheept wrote:
| Creating 3D scenes with CSS has always been possible[0], but like
| this project, it's required JavaScript for interactivity.
|
| But there's a lot more CSS features now. While in the past,
| Turing completeness in CSS required humans to click on
| checkboxes, now CSS can emulate an entire CPU without JavaScript
| or requiring user interaction.[1] So I wonder if DOOM could be
| purely CSS too, in real time.
|
| [0]: https://keithclark.co.uk/labs/css-fps/ [1]:
| https://lyra.horse/x86css/
| captn3m0 wrote:
| The author links to th CSS x86 project:
|
| > Yes, Lyra Rebane build a x86 CPU completely in CSS, but that
| technique is simply not fast enough for handing the game loop.
| So the result is something that uses a lot of JavaScript.
| sgbeal wrote:
| It would be really interesting to see this without the texturing
| applied.
| lysace wrote:
| _The game logic runs in JavaScript_
|
| Also: a modern CPU is around 10000x faster than the 486 CPU Doom
| was designed for. Per core.
| rkagerer wrote:
| But where can I try it out in my browser?
|
| EDIT: https://cssdoom.wtf/
| TeMPOraL wrote:
| Never tried Doom on a phone before, this one is surprisingly
| fluid and very playable.
| nine_k wrote:
| Works smoothly in Firefox. But the default key mapping is
| busted: fire at Alt means that it opens and closes the menu in
| Firefox with each press. Also, Alt + left arrow ends the game
| and goes back in history.
|
| Interestingly, it was more choppy in Chromium.
|
| I could not find a key for moving sideways ("strafing").
|
| All in all, quite mind-boggling.
| notnmeyer wrote:
| at this point i'm more interested in what _can't_ run doom.
| josefrichter wrote:
| scared to go check my washing machine display
| anthk wrote:
| I ran calypso.z3, tristam_island.z3 and a few more Zmachine
| text adventures under an interpreter created in PostScript.
|
| Also if I want I can cross-compile a static build of Frotz for
| Linux/Misc and emulate it under a RISC interpreter for Linux
| syscalls written in... Perl, runable in _every_ modern Perl
| port out there. Linux /RISC binary under Perl for NetBSD/Vax?
| Yes. Slow? Not much, it's a text game in the end.
|
| But, as for the ZMachine, you can run text adventures in
| Android, Game Boy, Amiga, MSDOS, Windows, Palm PDA's...
| anything 8bit and up.
|
| Also, damn _Sokoban_ under Eforth written in Subleq, a VM which
| can just:
|
| - set up a 2^16 RAM size
|
| - single opcode: substract A from B, if less than 0, go to addr
| in C. - A < 0? Get ASCII input in B - B < 0? Put ASCII output
| in B - C < 0? End
|
| This, just this, and people wrote Subleq simulators in C, AWK,
| Python, TCL, FPGA's and whatnot. And it will run Eforth, and
| that means... you can write a ZMachine interpreter on it and be
| really slow if emulated in a Pentium 4 (maybe 3/5 seconds per
| command with a ZMachine on top of Eforth for Muxleq instead of
| Subleq), but the game will be _playable_ and a great exercise
| on Turing completeness.
|
| If a Mandlebrot render under Muxleq+EForth (with no floats
| used, just integers) is as fast as a C64/Amiga with a native
| Forth. then having that tiny EForth+Muxleq is not that useless.
|
| https://github.com/howerj/muxleq
| josefrichter wrote:
| this is wild.
| anthk wrote:
| https://freedom.github.io
|
| Use Deutex, GNU make and Pillow for Python to compile.
|
| Then wou will have up-to-date IWADS to be used aywhere. No need
| to put ID copyrights, just a mention to FreeDoom creators.
| jsjsjxxnnd wrote:
| In recent years CSS has become closer to a full programming
| language through experimental features, for example in 2025 they
| added if statements and some math functions like modulo
|
| https://www.simplethread.com/new-and-upcoming-css-features-i...
| amelius wrote:
| The only thing missing is the ergonomics of a real programming
| language.
| fnord77 wrote:
| > CSS is awesome.
|
| No
| nathanmills wrote:
| >> CSS is awesome.
|
| >No
|
| Yes
| MrDOS wrote:
| In 2006, Ars Technica published an April Fool's article[0]
| declaring that the perennially-forthcoming Duke Nukem Forever
| would finally see the light of day... as... a _browser game_! Ho
| ho, how droll.
|
| Crazy to see how far we've come.
|
| [0]: https://arstechnica.com/gaming/2006/04/forever/
| socalgal2 wrote:
| FYI: this is a cool hack and very impressive, but ... don't do
| this. That fact that it runs doesn't make it a good idea. Like
| running DOOM in Excel (https://github.com/Pranshul-Thakur/DOOM-
| in-excel) or making a DIV for every pixel and rendering by
| changing colors of divs
| https://news.ycombinator.com/item?id=46409359
|
| Use 3D CSS to enhance a 2D page with some flair. But be aware, 3D
| CSS, it's trying to solve things that most realtime 3D rendering
| does not, like intersecting planes need to be subdivided in order
| to correctly handle transparency. This means 3D CSS has an O(N^2)
| or worse type of issue vs rendering yourself using WebGL or
| WebGPU where you'd avoid those issues. This demo probably does
| not intersect any planes but the browser itself has to check for
| those intersections anyway. TL;DR: If you're going to make a 3D
| web game use WebGL or WebGPU, not 3D CSS
|
| Very cool demo though!
| adi_kurian wrote:
| Really cool!
___________________________________________________________________
(page generated 2026-03-28 23:00 UTC)