Really looking forward to a how it works post. What is that READMEM_1??
it's a placeholder that gets replaces by the python script on build
Show HN: X86CSS – An x86 CPU emulator written in CSS
91–99 of 99 posts
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#92Earlier quoted context omitted.
I admit I don't have depth of knowledge with how JS and Wasm work behind the scenes, but you can already compile JS to wasm. Forgive the ignorance, but what am I missing here? When you compile JS to wasm, aren't the semantics and language behaviors already addressed? My understanding was that things like DOM manipulation APIs would need to be (and are) exposed to the WASM runtime so that the JS-to-WASM compiler could…
You can't currently "compile JS to Wasm", you can compile a JS engine (likely written in C++) to Wasm and run JS inside that (almost certainly at lower speed). So instead of "no more V8", it's closer to "ship V8 as part of the website, instead of part of the browser". Exposing DOM APIs to Wasm is a completely different question, though even those would actually have to be new APIs with a new API design that works for…
I didn't know this, thanks for explaining. If DOM APIs could be reworked for wasm support, and JS can work with those APIs, that would suffice. It won't get sites off normal JS any time soon. As far as speed, is it an optimization problem? I'd think just running bytecode is faster than interpreting a script. It doesn't need to be backwards compatible with existing JS code, it just needs to be possible to write front end code in JS for WASM. Migrating to the new approach could be similar to migrating away from Flash, ActiveX and Applets, but at a much larger scale.
10-20 years from now, is it really ok to be stuck with JS and CSS? The complexity is compounding, ever newer webapi's get encoded as JS APIs, and the dependency mess will only increase. Browsers are about as complex in some ways as an operating system. If we think about the world in terms of decades, what is the plan? This is a very serious issue, because of how much the world depends on browser tech, and effectively, Google is the arbiter and overseer of that technology. I don't think this will work out well, unless there is some timely foresight in the architecture.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#93Earlier quoted context omitted.
Now we can embed a cryptominer on a page even with JS disabled! /s
Interesting idea. This will be useful only when the CSS communicates with a server. Maybe it can make requests indirectly by setting background image URLs or something and send data piece by piece for each byte. Not sure.
That happens today in the wild even. CSS url() function and basic things like applying background images to semi-invisible blocks for entirely CSS-based data exfiltration. From what I've heard it is most commonly used today for fingerprinting systems of trackers that use a ton of @media queries to try to fingerprint you based on the subtleties of your browser.
Relates to some Safari and Firefox engineers warning on pretty much every new CSS proposal to consider how it can be (ab)used for tracking.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#94Predictably, all the same people who bemoan JS ubiquity feel the need to express their distaste for advances in CSS in this thread. Nobody is actually doing stuff like this in real applications, it’s just a demo, for fun. I get the feeling some people just hate the web.
Your grumpiness contradicts itself. To the extent that it's just for fun, it's not an advance. And CSS being Turing complete doesn't make it suitable to replace any JS it couldn't already replace, so why can't JS-haters dislike the idea? If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
> To the extent that it's just for fun, it's not an advance.
The features which are being exploited to implement this are indeed advances.
> If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style. Nobody is seriously suggesting CSS is a _replacement_ for JS, it’s just a better solution for certain common things on the web.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#95Whoa! Completely unrelated but somehow unsurprising: Zero-day CSS: CVE-2026-2441 exists in the wild - https://news.ycombinator.com/item?id=47062748 - February 2026 (233 comments)
I do actually have a CSS CVE[0] in Chrome, but it was in the changelog as "in Animation" instead of "in CSS", so no fun stories/headlines for me :c [0] https://chromereleases.googleblog.com/2025/06/stable-channel...
Wait, does it mean you can commit actual CSS crimes now?
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#96Earlier quoted context omitted.
Your grumpiness contradicts itself. To the extent that it's just for fun, it's not an advance. And CSS being Turing complete doesn't make it suitable to replace any JS it couldn't already replace, so why can't JS-haters dislike the idea? If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it!
> To the extent that it's just for fun, it's not an advance. The features which are being exploited to implement this are indeed advances. > If I didn't like a language and people offered an even worse to use replacement I'd be justified in having distaste for it! You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you…
> The features which are being exploited to implement this are indeed advances.
The specific way it became Turing complete seems more accidental than anything. We could have had pretty much the same features without the same --var handling.
> You’re missing my point. Nobody is actually suggesting replacing JS with CSS, but many new CSS features eliminate the need to use JS to accomplish what you need in terms of behavior or style.
I'm also talking about replacing specific things. But none of the specific things done in this article are easier in CSS than in JS.
If you're talking about different posts about CSS, I haven't seen those ones.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#97Earlier quoted context omitted.
> Turing completeness is notorious for showing up in systems unintentionally Greenspun's 10th law. https://wiki.c2.com/?GreenspunsTenthRuleOfProgramming
That's on the opposite end of the complexity spectrum.
Perhaps so, but ISTM that it encapsulates the same basic point. Try to make something rich and general and you often end up re-implementing a whole computer inside your computer.
Which is why these days it's easier in many cases to just embed an Arm core and implement your controller's functionality in software.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#98Earlier quoted context omitted.
That's on the opposite end of the complexity spectrum.
Perhaps so, but ISTM that it encapsulates the same basic point. Try to make something rich and general and you often end up re-implementing a whole computer inside your computer. Which is why these days it's easier in many cases to just embed an Arm core and implement your controller's functionality in software.
> Try to make something rich and general
It's also easy to stumble into Turing completeness when you're just trying to let one setting modify another setting in a basic way.
Re: Show HN: X86CSS – An x86 CPU emulator written in CSS
#99Earlier quoted context omitted.
> CSS only exists becuase javascript failed to develop a styling component to displace it there is no sortage of projects that do it (especially during the react era, people wanted to get rid of both html and css) but they get pushed down by dogma/inertia mostly. There was iOS constraint layout language ported to js. Seemed pretty cool, but the guy behind it decided to give up and everyone was like welp we tried, did…
It sounds like the consistent pattern is the requirement for browsers to support it. If browsers supported intermediary languages instead, that might be ideal?
browser is the new os. It should just have first class support for a common bytecode target (wasm), everything follows.
I think the issue with CSS was that the low level APIs wasn't exposed which was the point of project Houdini https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API...