pixie VS htmx

We have written pixie: https://github.com/treeform/pixie . Pixie is a 2D graphics library similar to Cairo and Skia written entirely in Nim. Which I think is a big accomplishment. It even has python bindings: https://pypi.org/project/pixie-python/

I made it because I really like pixie/boxy/windy combo, but there is no gamepad support built-in.

With Nim, you can continuously optimize and improve the hot spots in your code. For example, in the Pixie graphics library, path filling started with floating point code, switched to floating point SIMD, then to 16-bit integer SIMD. Finally, this SIMD was written for both x86 and ARM.

The author Fidget actually has a number of other great libraries that are part of the rendering stack. Notably, Pixie for text and shape rendering in 2D, Boxy for rendering textures to the GPU via opengl, and then Windy for an OS window context and user events, and a number of other libraries related to 3D rendering.

Perhaps not the "best" source code I've ever read, but libVF.io had some beautiful code for what's generally gnarly system-glue code. The iommu setup code is a good example and inspires me to think that system-glue code doesn't need to be gross or impenetrable: https://github.com/Arc-Compute/LibVF.IO/blob/master/src/libv...

Another one I've appreciated reading (and learned more about 2d graphics from) is Pixie, a 2d graphics library written in Nim. Here's the implementation of a fair subset of SVG paths: https://github.com/treeform/pixie/blob/master/src/pixie/path...

And one last one for basic algorithms: https://github.com/nim-lang/Nim/blob/version-1-6/lib/pure/al...

Of course Knuth's original code is still some of the best classic code. K&R's original C book is a classic.

I recently helped work on a new open source JPEG decoder in Nim. (Over here on GitHub: https://github.com/treeform/pixie/blob/master/src/pixie/file...)

This video was extremely helpful to understand the "why" of all the things the spec was trying to explain. It made a huge difference in us being able to get things working.

We talk a bit about JPEG and actually writing our decoder in Nim here: https://www.youtube.com/watch?v=vYwD7OynFcg

Overall, our concluding opinion is that JPEG has some extremely cool and really smart ideas for how to compress images but the binary file format itself has some very painful things in it (progressive and restart markers as a couple examples).

I am working on OpenStreetMap renderer in Nim - see https://github.com/severak/lunarender3/ (but work somewhat stalled)

I needed some language which is:

- compiled to binaries

- and really fast

- has needed libraries (HTTP server, protocol buffers, sqlite and image generation)

- it's easy to set up

It was nice experience and Nim simply worked for my needs. People on Nim forum were nice and helped me when I ran into problems. It has nice and usable built-in library and I was really impressed by graphic library pixie - https://github.com/treeform/pixie

I would use Nim again when I when I will see this application is suited for it (e.g. some command line apps).

> but not so small that there are no useful libraries written...

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!

A 2d graphics library like Nim’s pixie

Recently, I just rewrite one of my application Stashbin from Next.js to GO. Though my main motivation of this migration was to learn GO and experimenting with HTMX. I also aiming to reduce the resource usage of my application and simplify the deployment process. Initially, Stashbin codebase are split into two seperate repository, one for the frontend that uses Next.js and another for the backend that already uses GO. The backend repository is just a REST API responsible for storing and retreiving data from the database.

HTMX is another library that gained popularity due to its server-first approach to rendering data, although seeking a much simpler way of appealing to developers.

When I work with HTMX I need isolated component that can be reusable a form. So I create a PHP Function that generate the Input Datalist.

I was inspired by htmz (which was in turn inspired by htmx) and how the author got pretty close to a basic htmx-like experience just using an iframe. I wanted to push it a little further so whipped this demo together. My submission demonstrates progressive enhancement for the form - with js enabled the request targets an iframe that is inserted into the dom, meaning the page doesn't actually navigate (similar to event.preventDefault()). The iframe receives the html response from the request and on load triggers a function to swap out it's contents into the main page.

As described on htmx.org: "htmx gives you access to 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"

Apart from the source code itself, the repo's README also gives a bit more details about the various packages I used.

1. htmx: https://htmx.org/

Also, there’s some response header juggling you have to do when submitting forms that have a validation step before redirecting: https://github.com/bigskysoftware/htmx/issues/369

I’ve tried to iron out any footguns or server requirements I’ve bumped into while using HTMX & Hotwire in my projects.

✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.

I've been digging into HTMX lately (using Python web frameworks) and find the concepts and approach to be interesting and promising. The idea of hypermedia driven systems over the current practice of JavaScript based frameworks (I never really got into React, played with Vue, and enjoy Svelte/SvelteKit) and the ability to chose your language/framework for the backend while primarily leveraging HTML/CSS on the frontend just seems refreshing.