> would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms?

I would rather have one team developing a cross-platform application in a language that isn't Javascript.

We'd love to. What do you suggest we use? Java swing? C Gtk? C++ Qt? All of those often look ugly and are harder to use.

It's amazing how bad the options for native UI frameworks are, even without considering cross-platform, more so once you do. Android is actually decent but with caveat it only works on Android... Windows had a decent WPF but then they came up with 5 other framworks that got rebranded and now nobody knows what to use anymore. Is WinUI the latest and greatest there? Wouldn't be cross platform anyway.

Perhaps Unity? But that's more tailored for 3d scenes, rather than UI widgets.

Genuinely looking for suggestions on what is the best choice to pick there.

> I would rather have one team developing a cross-platform application in a language that isn't Javascript.

So, use one of the many languages that compile to JS. Starting with TypeScript. Or (alphabetically) ClojureScript, Elm, PureScript, or Rescript.

Given that there's no other language that works cross-platform with as little jank as JS, I don't think that distaste is adequate reason to avoid using it

Why do you care which language software is developed in?

Should I not use anything that uses ML if I dislike python?

HTML/CSS/WASM??

Would that work?

I am not a front end kind of developer, I am a "plumber". So it is a genuine question.

While I agree that maintaining one codebase is preferable, the 'teams' part is a bit off.

No-one wants 'three teams building one product' which is why it almost always is far better to have one team with android, iOS, web and desktop mixed. Obviously if their mixed erpertises are around one codebase, that is even better.

> It makes perfect business sense to use electron.

In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.

> I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.

This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we can muster.

The UI for each implementation is bespoke. This lets us build native interactions on the platforms we ship to, giving the end user the best look-and-feel for the platform they’re on. The flip side to this is development cost and time. In the long run, we believe it is worth it.

Rewriting Photoshop in Electron would have been infeasible and the performance hit a non-starter. The path we’ve taken has some trade offs to it, but is the right one given the legacy tech we have and what we want to do with it.

There's a terrible performance regression in Illustrator 26 when working with files with many objects. Works fine in 25, UI freezes for several seconds in 26.

Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).

I’m on the Photoshop team, so cannot speak to AI issues. Have you tried filing a report here? https://community.adobe.com/t5/illustrator/ct-p/ct-illustrat...

I get that it is basically an impossible problem to triage incoming issues on such large and widely used software, but my impression of the popular "community" approach is that it is useless and designed to provide an outlet for complaints rather than to identify issues.

On the Photoshop team we have dedicated staff to monitor, triage, and respond to these issues. You’re right in that we cannot address _everything_ that comes in from these boards- the sheer volume is too much. Nevertheless we do use it to identify top customer issues and our dev schedule prioritizations are influenced by them.

To wit: I’m known on the team for sussing out information from corrupted PSDs, and get called on about once a quarter to look into a bad file that’s come in. That wouldn’t happen as frequently without the community site.