Latest comments

Here are the latest 20 comments posted to my site.

Chrome’s web audio change is bad news – ChatApp on May 23, 2018:

I'm all for letting the user block autoplay, I'm just not for Chrome's solution.

Example where the change sucks. Chat apps. Chat apps want to make a "ping" sound when a new message arrives. Can't unless the user interacts. I reboot my machine and or log out. I restart Chrome, it reloads tabs, tabs that have my chat sessions in them. This change basically means I have to go to each tab and click something before I'll start getting notification sounds.

You might say a solution is to use the notification API but the notification API has other issues. One is that without warning message contents gets displayed in the notification. That content might not be something I want someone else to see so I have chosen not to opt into the notification API instead preferring just a sound so I can choose if it's safe to view.

A better solution, at least for chat, is to let the user whitelist the page. That's not an option with Chrome's new system.

Chrome’s web audio change is bad news – CL on May 14, 2018:

Personally, I applaud the change. No matter if it's an ad, a music site, or even a video site like YouTube, it really annoys me that things start playing the instant you visit them. I'm 100% behind requiring a click to play. If they want to add the ability to give a site blanket permission to play on visit, that's fine, but I'll probably never use it.

Chrome’s web audio change is bad news – SoundSlice customer on May 10, 2018:

As a SoundSlice customer, I see so many obnoxious autoplaying muted video ads that I’d gladly accept the tradeoff of disabling all autoplaying videos. That’s not currently possible in Chrome - the autoplay config flag actually still allows muted videos. I agree that the Chrome team shouldn’t make sudden unannounced changes, but disagree that requiring user interaction is a bad thing.

The UX damage from autoplaying video ads is worse than having to spend a bit more effort when I use SoundSlice (especially if Chrome supports whitelisting a domain).

Chrome’s web audio change is bad news – Steven Estrella on May 10, 2018:

I agree that this change to Chrome is badly done. The problem is that if an AudioContext is created when the page loads (from a direct URL request), then the AudioContext is automatically paused even if that AudioContext is not currently playing audio. That breaks a lot of code even in games where the user is required to click something before audio playback begins. So the fix Chrome implemented goes beyond stopping autoplay. Now I have to add context.resume() to the play button code in every page. ugh!

Chrome’s web audio change is bad news – Schmoo on May 10, 2018:

The bathwater really does need to be thrown out though. Interaction is a very small ask, and it's not the only way to get around this. I'd be sorry to lose any app, but that's not what's happening here and you're acting as if this change is someone trying to kill your business specifically. They are requiring a click FFS, get some perspective.

You need to dial down the outrage, and perhaps move the balance of it a little away from Chrome and little more towards "we knew it was risky".

Chrome’s web audio change is bad news – Tim on May 10, 2018:

So the issue is you weren't given enough notice? Because your post sounds like it's apocalypse. Can you not just add a "play" button?

Chrome’s web audio change is bad news – Andrew on May 9, 2018:

Perhaps try reading the thread. They enabled the change without getting a large enough sampling of the sites that are effected. And basically threw the baby out with the bathwater.

Chrome’s web audio change is bad news – Developere whos been forced to make autoplay on entering website on May 9, 2018:

I love the change. Its a blessing. What are reasons you really need autoplay? User has first to make an action to actually play and this is great.

Chrome’s web audio change is bad news – Šime Vidas on May 9, 2018:

Could you explain why the user interaction requirement is a problem for your service? In the example you provided, the playback is controlled via the play/pause button at the bottom, which seems to work fine.

About the PPK talk and tweet – Dave on February 13, 2017:

At least a little of the uproar is due to ppk doing some version of this same talk last June, and everyone went similarly bananas then:

So at least a little of the uproar this time is exasperation. Let's be honest, the slide is baity. I for one was hoping ppk might have toned it down a little because I just hate seeing the community like this. As you were there, you know PPK's point is well-meant. However repeated use of this slide causes me to despair. At best it's intentionally baity, at worst it's intentionally divisive. The community in general seems to assume the latter every time. Deliberately causing argument (as opposed to discussion) is not a pleasant thing.

About the PPK talk and tweet – Leticia on February 12, 2017:

Back in the day when you could write your CSS by hand your stored procedures by hand, your HTML by hand and have the thing render in milliseconds, bypassing whatever crap was generated by whichever language or framework you were supposed to be helped by, it was fun. Even if I had to write workarounds for IE, always IE.

When the Javascript frameworks came into the picture, changing (breaking up) every other week, taking the control from the developer and adding a lot of weight for not a lot of functionality, then it stopped being fun.

About the PPK talk and tweet – Pedro on February 11, 2017:

Exactly. I have been doing backend (Python, Django, databases, servers, Linux, caches, etc) and lot of front end (vanilla JS, jQuery, micro-frameworks, CSS3, Sass, Stylus, HTML5) for 7-8 years and have been thinking about those points in recent years. Totally agree with the main ideas:

1- Front end development is getting too complicated, too much sophisticated and with too many abstractions/layers. That's prone to errors.

2- You should have a "basic knowledge" of what's going on behind your abstractions.

3- Don't follow trends. Think like an engineer and choose the right tools.

About the PPK talk and tweet – Oleh Kuchuk on February 10, 2017:

It's all about managing complexity. Totally agree with your and ppt opinion. That guys are just looking for a way to joke, instead of focusing on real problems.

About the PPK talk and tweet – Felix Niklas on February 10, 2017:

Didn't expect that you'd get so much negative feedback for that tweet. I enjoyed it! Thanks for the write up!

The history of ‘this website is well-crafted’ hints – Ramiro on May 5, 2016:

For me another big well-crafted hint is speed. This is also one of the things that isn't tied to a particular time, but I think the release of yslow and the accompanying rules for frontend performance optimization around 2007 were a game changer.

When you see that developers take care about things like optimizing images, avoiding bloat, reducing HTTP requests and so forth, it is clearly a hint, that they know their craft.

iOS 9 problems with web audio – Jason on November 11, 2015:

Thanks Mitch Wells!
Yeah I'm working on a web synth as well, and touchend is not a good solution.
Handling touchend on first touch, then from then on touchstart works is a better solution.
I think you can avoid the ios9 fix prompt by playing on touchend of the first note that's hit. Just keep a state for hasFirstNoteBeenPlayed, and then play a sound on touchend.
e.g. my touchend event winds up calling this function:
//'this' is the object that defines the stopNote function in this case, not a dom node
var oscFix = this.options.audioContext.createOscillator();
oscFix.type = 'sine';
oscFix.frequency.value = 100000;
oscFix.start ? oscFix.start() : oscFix.noteOn();
oscFix.stop ? oscFix.stop() : oscFix.noteOff();

this.hasFirstNoteBeenPlayed = true;

So the first press won't work, but subsequent presses will work.

iOS 9 problems with web audio – Nikolay Tsenkov on October 13, 2015:

I think, they've fixed this in WebKit, but it probably hasn't been released, yet.
I doubt it will be more than a month from official release.
Here is the commit:

iOS 9 problems with web audio – ism on October 10, 2015:

I'm having problems with wad.js too. Anybody got a workaround for that library? touchend, mousedown, etc., don't resolve issue.

iOS 9 problems with web audio – Carl on October 6, 2015:

The bug posted about this says it's closed.
Does that mean it's getting updated in a new release?

iOS 9 problems with web audio – Jonny on October 6, 2015:

The same problem and fix has been reported for createjs. Can someone who has reported a fix on here try this test out for me.

Press and hold the "trigger" for 2 seconds and then release. This should still trigger your "click" and "touchend" events but for me it doesn't trigger the audio to play if you press and hold.