DEV Community: Yawar Amin

Open source is about vendor lock-in

Yawar Amin — Tue, 09 Dec 2025 23:24:45 +0000

TIME and again, people try to redefine the term 'open source', which has a well-known definition, to suit their own needs. We've seen people come up with all sorts of arguments why their stuff is really 'open source', why 'open source' does not mean what we think it does, and why it's not even important. But it's always notable that they're doing this while trying to co-opt the term.

The latest salvo in this inane war is by the infamous David Heinemeier Hansson (or DHH to save us some typing):

Love how calling Fizzy open source is triggering some because our MIT-derived O'Saasy License reserves SaaS monetization rights to us as creators. Same nerds will demoan lack of "sustainable OSS" or argue that handing over all changes under GPL is akshually freedom. Hilarious.

I'm reminded of the immortal Luke Skywalker quote:

Amazing. Every word of what you just said, is wrong.

Let's break it down:

triggering

Triggering? Annoying, maybe. Like, here we go again. 'Triggering' is the word you use, I guess, when you want to instantly dismiss the other side. Oh well.

Same nerds will demoan

I'll have you know I've never demoaned anything in my life. Bemoaned, maybe. But never demoaned!

lack of "sustainable OSS"

As far as I've seen, no one has claimed this. In fact, we've actually been saying it's not OSS, so whatever sustainability strategy you're going for here (SaaS monetization), isn't even relevant. The part we've been protesting is that you've been calling it 'open source'. We'll circle back to that.

handing over all changes under GPL is akshually freedom

Well, GPL is meant to guarantee the important freedoms of software to users. OSS is meant to achieve the same goal. The goal being: avoiding vendor lock-in.

Vendor lock-in

People forget this, but vendor lock-in is what gave rise to the Free Software movement, and thus to open source. Richard Stallman couldn't get his printer to work and couldn't just fix it himself because the software was proprietary and they refused to give him the source code.

The whole idea behind Free Software, and by extension OSS, is that you're not locked in to your vendor. If tomorrow they go away, or jack up your price, you're not just stuck. You have the option to go to a different vendor and get them to maintain the software for you. This creates, in a sense, a perfect free market condition. Economists fantasize about markets like this. With OSS we've actually created it.

But people today still haven't learned their lesson! They commit to the Oracles, the Salesforces, the Jiras, and tons of other vendors hoping and praying that they don't get screwed over. And when they inevitably do get screwed over, they finally start looking for alternatives–at massive cost.

OSS as anti-monopoly

OSS is the antidote to this situation. If tomorrow your PostgreSQL host jacks up their prices, you just move to a different host. Same with Linux, Redis, PHP, WordPress, etc.

And users (think: companies, aka paying customers) love this. This is one of their de-risking strategies: avoid vendor lock-in. This has made OSS a massive success, for decades. And (a large) part of this success is due to the definition of open source ensuring that all OSS licenses allow avoiding vendor lock-in. You can just pick up your software and take it to a different vendor.

And people look at this massive success and brand recognition and think: if I just put my code on GitHub and call it 'open source', it looks great and gives me a huge boost. And when you point out it's not open source, they argue, who are you to gatekeep the definition of open source?

Well I would argue, why do you care so much about calling your thing 'open source'? Why not 'source available'? Why not 'public source'? Or whatever? It's because you know the brand recognition and cachet of the term 'open source'. This didn't just happen out of thin air, spontaneously. It took the work of many, over decades, to build a massive success story of a competitive, free market, commons.

And you want to come in and cash in on this success while refusing to allow the one thing that made the success possible: to let anyone be a vendor for the software. You want to be the sole vendor? Keep it proprietary. Use a source-available license. Nobody will bat an eye. Nobody cares! Go and make your money.

Just don't call it 'open source'.

Why hx-boost is actually the most important feature of htmx

Yawar Amin — Fri, 20 Jun 2025 00:37:06 +0000

SOME of you may know by now that I'm a fan of htmx and its hypermedia-driven website/application design philosophy. When people first learn about htmx, they are often captivated by the idea of hx-get, hx-post, hx-delete, etc. attributes being able to fire off HTTP requests with these methods from any tag on the page. I know I was!

But it turns out there's a really good reason why we shouldn't just fire off requests with any method from any tag on the page: graceful degradation. The idea that even if the JavaScript on the page does not work for whatever reason–turned off on the user's browser, not loaded yet due to big scripts, or maybe due to a slow connection–the user should still be able to interact with most (if not all) of the functionality on the page.

For example, if JavaScript doesn't load, we want users to be able to submit a sign-up form or click on a link to load a new page.

This is what the hx-boost attribute is for. As mentioned on that page:

This has the nice fallback that, if the user does not have javascript enabled, the site will continue to work.

But graceful degradation isn't just a way to make websites that work without JavaScript; it leads us towards a more hypermedia-oriented design.

`hx-boost`–the starting point

hx-boost is a widely misunderstand and, I feel, misused attribute. Its documentation seems to suggest that it should be applied on an entire section of the page to 'boost' all the links inside it:

<div hx-boost=true>
  <a href=/page1>Go To Page 1</a>
  <a href=/page2>Go To Page 2</a>
</div>

And that 'boosting' would simply send the request to the given URL, swap out the entire <body> tag with the <body> tag from the response, and update the URL in the URL bar.

However, I think this is an incorrect way to use hx-boost. The biggest reason why is that applying htmx attributes and inheriting them into large sections of the page tends to lead to unpredictable behaviours and bugs. Also, it is missing the key point of htmx, which I feel is to do targeted updates to parts of the page, not the entire <body> of the page.

So why is hx-boost misused then? I believe it was intended as a shortcut to give people with classic multi-page 'apps' an easy way to make their apps 'feel' like SPAs without having to do the actual work to break down the pages into components. But I believe that this work is actually crucial to making an HDA–a Hypermedia Driven App–that has a great user experience.

Boosting only

The first decision we need to make is to eliminate or at least minimize the use of the hx-get, hx-post, etc. attributes and use boosting only unless we have a very good reason not to. Why? Remember–graceful degradation. The hx- + method attributes work as long as JavaScript and htmx are available, but become no-ops otherwise. Boosted elements gracefully degrade to their basic browser-provided functionality!

Boosted links

Links ie <a> tags do two things: load the resource from the given URL, and update the URL in the URL bar (+ pushing into the page's history stack, but we will treat both as the same thing in this article). Boosted links do the same thing but can additionally swap only parts of the current page, instead of the entire page. Eg:

<a href=/page1 hx-boost=true hx-target=#page>Go To Page 1</a>

This will make htmx request /page1 and swap the response HTML into the element with ID page. Remember that the default swap style is innerHTML, so the content will be inside the #page element, which will be preserved.

But wait...how should the server know to respond with a fragment that is appropriate to be swapped inside #page? Well, htmx sends a request header HX-Request: true with every request. So the backend server can use a fairly simple heuristic to figure out that it should respond with a fragment:

The request has a header HX-Request
The request does not have a header HX-History-Restore-Request

If these two conditions are fulfilled, it can respond with a fragment. Otherwise, it can respond with a full page ie <!DOCTYPE html>... and so on.

Note: when the server does use the values of these headers to determine the response content, it must set the response header Vary: HX-Request, HX-History-Restore-Request. This is to ensure that the browser caches the response correctly.

Then, htmx will automatically update the URL in the URL bar for boosted links; you don't have to manage that explicitly. Basically, boosting works as closely as possible to a normal, non-JavaScript hyperlink.

Lastly and very crucially, boosted links work with not only right-click 'open in background tab', but also with Ctrl-click/Cmd-click which users have come to expect from normal links. This may be surprising but Ctrl-click/Cmd-click does not work with hx-get–it works only with regular and boosted links!

Boosted forms

The other thing that automatically 'just works' with boosting is HTML forms:

<form method=post action=/page1 hx-boost=true hx-target=#page>
  <input name=title>
  <input name=contents>
  <button type=submit>Save Page</button>
</form>

When this form is submitted, htmx will automatically do the submission asynchronously using XHR and swap in the response. However, it will not update the URL in the URL bar automatically, because that's not how normal form submits work. Again, like most things in htmx, you can also override this (with the hx-push-url attribute).

Just like before, the server can figure out whether to respond with a fragment or a full page based on the request headers sent by htmx. For fragment responses, you just respond with an appropriate status code like 200 or 201 and the HTML fragment. For full page responses you respond with a 302 redirect as usual for the HTML form post-redirect-get pattern.

Accessibility

As many have pointed out, certain patterns that are possible with htmx are not great for accessibility (and for that matter, SEO). Eg, look at this: <div hx-get=/page1>Get Page1</div>.

Or this: <a hx-get=/page1>Get Page1</a>.

These are using htmx to essentially perform the function of <a href=/page1>Get Page1</a>. But the <a href=...>...</a> hyperlink is kind of well defined in HTML and many technologies, eg assistive technologies like screen readers, expect them to be structured in a certain way. Crucially, the href attribute needs to be present to allow assistive tech (and SEO crawlers) to understand the link. When we reinvent these patterns, these tools don't work as well.

Or look at this: <a hx-post=/page1>Save Page</a>. Or even: <a hx-delete=/page1>Delete Page</a>. I hope you can agree with me that the venerable anchor tag should not be repurposed to post or delete resources!

On top of that, using buttons for data loads and navigations takes away the standard web affordance of opening links in background tabs, which can be a huge productivity drain.

If we stick with boosted links and forms, we are making a commitment to adhere to established standards of web usability and accessibility.

Application design

Boosted links also have a big impact on the structure of your application. When most of the links will be shown in the URL bar at some point, you start carefully considering the set of URLs exposed by the app and the views that should be rendered when the user navigates to them. It becomes very important that URLs consistently render the same views on every visit. Eg,

/payment-methods should render a list of payment methods.
/payment-methods/new should render an 'Add payment method' form on the page.
/payment-methods/$id should render the payment method with the given ID,
and so on.

The ability to copy and paste, and bookmark, and send URLs to refer to specific parts of your app is a superpower that should not be underestimated. It's the difference between being able to point your user directly at the entry form to add a payment method and having to ask them to click around in the app looking for buttons to press to find the correct page or dialog.

Of course, this is nothing new in web application design; but a shocking number of SPAs nowadays don't follow these basic principles.

The cult of hx-boost

I don't believe in being dogmatic about this approach. There can be great reasons to use the hx- + method attributes. Eg, I've found it useful to do something like <tr hx-get=/foo hx-target=#detail-view style=cursor:pointer> in tables where I want the user to be able to easily select a row in a table and load some details. If JavaScript or htmx are not working, we can just have a <td><a href=/foo>Foo</a></td> cell in each row to gracefully provide only a slightly less convenient version of the user experience.

A lot is possible in htmx, but a little goes a long way. Think about these tenets:

If you are requesting something, try using a boosted link (or a form with method=get for a more complex query)
If you are changing something, try using a boosted form

These simple building blocks can provide a solid, accessible foundation for your app.

Easy parsing with reasonable error messages in OCaml's Angstrom

Yawar Amin — Thu, 08 May 2025 22:00:40 +0000

PARSER combinators are widely used in the world of functional programming, and OCaml's Angstrom library is one of them. It is used to implement many foundational parsers in the OCaml ecosystem, eg HTTP parsers for the httpaf stack.

However, one of their bigger downsides is the lack of accurate parse error reporting. Let's take a look. Suppose you want to parse records of this format: 1 Bob ie an ID number followed by one or more spaces, followed by an alphabetic word (a name). Here's a basic Angstrom parser for this:

open Angstrom

type person = { id : int; name : string; }

let sp = skip_many1 (char ' ')
let word = take_while1 (function 'A' .. 'Z' | 'a'..'z' -> true | _ -> false)
let num = take_while1 (function '0'..'9' -> true | _ -> false)

let person =
  let+ id = num
  and+ _ = sp
  and+ name = word
  and+ _ = end_of_input in
  { id = int_of_string id; name }

Let's try out various bad inputs and check the errors:

# parse_string ~consume:Consume.All person "";;
- : (person, string) result = Error ": count_while1"

# parse_string ~consume:Consume.All person "1";;
- : (person, string) result = Error ": not enough input"

# parse_string ~consume:Consume.All person "1 ";;
- : (person, string) result = Error ": count_while1"

# parse_string ~consume:Consume.All person "1 1";;
- : (person, string) result = Error ": count_while1"

The error messages are not great, unfortunately! It's hard to tell what went wrong. Of course, in this case we know what caused each error because we are feeding small inputs to the parser. But it's easy to imagine that for larger inputs it may be difficult to understand why a parse is failing.

Fortunately, parser combinator libraries usually provide a 'label' function to improve the error messages slightly. In Angstrom, a label works like this: parser <?> "label string". But the default label functionality allows labelling with only a static string. Let's improve labelling even more! Using a little-known feature of Angstrom, we can take a snapshot of the remaining string left to parse and actually include it in the error message if parsing fails.

Here, we are just augmenting the built-in label operator with a more powerful, snapshotting version:

let ( <?> ) p l =
  let* remaining = available in
  let remaining = min remaining 20 in
  let* s = peek_string remaining in
  p <?> Printf.sprintf "%s, got: [%s]" l s

Now let's redefine our parsers to use this augmented labelling operator:

let sp = skip_many1 (char ' ') <?> "expected one or more spaces"
let word = take_while1 (function 'A' .. 'Z' | 'a'..'z' -> true | _ -> false) <?> "expected a word"
let num = take_while1 (function '0'..'9' -> true | _ -> false) <?> "expected a number"

let person =
  (let+ id = num <?> "expected a numeric ID"
   and+ _ = sp
   and+ name = word <?> "expected a name"
   and+ _ = end_of_input <?> "expected end of input" in
   { id = int_of_string id; name }) <?> "expected a person"

Let's try the same error scenarios:

# parse_string ~consume:Consume.All person "";;
- : (person, string) result =
Error
 "expected a person, got: [] > expected a numeric ID, got: [] > expected a number, got: []: count_while1"

# parse_string ~consume:Consume.All person "1";;
- : (person, string) result =
Error
 "expected a person, got: [1] > expected one or more spaces, got: []: not enough input"

# parse_string ~consume:Consume.All person "1 ";;
- : (person, string) result =
Error
 "expected a person, got: [1 ] > expected a name, got: [] > expected a word, got: []: count_while1"

# parse_string ~consume:Consume.All person "1 b1";;
- : (person, string) result =
Error
 "expected a person, got: [1 b1] > expected end of input, got: [1]: end_of_input"

The text in the brackets shows a snapshot of the string remaining to parse, which narrows down at each level to the exact string where the parse failed! With this snapshot of the remaining string, we can easily figure out where the parse failed.

Happy parsing!

You're thinking about passkeys wrong

Yawar Amin — Wed, 29 Jan 2025 02:37:19 +0000

PASSKEYS have been in the news recently and with good reason–the big tech companies are seriously ramping up efforts to move all their users to this newfangled tech.

But there's a fly in the ointment: certain influential tech people really dislike them. According to DHH:

if you sign up for a service on Windows, and you then want to access it on iPhone, you're going to be stuck (unless you're so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!)...A decent alternative to passkeys, if you need the extra layer of security, is to lean on email for the first login from a new device. Treating email as a second factor, but only on the first login from that device. Everyone has email, everyone understands email. (Just don't force us all to go through magic links exclusively, as that's a pain too for those who've actually adopted a password manager!).

DHH is very close to the ideal UX for passkeys for ordinary non-technical folks, but can't quite put it together. Here's what I recommend:

Initial user sign-up

Don't make the user set up a password!
Send a magic link to their email
Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.

Subsequent logins on the same device

Use Conditional UI to allow selecting the passkey directly from the Email input autocomplete. Browsers support this now!
If JavaScript disabled: instead of Conditional UI and passkey login, send a magic link

Subsequent logins on a new device

Send a magic link to the user's email address
Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.

Notice how this is almost exactly the same as the initial user sign up process? It's so simple and low-ceremony, it should hardly take the user out of their flow.

It doesn't need to be a whole song-and-dance about having to 'recover' the account on the new device! There's nothing to recover. The user can just log in with a magic link and set up a passkey so that the next login is even easier. That's all!

Obviously, for this UX to work, the app must support being able to store multiple passkeys per account. This is non-negotiable! Passkeys are cheap and easy to store. There's no reason to be overly restrictive here. Once this is supported, you never have to worry about password leaks again. And your users never have to worry about getting phished (in the sense of accidentally entering their credentials into third-party sites).

Prominent security experts agree - passkeys and magic links basically solve the password problem for regular users. We can effectively retire passwords now.

Powerful form validation with OCaml's Dream framework

Yawar Amin — Sun, 01 Dec 2024 17:24:21 +0000

I'VE been a long-time proponent of the power of HTML forms and how natural they make it to build web pages that allow users to input data. Recently, I got a chance to refurbish an old internal application we use at work using htmx and Scala's Play Framework. In this app we often use HTML forms to submit information. For example:

<form id=new-user-form method=post action=/users hx-post=/users>
  <input name=name required>
  <input type=email name=email required>
  <input type=checkbox name=accept-terms value=true>
  <button type=submit>Add User</button>
</form>

Play has great support for decoding submitted HTML form data into values of custom types and reporting all validation errors that may have occurred, which allowed me to render the errors directly alongside the forms themselves using the Constraint Validation API. I wrote about that in a previous post.

But in the OCaml world, the situation was not that advanced. We had some basic tools for parsing form data into a key-value pair list:

But if we wanted to decode this list into a custom type, we'd need something more sophisticated, like maybe conformist. ~~However, conformist has the issue that it reports only one error at a time.~~ Actually, conformist has a separate validate function that can report all errors together!

If we have to decode a form submission like:

accept-terms: true

We would want to see a list of validation errors, like this:

name: required
email: required

dream-html form validation

Long story short, I decided we needed a more ergonomic form validation experience in OCaml. And since I already maintain a package which adds type-safe helpers on top of the Dream web framework, I thought it would make a good addition. Let's take a it for a spin in the REPL:

$ utop -require dream-html
# type add_user = {
    name : string;
    email : string;
    accept_terms : bool;
  };;

# let add_user =
    let open Dream_html.Form in
    let+ name = required string "name"
    and+ email = required string "email"
    and+ accept_terms = optional bool "accept-terms" in
    {
      name;
      email;
      accept_terms = Option.value accept_terms ~default:false;
    };;

Now we have a value add_user : add_user Dream_html.Form.t, which is a decoder to our custom type. Let's try it:

# Dream_html.Form.validate add_user [];;
- : (add_user, (string * string) list) result =
Error [("email", "error.required"); ("name", "error.required")]

We get back a list of form validation errors, with field names and error message keys (this allows localizing the app).

Let's try a successful decode:

# Dream_html.Form.validate add_user ["name", "Bob"; "email", "bob@example.com"];;
- : (add_user, (string * string) list) result =
Ok {name = "Bob"; email = "bob@example.com"; accept_terms = false}

# Dream_html.Form.validate add_user ["name", "Bob"; "email", "bob@example.com"; "accept-terms", "true"];;
- : (add_user, (string * string) list) result =
Ok {name = "Bob"; email = "bob@example.com"; accept_terms = true}

Let's check for a type error:

# Dream_html.Form.validate add_user ["name", "Bob"; "email", "bob@example.com"; "accept-terms", "1"];;
- : (add_user, (string * string) list) result =
Error [("accept-terms", "error.expected.bool")]

It wants a bool, ie only true or false values. You can make sure your checkboxes always send true on submission by setting value=true.

Custom value decoders

You can decode custom data too. Eg suppose your form has inputs that are supposed to be decimal numbers:

<input name=height-m required>

You can write a custom data decoder that can parse a decimal number:

# #require "decimal";;
# let decimal s =
    try Ok (Decimal.of_string s)
    with Invalid_argument _ -> Error "error.expected.decimal";;

Now we can use it:

let+ height_m = required decimal "height-m"
...

Adding constraints to the values

You can add further constraints to values that you decode. Eg, in most form submissions it doesn't make sense for any strings to be empty. So let's define a helper that constrains strings to be non-empty:

let nonempty =
  ensure "expected.nonempty" (( <> ) "") required string

Now we can write the earlier form definition with stronger constraints for the strings:

let add_user =
  let open Dream_html.Form in
  let+ name = nonempty "name"
  and+ email = nonempty "email"
  and+ accept_terms = optional bool "accept-terms" in
  {
    name;
    email;
    accept_terms = Option.value accept_terms ~default:false;
  }

Validating forms in Dream handlers

In a Dream application, the built-in form handling would look something like this:

(* POST /users *)
let post_users request =
  match%lwt Dream.form request with
  | `Ok ["accept-terms", accept_terms; "email", email; "name", name] ->
    (* ...success... *)
  | _ -> Dream.empty `Bad_Request

But with our form validation abilities, we can do something more:

(* POST /users *)
let post_users request =
  match%lwt Dream_html.form add_user request with
  | `Ok { name; email; accept_terms } ->
    (* ...success... *)
  | `Invalid errors ->
    Dream.json ~code:422 ( (* ...turn the error list into a JSON object... *) )
  | _ -> Dream.empty `Bad_Request

Decoding variant type values

Of course, variant types are a big part of programming in OCaml, so you might want to decode a form submission into a value of a variant type. Eg,

type user =
| Logged_out
| Logged_in of { admin : bool }

You could have a form submission that looked like this:

type: logged-out

Or:

type: logged-in
admin: true

Etc.

To decode this kind of submission, you can break it down into decoders for each case, then join them together with Dream_html.Form.( or ), eg:

let logged_out =
  let+ _ = ensure "expected.type" (( = ) "logged-out") required string "type" in
  Logged_out

let logged_in =
  let+ _ = ensure "expected.type" (( = ) "logged-in") required string "type"
  and+ admin = required bool "admin" in
  Logged_in { admin }

let user = logged_out or logged_in

Let's try it:

# validate user [];;
- : (user, (string * string) list) result =
Error [("admin", "error.required"); ("type", "error.required")]

# validate user ["type", "logged-out"];;
- : (user, (string * string) list) result = Ok Logged_out

# validate user ["type", "logged-in"];;
- : (user, (string * string) list) result = Error [("admin", "error.required")]

# validate user ["type", "logged-in"; "admin", ""];;
- : (user, (string * string) list) result =
Error [("admin", "error.expected.bool")]

# validate user ["type", "logged-in"; "admin", "true"];;
- : (user, (string * string) list) result = Ok (Logged_in { admin = true })

As you can see, the decoder can handle either case and all the requirements therein.

Decoding queries into custom types

The decoding functionality works not just with 'forms' but also with queries eg /foo?a=1&b=2. Of course, here we are using 'forms' as a shorthand for the application/x-www-form-urlencoded data that is submitted with a POST request, but actually an HTML form that has action=get submits its input data as a query, part of the URL, not as form data. A little confusing, but the key thing to remember is that Dream can work with both, and so can dream-html.

In Dream, you can get query data using functions like let a = Dream.query request "a". But if you are submitting more sophisticated data via the query, you can decode them into a custom type using the above form decoding functionality. Eg suppose you want to decode UTM parameters into a custom type:

type utm = {
  source : string option;
  medium : string option;
  campaign : string option;
  term : string option;
  content : string option;
}

let utm =
  let+ source = optional string "utm_source"
  and+ medium = optional string "utm_medium"
  and+ campaign = optional string "utm_campaign"
  and+ term = optional string "utm_term"
  and+ content = optional string "utm_content" in
  { source; medium; campaign; term; content }

Now, you can use this very similarly to a POST form submission:

let some_page request =
  match Dream_html.query utm request with
  | `Ok { source; medium; campaign; term; content } ->
    (* ...success... *)
  | `Invalid errors -> (* ...handle errors... *)

And the cool thing is, since they are literally the same form definition, you can switch back and forth between making your request handle POST form data or GET query parameters, with very few changes.

So...

Whew. That was a lot. And I didn't really dig into the even more advanced use cases. But hopefully at this point you might be convinced that forms and queries are now easy to handle in Dream. Of course, you might not really need all this power. For simple use cases, you can probably get away with Dream's built-in capabilities. But for larger apps that maybe need to handle a lot of forms, I think it can be useful.

Handling form errors in htmx

Yawar Amin — Fri, 11 Oct 2024 05:41:59 +0000

FROM time to time I hear a criticism of htmx that it's not good at handling errors. I'll show an example of why I don't think that's the case. One of the common operations with htmx is submitting an HTML form (of the type application/x-www-form-urlencoded) to your backend server and getting a response. The happy path of course is when the response is a success and htmx does the HTML fragment swap. But let's look at the sad path.

Form validation messaging

A common UX need is to show an error message next to each field that failed to validate. Look at this example from the Bulma CSS framework documentation: https://bulma.io/documentation/form/general/#complete-form-example

That does look nice...but it also requires custom markup and layout for potentially every field. What if we take advantage of modern browser support for the HTML Constraint Validation API? This allows us to attach an error message to each field with its own pop-up that lives outside the document's markup. You can see an example here: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/reportValidity#results

What if we had a message like this pop up for every field that failed validation? This is the question of this post.

Example form

Suppose you have an endpoint POST /users which handles a form with the payload fullname=Foo&email=bar@baz.com. You get the data in the backend, decode it, and if successful you are on the happy path as mentioned earlier. But if the form decode fails, we come to the interesting bit.

Here's the key point: if the form decode fails, you need some way to let htmx know about this specific error as opposed to some other error that could have happened. We need to make a decision here. Let's say we use the 422 Unprocessable Content status code for a form which fails validation.

Now, we need to decide how exactly to format the validation error message. The Constraint Validation API mentioned earlier is a JavaScript API, so that pretty much makes the decision for us. We will format the errors as JSON.

Here's an example form:

<form
  id=add-user-form
  method=post
  action=/users
  hx-post=/users
>
  <input name=fullname>
  <input name=email type=email>
  <input type=submit value="Add User">
</form>

Of course, in a real app both these inputs would have the required attribute; here I am just leaving them out for demonstration purposes.

If we submit this form with the fullname and email fields left empty, then the backend should fail to validate the form and respond with the following:

HTTP 422
Content-Type: application/json

{
  "fullname": "Please fill out this field",
  "email": "Please fill out this field"
}

How do we make this happen? Our form validation function should tell us the names of the fields that failed to validate and the error message for each. We just convert this mapping into a JSON object.

The error handler

With this response from the backend, we need some JavaScript to traverse the JSON and attach the error messages to each corresponding form field.

document.addEventListener('htmx:responseError', evt => {
  const xhr = evt.detail.xhr;

  if (xhr.status == 422) {
    const form = evt.detail.elt;
    const errors = JSON.parse(xhr.responseText);

    for (const name of Object.keys(errors)) {
      const field = form.querySelector(`[name="${name}"]`);

      field.setCustomValidity(errors[name]);
      field.onfocus = () => field.reportValidity();
      field.onchange = () => field.setCustomValidity('');
      field.reportValidity();
    }
  } else {
    // Handle the error some other way
    console.error(xhr.responseText);
  }
});

We are doing three key things here:

For each form field that failed validation, attach the error message to it
Attach an event listener to pop up the error message when the field gets focus
Attach an event listener to clear out the error message when the field's value is changed

The fourth action above, while not critical, is a nice to have: we just tell one of the fields to make it pop up its error message. This shows the user that something went wrong with the form submission. Of course, you can give even bigger hints, like highlighting inputs in an invalid state with CSS by targeting the input:invalid pseudo-selector.

Now, any time the form is submitted and there is a validation error, the response will automatically populate the error messages to the right places.

Note: we are using the field.onevent = ... properties for setting the event handlers so that we don't end up with duplicate event listeners added to each field.

Not htmx?

If you have been paying close attention, you may be thinking that this technique seems to be not limited to htmx–and you're right! This technique based on the Constraint Validation API can be used with any frontend which uses forms. It doesn't need to be used specifically with htmx. You just need to adapt it to handle a form validation error from the backend server.

By taking advantage of a built-in feature of modern browsers, we make the code more adaptable and benefit from future improvements that browsers make to their UIs.

A type theory mnemonic for boolean operator precedence

Yawar Amin — Mon, 16 Sep 2024 01:11:25 +0000

IN COMPUTER languages which support boolean operators like && (and) and || (or), && typically has higher precedence than ||. In other words, the following happens:

p && q || r == (p && q) || r
p || q && r == p || (q && r)

You can take advantage of this to construct simpler expressions which don't need so many parentheses. Eg, let's look at Cloudflare's expression language:

http.host eq "app.foo.com" and http.request.uri.path eq "/api" or http.host eq "api.foo.com" and http.request.uri.path eq "/app"

The above is equivalent to:

(http.host eq "app.foo.com" and http.request.uri.path eq "/api") or (http.host eq "api.foo.com" and http.request.uri.path eq "/app")

Let's leave aside for a moment the argument that you should use parentheses for explicit grouping and readability; readability is a very subjective question. The bigger problem might be that, unless you regularly design or use such logical expressions, it might be difficult to remember this operator precedence.

Math operator precedence

However, one precedence rule that most people remember pretty easily is that of math operators like + and * (yes, I'm using the programming language symbol * instead of the math symbol ✖️). We of course know, probably since childhood, that multiplication has higher precedence than addition. So,

a * b + c == (a * b) + c
a + b * c == a + (b * c)

Look familiar? These are the same precedence rules as for the logical operators shown above, where:

&& is equivalent to *
|| is equivalent to +

The type theory connection

Of course, type theory enthusiasts know pretty well that the symbols + and * are used to represent sum types and product types. The name is no coincidence: a sum type like a + b has the same number of values as the sum of the numbers of values of a and b. And a product type like a * b has the same number of values as the product of the numbers of values of a and b.

Try working through an example where type a = bool (2 possible values) and type b = unit (1 possible value). How many values does the type a + b have, and how many does a * b have?

In type theory, sum types represent alternatives, so a + b means 'a value that can be a or b', while a * b means 'a value that contains a and b' (commonly known as a tuple or pair). So in the type theory world,

* == &&
+ == ||

And very conveniently, they have the same precedence rules! So, if you are ever trying to remember the precedence, just remind yourself that 'and is times, or is plus'.

Constructing XML output with dream-html

Yawar Amin — Sun, 14 Jul 2024 21:53:00 +0000

FOR some time now, I have been maintaining an OCaml library called dream-html. This library is primarily intended to render correctly-constructed HTML, SVG, and MathML. Recently, I added the ability to render well-formed XML markup, which has slightly different rules than HTML. For example, in HTML if you want to write an empty div tag, you do: <div></div>. But according to the rules of XML, you could also write <div/> ie a self-closing tag, however HTML 5 does not have the concept of self-closing tags!

So by having the library take care of these subtle but crucial details, you can just concentrate on writing code that generates the markup. Of course, this has many other advantages too, but in this post I will just look at XML.

It turns out that often we need to serialize some data into XML format, for storage or communication purposes. There are a few packages in the OCaml ecosystem which handle XML, however I think dream-html actually does it surprisingly well now. Let's take a look.

But first, a small clarification about the dream-html package itself. Recently I split it up into two packages:

pure-html has all the functionality needed to write valid HTML and XML
dream-html has all of the above, plus some integration with the Dream web framework for ease of use.

As you might imagine, the reason for the split was to allow using the HTML/XML functionality of the package without having to pull in the entire Dream dependency cone, which is quite large, especially if you happen to be using a different dependency cone as well. So pure-html depends only on the uri package to help construct correct URI strings.

To start using it, just install: opam install pure-html

And add to your dune file: (libraries pure-html)

Now, let's look at an example of how you can use it to construct XML. Suppose you have the following type:

type person = {
  name : string;
  email : string;
}

And you need to serialize it to XML like this:

<person name="Bob" email="bob@info.com"/>

Let's write a serializer using the pure-html package:

open Pure_html

let person_xml =
  let person = std_tag "person"
  and name = string_attr "name"
  and email = string_attr "email" in
  fun { name = n; email = e } -> person [name "%s" n; email "%s" e] []

Let's test it out:

$ utop -require pure-html
# open Pure_html;;
# let pp = pp_xml ~header:true;;
val pp : Format.formatter -> node -> unit = <fun>
# #install_printer pp;;
# type person = {
  name : string;
  email : string;
};;
type person = { name : string; email : string; }
# let person_xml =
  let person = std_tag "person"
  and name = string_attr "name"
  and email = string_attr "email" in
  fun { name = n; email = e } -> person [name "%s" n; email "%s" e] [];;
val person_xml : person -> node = <fun>
# person_xml { name = "Bob"; email = "bob@example.com" };;
- : node =
<?xml version="1.0" encoding="UTF-8"?>
<person
name="Bob"
email="bob@example.com" />

OK cool, so our person record is serialized in this specific way. But, what if we need to serialize it like:

<person>
  <name>Bob</name>
  <email>bob@example.com</email>
</person>

After all, this is a common way of formatting records in XML. Let's write the serializer in this style:

let person_xml =
  let person = std_tag "person"
  and name = std_tag "name"
  and email = std_tag "email" in
  fun { name = n; email = e } ->
    person [] [
      name [] [txt "%s" n];
      email [] [txt "%s" e];
    ]

Let's try it out:

# let person_xml =
  let person = std_tag "person"
  and name = std_tag "name"
  and email = std_tag "email" in
  fun { name = n; email = e } ->
    person [] [
      name [] [txt "%s" n];
      email [] [txt "%s" e];
    ];;
val person_xml : person -> node = <fun>
# person_xml { name = "Bob"; email = "bob@example.com" };;
- : node =
<?xml version="1.0" encoding="UTF-8"?>
<person><name>Bob</name><email>bob@example.com</email></person>

Looks good! Let's examine the functions from the pure-html package used here to achieve this.

`std_tag`

This function lets us define a custom tag: let person = std_tag "person". Note that it's trivial to add a namespace: let person = std_tag "my:person".

`string_attr`

This allows us to define a custom attribute which takes a string payload: let name = string_attr "name". Again, easy to add a namespace: let name = string_attr "my:name".

There are other attribute definition functions which allow int payloads and so on. See the package documentation for details.

`pp_xml`

This allows us to define a printer which renders XML correctly according to its syntactic rules:

let pp = pp_xml ~header:true

The optional header argument lets us specify whether we want to always print the XML header or not. In many serialization cases, we do.

There's also a similar function which, instead of defining a printer, just converts the constructed node into a string directly: to_xml.

Conclusion

With these basic functions, it's possible to precisely control how the serialized XML looks. Note that dream-html and pure-html support only serialization of data into XML format, and not deserialization ie parsing XML. For that, there are other packages!

Bare-bones unit testing in OCaml with dune

Yawar Amin — Mon, 01 Jul 2024 01:30:17 +0000

THERE are various techniques and tools to do unit testing in OCaml. A small selection:

Alcotest - a colourful unit testing framework
OUnit2 - an xUnit-style test framework
ppx_expect - a snapshot testing framework
Speed, a new framework announced right here on dev.to, with an emphasis on a fast feedback loop.

While these have various benefits, it is undeniable that they all involve using a third-party library to write the tests, learning the various assertion functions and their helpers, and learning how to read and deal with test failure outputs. I have lately been wondering if we can simplify and distill this process to its very essence.

When you run a unit test, you have some expected output, some 'actual' output from the system under test, and then you compare the two. If they are the same, then the test passes, if they are different, the test fails. Ideally, you get the test failure report as an easily readable diff so you can see exactly what went wrong. Of course, this is a simplified view of unit testing–there are tests that require more sophisticated checks–but for many cases, this simple approach is often 'good enough'.

Enter dune

And here is where dune, OCaml's build system, comes in. It turns out that dune ships out of the box with a 'diff-and-promote' workflow. You can tell it to diff two files, running silently if they have the same content, or failing and printing out a diff if they don't. Then you can run a simple dune promote command to update the 'expected' or 'snapshot' file with the 'actual' content.

Let's look at an example.

Example project

Let's set up a tiny example project to test out this workflow. Here are the files:

dune-project

(lang dune 3.0)

This file is needed for dune to recognize a project. You can use any supported version of dune here, I just default to 3.0.

lib/dune

(library
 (name lib))

This declares a dune library inside the project.

lib/lib.ml

let add x y = x + y
let sub x y = x - y

This is the implementation source code of the library. Here we are just setting up two dummy functions that we will 'test' for demonstration purposes. Of course in real-world code there will be more complex functions.

test/test.expected

(This file is initally left empty–will be filled later.)

test/test.ml

let test msg op x y = Printf.printf "%s: %d\n\n" msg (op x y)

open Lib

let () =
  test "add 1 1" add 1 1;
  test "sub 1 1" sub 1 1

This file defines a test helper function whose only job is to just print out a message and then the result of the test, together, to standard output. Then we use the helper repeatedly to test various scenarios. This has the effect that we just print out a bunch of things to standard output.

test/dune

(test
 (name test)
 (libraries lib))

That's all you need! Dune runs the test mostly on a 'convention-over-configuration' basis.

The test component has name test, meaning that dune will build it into an executable test.exe.
The test executable will print some output to standard output, which dune will automatically capture in a file test.exe.output.
Then dune will diff this output against the expected output in test.expected.

The file test.expected is meant to be committed into the codebase. It is initially empty, and we will update it as part of our testing workflow.

Notice that dune automatically understands these inputs and outputs and their relation to each other, and will rebuild the test whenever necessary.

First test

Now let's run the initial test:

$ dune test
File "test/test.expected", line 1, characters 0-0:
diff --git a/_build/default/test/test.expected b/_build/default/test/test.exe.output
index e69de29..1522c5b 100644
--- a/_build/default/test/test.expected
+++ b/_build/default/test/test.exe.output
@@ -0,0 +1,4 @@
+add 1 1: 2
+
+sub 1 1: 0
+

Promotion

The diff says that the actual output content is not what we 'expected'. Of course, we deliberately started with an empty file here, so let's update the 'expected file' to match the 'actual' one:

$ dune promote
Promoting _build/default/test/test.exe.output to test/test.expected.

Rerun test

After the promotion, let's check that the test passes:

$ dune test
$

No output, meaning the test succeeded.

Add tests

Let's add a new test:

let () =
  test "add 1 1" add 1 1;
  test "sub 1 1" sub 1 1;
  test "sub 1 -1" sub 1 ~-1

And run it:

$ dune test
File "test/test.expected", line 1, characters 0-0:
diff --git a/_build/default/test/test.expected b/_build/default/test/test.exe.output
index 1522c5b..17ccf8e 100644
--- a/_build/default/test/test.expected
+++ b/_build/default/test/test.exe.output
@@ -2,3 +2,5 @@ add 1 1: 2

 sub 1 1: 0

+sub 1 -1: 2
+

OK, we just need to promote it: dune promote. Then the next dune test succeeds.

Fix a bug

Let's say we introduce a bug into our implementation:

let sub x y = x + y

Now let's run the tests:

$ dune test
File "test/test.expected", line 1, characters 0-0:
diff --git a/_build/default/test/test.expected b/_build/default/test/test.exe.output
index 17ccf8e..29adb0b 100644
--- a/_build/default/test/test.expected
+++ b/_build/default/test/test.exe.output
@@ -1,6 +1,6 @@
 add 1 1: 2

-sub 1 1: 0
+sub 1 1: 2

-sub 1 -1: 2
+sub 1 -1: 0

It gives us a diff of exactly the failing tests. Obviously, in this case we are not going to run dune promote. We need to fix the implementation: let sub x y = x - y, then rerun the test. And we see that after fixing and rerunning, dune test exits silently, meaning the tests are passing again.

Discussion

So...should you actually do this? Let's look at the pros and cons.

Pros

No need for a third-party testing library. Dune already does the heavy lifting of running tests and diffing outputs.
No need to learn a set of testing APIs that someone else created. You can just write your own helpers that are custom-made for testing your libraries. All you need to do is make the output understandable and diffable.
Diff-and-promote workflow is really quite good, even with a bare-bones setup like this. Conventional unit test frameworks really struggle to provide diff output as good as this (Jane Street's ppx_expect is an exception which takes a hybrid approach and wants to make the workflow a joyful experience).
You have all expected test results in a single file for easy inspection.

Cons

It's tied to dune. While dune is today and for the foreseeable future clearly the recommended build system for OCaml, not everyone is using it, and there's no guarantee that the ecosystem will stick to it in perpetuity. It's just highly likely.
You have to define your own output format and helpers. While usually not that big of a deal, it may still need some thought and knowledge to define printers for complex custom types.
You can't run only a subset or a single test. You have to run all tests defined in the executable test module. This is not a huge deal if tests usually run fast, but can become problematic when you have slow tests. Of course, many things become problematic when you have slow unit tests.
It doesn't output results in a structured format that can be processed by other tools, eg junit.xml that can be used by CI pipelines to report test failures, or test coverage.
It goes against the 'common wisdom'. People expect unit tests to use conventional-style frameworks, and can be taken aback when they don't.

Overall, in my opinion this approach is fine for simple cases. If you have more complex needs, fortunately there are plenty of options for more powerful test frameworks.

Why I don't use a third-party assertion library in Go unit tests

Yawar Amin — Mon, 20 May 2024 18:54:02 +0000

TL;DR: I don't need it, and you probably don't either. I'll explain below.

As we know of course, Go ships with a built-in unit testing framework in its standard library and toolchain, as explained in the testing package documentation. Assuming you have some code to test:

package add

func Add(x, y int) int {
    return x + y
}

The documentation shows a test like:

package add

import "testing"

func TestAdd(t *testing.T) {
    got := Add(1, 2)

    if got != 4 {
        t.Errorf("Add(1, 2) = %d; want 4", got)
    }
}

And if the test fails you get an error like: Add(1, 2) = 3; want 4.

Of course, as soon as people saw this, the third-party assertion helper libraries started appearing. The most popular one seems to be testify (although I've never used it). Personally, I thought that the explicit check would be good enough for me, but it's true that after writing a bunch of tests, the boilerplate does seem unnecessarily verbose.

But do we really need a third-party library to abstract it? Pre-Go generics, I might have said yes. But post-generics, I think it's pretty simple to write a helper function directly:

package assert

import "testing"

func Equal[V comparable](t *testing.T, got, expected V) {
    t.Helper()

    if expected != got {
        t.Errorf(`assert.Equal(
t,
got:
%v
,
expected:
%v
)`, got, expected)
    }
}

As you can see, generics are the key here, especially the fact that we specify that types must be comparable. Before generics, we would have had to use things like reflection, or even just not use a helper function at all. To my eyes, many pre-generics Go code patterns seem to be about avoiding things that would have required generics to express safely. Eg, we were using a generic comparison operator got != 4 directly instead of encapsulating the comparison in a function call that would have needed generics.

So, how does this look like in practice? Here's the above test case rewritten to use the helper:

func TestAdd(t *testing.T) {
    assert.Equal(t, Add(1, 2), 4)
}

Much nicer, I think, even though we lose the ability to format a custom error message. Speaking of error message, let's look at that:

$ go test gt/add
--- FAIL: TestAdd (0.00s)
    add_test.go:9: assert.Equal(
        t,
        got:
        3
        ,
        expected:
        4
        )
FAIL
FAIL    gt/add  0.119s
FAIL

Sure, we don't have a custom error message that tells us what operation was performed here, but we do have the exact line number in the test so we can just see for ourselves. And also, VSCode and I assume other good editors can show test results inline:

With a good editor showing inline results, it's pretty obvious what the code under test did and what result it expected.

API design considerations

Deciding on the right API and the right output is a little tricky, but it's worth taking the time to do it right. The function signature is important:

func Equal[V comparable](t *testing.T, got, expected V)

Notice that we pass in the actual ie 'got' value first, and the expected value second. The reason for this interconnects with my testing philosophy: one test function should try (as hard as possible) to assert one thing. Often, we need to test more complex data. In these cases, I believe the best approach is to snapshot the data as a string and assert on the string. Eg:

assert.Equal(
    t,
    dataframe1.Join(dataframe2).String(),
    `---------
| a | b |
---------
| 1 | 2 |`,
)

This allows us to elegantly capture the entire 'behaviour' of the code under test, and update it quickly in the future if needed. If one day the dataframe result changes, the test failure output will show the new value and we can update it with a simple copy-paste. Think of it as a proto-snapshot testing style. Maybe in the future editor support tools will even be able to offer a one-click way to update the expected value.

Finally, note the layout of the failure message: assert.Equal(t, got: x, expected: y). This is deliberately chosen to teach the user how to call this helper even if they don't start by reading its documentation. By just looking at the error, they learn that the 'actual' value is the second argument, and the expected value is the third. This is informative while also being fairly succinct.

Conclusion

As we see here, it doesn't take many lines of code to write a very useful test assertion helper directly on top of the standard library, thanks to Go generics. In my opinion this covers 99% of Go unit testing needs. The remaining 1% is left as an exercise for the reader!

Format strings in OCaml

Yawar Amin — Sun, 25 Feb 2024 02:34:10 +0000

OCAML doesn't have string interpolation, but it does have C-style format strings (but type-safe). Here's an example:

let hello name = Printf.printf "Hello, %s!\n" name
(* Can be written as: let hello = Printf.printf "Hello, %s!" *)

This is type-safe in an almost magical way (example REPL session):

# hello 1;;
Error: This expression has type int but an expression was expected of type
         string

It can however be a little tricky to wrap your head around:

# let bob = "Bob";;
val bob : string = "Bob"

# Printf.printf bob;;
Error: This expression has type string but an expression was expected of type
         ('a, out_channel, unit) format =
           ('a, out_channel, unit, unit, unit, unit) format6

This error is saying that the printf function wants a 'format string', which is distinct from a regular string:

# let bob = format_of_string "bob";;
val bob : ('_weak1, '_weak2, '_weak3, '_weak4, '_weak4, '_weak1) format6 =
  CamlinternalFormatBasics.Format
   (CamlinternalFormatBasics.String_literal ("bob",
     CamlinternalFormatBasics.End_of_format),
   "bob")

# Printf.printf bob;;
bob- : unit = ()

OCaml distinguishes between regular strings and format strings. The latter are complex structures which encode type information inside them. They are parsed and turned into these structures either when the compiler sees a string literal and'realizes' that a format string is expected, or when you (the programmer) explicitly asks for the conversion. Another example:

# let fmt = "Hello, %s!\n" ^^ "";;
val fmt :
  (string -> '_weak5, '_weak6, '_weak7, '_weak8, '_weak8, '_weak5) format6 =
  CamlinternalFormatBasics.Format
   (CamlinternalFormatBasics.String_literal ("Hello, ",
     CamlinternalFormatBasics.String (CamlinternalFormatBasics.No_padding,
      CamlinternalFormatBasics.String_literal ("!\n",
       CamlinternalFormatBasics.End_of_format))),
   "Hello, %s!\n%,")

# Printf.printf fmt "Bob";;
Hello, Bob!
- : unit = ()

The ^^ operator is the format string concatenation operator. Think of it as a more powerful version of the string concatenation operator, ^. It can concatenate either format strings that have already been bound to a name, or string literals which it interprets as format strings:

# bob ^^ bob;;
- : (unit, out_channel, unit, unit, unit, unit) format6 =
CamlinternalFormatBasics.Format
 (CamlinternalFormatBasics.String_literal ("bob",
   CamlinternalFormatBasics.String_literal ("bob",
    CamlinternalFormatBasics.End_of_format)),
 "bob%,bob")

# bob ^^ "!";;
- : (unit, out_channel, unit, unit, unit, unit) format6 =
CamlinternalFormatBasics.Format
 (CamlinternalFormatBasics.String_literal ("bob",
   CamlinternalFormatBasics.Char_literal ('!',
    CamlinternalFormatBasics.End_of_format)),
 "bob%,!")

Custom formatting functions

The really amazing thing about format strings is that you can define your own functions which use them to output formatted text. For example:

# let shout fmt = Printf.ksprintf (fun s -> s ^ "!") fmt;;
val shout : ('a, unit, string, string) format4 -> 'a = <fun>

# shout "hello";;
- : string = "hello!"

# let jim = "Jim";;
val jim : string = "Jim"

# shout "Hello, %s" jim;;
- : string = "Hello, Jim!"

This is really just a simple example; you actually are not restricted to outputting only strings from ksprintf. You can output any data structure you like. Think of ksprintf as '(k)ontinuation-based sprintf'; in other words, it takes a format string (fmt), any arguments needed by the format string (eg jim), builds the output string, then passes it to the continuation that you provide (fun s -> ...), in which you can build any value you want. This value will be the final output value of the function call.

Again, this is just as type-safe as the basic printf function:

# shout "Hello, jim" jim;;
Error: This expression has type
         ('a -> 'b, unit, string, string, string, 'a -> 'b)
         CamlinternalFormatBasics.fmt
       but an expression was expected of type
         ('a -> 'b, unit, string, string, string, string)
         CamlinternalFormatBasics.fmt
       Type 'a -> 'b is not compatible with type string

This error message looks a bit scary, but the real clue here is in the last line: an extra string argument was passed in, but it was expecting 'a -> 'b. Unfortunately the type error here is not that great because of how powerful and general this function is. Because it could potentially accept any number of arguments depending on the format string, its type is expressed in a very general way. This is a drawback of format strings to watch out for. But once you are familiar with it, it's typically not a big problem. You just need to match up the conversion specifications like % with the actual arguments passed in after the format string.

You might have noticed that the function is defined with let shout fmt = .... It doesn't look like it could accept 'any number of arguments'. The trick here is that in OCaml, every function accepts only a single argument and returns either a final non-function value, or a new function. In the case of functions which use format strings, it depends on the conversion specifications, so the formal definition shout fmt could potentially turn into a call like shout "%s bought %d apples today" bob num_apples. As a shortcut, you can think of the format string fmt as a variadic argument which can potentially turn into any number of arguments at the callsite.

Bookmarklets, and why you should use them

Yawar Amin — Tue, 02 Jan 2024 17:48:51 +0000

MOST of us have been using web browsers for a long time, yet relatively few of us know this somewhat obscure feature: browsers understand URLs that begin with javascript: instead of http: or https: protocols, and can actually execute the JavaScript code in the URL when you request it. Sounds like a security nightmare? Potentially, yes. You should be careful about what URLs you click on.

However! Harnessed in the right way, these javascript: URLs can be incredibly useful–enter bookmarklets.

What are they

Bookmarklets are just regular browser bookmarks except that they have a javascript: URL:

Name: (whatever name you want)

URL: javascript:/* code */

For example, javascript:alert('hi!').

OK, so an alert pop-up is not that useful. But bookmarklets can do anything that JavaScript running on the page can. Even better, they allow you to replace some browser extensions that have similar functionality. For power users, instead of the memory overhead of a loaded browser extension, you replace it with a zero-cost bookmarklet.

Let me show you two very simple and useful bookmarklets and explain how they work.

Allow paste

URL: javascript:document.addEventListener('paste', e => e.stopImmediatePropagation(), true)

When you click on this, it will 'trap' all paste events from further handling by JavaScript code, but allow the actual paste to go ahead. Why would you need this? Well, some annoying websites like to disable paste functionality by setting their own paste event handlers on certain text inputs. They think that eg if you can't paste a password, you will be forced to type it in, which for some reason will make it more secure.

Of course, that's nonsense. But that's the kind of reasoning these sites have (I guess). So we circumvent these geniuses by taking control of our own paste events.

This allows you to get rid of: Don't F*** With Paste

Scroll top/bottom

URL: javascript:window.scrollTo(0, window.scrollY == 0 ? document.body.scrollHeight : 0)

When clicked, this will:

If at the top of the page, scroll to the bottom
Else, scroll to the top

Simple, yet effective.

This allows you to get rid of: Scroll To Top

And more

These are just two simple use cases. As you can imagine, anything you can do with JavaScript on a web page, you can do with bookmarklets. Even making HTTP requests with the Fetch API! You're limited only by your imagination.

I have a collection of bookmarklets if you are interested in more. Have fun 🙂

DEV Community: Yawar Amin

Open source is about vendor lock-in

Vendor lock-in

OSS as anti-monopoly

Why hx-boost is actually the most important feature of htmx

hx-boost–the starting point

Boosting only

Boosted links

Boosted forms

Accessibility

Application design

The cult of hx-boost

Easy parsing with reasonable error messages in OCaml's Angstrom

You're thinking about passkeys wrong

Initial user sign-up

Subsequent logins on the same device

Subsequent logins on a new device

Powerful form validation with OCaml's Dream framework

dream-html form validation

Custom value decoders

Adding constraints to the values

Validating forms in Dream handlers

Decoding variant type values

Decoding queries into custom types

So...

Handling form errors in htmx

Form validation messaging

Example form

The error handler

Not htmx?

A type theory mnemonic for boolean operator precedence

Math operator precedence

The type theory connection

Constructing XML output with dream-html

std_tag

string_attr

pp_xml

Conclusion

Bare-bones unit testing in OCaml with dune

Enter dune

Example project

dune-project

lib/dune

lib/lib.ml

test/test.expected

test/test.ml

test/dune

First test

Promotion

Rerun test

Add tests

Fix a bug

Discussion

Pros

Cons

Why I don't use a third-party assertion library in Go unit tests

API design considerations

Conclusion

Format strings in OCaml

Custom formatting functions

More reading

Bookmarklets, and why you should use them

What are they

Allow paste

Scroll top/bottom

And more

`hx-boost`–the starting point

`std_tag`

`string_attr`

`pp_xml`