I've been working in games for the better part of a decade, at AAA scale for the last three years, and this is pure fantasy. It is extremely difficult to develop high-quality games for a console, which has fixed hardware specs and a single vendor for the SDK. Any layer of emulation on top of that creates new problems and dilutes every single aspect of performance, sometimes in unpredictable ways.
On top of that, building things that work consistently across browsers and across time is an extremely cursed problem.
Insomniac Games, makers of the new Spider-Man games, spent several years trying to port all of their development tools and workflows to be web-based and work in Chrome. And then, when they got there, it turned out to be terrible. Google would update the browser and key tools would break and nobody would know why. The tools folks had to work in Javascript, while the majority of the engine was still in C++.
The call was eventually made to migrate the tools back to native exes, which was another multi-year process, but nobody missed the Chrome tools. Clicking a bookmark in a browser turns out to be about as difficult as clicking a desktop icon, and the stability is significantly improved.
If there's a new web game disruption it won't be started by the AAA-games industry, the AAA model depends on big platform owners like Valve, Nintendo or Sony, none of them have an interest in a distribution channel they have no control over.
I'm not saying that WebGL is ready to take on AAA games today, but calling it "pure fantasy" is naive. People will never use a browser on their phones, the internet will never compete with television, electric cars can't take on gasoline, the list goes on and on.
How does Project Anywhere have any relevance to the point being discussed here? It does not run on WASM, it is not performance sensitive, it doesn't really "run" on browser.
Although I do see a future of Gaming on browser. Not everything has to be AAA 3D Games. I want retro 2D Games. Games that were even possible with good old Flash.
Have you actually tried it? I haven't seen a link to try it.
We built https://ayvri.com, and we use WASM extensively (though the public site is using cesium, we've also built our own renderer which is not public).
Also, the original blog isn't only about WASM, that's just one of the technologies making this sort of thing possible.
Canva was built pre-WASM, so photoshop in the borwser, may be better with WASM, but I'd suggest it isn't a requirement.
A, the 'individual example supposed to refute general trend' fallacy...
As if I said/meant that gameplay-based games didn't exist (as opposed that the industry and market has a heavy AAA/get newest GPU/ emphasis).
Not to mention that AAA light on gameplay and full on assets also hire gameplay programmers. It's not about gameplay programmers being busy, or gameplay-heavy games existing.
It's about having many more gamers stop chasing graphics to the detriment of gameplay - or in fact, stop chasing graphics, period.
The kind of games I really like are 4x strategy games, RPGs like Skyrim that have cinema-quality graphics, and highly mechanical games like Rocket League. The mobile equivalent for those games are always hot garbage when compared with the AAA version. The strategy games and mechanical games always fall apart because kbm/controller precision can't be achieved on a touchscreen, and the RPGs fall down because the graphics suck and the screens are way too small.
Well, I'd take Solaris (1972) over any and all Marvel crap too.
And viewers in general would gain much more subtle understanding of the world, appreciation of art, mature emotions and storytelling, exposure to global cultures (not just heroes-in-spandex-Hollywood-commercial monoculture) and lots of other things besides, if they didn't watch Marvel movies and watch arthouse cinema instead.
Or, as we call it here, just "cinema" (it doesn't need a qualifier, we call the rest "Hollywood crap" instead).
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.
>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.
People just don't want to invest/search for random new games on random websites.
For games people want to play, and already have heard about, it wouldn't matter if they are on a website or a "trusted store". If Fortnite was made available to play only from a website starting tomorrow nobody would have a problem using it from https://www.fortnite.com as opposed to Epic's game platform.
And for games sold by big companies, it also wouldn't matter. It's about trust (which Valve or Epic has), not about web vs a launcher/store.
If devs can get that trust, then getting users to play the game on the web is not a problem.
>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.
You also need to download/cache that 1GB or 10GB if you use Valve or whatever.
As for caching it client side in the browser, you can do it as well, either as browser cache (browser vendors will just add the technologies for that), or as locally downloaded assets with direct access granted from the browser (the article already talks about using a new API for mmapping-style access to files outside the browser).
> 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.
No doubt this is partially thanks to the numerous game-like ads that link to exceptionally cheaply made web games. I remember a time in the late 00s and early 10s when browser based games were starting to flower, but then the spammy stuff took over and their popularity dropped like a rock.
I would hazard a guess that the overhead of navigating to a specific site and the clunkiness inherent to browsers being a 1024-in-one multitool doesn’t help matters. It’s nicer to just fire up Steam and have all your games neatly listed, all free of extraneous browser chrome and whatnot.
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.
The "gatekeeper" in this case is Windows SmartScreen. SmartScreen will pop up a scare dialog unless the installer has enough "reputation points" by being popular or signed with an EV code signing certificate (which is a lot more expensive, and hassle to obtain and use than a regular code signing certificate). In any case, for ease of distribution nothing beats an URL which when clicked immediately starts the game.
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 various different kinds of games. However since most of them rarely played games, owned macs and weren't very technically inclined, the games that had the least friction were generally the browser based ones.
Since party games by nature tend to be great at organic advertising and benefit the most from quick easy installs, I think there is a big opportunity here that not many have taken notice to yet.
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.
Chrome has over a billion potential users of a game, and the reason it's so compelling is that fun is just a click away. Local installs of a client can be a thing of the past.
Unfortunately, choosing to not use Steam, GoG, or similar is simply out of the question.
The reality of you selling your game at a profit without the help of one of these app storefronts is improbable. Keep in mind that even if you somehow become successful in this regard, these storefronts have a vested interested in making sure you and your technologies fail.
Edit: apologies if I seem dire, I'm actually on your side and WISH that the world was a free market without all these gatekeepers. Myself, my partner, and many of my close friends constantly battle with these "gate keepers" as game devs/designers and I wish they would go away, but the market (users) love (to use) them even when they hate them.
> Unfortunately, choosing to not use Steam, GoG, or similar is simply out of the question
Sure but that situation doesn't change by simply distributing a webassembly package through a website. Or rather, that situation is no different than if you distribute a desktop binary through your website. In both cases you are eschewing the storefront.
Yeah there's lots of alternatives to the app stores for windows games. You can also just sell direct to consumer.
The real challenge with webassembly as it applies to games (at least large ones) is the asset size. AA - AAA games are 20-100 GB and that can't just live in browser cache.
Also, to be honest building a complex game and shipping it to the web is kinda crap shoot for other reasons. Games are power hungry, and don't want to be limited by browsers. Also, a browser is a massive application that sits around consuming resources that a AAA native game could use.
But of course, I imagine games will be developed differently to take advantage of the web (smaller games, streaming in levels / textures as needed, etc).
The total asset size doesn't matter much (see Google Earth which is probably backed by terabytes of data), but how much new data the game needs to present to the player per second (which means the games needs to be designed for a minspec bandwidth just like it needs to be designed for a minspec CPU and GPU).
It's pretty clear you haven't worked in that industry. Per your logic, no one should have that issue now, you can sell your games on your own site without issue (in fact you can sell your own Steam keys without the 30% fee).
It's a long way from being a usable gaming interface. There's too much "convenience UI" baked into browsers that trips up gaming. Pressed the wrong button? It was a browser hotkey for history-back and you just unloaded the game. Have add-ons enabled? Whoops they are messing up the controls.
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.
Our team is working on exactly this - an asset streaming system developers can utilize for Unreal Engine that only fetches what a players needs to see at any given moment, nothing more.
Combined with compression, you can get players into desktop-quality games in WASM in seconds on most computers.
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.
How would the problem of huge (dozens of GB) graphics assets be solved? Is there a current/planned way to have the large WASM binaries and assets stored on the computer?
I'm definitely not one to advocate web apps that only work in one browser, but Apple is certainly going out of their way to make lives harder for developers who do want to support their browser and we all know why that is.
I saw this on Twitter today also… however, this is after over a decade of taking a very very different approach though mind you. I’ll believe them when we see the outcomes though.
Two very underfunded teams there trying to play catch up.
Only one of them has an excuse though, the other is literally the most profitable company in the world who is strategically trying to make the web into a subpar platform for their own commercial interests.
I'd like to support Firefox with a donation as I'm sure many others would, but I don't trust Mozilla foundation to allocate it to something that actually matters.
I do trust the foundation and make a monthly donation, but those donations are not used for Firefox, and I'm not even sure they legally could be the way the foundation is structured. I too would really, really, really like a way to fund Firefox development. I don't use any of the features they make money from (search partnerships, sponsored suggestions, Pocket), and if I'm forced to I will stop using Firefox.
I don't understand why they can't do a pay-what-you-want model. Keep the browser free, but encourage people to pay $20 or something if they like it. I would.
I think paying for Mozilla VPN would be one way of donating directly to the corp. But that's not a great option unless you were already looking to use Mullvad, and also doesn't signal intent.
Seeing Firefox teams callous take on a critically important Native file system feature [1], it comes at no surprise that major products are dropping Firefox compatibility.
As others already mentioned, funding is just one factor here.
Mozilla decided to stop focusing on porting such applications to the Web before 2020's layoffs, when Mozilla was still growing. The decision came after some management changes, basically: I don't think any individuals changed their minds, just those people happened to leave, and their replacements had different ideas.
(I personally disagreed with the new priorities at the time, and ended up leaving.)
Chrome and its variants have already won the PWA space, not by some brilliant strategy or sinister ploy on Google's part, but by default of its competitors.
The relevant information is presented in the comment section below the bug report proper. If you would like a particular post to be pointed towards, here is one reprinted and slightly edited for clarity:
——————————————————————————————
Dave Townsend [:mossop] Assignee
Comment 15 • 10 months ago
(In reply to Hexandcube from comment #12)
>I disagree, many people have been waiting for PWA support in Firefox. Removing this feature, may result in people (including me, a huge Firefox advocate) switching from Firefox, to a browser that supports PWA. I'm very disappointed.
We already don't have the feature working in any decent fashion so I'm not sure removing it will have any impact here.
>I also would like to see the results of the research, Dave was talking about.
Unfortunately I think that the research is confidential at the moment.
(In reply to joshas from comment #13)
>You should reconsider this decision. It is understandable that currently there might not be enough resources to finish full PWA support, like in competing browsers, but removing it completely will not only make all work done on it a waste of time, but also send wrong signal to some users.
>Leaving feature hidden under flag for enthusiasts to experiment on and, maybe, even submit patches that will nudge it closer to completion - that would be a bigger win, than removing feature altogether.
The signal I hope we are sending is that *PWA support is not coming to desktop Firefox anytime soon* {emphasis: mine}. At this point I don't think we would accept patches to improve the feature so I don't think leaving the code in Firefox makes any sort of sense. Speaking as the developer who spent a good deal of time writing most of the code I am frustrated to see it removed too, but it is the decision that makes sense at this time.
I mean I think they are already in an extremely rough position but if they find themselves in the situation where they are seen as a browser for Web pages rather than Web apps I think that could prove fatal for them.
It’s clear that there is a lot of new tech on the horizon for browsers that is closing the gap with native very quickly.
If they are unable to make that transition which sadly seems like a real possibility then I don’t know where that leaves them.
Of course there are more than 40 full time devs working on Firefox. A quick grep over the last few months of commits of the main gecko repository surfaces more than 200 committers with a mozilla.com email. Keep in mind that some employees don't use a corp address, and that I didn't look at other repositories like the Android specific components or any of the backend services (like sync and push servers). Also add people that work on UI/UX design etc.
Yes there are issues with resources and resource allocations at MoCo, but claiming there are only 40 devs on Firefox is way off.
That's not ideal, of course - the point of the Web is that you can visit a website from anywhere - but in practice, when this type of cutting-edge application arrives on the Web, often at least initially it doesn't run optimally in all browsers or has other limitations. That's been the case with things like Mozilla porting Unreal Engine to the Web back in the day, for example.
In general, after the initial launch things tend to improve as both browsers and applications focus on compatibility.
I'm not at all looking forward the future where "conveniences" provided by operating systems (like consistent GUI styling, preferences, accessibility, etc) are thrown by the wayside and each application effectively re-implements a GUI targeting a canvas "framebuffer".
That day is already here and has been around for quite a while. Even before the proliferation of Electron applications there has been a push away from UI consistency in desktop environments. I believe the reasons are a combination of the following factors:
- Easier cross-platform support easier for developers
- "Branding" concerns
- A philosophy that the app, not the operating system, is central to the user experience; one consequence is there's a strong emphasis on having that app behave as similar as possible across platforms even when the app's behavior violates the platform's UI guidelines.
I lament the decline of the idea of a native desktop with an ecosystem of conformant applications. However, I see the economic incentives for writing cross-platform applications that emphasize consistency across platforms instead of consistency with each platform's UI standards. As long as we have app-centered desktop environments, the only way I see native applications that are conformant to that platform's UI standards being promoted is through market demand. Historically Mac users have shunned software that doesn't conform to the Mac's UI guidelines, though this may be changing in recent years thanks to the rise of Electron and Catalyst.
This reads like an ad for Google and "the Chrome team".
"Chrome has been working to empower web applications that want to push the boundaries of what's possible in the browser"
"Google Docs was a pioneer of this simplified access"
"Early apps like Gmail showed that more complex interactivity and applications were at least possible"
"No large project can be successfully completed without the appropriate tools for the job, and it's for this reason that the Chrome team developed full featured WebAssembly debugging support."
Mind you, I suspect I'll not be alone and by the time Adobe transition to a fully web-based subscription lock-in, Affinity et al will be better positioned to entirely fill the void.
Reminder that many people still routinely pirate software and can generally use downloadable software without paying for it. Going to a Web-only version would eliminate the ability of people to pirate it and use it free.
The present subscription model and the prospect of where an entirely web-based equivalent will lead.
Also, most of the people I know who use Creative Suite have absolutely zero need for any of the recent multi-user / social/web-based functionality. I've never in my twenty-plus years in design needed it and see a decreasing likelihood I would in future either.
I appreciate that ages me and marks me as an old fogey, but.. well, all for the best if competition gets to the point where I can go back to buying single releases every n years, at my leisure, again.
I'm still fond of offline desktop apps (non-expiring ones) and much prefer them over browser-based equalivents.
The debate about the browser replacing desktop applications stretches back to the early 2000s. I was sceptical the browser could complete with desktop apps back then.
Fast forward today and how wrong I was.
I used to believe design and graphics apps would never work in the browser unless extremely limited in features. But even design and graphics apps have found success in the browser (e.g. Figma, WebFlow, Canva).
Figma in particular is enjoying huge success and poses a challenge to desktop apps Sketch (Mac-only) and Adobe XD (Mac and Windows).
> The present subscription model and the prospect of where an entirely web-based equivalent will lead.
Aka the fact that, regardless of payment model, the latter is basically un-crackable. Photoshop has maintained some popularity, in spite of the SaaS move, because quite a few people can still get it by "sailing the high seas" (some of them pay for a while and then crack, others just get good ol' "releases"). I'm not so sure that turning off that tap for good will be a net positive for Adobe, but I guess we'll see.
Really interesting how the browser is becoming the universal OS. It sort of gives more power/control to Google and reduces it from Apple and Microsoft. Would love to be in the executive meetings where they discuss the implications of this.
Really interesting how the browser is becoming the universal OS
Firefox spent 2011-2016 creating a browser-based operating system called FirefoxOS (for smartphones). I used to think it was a terrible idea and a waste of Mozilla's resources. Now I wonder if I was wrong, and perhaps it was a good idea - but simply too early and too immature?
I understand the desire to leverage the technologies and talent we've invested into the Web, but as a platform it still reeks of its roots as a tool to display remote hypertext documents, and I would personally prefer to write "native" apps in a more tailored and coherent API and runtime environment.
Is this something to be worried about? I also see more and more things in the field of geography , especially data visualisation, to start living in browsers and most people default to Chrome.
Yes, it is something to worry about. It's wresting control away from users via their no longer able to run native applications. And it's only going to continue with the continuing new generation of programmers who know nothing but JavaScript continue to implement everything in JavaScript because they've never known a world that doesn't have JavaScript.
Native applications already have subscription models so I don’t get this.
And are mobile apps running in locked down OSes truly “native” either? Whether they’re written in WASM or Swift, if they are locked behind an App Store subscription, whether they’re downloaded and stored on the device filesystem permanently or downloaded on the fly and cached as needed is irrelevant as the end user still lacks control and you still end up with an uncrackable walled garden.
There some bizarre notions associated with “native” here which I don’t think have anything to do with control over how people run stuff.
Likewise, why is a world where most people learn JavaScript any better or worse than a world where most people learn Swift?
There’s never going to be a world where no minority languages exist and frankly, the more “pro” languages which have fewer users end up paying more $$$ as they are perceived to require more expertise than scripting languages. Seems like a win/win if concerned.
We once celebrated the Web and the idea of ephemerality, portability, “view source” and inspect, etc and now somehow we’re back to people wanting installable binary blobs locked into app stores as somehow superior.
> We once celebrated the Web and the idea of ephemerality, portability, “view source” and inspect,
Back when the web was mostly traditional websites and documents, not apps.
> And are mobile apps running in locked down OSes truly “native” either? Whether they’re written in WASM or Swift, if they are locked behind an App Store subscription, whether they’re downloaded and stored on the device filesystem permanently or downloaded on the fly and cached as needed is irrelevant as the end user still lacks control and you still end up with an uncrackable walled garden.
They're native if they're running on a native runtime, which is optimized for the device and has full access, instead of the more limited browser.
> Likewise, why is a world where most people learn JavaScript any better or worse than a world where most people learn Swift?
It's better if one language doesn't completely dominate the application space. Same issue when Java was all the hotness, and people thought everything was going to run on the JVM.
What do you mean by full access? Native apps on platforms like iOS and Android run within containers that present a narrowed view of the full platform.
If you take a “native” library like QT or wXWindows or even OpenGL do you have “full access”? Any cross platform abstraction or portability layer will remove power and access.
Do we really want to argue for a world where all software is written as if the target is a game console to the metal, even when 90% of apps don’t need it?
Yes. But it is mostly too late to doing anything. The move to the browser has been happening for years.
As an example, look at ChromesOS - a cloud operating system (OS) that tracks and records all your activity the moment you sign in. A Google account is required to use the full functionality of the OS. It is used by millions of schoolkids with all the privacy implications that entails. Somehow, Google's promise to never build profiles of their school users is enough to placate developers. In fact, developers are more likely to defend Google rather than question or scrutinise the privacy implications of using a cloud OS.
Google must be gleeful they've captured a whole generation of US kids to use Google services through the ubiquity of ChromeOS in US schools. And without any dissenting views from developers on the matter either.
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.
My name is Ivan Kutskir and I am the only developer of Photopea. I am 27 years old graduate of the Charles University in Prague. I live in Prague, Czech Republic, but I was born in Ukraine.https://blog.photopea.com/creating-photopea.html
He (Ivan Kuckir) has been building this online photo editor for 7 years now, and it’s paying off. Last year (2020), he broke the line of $500,000 ARR, and it’s still growing.
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.
The main trouble with GIMP (and Inkscape) is lack of first-class CMYK, making it irrelevant for any print-targeting activity. Otherwise the features have advanced in the last few years and the coherence is not bad, the photoshop crowd being in the same ballpark for me.
You know what's more than little depressing? That each time any similar topic comes up you don't have to scroll down very far to find someone in the comments that will bash GIMP for some random thing.
You're comparing an ad-supported/subscription web service making a good part of 6 figures per year with software maintained largely by volunteer work for the past 20+ years.
I apologize - I truly don't mean to bash GIMP and I appreciate all the work the volunteers have done. It has come a long way and appears to be getting better with every release.
My reliance on adjustment layers and non-destructive workflows probably doesn't represents the majority of GIMP's user base, and that's ok. I can't really use it seriously for photographic retouching until it does have that, but I'm glad other people get a lot of use out of it, and the other features that have taken higher priority surely make sense for a great number of those people that do use it regularly. I hope that drives more usage, donations, and development.
Nomen est Omen, with a name like GIMP what can you expect.
I mean, the software name is literally slang for a disabled person.
Why don't they start from changing the name I don't understand.. Open Source projects have these odd ways of just sticking whatever somebody came up in the late 90s and rolling with that.
Yeah I know that.
But do the people looking for a professional photo editing program know that. I'm just saying if you want to make it big or attract developers, maybe naming your software Gimp is not the best thing either..
A lot of the best software is made by one person. Large codebases and organisations have significant inertia that make producing good stuff hard. You’ll also get greater deviation from the mean in a single developer (so a lot of the worst software is also made by one person).
I wonder if this was what spurred it! A few years ago a free fan operated RuneScape server running an old version became more popular than the actual game. Jagex asked them to shut down, but they also launched their own version in kind: OldSchool RuneScape.
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.
polite thank you -- not sure if I checked it out in the earlier days or something but hadn't been back and stunned at how GIMPy it is (in a good way). And totally jump-right-in useable. Impressive.
Most people use less than 10% [1] of what Photoshop is capable of. It is the subset of features that is used by 90% [2] of people that Photopea covers. That means Photopea could take 90% of the market share of Photoshop, which is pretty good return on investment!
[1][2]: Like in the parent's comments, all percentages are made up.
I can see Illustrator and Photoshop running on a browser but I doubt we'll see After Effects and Premiere on WASM any time soon.
IMO the solution will probably be a combination of browser based UI and cloud based processing. The drawback of this approach is that the server would need to host the project files.
WebCodecs is available since the latest Chrome, so it is now possible to use hardware accelerated codecs from the browser. Instead of uploading & downloading GBs of data and paying for someone else's processing power, you can do everything locally as long as you don't mind a few limitations.
(still plenty of minor bugs, I was planning for a proper Show HN soon)
Also because both the preview and the rendering is done with WebGL the result is guaranteed to match what you see while editing, unlike with some cloud-based editors where a different stack on the rendering backend is trying to replicate what the browser is doing with js+css
Somewhat tangential, but if people are looking for an After Effects / Premiere alternative, I highly recommend Davinci Resolve.
I can only really speak to the editing, but it seems leaps ahead of premier in a lot of ways. Very quick for scrubbing through 4k footage (even the free version) and far more intelligence when it comes to certain jobs (eg throw a folder of RAW photos in there to make a hyperlapse and it'll recognise them as a sequence and let you treat it as video).
The free version contains 90% of the features and is completely free - even for commercial use. The studio version is a one-off £250 (two seats) with free major and minor updates for life. It ran on Linux before it could even run on Windows and has just been optimised for M1 Macs.
Considering Adobe wants £238/year just for Premier (editing) or £600/year for the whole suite if I want After Effects (Resolve has "Fusion" built in for sfx, though admittedly the CS suite has far more to it than just that), for my uses it seemed like a no-brainer. And I got a free editor keyboard (£250 retail) when I bought the license.
My only annoyance is that Premier is so ubiquitous that you can need a license to be able to open projects from other editors. And that also requires you're all on the same version as the file format gets bumped every version (infuriating if you've deliberately stayed a version behind because it runs better on your older hardware). I find it quite ironic as the two big Premier users (companies) I know will do their final cut in Premier, render it and then throw it to a colourist who imports their final video into Davinci for colour grading anyway.
One of them already has plans to transition across for the edit, but as they have decades of combined experience working with Premier, it's a difficult if not dangerous decision to deliberately loose productivity whilst people retrain. If you're just starting out, especially at home or in a small team, then the idea of starting with Premier seems crazy.
For anybody thinking of getting the Davinci Resolve Studio (full version), you can buy the hardware editor (Davinci Resolve Speed Editor) and get Studio for free. The hardware is the same price as buying Studio on its own so it seems a no-brainer.
An offline-first web version of AE/Prem is what we're working on @ Vidbase. Internally, it works today better than the desktop apps imo. Others are working on similar tools as well.
I'd actually like that. Like running a jupyter notebook on a beefy server somewhere. Biggest issue is probably that one still needs to be able to quickly seek in the movie, and watch rendered results in correct resolution without too much delay/downloading. But that delay could in practice end up being shorter if the server is faster at rendering.
And once everything is running on Chrome, oops we mean uhh the open web, we'll be able to track everything everyone does all the time, without pesky cookies!
People sometimes talk about how crypto / bitcoin will decentralize things, but honestly we just need a better culture of native software. One that brings the best of what modern user interfaces and collaboration have to bring without the headaches of multi-OS development.
Really cool to see what's possible in desktop browsers these days. Photoshop coming to our browsers is a huge achievement and milestone.
But it also makes me kinda sad that none of the mentioned examples properly work on mobile. If even big web companies can't pull that off, is it impossible? (Mainly thinking about Gmail and Google Docs here). Or have we given up on web applications on mobile?
I’m fairly certain the reason that is currently not officially a thing is due to Safari on iOS missing a huge chunk of features that would have made that possible. They spent over a decade by this point intentionally underfunding that team while maintaining a browser monopoly on their platform under the guise of “security”.
That seems like it’s very slowly starting to change perhaps.
Google could have made Gmail to work on Chrome (just on Android) as a show case what would be possible on a good browser. It's true that Safari is lagging behind in features, but I don't believe it's the only reason.
Its not impossible. I think the biggest issue is that many of these ported web apps don't use the DOM for their UI. This makes it a much more difficult task creating responsive UI.
Someone did a really funny presentation on all apps moving to the web and then eventually OS's, followed by OS's running on OS's on the web. If anyone know's where I can find it I would really appreciate a link!
It's pretty relevant to this seeing as it does seem to be where we are going.
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.
Yeah, I actively avoid web.dev becauee every time I read something there I end up being steered towards another Chrome-only nonstandard feature. MDN is always clear about what's supported where and when features are Firefox-only, it clearly warns you and provides alternatives and fixes for other browsers.
You can still get pirated versions of CC everywhere. Adobe didn’t act like they had the benefit of their users in mind in recent years, so there’s no reason to give them the benefit of the doubt.
If your reason for not wanting web is "I can't pirate it anymore", I don't have a lot of sympathy for you. And it's probably not even true. With a web app like this which is mostly client side, it will probably become possible to rip it and host it on non-Adobe servers or package it up with a local web server. Especially if they offer an offline mode. I imagine pirate groups are already starting to think about building tools for this.
I‘m not condoning piracy (cue for exceptions like defunct license servers), I merely tried to ponder why I don’t think this change is for the benefit of the user and what its purpose is. I don’t know whether it will be as easy to pirate, but it certainly is a step to give users even less control over their (the user’s) software.
There are a lot of casual users that the business model doesn't address. If you're a pro artist then CC is just a business expense and your clients pay for it. If you're not it's really hard to justify spending that amount of money for software you use once or twice a year. Don't forget the piracy to pro pipeline either.
I am still able to run my copy of CS6 without problems thank God... I had to do some tweaks to get it to run on Windows 10 though. Not upgrading to Windows 11 until I have to because I hear that is even more designed to force users into mandatory software updates by creating new incompatibility with older apps.
It's really future OS updates that threaten that.
There have been no major advancements in PhotoShop for my needs that really warrant an upgrade. No added value. I paid for CS6 long ago, and it should run properly without artificial disruptions indefinitely, because that is how it was marketed to me.
Did you purchase the Master Collection Suite? If you so, is CS6 still viable for commercial-level work? Have apps aside from Photoshop CS6, like Premiere and Flash Pro, continued to work? Do you have any issues with plugins?
I think what they're saying is more or less true, though they're obviously putting a spin on it. This is them trying to catch up to what professional teams already expect, and what "prosumers" are increasingly expecting. Teams that collaborate on art and design, or who have to deliver assets to other people, moved to the web a few years ago. It's so much nicer.
I also believe them when they say performance was an issue that kept them from doing this until now: the fact that the Photopea guy can do a large subset of Photoshop's functionality in the browser is astonishing, but power users expect a lot more, and wouldn't pay Adobe's organizational licensing fees for anything less.
Yes, this will allow them to enforce their subscription model more tightly, and likely push all kinds of new monetization at users. You're right about that part, I just don't think it's the only reason.
I've never met anyone who couldn't grasp the idea of programs running locally on a computer. Practcially every user of Android/iOS will understand it intuitevly. Back in the day anyone of all ages and abilities I knew on 90s-2000s hardware could download and install programs. Anyone who couldn't honestly wouldn't get much benefit from a computer.
Indeed, the convenience argument is just a pretext. They long to see the back of the days when you could buy Photoshop 7.0 for a one off fee and still use it today.
I see these comments in virtually every web app thread that there is, and it's immediately clear that the people making them have never worked somewhere with a vaguely incompetent IT department (most companies). There are companies where adding a new application to the image/getting IT to install it requires forms, waiting, and sacrificing a small animal. Those people are also not paying for it and thus don't care at all how much it costs.
I was referencing my experiences of the average computer user in that time peroid, which was mostly but not exclusively home PCs. They managed. And I know nowadays many of them hate the constant UI changes and sluggish JS browser apps.
But as to organisations, if it is that bad, it sounds more like an exacting support contract or overly bureaucratic processes. (Or how things are in the public sector.) In either case, if the company makes the process of getting its work done needlessly tedious, then it deserves to founder and give way to the agile competition.
It is really unfortunate if this is a main reason that webapps are so popular with all their bloat, wastage and transience.
Subscription pricing models are hardly unique to Adobe. I can’t even find any decent accounting software that doesn’t require some kind of a subscription. It’s pretty common, for better or for worse.
I'd like the answer to be “yes”, but at this point if you need to ship software I'd say “no”. There are wasm counterparts to React (my favorite right now is yew.rs), but they're self-described as not production-ready. Overall, the tooling is just much more developed on the JS/React side. Unfortunately.
That said, you can get plenty of mileage out of using React as a frontend and wasm for the application core. I believe this is what Figma does. And you can sidestep the DOM entirely and use your own UI renderer, which seems to be what Adobe is doing here. https://makepad.dev/ is another (absurdly impressive) example of that approach, but that's a very involved approach!
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.
I felt the same way my desire to learn a new language was somewhere between low and none at all.
I’m happy to say when I’m wrong though, it ended up as probably my favourite language of all after not too long.
It’s often described as the love child of Java and JavaScript where they took the best from both and got rid of the most hated parts of both too. But it ends up as a really nice and performant language to build apps in and is supported by a lot of amazing dev tooling to make life easier.
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.
Just because something is doable (running a complex app such as an OS or Photoshop or 3D Max in a browser)- doesn't mean that you should do it.
Also, I'd rather own the application (and run it on my computer) and my data rather then rent the application and depend on a company to have access to my data.
I, for one, do not like this. Software that doesn't exist on your computer, but instead gets ephemerally downloaded from a server somewhere when you wish to use it, is about as anti-user-freedom as I can possibly imagine. I can ony hope this doesn't become the standard.
I would love to see Photoshop in browser as a self-hostable option. I have many tools setup on my LAN and slowly been porting applications over to my local server so I can access all my applications on all my devices.
Nothing too crazy but makes my work flow easy to swap between locations. I got VSCode server, PHPMyAdmin, Transmission (Web based torrent client), DIY Youtube downloader client, DIY video editor, A bunch of service managers, and a couple more things.
It's basically a whole developer suite with remote processing. I could do AI training on my cellphone with this setup if I wanted.
I've been working on a DIY spotify clone for a media player.
It makes it really convenient having all my files on a central server, so I'm not juggling drives, and copying over data.
As well, it's automatically backed up weekly so it's always safe.
I’m not sure if you’re only accessing applications through a browser in this case but if you’re using Remote Desktop then why not Gimp or similar FOSS alternative?
Oh no, it's all in-browser apps. I use it when at work by connecting to my server through chrome and using those apps. We only have chrome access at work, in fact all port besides 80/443 are blocked.
How does an app like Photoshop protect its IP when algorithms are compiled in webassembly and downloaded to the browser? Or do they hide away the secret sauce behind service calls?
Biggest difference is probably more people have the means to debug something when it runs in the browser. So technically the same, but it may be more available to look at.
Near native performance, players can join with just a link, and no 30% cut that developers have to deal with.