Skip to content

Executive summary

Nine practitioner interviews and a two-call Tufts University case study inform this report.

Findings

Findings from the interviews and case study:

  • A. PyScript's core asset is its friction-free experience: type Python and immediately see it run in the browser. PyScript.com problems have damaged this story.
  • B. We win people on the simple use case but lose them on the technical journey through the JavaScript/browser boundary. This is the key retention finding.
  • C. Package compatibility, Pyodide version churn and opaque errors are the recurring practical blockers.
  • D. Onboarding fails at both ends of the journey: beginners face a blank page on PyScript.com and don't know where to start; experienced users lack a graduation path to grow their skills and integrate PyScript into their existing Python practices.
  • E. AI is now the default route into, through and around PyScript. Community attitudes span the full range of opinions about AI; we should cater to all of them.
  • F. PyScript is invisible in places where developers now learn, feedback routes are unknown to users, and past community contributions have not always been honoured - causing hurt feelings and a loss of trust.
  • The case study shows PyScript.com's unreliability is disrupting Tufts' teaching now. TuftsHub, built in response, shows what a replacement needs and how such work should be done (collaboratively placing practitioners at the heart of our development process).

Proposals

Proposed next steps (for discussion, not commitments; see Section 6):

  1. Migration tutorials, tightened learning pathways and engineering fixes to address the technical boundary drop-off.
  2. Remixable demos clearly signposted as a primary onboarding surface.
  3. Continue the package compatibility and error-message work; add a confidence-building long-term-support story.
  4. Make PyScript an excellent citizen of the LLM ecosystem; keep the AI-free path first-class for those avoiding AI entanglement.
  5. Get Invent to an early release and validate it with real users.
  6. Fix PyScript.com reliability; ship the self-hostable TuftsHub.
  7. Build sustained visibility and repair community trust.

An authorial note

Nicholas planned this process, wrote this report, built TuftsHub, created Invent, contributed to PyScript and conducted the interviews (with Jessie).

This concentration of roles is common in practitioner-led open-source research, but it should be declared: you are entitled to know that I am reporting the findings, and have a non-neutral stake in some of the work those findings support.

Nevertheless, every finding can be linked back to named interviewees.