Add Collaborative Editing

[ghost]

I see one use case for Stackblitz: Collaborative editing

Imagine having a design sprint, making a mockup of a new application. Participants in the design sprint are a developer, a designer and a client who has data that needs to be in the application. This group has achieved the ideal workflow. The developer starts by going to Stackblitz and pressing the button to start a project, and then quickly fills in some code in the component that comes included in the new project, and the preview soon shows something that is starting to take the form of a real working application. The URL is shared so everyone can see the preview and interact with it at the same time.

The designer drops some pictures into the project, immediately available for the developer to use. The designer also starts editing the CSS file. Although the designer doesn't know much about CSS, with changes instantly previewed, the designer can see how everything turns out, and with collaborative editing, the designer and the developer can work together, editing the same code without waiting for the other person to finish their work and commit and push their changes. The designer feels empowered and even starts editing the JS code for the components. With no difficult technology like Git and an IDE to set up, the designer can easily see how the components are structured, and keep extending them, without knowing any programming, looking at the live preview to see how it turns out.

The client also starts editing the JS files, first starting with copy edits. Although the client would never learn anything about Git or programming, the client can edit texts in the JS files as easily as using Google Documents. The developer creates a JSON file for the data to show in the app, and imports it to use in the component. The client starts editing the JSON file, filling in real data. Although the client doesn't know anything about data structures, the linter instantly tells when data is entered in an invalid format, and the preview instantly shows what the app looks and feels like with the updated data, allowing a non-technical person to do something they could never do before.

The mock application is tested on users. The user's don't notice it's a mock. It works exactly like a real application, even though it was made as fast as making a paper prototype with other prototyping software. Instead of having to ask the users to pretend it's a real application, they can observe how users interact with a real application. Users can take any path they want though the application, not restricted to which slides are included in a paper prototype.

When the design sprint is over, the project is exported, and all of the code is used in the real application. No time is lost recreating things that have already been created in the prototype.

Unfortunately, there's just one thing that makes this scenario impossible: Stackblitz doesn't support collaborative editing. Everything else is already possible.

A project on Stackblitz can only be edited from one computer. When it's opened from another computer, it cannot be saved. It can only be forked. Forking splits the team, making it impossible for more than one person to collaborate on the project. It is technically possible to edit the same project on two computers by signing in with the same Github account an both computer, but you can't changes saved from the other computer without reloading everything, and saving from one computer overwrites the edits saved from the other computer.

The design sprint team is now forced to use traditional prototyping methods. The designer has to draw every screen of the application, manually filling in data on each screen. The designer has to duplicate all screens that can be displayed with different sets of data, manually editing each copy with different data. When the data is changed, the designer has to manually redraw all screens to fill in the new data. Since it would be impossible to draw screens for all possible paths that can be taken through the application, only a few chosen paths can be selected. When testing on users, if the user chooses another option than the one selected to be drawn, the interviewer has to tell the user that because this is not a real application, only one option is possible. The team doesn't learn much about how the user would interact with the real application. When the design sprint is over, the prototype will be thrown away, and all code must be written from scratch.

[EricSimons]

@portstrom I love this idea. Your user story here really helped me imagine why this would be so incredibly useful, thanks so much for taking the time to write this up 🍻 Looks like we have a dupe issue of this at https://github.com/stackblitz/core/issues/23, going to jump in there as well and provide feedback!

[itsJess1ca]

This feature would be an absolute god send. My team uses remote buddy coding as pretty much the standard, this would solve the "hey can you commit real quick I wanna try something" moments.

We've come close to having a great system with tools like screen hero but being able to both edit separate files quickly, or making small tweaks or typo fixes, would be incredible. I love this idea and will definitely be using this at least for prototyping if this feature gets added.

Exciting times :) 👍

[wluijk]

I am at work and want to help my son learning programming who is in school. So collab editing is an nice to have

[jskrepnek]

Could it be straight forward with https://togetherjs.com/?

[EricSimons]

Hey all- just wanted to give an update on this! We're actively investigating the implementation details to pull off realtime editing. There are a surprising number of factors we have to take into account that most other realtime apps do not, particularly because all transpiling/bundling/serving is being done by the browser itself and is pretty resource intensive. Throwing multi-user realtime editing into the mix makes our bundler/devserver lifecycles ~2-3x more complicated, so we've got some R&D ahead of us before we can start implementation.

Right now we're targeting Q2/Q3 for this. Will circle back here as our R&D progresses w/ updated info and timelines 👍

[joshuakwaite]

Any update on this?

[nagromnortara]

Is this still scheduled for Q3?

[jcush]

I'd also like to know if this is still a plan for Q3? I'm not a user of StackBlitz yet but having looked at it and played around a bit, I seem to remember collaborative viewing (and, by extension, editing) being the only thing which meant I didn't use it at the time. Having revisited today I'm glad to see this is nearly on the way!

[hscheuerle]

Another update on this? I would love to use stackblitz for mentorship and teaching. Is live sharing on vscode pushing this improvement forward?

[sareeshv]

Any progress on this? I think this will give one more use case for the Tech Interviews. Currently the available collab editors/code shared doesn't provide Angular/React share option realtime

[forrestblade]

THE PEOPLE HAVE SPOKEN! we need this

[drew-codes]

Would also love to see this feature come to life!

[martinakraus]

This would the the perfect feature right now!!!

[brunolm]

Will this be done or is it something you'll never invest in?

• Codeshare doesn't run code
• Glitch glitches all the time

It'd be nice to have someone do it right (without having to install anything, use case: interview people)

[maxbethke]

I would really be looking forward to have this kind of feature too.

[sflanker]

Could it be straight forward with https://togetherjs.com/?

Based on experience using the JsFiddle.net collaboration which uses togetherjs compared to Repl.it and Glitch.com that appear to use their own collaborative editing model, most likely based on operational transformation and web sockets, the latter seem to perform better to me. I think the genericness of togetherjs causes it to be a bit slow.

I think Glitch and repl.it have a bit of a leg up here and will be hard to catch.

[yugeshk]

Is there anything new on this feature? It would absolutely change some of our workflows and put stackblitz right at the center. Currently, to use stackblitz we open the same fork and keep saving/refreshing which is a very synchronous process.

[edwinquaihoi]

A multi-dev feature would tip Stackblitz over the edge for me. Avoiding having to fork a repo to be able to collaborate would really drive adoption for Development Teams. Doesn't need to be real-time, just be able to handle merge & conflict resolution.

[mattseaboard]

Hey all- just wanted to give an update on this! We're actively investigating the implementation details to pull off realtime editing. There are a surprising number of factors we have to take into account that most other realtime apps do not, particularly because all transpiling/bundling/serving is being done by the browser itself and is pretty resource intensive. Throwing multi-user realtime editing into the mix makes our bundler/devserver lifecycles ~2-3x more complicated, so we've got some R&D ahead of us before we can start implementation.

Right now we're targeting Q2/Q3 for this. Will circle back here as our R&D progresses w/ updated info and timelines 👍

Hey Eric, would love any sort of an update to this! Did any R&D get accomplished on this? Any sort of idea on if collaborative editing might actually get implemented at some point? thanks!

[Frazer]

I'm guessing you use vscode under the hood. What if you used the Live Share system already working on https://vscode.dev/ and got around your 'transpiling/bundling/serving' issues by NOT syncing them. Either:

• allowing each browser to do their own serving, or
• the host instance just shares the URL of the server they build

[toddewilliams]

One way to easily provide collaborative editing is to support VS Code extensions in the StackBlitz editor and then add the CodeTogether extension. CodeTogether is a VS Code-compatible extension for developer collaboration and cross-IDE live sharing. It would also allow collaboration between desktop IDEs as well, if desired.

It appears that full VS Code will become the default editor in StackBlitz, according to this TechCrunch write-up. Once that occurs, CodeTogether should "just work" if it has access to a set of "proposed APIs" that Microsoft restricts default access to simply for competitive advantage.

If the committers would like to whitelist CodeTogether, as many other editors have done, I'd be happy to provide details on what is required either in this enhancement or a specific one.

We've already worked with many other VS Code-based editors to ensure a seamless collaboration experience that we detailed in this blog on the latest CodeTogether release in the External Compatibility) section.

I'd be happy to work with StackBlitz to provide the same, if you like.

[FossPrime]

One way to easily provide collaborative editing is to support VS Code extensions in the StackBlitz editor and then add the CodeTogether extension.

Unfortunately code together uses something that doesn't work on VSCode.dev (It's the same thing made by the same people but targets the web browser), so it probably can't work on StackBlitz either.

That said, about a month ago connecting from WebContainer Node.js to external websocket servers was made possible. isomorphic-git is also 100% working. This means there is no technical hurdle preventing this from working, specially for less volatile things like Markdown documents.

Here's a possible user story for vite/rollup compatible builders with watch capabilities:

1. Adam makes a private SB
2. Adam shares the SB with Steve
3. Adam installs a devDependency to "rollup-sb-sync-plugin"
4. Adam adds the sb-sync command to vite.config.ts which creates a secret in ./.sb-sync.key, makes sure it's part of ./.gitignore.
5. Adam saves the SB and reloads
6. The plugin then tries to connect to Steve via either
   • WebRTC handshaked by RunKit or CFW
   • A socket.io server running on Netlify
7. When vite triggers rollup lifecycle hooks for file changes, it will then use isomorphic-git to diff and merge the files using a sub-line algorithm.
8. Optional: it would display messages in the terminal showing whats being changed.

Unfortunately there is currently no way for WebContainer Node.js to read the SB url for information on what's open or what line is being edited. Obviously this is not as neat as Google Docs and docker based sandboxes. My boss is allergic to all things Google and I can't stand the slowness of CSB, hence why I was looking for alternatives.

[dfilmon]

Even if it could be one editor per file that would probably so much better than true live collaboration where everything is breaking and running at the same time and people are typing on top of each other.

Here are some big ideas:

1. Solves for lonely coding
2. Mentor supports
3. Visibility to code
4. Collaboration
5. Etc

Again, it could just be one or limited editor(s) per page and that would literally solve 99%.

[FossPrime]

Even if it could be one editor per file that would probably so much better than true live collaboration where everything is breaking and running at the same time and people are typing on top of each other.

Repl.it already solved this problem and it did not lead to what you're suggesting. I've talked to teachers who use this in class room settings and they live by it. It was a deal breaker for them that CodeFlow has no support for it.

Speaking of which, Repl.it and CodeSpaces clearly show auto saving to cloud storage is a better model than what CodeFlow has... specially as it has no export feature, specially as it crashes if you leave it running in the background overnight.

[timothyallyndrake]

This is unfortunate. I purchased StackBlitz with the understanding that I could collaborate with my children as I teach them to code. However, unless I am missing something this does not seem to be the case. It is really neat what has been created but I am able to achieve this with Visual Studio Code and screen share. I wish you the best of luck but I will need to go somewhere else now. Thank you!

[nilskroe]

We don't use it for our organization because of that.