So, what’s the difference between . and emit? It seems both take a string and output it to the HTML of the page. If so I don’t see why that couldn’t be
LLM-based coding is enabling so much! The crazy weekend project now can have compilation to native code and web assembly, allow server-side or client-side rendering, manage multiple types of persistence, include adaptive compression, and do all of this without breaking a sweat.
React (and the unidirectional FRP approach in general) is the only known sane way to describe complex GUIs. It's the same approach that powers spreadsheet calculations.
Most websites are not complex GUIs though, and do not need React.
It's not "the only known sane way". In many cases, it's not even an appropriate approach! MVC, PAC, and asynchronous self-contained widgets are perfectly cromulent alternatives, each with their own strengths, but I've yet to see a situation where React was actually the best way to go.
> Something like this:
> : h1 ( s -- ) "<h1>" emit . "</h1>" emit ;
> "Hello, World!" h1
So, what’s the difference between . and emit? It seems both take a string and output it to the HTML of the page. If so I don’t see why that couldn’t be
We also have: where, I think, the idea is to always have the two strings consistent with each other. If so, why require the blog writer to do that conversion?There's no docs or implementation, but I'd say that `.` in Forth is a generic way to print something, and `emit` may do more work, like HTML escaping.
It looks like it's the opposite: `.` does HTML escaping, whereas `emit` is raw.
LLM-based coding is enabling so much! The crazy weekend project now can have compilation to native code and web assembly, allow server-side or client-side rendering, manage multiple types of persistence, include adaptive compression, and do all of this without breaking a sweat.
It's scary but I love it.
For all its worth this could just be an AI generated blog post. There is no code, no repository, no link to any use.
And yet people keep using React, relying on a fractal pattern of kludges.
React (and the unidirectional FRP approach in general) is the only known sane way to describe complex GUIs. It's the same approach that powers spreadsheet calculations.
Most websites are not complex GUIs though, and do not need React.
It's not "the only known sane way". In many cases, it's not even an appropriate approach! MVC, PAC, and asynchronous self-contained widgets are perfectly cromulent alternatives, each with their own strengths, but I've yet to see a situation where React was actually the best way to go.
This post isn't offering anything better.
> I like how weird it is. I might use it for my site, who knows?
If there's a place to use a weird and fun language it is certainly one's own personal blog. Sounds like a great opportunity, I think you should do it.
HN Hug of Death: https://web.archive.org/web/20260522134016/https://robida.ne...