Being new to Clojure I was (and still is to be honest) infatuated with functional zippers. They are just…​ supercool, awesome and the coolest ever. Something along those lines. When sliced bread was invented, functional zippers were there for the initial draft, slicing and dicing all the atoms in the bread for the perfect cut so that future generations of bread slice makers had something to aim for, but never reach.

Knowing that I had to do a lot of data manipulation I crafted up a whole eloborate scheme for extending syntax that you could hook into. And it worked. Quite well actually.

But a postwalk can get you to about 70-80% of what you can do with functional zippers, so unless you need to know about the surrounding data in the data structure you’re walking through, a postwalk is probably fine.

Multimethods is another of those things that I dove straight for. Very powerful stuff. A map lookup can also work just as well, and with a small setup step you can have your extendability as much as you want with a simple merge.

Validation is super important for web forms. Especially for backend. Don’t trust data from the web. Always validate.

The mistake I made here was that I went with a specific validation library. It was a really good library, but I now tied myself down to a specific validation, instead of making it optional.

I made the same mistake with i18n as with validation. I picked a specific implementation. In addition, I added a number of translations out of the box. While helpful to some extent, I still would consider them harmful because they set a specific direction, and thus sets an implicit boundary for the library in terms of what it should do, as opposed to what it can do.

Syntax. If you can avoid it, do it! Syntax is one of those insidious things that are really, really, really hard to get right. Hiccup’s genius is that it’s HTML in the guise of EDN. Pure data structures, with a one to one mapping to HTML.

I did not use maps and vectors enough. Maps are so incredibly versatile because of their associative nature. Combine it with vectors for lookups and you remove the need for a lot of elaborative walk-throughs of complex datastructures. It is better to spend time designing a datastructure with maps and good key naming, than writing yet another function that navigates a complex datastructure for a small update.

With the old version of ez-form, I had 8268 words in my src directory. With the rewritten version, which mostly has feature parity, I stand at 1003 words. That is a 88% reduction in code size. The code is smaller, easier to reason about, easier to test and has so far been very easy to extend whenever I found myself wishing for a new feature.