[chrsjxn]

It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery.

jQuery allows for websites to be interactive with minimal latency, but it's pretty low level so it leads to a lot of common problems. Like locking the main thread, undisciplined architectures, and a ton of issues with back/forward navigation.

SPA frameworks are developed to solve jQuery problems, but they introduce some new ones. Everything being JS is a big win, compared to split apps. But you have to deal with the up front cost of loading all the JS and a higher memory footprint.

And we iterate. SSR frameworks tone down the up front cost of SPAs in favor of more complex infrastructure. Frameworks that deploy to edge networks take another bite out of latency, but it isn't entirely clear what that will mean long term.

It feels so iterative that blaming framework popularity on malice is wild. There are real benefits to businesses, developers, and customers at every step along the path. Of course developers are going to follow along.

[crabbone]

Let's look at it from a different perspective. Web wasn't meant to be an application platform. It accidentally became one, due to events that had nothing to do with technological merit, but were social in nature.

For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be. But, it failed due to Adobe's bad market strategy. But Flash, too, was a band-aid on top of broken tech. It was obvious that Web was not meant for what Flash was trying to do, Flash was just better at overcoming the problems than HTML+JavaScript is.

Web frameworks aren't here to add value, they are here to patch bad foundations. To deal with "defects" (or, rather the consequences of unintended use) of HTML and JavaScript. So, they will inevitably be bad, because they are trying to fix the problem they didn't create and that is beyond their power to fix. And as long as Web stays the application platform of choice, Web frameworks will cause a lot of resentment amongst their users.

[mejutoco]

> For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be

Flash was very nice for some use-cases, but it leaked memory. It is not a good fit for long-running apps (probably why Flex/Adobe Air failed, too).

[thoughtpalette]

IIRC it also wasn't good for screen readers and accessibility.

[crabbone]

Yeah, that's true. Flex, however, dedicated some efforts to accessibility. But, developers didn't want the components Flex had to offer. Custom stuff almost never implemented accessibility interfaces.

This also impacted how search worked. At the time of the sale of Flash to Adobe, either Macromedia before the sale, or Adobe right after the sale donated a "headless" version of Flash player to Google in hopes that they'll make something of it, something that'd help with searching within Flash applets... I don't know the details, but I know that the project essentially failed to even start. That player never received any updates, and Google wouldn't search inside Flash. I think, the real reason was that it was just way too hard to search inside Flash due to the very dynamic nature of these applets. Pieces of text would often appear in very small chunks, random order, impossible to tell if visible or not etc.

With HTML and JavaScript, eventually Google faced the same problem, and that's how they came up with Chrome. For some reason they decided not to make their own player.

[crabbone]

That's a very bold claim about technology in general... Did every version of Flash player ever leak memory? -- I seriously doubt that. For practical purposes, even if there were leaks, Flash applications weren't supposed to run for more than few days on end, at least not until AIR came along and Flash expanded into the desktop world. The longest-running applications were browser MMO games which some gamer fanatics would play for several weeks in a single session. Even in this context, some other problems would prevent users from experiencing the adverse effects of memory leaks (usually, the game would crash due to some programming errors of the game developers, not because of the player).

Anyways, suppose for a moment that every Flash player since ever had a leak... well, Adobe's Flash is a relatively small C program, so more Valgrind tooling and more work would eventually had that fixed. It's not a flaw of technology in general, just a particular implementation. (There used to be GNash, and there's still Lightspark implementing the same technology).

> long-running apps (probably why Flex/Adobe Air failed, too).

I happen to have a bit of an insider insight here. I was on Adobe's CAB for about a year before they handed Flex over to Apache.

Long-running apps weren't a problem. Not enough to be ever mentioned in that context. The problem was in how the product was managed, in the misunderstanding of how to derive value from it.

Adobe wanted to sell two things:

1. Development environment (Flex Builder later renamed Flash Builder).

2. Services in development of Flash-based applications to enterprise users. (Think of VSphere Web console or some hospital interface etc.)

In both instances they made a bet on Flex. This was also the biggest argument in favor of buying Macromedia when Adobe bought it. Flash was hugely popular and growing and especially due to Flex which was a lot more appealing to developers than previous authoring tools.

What Adobe failed to realize is that the thing that made the technology popular ware these characteristics:

1. A tool for creating hand-made animations.

2. Very light-weight baseline components.

3. Video streaming.

The first two enabled indie game developers and small-scale e-commerce developers to create appealing products. And these were the absolute majority of the users of technology.

Adobe didn't do anything for their largest user group. They were working on a framework that grew slower and heavier by the day, and was, in its core, designed to mimic WindowsForms. They, essentially, were making a Web version of WindowsForms. The tool that they were trying to sell didn't support direct editing of animation, didn't even have a concept of timeline, no drawing tools etc. You were supposed to make your animations elsewhere and bring them pre-compiled into this tool. The code editing was so-so... an Eclipse-based heavy-weight plugin very much constrained by the abilities of the host. They tried to make "designer" view, similar to one that exist in MSVS, but that project failed due to lack of demand on the user side and lack of attention on the developers' side...

Adobe didn't allocate enough efforts to maintain the open-source code they had. At some point there was literally no one maintaining the MXMLC code. And then they made repository read-only and stopped accepting merge requests from community (there weren't many anyways). On the community part there was a growing disappointment that part of the toolchain always remained proprietary and that cheaper automation that could be run on Linux was always broken.

And then Adobe decided to dedicate the remaining development effort to the product you probably never heard of: Flash Catalyst. It was supposed to be a kind of an extension to Flash Builder, more geared towards animations and... mobile :D At that point, Flash was already on its last legs, and Apple dealt it final blow by completely disallowing it on its devices. Catalyst was scrapped. Adobe allocated the bare minimum of development effort to keep patching the player with security patches and hastily arranged for Flex to be handed to Apache.

I don't think that even after all that happened they learned about the reasons of the failure. Guess, most were bitter about Apple, but that's about it. They never realized that they failed to understand who their community was and how much it was important to support their community if they wanted their technology to live. They took the community for granted and tried to capitalize on popularity, but popularity disappeared because they took their community for granted.

[mejutoco]

> at least not until AIR came along and Flash expanded into the desktop world.

Sorry if it sounded arrogant. At the time I was developing a display application for hospitals (showing what is in each floor, etc. on screens), and our prototype was running 2 instances of it, and killing one and switching to the other to keep this memory leaks in check (horrible hack, I know). It was nothing too fancy, and it was still causing memory leaks when run for a long time.

I believe these were already the Air times.

Maybe it was not on each Flash player version. I found a couple here as an example:

https://blog.gskinner.com/archives/2005/10/major_flash_pla.h...

https://www.reddit.com/r/RotMG/comments/19kc4u/memory_leaks_...

[crabbone]

I worked on a browser MMO game TimeZero. It used to be the second most popular game in Russia in early 2000's. Had about 5000 online users and ten times that much of active accounts. We had a lot of different problems with Flash player, but memory leaks weren't a thing.

Grant Skinner was a... popular person in Flash community... but, you also need to understand that Flash community, almost entirely, was amateur programmers. Looking back at those days, I feel the same kind of light embarrassment like when I thought I'd discovered some new fundamental theorem in algebra when I was in mid school only to later learn that it's something we'd learn about a year later.

So, what he discovered can be summed up as "works as intended". It's not a memory leak. His mistake was literally:

> function variables are transitory – they should only exist during execution of the function.

He's both confused between variables and values, and believes that common behavior is the only possible one. It's easy to make this mistake if you never work with entities like, eg. sockets or threads and similar system resources that have to be explicitly released by the program because the system that created them doesn't track their lifetime.

In other words, that's not a memory leak. A memory leak would be something like if BitmapData.dispose() didn't actually free memory.

I believe that the reason for this kind of behavior was that BitmapData would be also implicitly used by the player's own rendering layer which had to be explicitly instructed to remove it, if the program no longer needed it.