Hi, I’m Javan. I make resilient web applications.

You can reach me by email, find me on Twitter, and explore my open-source work on GitHub.

I’m currently looking for a new role. Get in touch!

Previously I worked at Basecamp where I led the Research & Fidelity team and spent a decade designing, implementing, documenting, and maintaining front-and-back-end systems for multiple high-traffic applications.

At Basecamp I co-authored several successful open-source JavaScript libraries including Hotwire (Stimulus + Turbo) and Trix, and helped build new Ruby on Rails frameworks like Action Cable and Action Text.

I’m a member of the Rails committer team, an active contributor, and a seasoned veteran with 15 years of professional experience.

Timeline

58 things I’ve done on the internet since 2013.

  1. twitter.com/javan/status/1486059026064584711
  2. github.com/rails/website/pull/15
  3. twitter.com/javan/status/1466119118420164612
  4. twitter.com/javan/status/1463593950183403524
    Javan Makhmali Javan Makhmali @javan

    Update: I’m no longer looking for a new role. More soon, but for now a huge thank you to everyone who reached out and helped spread the word. I’m humbled and grateful.💞

    1 2
  5. twitter.com/javan/status/1388215254685990915
  6. bugs.webkit.org/show_bug.cgi?id=222657

    Bug 222657 — Media element never populates its UA shadow if it was initially created in a document without browsing context 

    When input and media elements are adopted with document.adoptNode() from a foreign document (via DOMParser, for example) they lose their native shadow DOM roots and are left in a mostly broken state: <input>s lose their native UI, and <video> and <audio> elements lose their native controls.

To reproduce, open the attached adopt-node-bug.html file in Safari and compare the correct middle column (imported node) to the incorrect right column (adopted node).

Tested in Safari v14.0.3 (16610.4.3.1.4) on macOS v11.2.2, and mobile Safari on iOS v14.4.
  7. twitter.com/javan/status/1357800714018443270
    Javan Makhmali Javan Makhmali @javan

    This shit is totally unacceptable, @canary. I’ve wasted enough time completing your dark pattern maze. Cancel my account.

    699 143
  8. youtube.com/watch?v=hdiLqJc0ySc
  9. bugs.webkit.org/show_bug.cgi?id=211620
  10. bugs.chromium.org/p/chromium/issues/detail?id=1043564#c7

    Re: Bug 1043564 — Incorrect range calculated during a 'deleteSoftLineBackward' event 

    Here is another example that demonstrates the issue. It works by canceling the "beforeinput" event and applying the target range to the selection to illustrate it.

1. Open the attached "select-target-range.html" file in Chrome
2. Place the cursor at the end of each line and press Cmd+Delete
3. Observe the selection, which represents the target range
4. Not that it doesn't match the actual range of text to be removed
  11. Show me 48 more…