Hello Ruby friends! ✌🏼

I hope you had a lovely St. Patrick's Day ☘️ weekend…certainly much fun was had here in Portland, Oregon with plenty of bagpipes and beer to go around.

But that's not why you're subscribed to this newsletter. So let's talk about Ruby!

Signalize, a Ruby Port of Preact Signals

I'm excited to announce a new gem called Signalize. It's a direct port of the JavaScript package called Signals, brought to us by the fine folks at Preact. As it says on the tin, Signalize provides reactive variables, derived computed state, side effect callbacks, and batched updates. While these concepts make the most "obvious" sense in interactive UI scenarios, I've grown quite fond of how signals work and have been experimenting with using them server-side via Ruby. They seem to inhabit a nice middle ground between simply writing "procedural" code based off of callbacks, and implementing more complex and formal state machines.

Naturally I had to record a podcast talking more about signals and the Signalize gem, so listen to Episode 9 of Fullstack Ruby if you're interesting in learning more! I hope to feature additional Signalize-related content in the months ahead.

Nokolexbor…like Nokogiri, but way faster

Another project I've been noodling on for a while now is a Ruby-based component renderer for HTML Modules. Wondering what an "HTML Module" even is? Check out our sister site The Spicy Web's video all on the topic, as well as the esbuild plugin I released to bundle HTML Modules.

In order to maniuplate and render an HTML Module, you of course have to be able to parse HTML. And the most common parser Rubyists are no doubt familar with is Nokogiri. Everybody uses Nokogiri! We even found a cool use for it in Bridgetown which we call HTML Inspectors.

But in experimenting with Nokogiri for this project, I wasn't entirely satistifed with the performance. It wasn't just slower than other component renderers. It was significantly slower. I'm willing to take a bit of a performance hit to gain the ability to use HTML Modules in the cases where they're particularly useful, but not quite that much.

Then last week, I stumbled across a new parser gem called Nokolexbor. It utilizes a C-based parser called Lexbor, and offerers significantly greater performance than Nokogiri. How much greater? Well, when comparing both parsing and CSS selector speeds, you may see gains of anywhere from 5X to 998X! Whoa!!

In my case, I directly compared the performance of cloning and manipulating an already parsed document and serializing out to HTML, and Nokolexbor was around 2X speed in my benchmark. Combine that with its faster parsing, and I'd say that's quite impressive. I did run into an issue with cloning trees which contain <template> tags, which I noted here, but the workaround is fine for now. I should mention that Nokolexbor's handling of template elements is actually closer to the real DOM in the browser—aka the template's single direct child is a document fragment which in turn contains child elements. Nokogiri merely has child elements as direct children of the template element—easier to deal with perhaps, but less like browser DOM.

So I'm pretty stoked about this find and hope to see Nokolexbor grow in popularity and capability. It's always exciting to see powerful new gems enter the Ruby scene.

Speaking of powerful gems…Phlex!

It feels like Phlex has taken the world of Ruby component rendering by storm and offers a fascinating alternative to GitHub's ViewComponent. Now to be fair, Phlex is by no means the first "Ruby DSL" for describing HTML. In fact, a year ago I recorded an episode of Fullstack Ruby all about several DSL templating gems—including my favorite at the time, Papercraft. Crazy to think that Phlex hadn't even begun yet!

What helps Phlex stand out a bit above the rest is creator Joel Drapper's fierce dedication to refining the API, keeping things streamlined yet sophisticated, and zeroing in on great performance. In fact Joel regularly highlights just how fast Phlex is, blowing away both Rails' partials as well as ViewComponent.

My goal is to work on a Bridgetown Phlex plugin soon which folks can use as easily as any other component format. Obviously it works in Rails today. But the neat thing about Phlex is that at its core, it's a pure Ruby API. So you can plug it into pretty much any framework or context you need to use it in. That's rad!

If you haven't yet given Phlex a try, I encourage you to do so!

​

That’s all folks!

Thanks for reading this issue of the Fullstack Ruby newsletter. Got feedback? Questions? Suggestions? Let me know by replying to this email, I'd greatly appreciate it!

Jared