Building a simple room-based chat application in Nim (using HTMX)
arhamjain.com
arhamjain.com
And HTMX "allows you to access AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext": https://htmx.org/
I also like the community. It's not so big that it feels like you only see people once but not so small that there are no useful libraries written. Just the right size for me. You can always get people to help you out on stuff, reminds me of old IRC days.
Says the person responsible for a ton of really useful, well-done Nim libraries, such as this amazing Cairo/Skia-like library: https://github.com/treeform/pixie#readme
Thank you for all the things you've made for Nim!
Why does this sound like some sort of code[3][4] that leads to some sort of Ouroboros[5] ultra pun[6]?
Quick! To Rome!!
[0] https://en.wikipedia.org/wiki/Skia_Graphics_Engine
[1] https://en.wikipedia.org/wiki/Chiaroscuro?wprov=sfti1
[2] https://en.wikipedia.org/wiki/Cairo_(graphics)#History
[3] https://en.wikipedia.org/wiki/The_Da_Vinci_Code
[4] https://drawpaintacademy.com/chiaroscuro/
It makes debugging shaders much easier as you can use print statements and unit tests. You can also share code between CPU and GPU side.
Huh, this is an interesting take. Instead of taking either of the extremes of "coerce types aggressively" (Perl, PHP, C (kinda)) or "no type coercion ever" (CL (kinda), Rust?), Nim has programmable type coercion, so you can enable it just when you need it.
It used to be that a powerful demo of a framework or language would be a pretty sweet starting point, but I'm not so sure about that anymore.
Nim has a smaller community, so the supply chain tends not to be more than one or two levels deep in my experience. This is also because the standard library is fairly large.
sounds extremely tight given the functionality
Plus Nim is fast! I can load the index page of this application at 90k requests per second single-threaded on a laptop from a few years ago.
So in this case, the `template` bits are doing plain code substitution at compile time, and the buildHtml `macro` is doing more advanced code generation, also at compile time. This means that it should avoid the overhead you mentioned with a key-value struct/lambda.
For what it's worth, this could also have been implemented as a `proc` which would then take in a lambda/anonymous function to generate the HTML, but that incurs additional overhead and requires a bit of extra syntax, which felt like a hassle.
text ": " & sentMessage.getStr()
The `text` function in the Karax DSL is actually escaped once it is converted to a string, see https://github.com/karaxnim/karax/blob/c71bc927494418c3f52f9... for the implementation if you are curious. There is a way to render raw HTML using `verbatim` instead of `text` in Karax.So in this case, I believe it would be protected against XSS to some extent, but I obviously haven't done an in depth security check for a demo/simple project. There are plenty of other potential issues as well (username collisions, websocket errors, user lists) but I judged those to be out of the scope of a simple project like this.
https://github.com/lelandbatey/flask_example/tree/master/fla...