Flashback to Steve Jobs' famous "Thoughts on Flash" https://newslang.ch/wp-content/uploads/2022/06/Thoughts-on-F...
It was not well received at the time. Oh how things have changed.
It was not well received at the time. Oh how things have changed.
There are dozens & dozens of really really good html/svg animation products that give Flash like capabilities. But there's vastly less interest in this stuff today. Fun/simple/quirky Flash-like stuff isn't nearly as unique or novel, now that we have much more upscale products & experiences. It was a magical time & Flash helped, but we've changed & these rose-colored glasses views on Flash never point out all the myriad of ways it was awful, choppy, poorly integrated, quirky to work with, & otherwise difficult.
If you want higher there are hundreds of web-dev targeting game dev systems which can be put to use. Many of these actually do have popularity. In spite of their being good Flash-ish animation toolkits, it doesn't feel like there's a ton of demand or clear winners. It's hard to imagine what we'd want it for today.
Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
It's okay to say "please visit this from your computer" when someone opens something that requires a keyboard from a phone.
> Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
The barrier to entry is considerably higher with these things. They require programming from the beginning. The coolest part about Flash was that you could get started without writing a single line of code. Then you could build up your understanding of the thing iteratively. You could build a simple quest-type game with just one line of code that you copy-pasted from somewhere, `goToAndStop(frameNumber)`. And then you go from there — variables, flow control, all that. Flash got a sizable number of people interested in programming. This ease of use is extremely important and it's still unmatched by any purported modern replacements.
Unless you have a captive audience, like forced to use enterprise users, this is not a winning strategy for any internet based product.
Also, the assumption that everyone will have devices in two form factors is, and I am being charitable here, naive.
Flash was great because it was popular and supported with the weight of a big company that loved its own child. Their love translated to great tooling.
Whereas the web is “community-owned” and community/committee-designed things rarely get super cool and fleshed out things like well-integrated for-everyone tooling. Instead, you mostly get self-serving projects that serve the creator’s own need primarily. Usually half-baked. And it’s not interoperable with anything else.
And those are?
> now that we have much more upscale products & experiences.
And those are?!!
Surely lack of hardware acceleration and poor implementation are incidental, not fundamental issues. Just as browsers eventually got their own PDF implementations because Adobe's sucked, I expect the same would have happened for Flash eventually.
> We also have ~3 major open source browser engines that independently implement the web compared with one closed source vendor.
We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
WebKit and Blink are not the same browser engine.
Of course not. These are just some of the many many needles of crap that broke Flash.
> I expect the same would have happened for Flash eventually.
Perhaps you underestimate just how complicated "Flash" is: It's 2023 and despite everything you can do in a modern Web browser with HTML5, SVG, JavaScript, Video and so on, we still don't have a second full reimplementation of Flash. No emulator or converter that preserves all of the authors intentions, not even with a server-side-helper to cover the differences in networking policies between the web and Flash. I still think it would take serious cash/time to do this.
And for a large company to do it would risk being sued by Adobe. They promised. I think if Adobe couldn't fix the crap-needles for whatever reason, nobody else could either. Adobe made sure of that. And nobody wants to pay the Adobe tax when Flash hurts users so bad.
PDF on the other hand, is easy enough to implement on screens in a month or less, spec-in-hand. Users who use Adobe's PDF reader deserve what they get.
> We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
I do feel a little better off. I remember a time when every flash bug was an opportunity to airdrop malware, just buy an ad and get on every desktop PC in the world for chump change. I had to browse the Web in a VM, back when VM's on workstation PC's were still painfully slow, because I needed the ability to rewind state so often. I really don't miss that.
A small number of players working (largely) openly (i.e. we have webkit and gecko's source code!) allowed features to the Web be deployed relatively quickly, and problems fixed fast and usually with the smallest-possible harm. And I think people are sufficiently suspicious of closed-source infrastructure that people (mainly purchasing VPs at big enterprises) will be able to resist any attempts to change that.
Whereas back in the flash days there was basically just x86 desktop Windows and the few other web enabled devices were niche and didn’t properly support Flash.
The Dreamcast had a browser (based on IE) but suffered from an ancient version of flash. PDAs were uncommon, also had a browser based on IE, and also suffered from a crippled version of Flash. Smartphones were a few years off and when they did arrive also had a crippled version of Flash (or no support at all).
Flash was a format for a different era. An era when Microsoft had suffocated the tech industry. The fact that we can now view basically any website on any hardware is a massive step forward.
I agree that the modern era of the web has its problems too (I’m looking at you Google, Facebook, etc) but having been a developer and early adopter of the web, I’d still take modern web technologies over Flash any day of the week.
It wasn't quite that bad. I was running FreeBSD at the time and Flash was fine there. In fact I remember for a few years it was easier to have working Flash than working "web video".
And as good as the 3rd party hacks were, they didn’t work all of the time. I remember a few sites I needed for work which required me jumping onto a Windows VM just to use.
There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
I had to put some kind of wrapper in, and I think it was actually using the Linux version of the plugin, but it all worked pretty reliably once it was there.
> There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
I'm talking about slightly later, when people were pushing "web video" as a replacement for Flash for e.g. YouTube. Flash was more reliable and better supported on FreeBSD for some time, is my recollection. Although honestly straight-up <embed> also worked fine and I never felt that the move away from that was really justified.
As for the early days of web video, I think half the problem was that nobody could agree on what video format to support. Some wanted patented formats while others (namely Firefox) wanted open source formats.
I’m not sure what the end outcome was of all that but it does feel a resolution has at least now been found.
JavaScript is one.
That too in turn also covers six types of JavaScript engine.
* Mozilla * Microsoft * WebKit * Adobe * Opera
https://egbert.net/blog/articles/javascript-jit-engines-time...
Is this an idiom? What does it mean?
Additionally, the SWF format itself was way ahead of SVG. It still is to some extent: https://open-flash.github.io/mirrors/swf-spec-19.pdf - look at the part that describes shapes, and compare it to SVG.
One thing that helped was ability to have shapes with fill on each side of the edge, allowing smoothly joined scenes that can be animated at real-time. All without the use of high-precision math, Flash used integers only with some fixed-point data!
You're describing javascript in that era.
The other big thing which hit Flash was mobile. Rearchitecting it to support the equivalent of the web’s responsiveness was a huge problem which got lost in the “Steve Jobs killed Flash” narrative. Battery life wasn’t the only thing which made it unpopular on mobile – that could have been improved even though some aspects of the platform made that hard – but also the fact that Flash was based around mice and fixed-size displays. Very little of the existing content worked well (often at all) on the mobile devices which did have Flash.
Flash Lite was usually used on the devices you mention as the "app" environment instead of J2ME, BREW, or whatever.
This doesn't gel well with the bring-your-own-everything nature of the web, unfortunately. Even if you look just at React there's 50 ways to build the same thing, which I'm sure makes rolling in accessibility that "just works" across all React apps without additional effort from the developer extremely difficult. It's much more practical with UI frameworks that are strongly opinionated with only a single well-supported "happy path" for most things.
Losing the high-quality authoring environment, without anyone producing something competitive, was a pretty big blow. But for the rest, I'm quite glad to see invasive browser plugins disappear.
The complainers were loud, but I think the majority of people who cared (99% of humanity didn't even notice, of course) were muttering "amen brother!"
iPhone customers were so desirable that, over time, the video streaming sites had to support Apple's video streaming format. They would have also supported Apple's video conferencing app, but I think Apple was unable to open-source the protocols for the video conferencing format, due to patent issues.
It's a little weird to call an open standard (like H264) "Apple's format".
I think it's pretty clever.
There are a lot of usability issues with firewalls and proxies that make implementing other streaming protocols very difficult, and the HLS design basically causes the implementer to adopt a pattern that is resilient to those problems.
Networks got a lot better after Covid had everyone work from home so IT had to sort the hot-path out for videoconferencing. Nowadays I think WebRTC would be fine, but in 2009 I think HLS was pretty smart.
Source: I write an HTTP streaming client library for a living.
Why do you think users care about “separate manifests and non-aligned segments” more than the video playing and not stalling and having to refresh?
Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
BTW, when I say "HLS is pretty backwards" I mean designed unergonomically and without clear requirements in mind, not a step back from what existed before. I would guess this is because the original specification was something like "whatever Major League Baseball can easily stream from their existing setup" (see the various Pantos drafts that ultimately became RFC8216)
Oh you're quite right! I was definitely mis-remembering silverlight.
> Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
I don't know if that's actually true. I sell ads, so I'm collecting delivery data on billions of devices, but only over the crappy internet that has a lot of ads on it, and at least for short videos, and the long videos after the places those short videos are, HLS stalls less than Dash and silverlight: HLS publishers make more money.
I would be interested in learning more.
> I mean designed unergonomically and without clear requirements in mind
I can easily agree with that. I misinterpreted what you meant by "backwards" as referring to the progress of the experience.
I mean it could be delivered via HTTP and was was built off of open standards for the manifest files. (HLS just breaks down mp4 files into smaller chunks and lists them in a text manifest file based on the mp3 playlist spec) *
It significantly moved the needle forward on how video was delivered and did so in a standards based way until DASH came along.
Not sure why the hate here for their “proprietary standard” it wasn't proprietary - just no one was using it and it eventually became a defacto standard because it “just works”.
* I know I’m simplifying this.
Scaling RTSP was difficult because it required two way signaling with the server and for the server to maintain client state. Using HTTP instead allowed for stateless servers in a CDN to easily scale and pushed stream negotiation onto the client. Besides simplifying the server side of streaming it made it much easier for clients switching from cellular to WiFi to maintain a stream, RTSP (and protocols like it) can't really handle clients switching addresses mid-stream.
It had some fun games but on the Mac side it was always an unstable dumpster fire. Having the iPhone browser start to push people away from making entire Flash-based websites so they could play music and crash my browser was a godsend.
https://www.fastcompany.com/1646594/adobe-launches-hearts-an...