It’s March 2010 and everyone you know is playing FarmVille. You’re a little ashamed to admit it, but you also enjoy playing from time to time. FarmVille is a Flash game that has gone viral on Facebook, and Zynga, the studio behind it, is on the verge of going public.

At that time, there were around 2 billion users on the internet, and 80 million were monthly active FarmVille players. Facebook was just one of many sites hosting Flash games, if you count others like Newsgrounds, I wouldn’t be surprised if the total had reached 100 million monthly players. That was 5% of all the internet users. Wild! But I doubt we’ll ever see anything like it again: it was the peak of casual gaming in the browser.

One month later, Steve Jobs published an open letter called “Thoughts on Flash”, effectively dooming the web as a platform for game distribution.

The iPhone took over the world and smart phones became the dominant gaming platform. Flash was dead, and HTML5 wasn’t ready, but more importantly, mobile changed the distribution model for games. If you were a developer looking to reach an audience, your best shot was getting into an app store. And speaking of stores, Steam was about to explode in popularity, porting the store model to the PC too.

Fifteen years later, driven by a bit of nostalgia, I wanted to explore whether the web could be a viable platform for games again. Here’s what I found:

The good

The good news is that you can build pretty much anything. The web has now more APIs than Flash ever did. To me, the biggest upsides are:

• Distribution: The web is unbeatable here. I send you a link, and you can play my game. No downloads, no installations, no stores required.

• Cross-platform: Porting games across platforms is one of the biggest headaches. The web, despite its historical quirks, is pretty good at this. And with Electron and Capacitorjs it’s easier than ever to create builds for any store. But wait… why would you want to do that? Wasn’t the web the ultimate distribution platform? I’ll revisit that, because it’s not so simple.

• Layouts: Game UI is one of the least fun and most underappreciated parts of development. Making layouts responsive to different screen sizes can be a huge time sink. But the web has great layout primitives, specially with grid layouts. You can define your UI as a set of constraints and let the browser take care of the rest.

• DX: Tooling is pretty good. With tools like Vite, you get instant hot reload and fast build times. The browser’s inspector and debugger are solid and you can use Typescript, which is a pretty good typed language that can speed up a lot development. I know, I know. It’s not C#, but it’s not GDScript either.

• SVG: Vector graphics are lightweight, scalable, and easy to morph. Flash started as a tool for animating vectors, after all. SVG can do much more than most people realize. You can animate with CSS or SMIL, and filters (your “poor man’s shaders”) let you pull off some really amazing stuff.

The bad

Now for the rough edges, things that’ll make you question choosing the web as your game-development platform. A lot of these issues stem from the web’s greatest strength and weakness: high-level APIs that abstract complexity but limit access to low-level control.

• Performance: It’s gotten better, but performance is still a concern for certain types of games. JavaScript isn’t the fastest language, and more importantly, it’s single-threaded. You need to be clever to avoid jank. That usually means leveraging Web APIs to offload as much work as possible to the GPU (WebGL, and eventually WebGPU). A lot of animations can run on the GPU, but more on that below.

• Animations: I was pleasantly surprised by how smooth and easy animations are. You can get 90% of what you want without much optimization. But for the remaining 10%… it’s just either not possible or a pain to work around. Thankfully, browser dev tools offer great insight into why your animation might be dropping frames. I stuck with plain CSS, no Motion, no GSAP, not even Web Animation API, and it handled all my needs.
  

  

• Sound & Music: For some reason, I just couldn’t get sounds to be as snappy as I wanted. That’s frustrating, especially for certain actions that need instant feedback. Also, because autoplay is forbidden on the web, users have to interact with the page to unlock audio. I also had some issues with Safari, but Howler helps by smoothing out cross-browser quirks. Combine it with audiosprite, and you can juggle multiple tracks and transitions fairly easily.

The ugly

These aren’t deal-breakers, and they’re not outright bad either. Just how things are in 2025. Ugly.

• Ecosystem: You can’t talk platforms without talking ecosystems. A platform is not just a bunch of APIs and tools, but everything around it too: tutorials, articles, third-party plugins, integrations, community, etc... And the reality is that in 2025, there is a platform that is overwhelmingly dominant, and that’s Unity. Sure, Balatro was built in LÖVE, and Animal Well was famously rawdogged in C++, but you can’t ignore the sheer gravity of Unity’s ecosystem.

• Distribution (again): I leave this one for the last one, because for me, it was the bitterest lesson: Game distribution is ruled by Aggregation Theory.

• Consoles: My game was mostly targeting mobile and PC, since that’s were my target audience is. I haven’t explored consoles at all but my guess is that porting to different consoles is harder or impossible for web-based games.

App Stores and Aggregation Theory

One of the internet’s core lessons is that whoever aggregates demand controls the supply. This can be either by virtue of user experience (you prefer buying on amazon) or channel control (you don’t have a choice on iPhone).

Ben Thompson from Stratechery called this framework Aggregation Theory:

[...] First, the Internet has made distribution (of digital goods) free, neutralizing the advantage that pre-Internet distributors leveraged to integrate with suppliers. Secondly, the Internet has made transaction costs zero, making it viable for a distributor to integrate forward with end users/consumers at scale.

This has fundamentally changed the plane of competition: no longer do distributors compete based upon exclusive supplier relationships, with consumers/users an afterthought. Instead, suppliers can be commoditized leaving consumers/users as a first order priority. By extension, this means that the most important factor determining success is the user experience: the best distributors/aggregators/market-makers win by providing the best experience, which earns them the most consumers/users, which attracts the most suppliers, which enhances the user experience in a virtuous cycle. […]

How does this apply to games? Demand is fully aggregated on every major platform. Want to sell a game? Good luck avoiding the stores. Steam rules PC, and the App Store and Play Store dominate mobile. Players simply don’t buy games elsewhere. Sure, there is itch, but expect niche traffic at best. […see edit below]

Final Thoughts

Whether or not to build on the web really depends on your game’s complexity. For a casual or mini game, the web is likely the better option. You’ll move faster and be more productive. But for complex games needing low-level access, you’ll waste too much time fighting the platform.

I’m glad I explored the web as a platform for my casual game. It’s a viable option, and I wish more people took it seriously. But unless you already have an audience or stumble upon a novel distribution channel, don’t get your hopes up. This isn’t 2010, and no one plays FarmVille anymore.