> That was most definitely not the primary selling point of Chrome.
It was very popular, especially for people who did support or were the “tech guy” for their friends & family. Chrome had multiple nice features but the one which most frequently got people to switch permanently was not losing all of your work when Flash crashed. Not having to tell people that the big comment they’d been working on for an hour was permanently gone because some ad in a different windows crashed Flash lead to a lot of installs.
This was especially bad for anyone developing in Flash because Adobe was motivated to sell licenses and only cared about reliability to the extent that it impacted sales. Their vision was that instead of using web technologies you’d target Flash and run things maybe on the web, desktops, mobile, or set top boxes but always Flash. The problem with that was that they mostly focused on shiny new things which demoed well but didn’t spend money on QA or support. I shipped a couple of Flash apps in the 2000s where we hit basic bugs in their library code, and the support process was basically that you filed a bug report with a ton of details, didn’t hear anything back until the next major release, and then the issue would be automatically closed with a generic suggestion that you try buying the new version and reporting if it wasn’t fixed. $800 later, you could repeat the process as they never once fixed a bug even with a simple reproducible test case.
Flash did things "web technologies" didn't. There was no module system, no React, no custom elements. JavaScript was a bit like bash: usable for simple things, but only masochists would use it for anything complex.
The early Google web properties - Maps and Gmail - were the vanguard of the web as an interactive platform. As I recall, they were actually written in Java and translated to JavaScript (by GWT) in part because of how limited JS was as a platform at the time.
To this day, there are things that's were easy in Flash that are borderline impossible on the web. The dual paradigm of drawing when drawing is easiest and coding when it isn't was really powerful, and the modern web still misses that.
I was thinking the other day of making a button that transitions into a throbber when you click it. Would have been a fun afternoon project in Flash. Would be a couple weeks of math homework in JS.
> As I recall, they were actually written in Java and translated to JavaScript (by GWT) in part because of how limited JS was as a platform at the time.
GWT - at least the opensource version - came a few years after Gmail launched. I’m pretty sure gmail and other Google products of that era were written using the Google Closure compiler. Not GWT. (Not to be confused with closure the language).
The closure compiler was written in Java, but it was a JS-to-JS compiler similar to a js bundler, minifier and the typescript compiler all rolled into one. Its input was (is) a semi-typed JavaScript dialect where types were put in special comments. It has a lot of code analysis & optimisation tricks that I think still aren’t present anywhere else in the JavaScript ecosystem. And it came with a batteries-included standard library that was really needed at the time, to both pave over browser differences and provide a lot of missing functionality. (Js was a scrapyard back then).
I’m surprised the closure compiler never saw much use outside of Google. It was a lovely piece of software for its time. It’s opensource - but nobody seems to know about it.
This is true. Especially before HTML5's canvas, video, and audio elements were standardized. Things have gotten so much better now with the advent of the Web Animation API also.
As powerful as Flash was though, sometimes that power was misused. I remember websites with slow intro animations that you had to wait to load before using the website. Flash also powered some of the most annoying advertisements I've ever had the displeasure of viewing.
Oh, sure, I wasn’t saying that Flash was entirely without value - we all used it for a reason - but simply that it wasn’t a web native technology. That proved to be its downfall: the entire ecosystem depended on the whims of a company which just isn’t interested in supporting platforms, and that proved to be fatal in the end.
That's a longer answer than I have scope to type right now…
The short version is the seamless interplay between drawn and coded objects. The viewport was called a Stage (Illustrator's equivalent is the Artboard). The Flash tool had all the vector drawing goodies you'd expect. Everything you drew on the Stage was a DisplayObject. Everything you coded was also a DisplayObject. Things that were easier to draw than code, you would create in the Flash app. Things that were parametric (e.g. you want 200 of them, or you want to explain in code how a thing moves), you'd code. You could easily import drawn assets into code, or drag visual containers for coded assets onto the Stage.
Modern JavaScript does an okay job at the coded aspect of it, but first class support for hand-drawn assets is totally missing. SVG (Adobe's attempt to compete with Flash before they bought it) can handle still images, but nothing is seamlessly multi-modal like Flash was.
The other thing Flash had going for it that nothing else does is animation. Even today, motion designers are stuck using After Effects (a tool designed for movie titles and broadcast news graphics). We still don't have a good tool for making interfaces that move, which means our ability to make properly interactive interfaces was severely knee-capped when Flash was removed.
So Flash let you draw and animate at whatever level of fidelity you wanted - draw an arm, animate a progress indicator - and use those assets seamlessly in code. Or code the parts that are painful to draw and lay everything out visually. It really let you use the best tool for the job, and it provided some best-in-class tools for those parts of the job that still aren't matched today.
PS: One of the coolest parts of Flash that nobody talks about was its ability to treat vectors like clay. Illustrator and the tools it inspired make you compose a vector out of points and bezier handles. Vector creation in those tools requires deft use of barely-abstracted math - it's a craft that's hard to master.
In Flash, on the other hand, you could just push and pull on the edge of a shape until it looked how you wanted. It abstracted the bezier into a more humane form, and that's just one of countless microtools that we lost when we lost Flash.
> The other thing Flash had going for it that nothing else does is animation. Even today, motion designers are stuck using After Effects (a tool designed for movie titles and broadcast news graphics). We still don't have a good tool for making interfaces that move, which means our ability to make properly interactive interfaces was severely knee-capped when Flash was removed.
We definitely need an easy to use GUI for building complex animations. Exporting animations from After Effects via Lottie is not an ideal solution. Maybe Rive or some other startup will fully supplant this workflow at some point.
It was very popular, especially for people who did support or were the “tech guy” for their friends & family. Chrome had multiple nice features but the one which most frequently got people to switch permanently was not losing all of your work when Flash crashed. Not having to tell people that the big comment they’d been working on for an hour was permanently gone because some ad in a different windows crashed Flash lead to a lot of installs.
This was especially bad for anyone developing in Flash because Adobe was motivated to sell licenses and only cared about reliability to the extent that it impacted sales. Their vision was that instead of using web technologies you’d target Flash and run things maybe on the web, desktops, mobile, or set top boxes but always Flash. The problem with that was that they mostly focused on shiny new things which demoed well but didn’t spend money on QA or support. I shipped a couple of Flash apps in the 2000s where we hit basic bugs in their library code, and the support process was basically that you filed a bug report with a ton of details, didn’t hear anything back until the next major release, and then the issue would be automatically closed with a generic suggestion that you try buying the new version and reporting if it wasn’t fixed. $800 later, you could repeat the process as they never once fixed a bug even with a simple reproducible test case.