Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Photoshop’s journey to the web

web.dev

Post reply on HN
Print view View original

81–90 of 203 posts

Re: Photoshop’s journey to the web

#81

Post by jbnorth »

flohofwoe wrote: post #71
q_andrew wrote: post #63

Earlier quoted context omitted.

Download time is the biggest setback for games in the browser in my experience.

That's why games running in browsers need a different approach to asset loading, instead of downloading everything upfront, stream the asset data directly from CDN when needed. It's nothing new, games had to deal with streaming data from slow mass storage devices throughout their entire history.

That's not an option for most games. That means I now either need to be online-only with a good enough internet connection and latency to stream this game (a la Stadia but worse since it's not just video) or I need to download it into an offline cache which now brings us back to the same spot.

Re: Photoshop’s journey to the web

#82

Post by softfalcon »

astlouis44 wrote: post #11

WebAssembly is coming for games next. Near native performance, players can join with just a link, and no 30% cut that developers have to deal with.

I feel your excitement and wish it were true. I'm even building a game to leverage this newly supported tech. The good news is that the tech works really really well and is very performant in the browser. You can do a lot of cool stuff!

The bad news is that it's not the tech that is holding back web based game dev. It's the users. Market research and testing has shown that users dislike "just playing" a game in the browser. This is particularly true in the AAA segment that webassembly and its perf gains would best serve.

Players who play the high profile games that web assembly would allow you to make games for (think Fortnite, CS:GO, etc) all want to play games from a trusted download from a trusted store, not some random website. Please note, random is used very loosely here to mean "any store/website that isn't Apple Store, Play Store, Xbox Live, PSN, or Steam".

I foresee that we'll need some major player with a big game like Fortnite, Roblox or Mojang to spearhead using web deployed games before we'll see anything happen in this space. The existing "install to disk and play" is working just fine and game devs don't really see any reason to change that.

The other major thing is that most "slightly" big games (even smaller mobile ones) have assets in the minimum size of 4-10 GB of data. Even if you can render the game in browser, you have to download those assets. Yes, of course you can "load only what you need" but for many many games (source: my wife is a game designer and I'm a game programmer/web dev) that still entails at least 1 GB of data that would need to be loaded and is difficult to cache client side in the browser.

Re: Photoshop’s journey to the web

#83

Post by flohofwoe »

jbnorth wrote: post #81
flohofwoe wrote: post #71

Earlier quoted context omitted.

That's why games running in browsers need a different approach to asset loading, instead of downloading everything upfront, stream the asset data directly from CDN when needed. It's nothing new, games had to deal with streaming data from slow mass storage devices throughout their entire history.

That's not an option for most games. That means I now either need to be online-only with a good enough internet connection and latency to stream this game (a la Stadia but worse since it's not just video) or I need to download it into an offline cache which now brings us back to the same spot.

Traditional MMO games have the same requirements, and it works fine. Some of them also allow starting the game while only a fraction of the asset data has been downloaded and continue downloading while the game is running.

Re: Photoshop’s journey to the web

#84

Post by modeless »

orangepurple wrote: post #53

> Why Photoshop came to the web The entire section is a deception. The real reason is to strong arm everyone into a subscription model where you never own the software that runs on your computer. That's the real end game, not this nonsense about how easy it is to launch an application if its a URL in a browser.

Adobe strong-armed everyone to the subscription model long before they supported web. There's no relation at all.

Re: Photoshop’s journey to the web

#85

Post by enumjorge »

orangepurple wrote: post #53

> Why Photoshop came to the web The entire section is a deception. The real reason is to strong arm everyone into a subscription model where you never own the software that runs on your computer. That's the real end game, not this nonsense about how easy it is to launch an application if its a URL in a browser.

Speaking of ulterior motives, the way web.dev presents itself on the surface as a general web development learning resource feels a little icky, especially since it's clearly very Chrome-focused once you dig in. It's weird to me that what is essentially content marketing for Adobe gets a blog post on this site instead of the Chrome team's blog. As others have mentioned this browser-based Photoshop works only in Chromium. I've never seen MDN push Firefox-specific content like this before.

Re: Photoshop’s journey to the web

#86

Post by mhoad »

zz865 wrote: post #51

As someone who is bad at JS I really hoped webassembly would let me leapfrog JS/React etc. Is it time to start using it?

There are a few things already here or “coming soon” that will 100% let you leapfrog JS.

WASM still has no concept of garbage collection which means that by default it’s limited to a smallish number of languages that are viable. That’s changing in the not too distant future it seems as the plans for garbage collection are well underway already.

It also has no ability to do DOM manipulation meaning you end up in a scenario like the one in the article where “algorithms” end up in wasm and the UI in web components / JS.

I believe that too is going to change at some point.

As for where things stand RIGHT now in 2021 if you want to skip JS I would say it probably depends a lot on what you want to build. I think for a lot of B2B enterprisey apps that mostly run on Desktop devices Flutter is already a viable option there and generally a much nicer experience.

The performance / accessibility right now isn’t at a level where it would make sense for a bunch of other options but as I mentioned elsewhere in this thread it is barely out of beta by a couple of months. It’s improving a lot at a pretty rapid pace and is built upon solid tech choices and open standards. I think it has a decent future ahead of it.

Re: Photoshop’s journey to the web

#87

Post by softfalcon »

yesco wrote: post #74
anonymousab wrote: post #32

Earlier quoted context omitted.

You only deal with the Steam or EGS or Gog cut if you're utilizing their storefront; if you are just hosting the game on your own site, then whether that game is a webassembly package or a desktop application, you don't have to pay some gatekeeper (other than your file host). Same thing with Android, though there is a bit more friction there.

This doesn't really solve the issues with advertising though. I believe the main reason so many developers want their games on Steam is because of the greater attention they get rather than the distribution side of things. That said, I think the niche of casual remote party games would probably work very well here. During the height of the pandemic my friends and I started doing a lot of "remote game nights" with var…

This is it. What kills a game isn't its platform, but where and how you sell it. Sales and user eyeballs matter more than even what game engine you use.

We use Steam, Xbox Live, PSN, etc not because we wouldn't prefer to use our own store, but because no one cares about anything else.

Re: Photoshop’s journey to the web

#88

Post by dperfect »

wgx wrote: post #4

A polite reminder that the (quite extraordinary) Photopea[0] is available which replicates most of Photoshop's features in the browser, and is free - with a paid ad-free option. 0. https://www.photopea.com/

The fact that Photopea is better than GIMP in so many ways (does GIMP still not have adjustment layers for non-destructive editing?), and was created by one person is a little depressing, but also inspiring at the same time.

Re: Photoshop’s journey to the web

#89

Post by toastercat »

wgx wrote: post #4

A polite reminder that the (quite extraordinary) Photopea[0] is available which replicates most of Photoshop's features in the browser, and is free - with a paid ad-free option. 0. https://www.photopea.com/

Yep, I use this all the time when I need to do some quick image editing. I tried to get used to Krita, but PhotoShops hotkeys and menus were already burned into my brain. PhotoPea does a great job emulating them.

Re: Photoshop’s journey to the web

#90

Post by TN1ck »

jon-wood wrote: post #69
orangepurple wrote: post #57

Earlier quoted context omitted.

No, layout is all CSS with some JS mixed in, and will be for a long time. Webassembly will help accelerate heavy mathematical computations such as canvas graphics.

You could hypothetically use Webassembly to build your entire application around a canvas and either render directly with canvas calls or WebGL, but it would somewhat miss the point of the web unless you're explicitly building a game or something.

This is what Figma is doing for their main UI, they reimplemented everything [1]

[1] https://www.figma.com/blog/building-a-professional-design-to...

Post reply on HN