Hi everyone! This is my first post in r/perl.

I've been working on a CPAN module called JSON::JSONFold, and I wrote an article describing the motivation and design. I'd really appreciate feedback from other Perl developers.

JSON serializers tend to give us two choices: compact JSON, which is efficient but a dense wall of text that's painful to read, or pretty-printed JSON, which is readable but often wastes a lot of vertical space (a small array of numbers can turn into ten lines).

I wanted something in between. JSONFold keeps the shape of pretty-printed JSON, but folds small, simple structures back onto a single line whenever that improves readability. It works on top of your existing serializer (JSON, JSON::PP, JSON::XS, etc.) - you keep using whatever you already have, and JSONFold just reformats the output.

Example 1 - Coding

use JSON::JSONFold qw(encode_json);

my $data = {
    _id       => 123,
    locations => [
      { city => "Boston",    state => "MA", country => "USA" },
      { city => "Seattle",   state => "WA", country => "USA" },
      { city => "Montreal",  state => "QC", country => "Canada" },
    ],
    info      => {
      roles     => [ "foo", "bar", "baz" ],
    },
    name      => "Alice",
};

print encode_json($data) ;

Output

{
  "_id": 123,
  "info": { "roles": [ "foo", "bar", "baz" ] },
  "locations": [
    { "city": "Boston",   "country": "USA",    "state": "MA" },
    { "city": "Seattle",  "country": "USA",    "state": "WA" },
    { "city": "Montreal", "country": "Canada", "state": "QC" }
  ],
  "name": "Alice"
}

Example 2 - Packing

Traditional pretty-printing:

{
  "states": [
    "Alabama",
    "Alaska",
    "Arizona",
    ...
    "Wyoming"
  ]
}

JSONFold:

{
  "states": [
    "Alabama", "Alaska", "Arizona", "Arkansas", "California", "Colorado",
    "Connecticut", "Delaware", "Florida", "Georgia", ...
    "West_Virginia", "Wisconsin", "Wyoming"
  ]
}

Same data, just using the available line width more effectively.

Example 3 - Grid Formatting

When an array contains repeated structures, JSONFold can align values into columns:

Traditional pretty-printing:

[
  {
    "orders": 18,
    "product": "Laptop",
    "region": "North",
    "sales": 1250
  },
  ...
  {
    "orders": 24,
    "product": "Mouse",
    "region": "East",
    "sales": 1422
  }
]

JSONFold:

[
  { "orders": 18, "product": "Laptop",   "region": "North",     "sales": 1250 },
  { "orders": 21, "product": "Monitor",  "region": "Southwest", "sales": 1345 },
  { "orders": 17, "product": "Keyboard", "region": "West",      "sales": 1198 },
  { "orders": 24, "product": "Mouse",    "region": "East",      "sales": 1422 }
]

The module also supports:

• Folding small arrays and objects onto a single line.
• Joining adjacent folded objects to further reduce vertical space.
• Compatibility APIs similar to JSON and JSON::PP.

I wrote a more detailed article covering the design, implementation, and full set of examples:

Medium: https://medium.com/p/a619c9e7c3ec

CPAN: https://metacpan.org/pod/JSON::JSONFold

GitHub: https://github.com/yairlenga/jsonfold/tree/main/perl

I'd love to hear what the Perl community thinks. Has anyone else run into JSON pretty-printing pain in logs, configs, or debugging output? And are there formatting styles or options you'd want to see?

Time::Str's DateTime format now runs on a native Ragel-generated C state machine instead of a regexp, ~20x faster than the regexp path.

Supported formats

One parser accepts ISO 8601, RFC 3339, RFC 9557, RFC 4287, ISO 9075, RFC 2822, RFC 2616, RFC 3501, and ECMAScript Date.toString, plus free-form textual dates (Monday, 24th December 2012 at 3:30 pm UTC+1 (CET), 24. XII. 2012 12PM, 24DEC2012 12:30:45.500).

No heuristics, multi-standard, single-pass

Most permissive parsers (Python's dateutil, PHP's strtotime, Ruby's Date.parse) resolve ambiguity by guessing, whether via fixed heuristics or dayfirst/yearfirst flags.Time::Str refuses it: numeric-only dates are Y-M-D only; any other ordering requires a textual or Roman-numeral month. Disambiguation is baked into the grammar's alternation, not resolved at runtime. Even separator-consistency (2024-12/24 is rejected) is enforced inline, no second pass.

Performance

The DateTime parser accepts every format listed above, yet runs within ~10-20% of the single-standard parsers beside it. On Perl v5.42 (XS), parsing 2012-12-24T11:30:45.123456Z:

                Rate   DateTime  RFC3339  RFC2822  ECMAScript
DateTime   10523558/s        --     -11%     -15%        -18%
RFC3339    11785319/s       12%       --      -5%         -8%
RFC2822    12376403/s       18%       5%       --         -3%
ECMAScript 12776079/s       21%       8%       3%          --

A purpose-built RFC 3339 parser is only ~12% faster than the permissive one. That's the payoff of baking disambiguation into the grammar — there's almost no "permissiveness tax".

Enjoy!

This weekend at the perl and raku conference I did a presentation on how to move forward from the current state of DBIx::Class and its lack of new development. We discussed several options including an alternative I have been writing. I have never liked DBIx::Class, so I tried to write something that felt more intuitive to how my brain works. It was suggested that I post it here.

DBIx::QuickORM - QuickStart

Comparison to DBIx::Class, term map, etc (Note: This document is AI generated)

Manual

It is probably NOT the right path for large apps with hundreds of lines of DBIx::Class code, it is not intended to be interoperable or a drop in replacement. It is however good for quickly getting ORM functionality in a new project, or against an established database. It is also actively maintained and will continue to be so. I dogfood the things I write, and this will be used in Yath 2.0 when it is released.

Hey folks, I just published HTML::Composer, a new module for creating HTML in Perl.

Here is my blog post about it: https://rawley.xyz/posts/html-composer.html

I'd love to hear feedback on it, or any general opinions. Thanks!

DBIO (MetaCPAN), on LinkedIn, and on codeberg.