Embedded replit features degraded

There are a few other threads about the recent changes to embedded repls (announced here: Embedding an Editable Repl has been deprecated and Replit - Embedding an Editable Repl is Going Away)

While I don’t love the loss of functionality, I guess, whatever, you do you product team. There is a flow that is now broken, that was possible before and now seems tricky.

In our intro course, we gradually introduce replit, first through some runnable examples (still possible in the new regime, though a little tricky to figure out how to configure the embed to show the right file by default in some platforms). Next, we have students edit some code in the context of a lesson (this would implicitly fork the underlying project), then we gradually move them into their own replits, have them join the team, and use Replit in its own tab instead of from within the lessons, since the programs they write start to get more substantial.

This gradual approach is now much more difficult - in order to get students to edit, we have to teach them the Replit UI, which locks us into a particular (and, imo, worse) teaching sequence. It’s not the end of the world, we can show them how to use the fork button and teach them what ‘forking’ means… but it was really nice to push that discussion off until they had run their first few python programs before, and this kinda stinks.

One remediation might be to reintroduce a way to ‘link to fork’, a la google docs’ link-to-copy-a-doc. That way, students who tap the link would at least not need to learn to locate the fork button, they could just tap a link and start editing their own version of a project. That ‘quick start’ ability was really prized by us and by students, and this set of changes has increased the number of clicks and concepts between our very beginner students and writing code, rather than decreasing it.

On the rollout itself
It’s not like the change was a secret, but it was annoying that I missed this until I went to check on my course. I presumed that the stuff we’ve run 4 times would continue to work, and then saw that we’d actually have to change a ton of the way that we use replit right at the start of the program. Maybe it’s too much to ask for a deprecation like this, but pulling a list of users who had embedded repls and emailing them with the link to the blog post would have prevented a pretty confused / frustrated couple of hours for me. Amidst all the rollouts of exciting features, it’s hard to focus on ‘launching’ a regression, but it’s burned me a little bit. Hard to get excited about the new stuff when this is how the old stuff gets handled.

Hey Rob,

Thanks for this feedback. We hear you that we could have done better on the rollout, and we’ll do better in the future to give you an early heads up as well as resources on any alternative workflows.

For now, I’m curious if you are using Teams for Edu? It is completely free for educators and eliminates the need for students to locate the fork button (all they’ll see is a button that says “Start project”). It also allows you to sequence the projects in the order you wish. We have some shortcuts to help you transfer any repls from your personal account into team projects. Happy to give you a demo one of these days!

1 Like

Thanks for the reply! It’s hard to do rollout comms when there’s so much going on - and you did put out posts in different places! Just hard to pay attention when there’s so much replit news…

We are using TfE, but the previous feature let us avoid talking about that until later on. We have a ‘pre-course’ before the proper course, letting us check that students are ready and interested in the program, so that we don’t get a ton of folks who quit in week 1. If we switch these to TfE projects and move up the switch to TfE for students, that might work. It feels a little heavy for the “just try a tiny bit of code” examples, but might be the right answer now.

1 Like