Thursday, October 28, 2021

Photoshop for the Web Public Beta

Google (Hacker News):

The idea of running software as complex as Photoshop directly in the browser would have been hard to imagine just a few years ago. However, by using various new standardized web technologies, Adobe has now brought a public beta of Photoshop to the web.


Adobe previously brought Spark and Lightroom to the web and had been interested in bringing Photoshop to the web for many years. However, they were blocked by the performance limitations of JavaScript, the absence of a good compile target for their code, and the lack of web capabilities. Read on to learn what Chrome built in the browser to solve these problems.


WebAssembly and its C++ toolchain Emscripten have been the key to unlocking Photoshop’s ability to come to the web, as it meant that Adobe would not have to start from scratch, but could leverage their existing Photoshop codebase. WebAssembly is a portable binary instruction set shipping in all browsers that was designed as a compilation target for programming languages. This means that applications such as Photoshop that are written in C++ can be ported directly to the web without requiring a rewrite in JavaScript.

John Gruber:

Unsurprisingly, supported only in Chrome and Microsoft Edge, but an impressive demonstration of just how rich a platform Chrome is for something like this.


11 Comments RSS · Twitter

This is the real issue with safari.

Not that its tabs are fugly, and hard to read, but that it's years behind.

That presupposes not only that running Photoshop in Safari would've been impossible (it does have WebAssembly), and that "make web apps more potent" automatically makes for a better web browser.

Also that Apple created the tabocalypse as a distraction.

"That presupposes not only that running Photoshop in Safari would've been impossible"

I'm sure it would have been possible. You can also get Photoshop to run on a ZX Spectrum, but if the benefit doesn't warrant the effort, and you can't hit the same quality bar even with the additional effort, why do it?

The problem isn't usually that you can't get these things to run on Safari, it's that it's much harder to get them to run on Safari, and it ends up working worse than on other browsers. Meanwhile, the option of just telling people "install Chrome, it's free" exists.

"and that "make web apps more potent" automatically makes for a better web browser"

Safari users can't use this web app. That makes Safari a worse web browser.

"It's good that I can't run this really useful thing, actually" is not a great take. The longer Apple's fans give Apple cover fire while Apple is dropping this ball, the further down the ball will drop, and the more successful Chrome will be.

Nobody wants that. Stop giving Apple cover fire.

Not everyone wants Google’s web monoculture. Having the web be one of multiple competing app platforms has benefits.

Web browser market share:

Chrome 65.15%
Safari 18.4%

So Adobe has little choice but to make it work on Chrome. The entire point of rewriting their software to work on the web is to avoid OS dependencies, and Safari only works on MacOS.

Unless Adobe needs browser independence, it does not need to support Safari, since Chrome works on MacOS. Adding support for Safari creates the expectation it will continue to be supported, which might prove to limit further progress.

If Apple didn't want to be a follower, they shouldn't have cancelled Safari for other platforms.

"Not everyone wants Google’s web monoculture"

Nobody wants Google's web monoculture. But unless you want Chrome to keep gaining market share, you need to get Apple to start taking Safari seriously.

I know of multiple web companies where developers are fighting a constant war to stop supporting Safari, because Safari is now the browser that requires an inordinately high effort to support. Unless Apple changes that, things will keep getting worse for Safari.

I don't like monopolies so I'd love to see Apple use a portion of their minutes to put some pressure on Google, rather than innovating around tabs.

I'm not holding my breath.

I guess I don't understand _what_ they're supposed to pressure Google on, though. Apple (apparently) doesn't share Google's vision of "as much as possible should be done in the browser", and I personally agree. So the way you apply "pressure" is by competing and offering a good app platform of their own.

I'd argue Apple has done a bit poorly on that front in recent years, because it isn't even clear which of AppKit, UIKit/Catalyst and SwiftUI is the future™, but surely Apple does _not_ view web apps as the future.

Why don't you like running apps in a browser?

That's kind of a big topic of its own, but…

* I like the OS integration that desktop apps offer. Keyboard shortcuts, a menu bar, etc. Granted, some of that could be added to web apps, but that's besides the point.
* Web apps that have been ported-ish to desktop apps tend to be shoddy user experiences. Teams, for example.
* Fundamentally, web apps, like cross-platform apps, will never feel at home anywhere (except on ChromeOS, I suppose). The very economics that lead to the decision that a web app should be built instead of native apps are the ones that lead to not hiring experts on platform-specific UI, and not reading respective UI guidelines.
* Competition is good. It's good for Apple, Microsoft, Google, Ubuntu, Red Hat (GNOME), and others to each try out their own approaches to improving user interfaces. The web just seems to lead to sameness and shoot for the lowest common denominator.

Which is not to say that web apps don't have benefits. Being able to just enter a URL and get there is nice, no doubt. But for anything I use on a regular basis, that benefit is, IMHO, moot.

Leave a Comment