Just a heads up: it scrolls really weird on iOS. I suppose it might be because of your implementation of the “sticky” header? I can’t look at the code right now, but I’d recommend either making the header sticky using position: sticky; top: 0, if that is the problem, or using -webkit-overflow-scrolling: touch, which would make it scroll more naturally in its current state.

Is this a feature people actually want?

YES. I work 100% remotely, and a lot of my work is mentoring newer developers by pair programming thorny problems with them. Screensharing is kind of okay at this, but sometimes saying, “On line 39, you need a closing paren. No, not there, back 6 characters. No. 6 characters.” is a little too challenging.

Slack itself has voice+video chat with screen sharing+control built in so there was no need to leave the app.

I’ve used ScreenHero in the past (the product Slack bought to power their system). In some ways it was better than screensharing. In other ways worse. I work on a Windows computer while most of my coworkers are on Macs. Even if we use the same editor, I’d have to use the Mac keyboard shortcuts in order to do anything useful.

If I understand this correctly, the Live Share feature allows you to use all your local shortcuts, etc. and just transmits the effect over to the other user’s editor. The difference between remotely using someone else’s editor, and having my local editor transmit changes over to them is HUGE.

Is this a feature people actually want?

That’s a good question. This has never been on my list of wants.

It’s kinda cool that both developers get to use their own key bindings.

Maybe if you were pair programming, and you had two developers next to each other with their own keyboard/mouse/monitor, then having your own keybindings would be great.

– jorge.

It’s something that I’ve been wanting since I used it in Eclipse a while back. It’s not really useful for professional collaboration, but it’s excellent for one‐on‐one teaching—no switching between windows or awkward vocal instructions. Also, it tends to be easy on bandwidth and avoid the sort of video artifacts that screen sharing brings.

There’s a group of computational linguists at the University of Tromsø who swear by Subethaedit. They make everyone get Mac’s so they can run that. I’m guessing it has to do with constantly onboarding new phd students, getting them quickly set up in their dev environment, as well as collaborative article writing (though https://www.overleaf.com/ is now a better alternative for that). They’re always annoyed at having to use less capable editors like Etherpad with non-mac-users …

See also: https://www.reddit.com/r/emacs/comments/7d6hv0/real_time_collaboration_in_emacs/

I use tmate whenever I need to remote pair; it lets you share both the editor and the terminal (of course; really I’m just sharing Emacs with terminal buffers inside it, but anyway) and it shows the exact same thing to both participants, whereas most buffer-centric sharing solutions I’ve seen had you enable sharing on a per-buffer basis, so you had to talk thru “OK, now I’m switching to this other file” over voice whenever you changed focus.

The slack-style screen sharing isn’t nearly as nice for my purposes because it’s read-only, whereas with tmate the other person can make edits easily.

That’s my reading, here- this is much-ado about the standard sort of text for any file hosting service. “Look, we’re going to need to make copies of your stuff, and sometimes when we show it, we’re only going to show parts of it, so, y'know, just FYI. Don’t come yelling at us if this somehow violates a license, blame whoever put the code here.”

They do have some benchmarks against PHP 7, although it unfortunately doesn’t have HHVM, which is really what they’re up against.