Fixed small bugs in 1.0.8: - Install failing due to workspace:* error - Dashboard not showing up - Accidental logs in browser console Get the latest version: npx million@latest

example pre million and post million optimisations for land.org.au (Gmaps is the bottleneck)

Introducing Million Lint: A VSCode extension that automatically fixes slow React code for you! Try it out via CLI: npx million@latest

Got million.dev (@milliondotjs) working on our huge work app yesterday. Tons of extremely helpful insights, and I see this tool becoming extremely important, even in the age of the react compiler.

your company: skips leg day our company: every day is leg day

Automatically detect which useContext/useState caused a component render inside VSCode

WIP: Preview React optimization changes inside Cursor/VSCode

WIP: See your React component hierarchy inside Cursor/VSCode

Full 30 sec clip. It's not perfect yet (fixed in ~2 shots). We're working on it.

WIP: a Cursor/VSCode extension that optimizes your your React website ⚡️ It found the source of lag and sped it up 144ms!

Soon: Predict how much faster your React app will be before you optimize

hi friends, the million team is overloaded with customer support requests. we're look to hire someone that: - high agency and knows how to respond to users directly - smart and learns our product quirks fast - high ownership over product not accepting resumes. help us in our discord if you're interested :)

the team is cooking

i've met a lot of great performance engineers in my (brief) experience. I’ve noticed 2 archetypes emerge: 1. "career" perf engineers: think framework authors, v8 engine devs. critical prod-level tooling where perf is a #1 requirement. think @RyanCarniato w/ solid.js and @trueadm w/ svelte/inferno 2. senior engineers working on apps at scale: think @gao_jude at faire, @getKonstantin at brex. generally overhead ~= limits of tech choice * # of people my current investment thesis is that this generally works because of manager~engineer symmetry. where perf is accurately correlated to an important KPI, and managers actually care about investing in perf because of that ive noticed the long tail (>95%) have high asymmetry. usually the perf directly and negatively impacts sales. asymmetry = the investment is lower/higher than necessary the #1 problem in this space isn't that perf issues don't exist - it's that the tools we use to understand performance are too limited. lighthouse scores may generally indicate perf - but managers might ask whether it's worth optimizing. engineers might not know where to get started. the barrier of entry - and the effort to finish is just too high. the first version of million lint was small script that would count the number of times a component would run. it was small but super handy - finding the highest rendered components proved more useful than a generic score or page timing. today, we've built full render tracking within your IDE and app. we tap directly into react fiber to grab timing and render data. we process that and display it in your IDE. we run complex algorithms and language models to suggest changes and improve code. my hope is that the next version of million lint will take a step further. what if we can help empower engineering teams to resolve perf requirement asymmetry AND help engineers (not just archetypes 1 & 2) contribute to improving perf. and that's what we're going to do. new version dropping ~tomorrow. until then, back to building.

you can check yours using Million Lint

New version of Million Lint: 🔗 Get parents/children on hover 🔊 Locate render triggers (setState & interactions) ⚡️ Next.js --turbo support 📸 Record & replay the DOM npx million@latest

What if your React app scanned for renders?

million wallpapers by lowercase.club (@angehyc @itswilsonhou)