The case for frameworks

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.

the framework/bespoke complexity/effort graph in this article is one of the most brazenly untrue graphs I've ever seen.

frameworks are all low-effort fun until you need to do some Hard Problem that they can't handle well, then suddenly the effort shoots up massively, because now you're trying to figure out how to do your hard problem within the structure and using the primitives of the framework.

bespoke solutions start off high-effort because you have to reinvent the proverbial wheel, but then as you keep rolling, it gets easier, and you have something that is better-architected for your exact problem. when the same kind of Hard Problem arises, you can solve it much more easily, because you're unburdened by trying to shoehorn the solution into the structure and primitives of someone else's framework.

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.

I've literally never experienced this with react. This sounds like an infinite loop of some sort.

> This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal

The point is that it's better to depend on something simple and quickly fixable than something convoluted. Vendors/sponsors can and do go away.

If you have a skilled API builder, they know how to do KISS. If a specific need requires something that's not KISS-able, such builders will be honest about it and recommend a pluggin. But every shop and domain is different such there are indeed cases where throwing libraries at the problem is the right tool for that particular job.