Browser vs. native client for cloud desktops

The usual assumption is that a native client must be faster because it is native. For remote desktop streaming that has stopped being true. Browsers ship the same real-time media stack a native client links against — the same transport, the same congestion control, the same hardware-accelerated video decode path — because the browser is where that stack was standardised in the first place.

What remains is a small amount of compositing overhead as the decoded frame is painted into the page, typically under 5 ms. Set that against the dominant terms described in the latency guide — network round trip and codec pipeline depth, which are identical for both surfaces — and the delivery choice is not where your responsiveness is won or lost. Region choice is.

• Zero deployment: there is no package to build, sign, distribute, version or roll back. A new joiner is productive from a link, and a contractor needs no install rights on a device you do not own.
• Smaller attack surface on the endpoint: nothing is installed, nothing persists on local disk, and the sandbox is maintained by a vendor that patches it continuously. Closing the tab ends the local footprint.
• Device independence: the same session opens on a work laptop, a personal machine, a borrowed desktop or a tablet, with no per-platform build to maintain.
• Instant updates: improvements ship the moment they deploy, so there is no long tail of endpoints running an old client against a new backend.

• Arbitrary USB redirection: dongles, licence keys, smart cards, lab and medical instruments. Browsers expose a deliberately narrow device surface; if your workflow needs a device outside it, the browser cannot help.
• High display counts: three or more monitors with independent scaling are better served by a client that can own several native windows and negotiate a stream per display.
• System-wide input capture: global hotkeys and full keyboard grab, including combinations the browser or operating system reserves for itself.
• Mounted local storage: workflows that expect a drive letter or a mount point rather than an explicit upload and download step.

Notably, webcam and microphone are not on this list — those work in the browser, with the caveats covered in the webcam passthrough guide.

The choice is not actually binary. A browser-delivered desktop can be installed as a progressive web app, which gives it a dock or taskbar icon, its own window without browser chrome, and a cached shell that opens during patchy connectivity — while remaining the same sandboxed surface with no deployment programme behind it.

Deeper local integration is then handled by a small optional agent rather than by moving the whole desktop into a native client. That keeps the heavyweight install out of the critical path: the platform works for everyone from a tab, and only the people who need local folder sync or wider device access run anything on their machine. Both are set up from Apps & install.

Four questions settle it for almost every team:

• Does any user need a USB device beyond camera, microphone and printer? If yes, that group needs a native client or the agent. Everyone else does not.
• Do users have install rights on the devices they will use? If contractors, clients or personal devices are in scope, browser delivery is the only option that reaches them.
• How many displays do power users run? Two is comfortable in the browser; four argues for a client.
• Who patches the endpoint? If there is no endpoint management programme, an installed client becomes an unpatched binary within a quarter — pick the browser.

Most organisations land on browser-first with a small exception group, which is precisely why SisiDesk is browser-delivered by default and treats the agent as an add-on.

No delivery surface can run a cloud desktop without a network, because the desktop is not on your device. The honest question is what happens during the gaps. SisiDesk caches its application shell and key pages so the app still opens and shows your last known workspace state during intermittent connectivity, then reconnects when the network returns.

Because Ghost Sync captures workspace state before a session ends, a dropped connection costs you the session, not the work in progress — you resume the same layout on whatever device you reach next.

Is a browser cloud desktop slower than a native client?

Not meaningfully. Browsers run the same WebRTC media pipeline a native client uses, with hardware-accelerated decode, so browser overhead is typically under 5 ms. The dominant latency terms are geographic distance and codec pipeline depth, which are identical for both.

What can a native client do that a browser cannot?

A native client has deeper operating-system access: arbitrary USB device redirection, smart-card and specialised peripheral passthrough, more than the browser's practical monitor limit, system-wide hotkey capture, and direct local filesystem mounts. If your workflow needs any of those, you need the client.

Which is more secure, a browser or a native client?

The browser has the stronger default posture: it runs in an established sandbox, updates itself, leaves no installed binary to patch and no local disk footprint to wipe. A native client requires an endpoint deployment and patch programme, which is a real security cost that only pays for itself when you need its extra capabilities.

Can I use a cloud desktop offline?

Neither option can stream a desktop without a connection, because the desktop is not running on your device. What can work offline is the surrounding application shell — SisiDesk caches its shell and key pages so the app opens and shows your last known state during intermittent connectivity, and reconnects when the network returns.

Do I need to install anything to use SisiDesk?

No. SisiDesk is browser-delivered — you sign in and the session opens in a tab. You can optionally install it as a progressive web app for a windowed, dock-launchable experience, and there is an optional desktop agent for deeper local integration, but neither is required.

Tell us the device mix, display counts and any peripherals in play at hello@sisidesk.com and we will map out which users can stay in the browser and which need the agent.