<- all tokdocs
2026.09.24@jploftofficial

The spinner this video tells you to delete beat its replacement 74% to 59% in a 136-person test

Coding
Watch on TikTok

View on TikTok ->

A bald, bearded presenter in a purple henley sits in a dark office with a globe, a black-and-white Manhattan print, and a brass lamp, and delivers a 104-second list that the audio calls "five features" and then closes with "number six." The TikTok was uploaded 2026-09-24 at 20:47:06 UTC and captured 8.3 hours later at 2026-09-25 05:03:30 UTC with 890 views, 38 likes, 2 comments, 8 reposts, and 48 saves, meaning more people saved it than liked it. The 52 extracted frames at 2-second intervals show that every one of the five features gets a staged dark-mode UI mock on the top half of the screen while the presenter stays on the bottom half, and those mocks carry text the audio never speaks. Frames 1 through 5 hold a fixed three-line header: "Here are 5 features I'd put in / almost EVERY app / (after building apps for 10+ years)". Frame 7 shows a dim grey placeholder card with a circle avatar and three bar rows, the skeleton itself; frame 8 replaces it with a blue partial-ring spinner over a rounded card and a red pill reading "✕ Staring at a spinner". Frames 14 through 16 run a form card labelled "Name", "Email", "Phone" that fills in green, ending on a sharp "+1 555 0100" over two deliberately blurred green values. Frames 24 and 25 show a three-row action list, "💾 Save", "🗑 Delete", "☑ Complete", gaining green checkmarks and a green pill reading "⚡ Instantly". Frames 32 through 34 show a card reading "Form · 50%" with a green progress bar, then a red pill reading "↺ Start over?". Frames 40 and 41 stack a yellow warning triangle over "🔌 API fails" and "📡 Connection lost". Frames 51 and 52 close on a card reading "Bonus", the wordmark "JPLoft" in a purple-to-blue gradient, a purple "+ Follow" button, and the line "10+ years of lessons, shared". The audio's single quantified claim, that skeleton loaders make an app "feel 100 times faster," is the one claim published A/B testing contradicts.

The frames carry a full UI storyboard that the audio never describes

The transcript is pure voiceover. It never mentions a spinner ring, a green progress bar, a fictional phone number, or a follow button. All of that lives only in the top-half mocks.

The clearest example is the autofill sequence. At frame 14 the card is empty with three grey labels. By frame 15 the "Name" and "Email" rows carry green text rendered deliberately blurred, and by frame 16 the phone row resolves sharp as +1 555 0100. That number sits inside 555-0100 through 555-0199, the block the North American Numbering Plan reserves for fictional use, so the mock is using a number that cannot ring a real line. The blur-then-sharpen progression is a staged animation: the fields are filling themselves, which is the point the voiceover only states abstractly as "pre-fill anything you reasonably can."

The error-handling mock is built the same way. Frame 40 shows one row, "🔌 API fails". Frame 41 adds a second, "📡 Connection lost". The transcript for that moment reads:

Your app is eventually going to have an API fail, lose connection, or have something go wrong.

The frames turn that sentence into a list that accumulates one item at a time, in sync with the spoken clause. Nothing in the audio tells you the video is doing this.

Skeleton screens lost the only published head-to-head against the spinner

The video's first and most emphatic claim is that skeleton loaders beat spinners:

Why are we still making users stare at a spinning circle while something loads?

and, from the burned-in caption at 21.5 seconds, that skeletons make an app "feel 100 times / faster and more polished."

Viget ran exactly that comparison and published the result on 19 October 2017. Kathryn Faulkner and Katherine Olvera tested 136 participants split across three conditions: skeleton screen (39), loading spinner (39), and blank screen (58). The skeleton group finished last on every measure. 59% of the skeleton group agreed the content "loaded quickly," against 74% for the spinner and 66% for the blank screen. 36% of the skeleton group actively disagreed, against 10% for the spinner. Skeleton users estimated a longer wait, 2.82 seconds against 2.41, and took longer on the follow-up task, 10.54 seconds against 9.49. Viget's own conclusion is that "skeleton screens aren't a silver bullet for increasing perceived performance and should be used thoughtfully."

The evidence is genuinely split rather than one-sided. Mejtoft, Långström and Söderström presented the opposite finding at the 36th European Conference on Cognitive Ergonomics in 2018, reporting that a page using skeleton screens scored higher on both perceived speed and ease of navigation, with the caveat that spinner users found the target article faster on first visit. Bill Chung's UX Collective write-up adds a mechanism: skeletons animated left-to-right read as shorter than skeletons that pulse, and slow steady motion reads as shorter than fast motion. Chung states directly that his sample sizes are too small to conclude anything definitively.

The honest version of feature one is that skeleton screens are a defensible pattern whose measured effect flips depending on animation direction and how familiar the interface is. "100 times faster" is not a number any of this supports.

Autofill is the one item in the list with hard numbers behind it

Feature two is the least glamorous and the best evidenced.

If I already gave your app my name, email, address, or any other information, please don't make me type it again. Use native autofill.

"Native autofill" is a real, specified thing on every platform the video implicitly targets. The WHATWG HTML standard defines the autocomplete attribute and a fixed vocabulary of field names covering exactly the three shown in the mock: name, email, tel, plus street-address, address-line1 through address-line3, postal-code, cc-number, one-time-code and others. On iOS the equivalent is UITextContentType, set per field as .name, .emailAddress, .telephoneNumber, .streetAddressLine1, which wires the field into iCloud Keychain AutoFill.

Google's Chrome team published measured effects on 17 December 2024, after analysing thousands of address and credit card forms across millions of page loads on the most-visited sites in Chrome in the United States: time spent filling forms is roughly 35% lower with autofill, and users abandon forms 75% less often when they use it. Chrome's own post flags this as correlational, since people who use autofill may already be faster form-fillers.

Baymard Institute's cart abandonment list puts a price on the failure mode: 17% of US online shoppers have abandoned an order because the "checkout process was too long / complicated," inside a documented average abandonment rate of 70.22% compiled across 50 studies from 2006 to 2025. The video's framing, that autofill "removes a ridiculous amount of friction," is the claim in this list that holds up best.

Optimistic UI stopped being a pattern and became a built-in hook

Feature three describes optimistic UI without naming a single API:

Update the UI immediately, process the actual request in the background, and only reverse it if something goes wrong.

That is a near-verbatim description of React's useOptimistic, shipped in React 19 on 5 December 2024. The React docs describe the revert behaviour the video asks for: "If the Action throws an error, the Transition still ends, and React renders with whatever value currently is. Since the parent typically only updates value on success, a failure means value hasn't changed, so the UI shows what it showed before the optimistic update." The rollback the presenter describes as something you implement is, in React 19, the default.

The frames are more specific than the audio here too. Frame 24 shows the three actions unchecked; frame 25 shows "💾 Save" with a green checkmark, "☑ Complete" checked, and a green "⚡ Instantly" pill underneath. The mock shows the optimistic state, not the confirmed state, which is the correct thing to be showing.

The video promises five features, delivers six, and gets the HTTP status wrong

Two small factual slips are worth naming.

First, the count. The header card in frames 1 through 5 says "Here are 5 features," and the audio opens with "here are five features." The closing caption in frame 49 reads "And number six, bonus." Six is not a feature; it is the follow prompt, rendered in frames 51 and 52 as "Bonus / JPLoft / + Follow / 10+ years of lessons, shared". The TikTok description lists only five and drops the sixth entirely.

Second, the status code. The audio and the description both single out 404:

What's not normal is showing your users a 404 random backend message or wiping everything they just did.

and, in the description, "Users should NEVER see a 404, 500, or random backend message." A 404 is not a backend message in the sense implied. MDN and RFC 9110 classify it as a client error response in the 4xx range, indicating the server cannot find the requested resource, with no statement about whether the absence is temporary or permanent. 500 Internal Server Error is the 5xx server-side class. Lumping them together as one category of "backend message" blurs the distinction that would actually tell a developer whether to retry or to fix a route.

The underlying advice, "Catch the error, preserve their progress, tell them what happened in normal language, and give them a button to try again," is sound, and the save-state feature that precedes it maps onto documented platform APIs. Android's Saved State module for ViewModel provides SavedStateHandle, a key-value map injected into the ViewModel constructor whose values survive system-initiated process death, with Android's own documentation naming "input in text fields" as a target use case. The documented limit is that saved state dies with the task stack: force-stopping the app, swiping it out of recents, or rebooting all destroy it. So "just put me where I left off" needs real persistence, not only instance state, which is a nuance the 104 seconds do not have room for.

The "10+ years" on screen undersells what JPLoft's own site claims

The header card says "(after building apps for 10+ years)" and the closing card says "10+ years of lessons, shared." The audio opens with "I've been building apps for over 10 years."

JPLoft's own homepage claims "16+ Years of Experience" and "1250+ Projects Successfully Completed," and says the company is "Headquartered in Denver, USA, with operational offices across the UK, India, Australia, and Saudi Arabia," listing Denver, Melbourne, Basingstoke, Jeddah and Jaipur. Its Clutch profile lists a 2010 founding, 50 to 249 employees, a Denver headquarters, a $10,000 minimum project size and a $50 to $99 hourly rate. Rahul Sukhwal is listed on LinkedIn as Founder, Director and CEO. The Indian entity, Jploft Solutions Private Limited, carries CIN U74999RJ2019PTC063470, where the RJ2019 segment indicates a 2019 Rajasthan incorporation, which is a separate fact from the parent company's founding year and not a contradiction of it.

The "10+ years" figure is therefore conservative against the company's public claims rather than inflated. It is also a first-person claim in the voice of a presenter whose identity is not stated anywhere in the video, the description, or the metadata.

Key Takeaways

  • Whisper mis-transcribed the single most load-bearing verb in the optimistic UI section. The transcript line reads "Create the UI immediately," but the burned-in caption at 53.5 and 54.5 seconds clearly reads "Update the UI immediately," and the TikTok description also says "Update the UI immediately." "Create" and "update" mean different things in an optimistic-mutation context.
  • The 2-second frame grid missed a caption chunk. Frame 11 (20s) reads "And it makes your app" and frame 12 (22s) reads "faster and more polished." Pulling a frame at 21.5 seconds recovers the missing chunk, "feel 100 times," which is the video's only numeric performance claim.
  • Every UI mock exists only in the frames. The spinner ring, the "✕ Staring at a spinner" pill, the +1 555 0100 fictional number, the "Form · 50%" progress bar, the "↺ Start over?" pill, the "⚡ Instantly" pill, and the "+ Follow" card are all silent on the audio track.
  • Published A/B data cuts against feature one. Viget's 136-person test found 59% of skeleton-screen users agreed content "loaded quickly" versus 74% for spinners; the 2018 ECCE paper found the opposite on perceived speed. No source supports "100 times faster."
  • Feature two is the best evidenced. Chrome's December 2024 analysis measured ~35% lower form-fill time and 75% less form abandonment with autofill, and both autocomplete (WHATWG) and UITextContentType (Apple) are specified, free to adopt, and cover the exact name/email/phone fields in the mock.
  • Feature three now has a first-party implementation. React 19, stable 5 December 2024, ships useOptimistic, which reverts automatically when the action throws.
  • The video says "five features," then says "And number six, bonus." The sixth is a follow prompt, and the description omits it.
  • Unverified: I could not confirm the presenter's identity. He is not identified in the audio, the on-screen text, the description, or the yt-dlp metadata, and he does not appear to be Rahul Sukhwal, JPLoft's listed founder and CEO. Whether he is a JPLoft employee, a hired presenter, or a synthetic avatar is unresolved. I also could not retrieve the account's follower count, since tiktok.com returns only a generic shell to an unauthenticated fetch, and I could not open the ACM full text of the 2018 ECCE skeleton-screen paper, which returned HTTP 403, so its findings here come from the abstract and secondary summaries rather than the full method and sample size. The exact RFC 9110 wording for 404 and 500 could not be pulled directly (the fetched excerpt truncated before section 15.5.5), so the classification above rests on MDN's documentation of the same status codes.

Resources

Published September 24, 2026. Writeup generated from a favorited TikTok.