weirdest part is, the initial load looks fine (try refreshing, scroll persists).

firefox's reader view helps too

Looks decent on iPhone safari FWIW.

turn off 1password

What a good transactional API is like is an interesting question.

   public void modify(K key, Function<Optional<V>,Optional<V>> modifier)

or something along those lines covers the race of a single value being changed out from under you, but if you want to update one or more keys you might want

   public void modifyMany(Set<K> key, Consumer<Map<K,V>> modifier)

where the modifier gets passed a modifiable view that has just the keys in the set.

There is also the Clojure-style immutable API for maps though I can say I never really enjoyed working with that the way I enjoyed immutable lists (which are Lispier than Lisp: I went through all the stages of grief reading On Lisp and couldn't help think "If he was using Clojure he wouldn't be struggling with nconc)

  lookup :: k -> Map K v -> STM (Maybe v)

  insert :: v -> k -> Map K v -> STM ()

There's a design in the .NET ConcurrentDictionary that is even more inviting:

  GetOrAdd(TKey, Func<Tkey,TValue> )

This lets you specify a key, and a method to run to generate a value to store if the key does not exist.

This is thread-safe, however it is not atomic much to the surprise of many that use it.

If you wrongly assume that the factory method can only execute once, you fall into a trap, since it actually can execute many times before the result is stored.

This can cause a problem if you use it for caching, because you might for example put an expensive calculation you want to cache there, only to find out cache expiration causes a stampede as the factory suddenly executes a lot at once.

I don't see the problem at all, tbh. Both `get(K); put(K);` and `put(K); get(K);` are valid execution traces on a uniprocessor.