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

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

I work at Status Hero as VP of engineering.

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

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

  1. mastodon.social/@javan/109869913242555450
  2. twitter.com/javan/status/1516057444463616000
  3. github.com/rails/website/pull/28
  4. twitter.com/javan/status/1486059026064584711
  5. twitter.com/javan/status/1466119118420164612
  6. 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
  7. twitter.com/javan/status/1388215254685990915
  8. 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.
  9. 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.

    648 132
  10. youtube.com/watch?v=hdiLqJc0ySc
  11. bugs.webkit.org/show_bug.cgi?id=211620
  12. 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
  13. bugs.webkit.org/show_bug.cgi?id=203116

    Bug 203116 — Native text substitutions interfere with HTML <datalist> options resulting in crash

    To reproduce:
    
    1. Open System Preferences → Keyboard → Text and add entry to replace "cat" with "Cat"
    2. Open the attached datalist.html file in Safari
    3. Ensure that the menu option for Edit → Substitutions → Text Replacement is selected
    3. Type "cat" in the text field and wait for the "Cat" replacement overlay to appear
    4. Click any option from the expanded <datalist> menu and Safari will crash
    
    Tested on macOS 10.14.6 (18G103) with Safari 13.0.2 (14608.2.40.1.3) and Safari TP Release 94 (Safari 13.1, WebKit 14609.1.6.1). I believe this issue occurs in Safari 12.1 as well.
  14. weblog.rubyonrails.org/2019/8/15/Rails-6-0-final-release/

    Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk

    Dealing with incoming email, composing rich-text content, connecting to multiple databases, parallelizing test runs, integrating JavaScript with love, and rewriting the code loader. These are fundamental improvements to the fundamentals of working with the web and building fast and fresh applications. This is the kind of work we’ve been doing for the past fifteen years, and we’re still at it. THIS IS RAILS SIX!

  15. bugs.chromium.org/p/chromium/issues/detail?id=992862

    Bug 992862 — Cutting from a contentEditable element causes slow forced reflow

    Steps to reproduce the problem:
    1. Open the attached cut.html file and click "Cut All" (or, use the Edit → Cut menu)
    
    What is the expected behavior?
    The cut operation completes in a reasonable amount of time.
    
    What went wrong?
    The cut operation takes several seconds to complete. The Performance inspector reveals a very slow Layout task. See the attached .gif for a comparison by browser.
    
    Chrome: 5,177ms
    Firefox: 19ms
    Safari: 147ms
    
    Did this work before? N/A 
    
    Does this work in other browsers? N/A
    
    Chrome version: 76.0.3809.100  Channel: stable
    OS Version: OS X 10.14.6
    Flash Version:
  16. topenddevs.com/podcasts/javascript-jabber/episodes/jsj-376-trix-a-rich-text-editor-for-everyday-writing-with-javan-makhmali

    Trix: A Rich Text Editor for Everyday Writing with Javan Makhmali

    Today’s guest is Javan Makhmali, who works for Basecamp and helped develop Trix. Trix is a rich text editor for the web, made purposefully simple for everyday use instead of a full layout tool. Trix is not the same as Tiny MCE, and Javan discusses some of the differences. He talks about the benefits of using Trix over other native browser features for text editing. He talks about how Trix has simplified the work at Basecamp, especially when it came to crossing platforms. Javan talks more about how Trix differs from other text editors like Google Docs and contenteditable, how to tell if Trix is functioning correctly, and how it works with Markdown.

  17. twitter.com/javan/status/1151914387428564992
  18. github.com/github/eventlistener-polyfill/pull/13
  19. twitter.com/javan/status/1111329710842101760
  20. remoteruby.transistor.fm/31

    Remote Ruby | Joined by Javan Makhmali and Sam Stephenson

    Buckle up! In this episode, Javan Makhmali and Sam Stephenson join Jason and Chris. Sam and Javan are employees at Basecamp and also part of the mastermind behind many JavaScript libraries to come out of Basecamp: Turbolinks, Trix, and Stimulus. They each share how they got started programming, a brief insight into how they work at Basecamp, the transition from CoffeeScript to ES6, Typescript, as well as (wait for it...) upcoming features in Stimulus (🙌) and considerations for Turbolinks 6 (no feature promises made 😉). It was an absolute joy to chat with Javan and Sam. We very much enjoyed this episode and hope you will enjoy it, too.

  21. Show me 40 more…

The end! 👋