Tags: flash

54

sparkline

Monday, May 30th, 2022

Re-evaluating technology

There’s a lot of emphasis put on decision-making: making sure you’re making the right decision; evaluating all the right factors before making a decision. But we rarely talk about revisiting decisions.

I think perhaps there’s a human tendency to treat past decisions as fixed. That’s certainly true when it comes to evaluating technology.

I’ve been guilty of this. I remember once chatting with Mark about something written in PHP—probably something I had written—and I made some remark to the effect of “I know PHP isn’t a great language…” Mark rightly called me on that. The language wasn’t great in the past but it has come on in leaps and bounds. My perception of the language, however, had not updated accordingly.

I try to keep that lesson in mind whenever I’m thinking about languages, tools and frameworks that I’ve investigated in the past but haven’t revisited in a while.

Andy talks about this as the tech tool carousel:

The carousel is like one of those on a game show that shows the prizes that can be won. The tool will sit on there until I think it’s gone through enough maturing to actually be a viable tool for me, the team I’m working with and the clients I’m working for.

Crucially a carousel is circular: tools and technologies come back around for re-evaluation. It’s all too easy to treat technologies as being on a one-way conveyer belt—once they’ve past in front of your eyes and you’ve weighed them up, that’s it; you never return to re-evaluate your decision.

This doesn’t need to be a never-ending process. At some point it becomes clear that some technologies really aren’t worth returning to:

It’s a really useful strategy because some tools stay on the carousel and then I take them off because they did in fact, turn out to be useless after all.

See, for example, anything related to cryptobollocks. It’s been well over a decade and blockchains remain a solution in search of problems. As Molly White put it, it’s not still the early days:

How long can it possibly be “early days”? How long do we need to wait before someone comes up with an actual application of blockchain technologies that isn’t a transparent attempt to retroactively justify a technology that is inefficient in every sense of the word? How much pollution must we justify pumping into our atmosphere while we wait to get out of the “early days” of proof-of-work blockchains?

Back to the web (the actual un-numbered World Wide Web)…

Nolan Lawson wrote an insightful article recently about how he senses that the balance has shifted away from single page apps. I’ve been sensing the same shift in the zeitgeist. That said, both Nolan and I keep an eye on how browsers are evolving and getting better all the time. If you weren’t aware of changes over the past few years, it would be easy to still think that single page apps offer some unique advantages that in fact no longer hold true. As Nolan wrote in a follow-up post:

My main point was: if the only reason you’re using an SPA is because “it makes navigations faster,” then maybe it’s time to re-evaluate that.

For another example, see this recent XKCD cartoon:

“You look around one day and realize the things you assumed were immutable constants of the universe have changed. The foundations of our reality are shifting beneath our feet. We live in a house built on sand.”

The day I discovered that Apple Maps is kind of good now

Perhaps the best example of a technology that warrants regular re-evaluation is the World Wide Web itself. Over the course of its existence it has been seemingly bettered by other more proprietary technologies.

Flash was better than the web. It had vector graphics, smooth animations, and streaming video when the web had nothing like it. But over time, the web caught up. Flash was the hare. The World Wide Web was the tortoise.

In more recent memory, the role of the hare has been played by native apps.

I remember talking to someone on the Twitter design team who was designing and building for multiple platforms. They were frustrated by the web. It just didn’t feel as fully-featured as iOS or Android. Their frustration was entirely justified …at the time. I wonder if they’ve revisited their judgement since then though.

In recent years in particular it feels like the web has come on in leaps and bounds: service workers, native JavaScript APIs, and an astonishing boost in what you can do with CSS. Most important of all, the interoperability between browsers is getting better and better. Universal support for new web standards arrives at a faster rate than ever before.

But developers remain suspicious, still prefering to trust third-party libraries over native browser features. They made a decision about those libraries in the past. They evaluated the state of browser support in the past. I wish they would re-evaluate those decisions.

Alas, inertia is a very powerful force. Sticking with a past decision—even if it’s no longer the best choice—is easier than putting in the effort to re-evaluate everything again.

What’s the phrase? “Strong opinions, weakly held.” We’re very good at the first part and pretty bad at the second.

Just the other day I was chatting with one of my colleagues about an online service that’s available on the web and also as a native app. He was showing me the native app on his phone and said it’s not a great app.

“Why don’t you add the website to your phone?” I asked.

“You know,” he said. “The website’s going to be slow.”

He hadn’t tested this. But years of dealing with crappy websites on his phone in the past had trained him to think of the web as being inherently worse than native apps (even though there was nothing this particular service was doing that required any native functionality).

It has become a truism now. Native apps are better than the web.

And you know what? Once upon a time, that would’ve been true. But it hasn’t been true for quite some time …at least from a technical perspective.

But even if the technologies in browsers have reached parity with native apps, that won’t matter unless we can convince people to revisit their previously-formed beliefs.

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.

Wednesday, December 30th, 2020

Here Lies Flash » Mike Industries

Flash, from the very beginning, was a transitional technology. It was a language that compiled into a binary executable. This made it consistent and performant, but was in conflict with how most of the web works. It was designed for a desktop world which wasn’t compatible with the emerging mobile web. Perhaps most importantly, it was developed by a single company. This allowed it to evolve more quickly for awhile, but goes against the very spirit of the entire internet. Long-term, we never want single companies — no matter who they may be — controlling the very building blocks of the web.

Sunday, July 5th, 2020

Dark Ages of the Web

Notes on the old internet, its design and frontend.

Tuesday, June 5th, 2018

AMPstinction • Robin Rendle

And so whenever I look at AMP I wonder whether the technology and process itself might be bad (which is arguable) but the efforts might lead to something longer lasting, another movement inspired because of it, despite it, a movement that we can all benefit from.

Monday, July 31st, 2017

Flash is in the pan

Cameron counts the ways in which Flash was like a polyfill.

Yeah, that’s right: The Man In Blue is back!

Wednesday, July 26th, 2017

Bruce Lawson’s personal site  : Eulogy for Flash

Web developers aren’t going to shed many tears for Flash, but as Bruce rightly points out, it led the way for many standards that followed. Flash was the kick up the arse that the web needed.

He also brings up this very important question:

I’m also nervous; one of the central tenets of HTML is to be backwards-compatible and not to break the web. It would be a huge loss if millions of Flash movies become unplayable. How can we preserve this part of our digital heritage?

This is true of the extinction of any format. Perhaps this is an opportunity for us to tackle this problem head on.

Friday, March 27th, 2015

isolani - Web Standards: Flash’s slide into irrelevance

Mike runs through the history of Flash. Those who forget the history of the web are doomed to repeat it:

The struggle now seems to be turning to native apps versus non-native apps on the mobile platform. It is similar to Flash’s original battle ground: the argument that the Web technology stack is not suitable for building applications with a polished user-experience.

Sunday, October 20th, 2013

Jim Silverman - Native Mobile Apps are the New Flash

The case may be a little overstated, but I agree with the sentiment of this. The web is always playing catch-up to something. For a while, it was Flash; now it’s native.

Flash was a great stopgap measure. But it outlived its usefulness and has been reduced to niche status.

Today, we’re seeing the nearly exact same scenario with native apps on mobile devices.

Native mobile apps are a temporary solution. We’re just over 4 years into the Appstore era and this has already become apparent. Open web technologies are catching up to the point that the vast majority of web apps no longer need a native counterpart.

Tuesday, April 10th, 2012

Caine’s Arcade | A cardboard arcade made by a 9-year old boy.

No, you’re tearing up watching a video about a boy who built his own arcade out of cardboard. I’ve just got something in my eye.

Wednesday, March 30th, 2011

HTTP Archive

This is wonderful stuff: a long-term project to track the performance of high-traffic sites over time: oodles of lovely data and some quite shocking stats.

Wednesday, December 15th, 2010

audio.js

A handy shim for audio: it uses the native implementation where possible and Flash as a fallback.

Monday, May 31st, 2010

Awe Dee Oh

You may have noticed a lot of HTML5 vs. Flash talk lately. Substitute HTML5 for HTML5 video.

Frankly, I’m a little baffled by this supposed dichotomy because you don’t have to choose. The way that video works, according to the spec, is for fallback content to be placed between the opening and closing<video> tags. So you can go ahead and use object or embed or whatever you need to put your Flash video in your markup. Browsers that understand the video element will use that while less capable browsers will play the Flash movie in the object element (and because of the way the object element works, you can put yet another layer of fallback content between the opening and closing <object> tags).

It’s the same with audio. So, on Huffduffer, for example, I can wrap <audio> tags around the object element that embeds the Flash player:

<audio controls src="file.mp3">
 <object data="flashplayer.swf?audio=file.mp3">
  <param name="movie" value="flashplayer.swf?audio=file.mp3">
  <a href="file.mp3">ah, just download it</a>
 </object>
</audio>

But there’s a problem. Firefox understands the audio element but refuses to implement support for MP3 as long as it is patent-encumbered. Firefox users don’t get the fallback content (because the browser does support audio) but they don’t get the MP3 either. They get a broken icon.

So it’s safer to just use the Flash player, right? There’s a problem with that too. Mobile Safari doesn’t support Flash …but it does support the audio element. How can I serve up Flash to desktop browsers and HTML5 audio to the iPhone and iPad without going down the dark path of browser sniffing?

Easy. Just flip the order of what constitutes fallback content:

<object data="flashplayer.swf?audio=file.mp3">
 <param name="movie" value="flashplayer.swf?audio=file.mp3">
  <audio controls src="file.mp3">
   <a href="file.mp3">ah, just download it</a>
  </audio>
</object>

That works in Firefox—and any other browser with Flash installed—and it also works on the i(Pad|Phone|Pod).

Huffduffer — landscape

Friday, March 26th, 2010

Demo jPlayer 1.1.0 : jQuery audio player plugin

A nice-looking jQuery plugin for HTML5's audio element, with fallback to a Flash player. I might just end up using this on Huffduffer.

Wednesday, December 2nd, 2009

Continuity

A puzzle game with an extra dimension. Utterly compelling.

Wednesday, November 25th, 2009

Cause and effect

On November 14th, Cork City was the location of a wherein a crowd of people sang Mister Blue Sky on the city’s main thoroughfare.

One week later, the city suffered its worst flooding in 800 years.

Coincidence?

Sunday, October 25th, 2009

Machinarium

Beautiful artwork in a fun puzzle game.

Monday, August 17th, 2009

This Is The Only Level | Armor Games

Fiendishly clever and joyful platform game ...and it only has only level.

Saturday, August 1st, 2009

Friday, July 24th, 2009

teoskaffa.com AND THAT'S WASSUP

I don't normally like all-Flash sites and I really don't like sites that mess with my cursor* but this one works really well. * I'm looking at you, Harry Potter Twitter site with the password anti-pattern.

Monday, July 20th, 2009

MoonLander3D Apollo 11 40th Anniversary Edition

Celebrating the Apollo 11 anniversary with Seb's 3D lunar lander game.