Modern Frontends Live

Dictionary definition of the term "shitshow": noun, vulgar, slang. A situation or event marked by chaos or controversy.

I let the community speak on this event. I have collected all the blog posts about Modern Frontends Live that I could find. If you wrote another, please send a pull request or let me know directly, and I will happily link to it.

Niall Maher even made a video about the conference experience. Lean back and enjoy… 🍿

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2022/11/23/modern-frontends-live/.

Reflections about Project Fugu 🐡

I had the honor of being asked to contribute some lines to Jorge del Casar's newsletter called Estandarte. As you may guess from the name, the newsletter is written in Spanish, so I wrote my contribution in said language (which Jorge thankfully brushed up a little). Find the English translation below.

In the early days of Project Fugu, we talked a lot about "closing the app gap". We wanted to put Web developers in a position where they could implement anything on the Web that they could implement for platforms like Windows, macOS, Android, iOS, etc. We still want that, but we have changed our thinking a bit: instead of working down a list of APIs, we're now looking at what use cases this has enabled. Don't get me wrong, working down this list was essential, but it left developers a bit in the dark as to our actual motivation and priorities. To the external observer, some of what we released may have seemed a bit random. The opposite is the case: from the start we were partner-driven. Where things fell a bit short was that we failed to fully convey our vision to developers what this was all about: enabling Microsoft to release Visual Studio Code, Adobe to launch Photoshop, BandLab Technologies to create BandLab, and many projects big and small more.

Now with the initial batch of APIs done, our focus has shifted on refining and improving these APIs. Make them more ergonomic to use, be more privacy-preserving, and more complete in addressing the needs of developers. Be sure to read my recent article Is Project Fugu done?, where I go in more detail regarding our thinking there. My Twitter DMs and email are always open and I love hearing developer stories and feature your apps on the 🐡 Project Fugu API Showcase.

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2022/10/14/reflections-about-project-fugu/.

Things not available when someone blocks all cookies

The other day, I received a harmless-looking Issue for my app SVGcode (announcement blog post). The Issue read:

Crash when opened with cookies blocked

Hey I block cookies by default. Unfortunately your website doesn’t handle that nicely despite it not needing (IMO) cookies to operate. I'm getting this error, because blocking cookies also blocks localStorage.

Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. Please add fallback to js provided localStorage, because it makes the app unusable.

I don't use cookies in the app at all, but for sure, when I disabled cookies in Chrome, the app wasn't usable.

Chrome Settings with all cookies blocked.

All I am using is some innocent localStorage and IndexedDB to persist user settings like the values of the sliders or the chosen color scheme.

Turns out, with all cookies blocked, Chrome disables a lot of (all?) APIs that can be used to persist data and thus potentially profile users. Here are the ones that I found:

The code sample below shows all these APIs and the error messages they throw when you try to use them with cookies blocked.

localStorage;
// Uncaught DOMException: Failed to read the 'localStorage' property from Window: Access is denied for this document.

sessionStorage;
// Uncaught DOMException: Failed to read the 'sessionStorage' property from 'Window: Access is denied for this document.

await caches.open('test');
// Uncaught DOMException: An attempt was made to break through the security policy of the user agent.

const openRequest = indexedDB.open('test', 1);
openRequest.onerror = function () {
console.error(openRequest.error);
};
// DOMException: The user denied permission to access the database.

openDatabase('test', '1', 'test', 1);
// Uncaught DOMException: An attempt was made to break through the security policy of the user agent.

await navigator.serviceWorker.register('.');
// Uncaught DOMException: Failed to register a ServiceWorker for scope ('https://example.com/') with script ('https://example.com/'): The user denied permission to use Service Worker.

await navigator.storage.getDirectory();
// Uncaught DOMException: Storage directory access is denied.

webkitRequestFileSystem(
window.PERSISTENT,
1,
() => {},
(err) => console.error(err)
);
// DOMException: An ongoing operation was aborted, typically with a call to abort().

webkitRequestFileSystem(
window.TEMPORARY,
1,
() => {},
(err) => console.error(err)
);
// DOMException: An ongoing operation was aborted, typically with a call to abort().

Did I miss anything? If so, please let me know!

Console errors when trying to access localStorage, sessionStorage, the Cache API, IndexedDB, and Web SQL.

The fix for the Issue was annoying, but simple. Always try...catch any potentially blocked calls:

SVGcode app with blocked cookies working and showing caught exceptions in the DevTools console.

Please report any other errors you encounter (I don't care for the analytics script failing). And thanks, @JakubekWeg for caring enough to having opened this Issue! Jakub is the proof that users exist who block any and all cookies. Check your error logs, you might be losing users, too!

(On a tangent, MDN is completely broken with cookies blocked, too. I was about to report this problem (because I care and love MDN 😍), when I discovered a PR is already under way that fixes the Issue. Thanks, @bershanskiy!)

MDN with blocked cookies

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2022/08/30/things-not-available-when-someone-blocks-all-cookies/.

Announcing the Project Fugu API Showcase

One of the most frequent questions we hear on the Project Fugu team is: 🤔 "What are some of the apps people build with Project Fugu 🐡 APIs?"

The Project Fugu API Showcase is our answer:

Project Fugu API Showcase

It allows interested parties to get a filterable list of all the apps, big and small, that use a given API.

Need to prove that we're building obscure-sounding APIs like the Web Serial API for a reason? Select the API's chip and there goes a list of all the apps that use it:

Project Fugu API Showcase filtered on apps that use the Web Serial API

The Project Fugu API Showcase is community-driven. Everyone can submit apps for inclusion, and they will get listed after a short period of time of verification and approval.

Of course the Project Fugu API Showcase is contained in itself (yay, recursion 🎉), which means on supporting browsers you can use it to share it (or any other of the contained apps) with your followers:

Project Fugu API Showcase Project Fugu API Showcase and the iOS Share Sheet Project Fugu API Showcase and the Twitter compose tweet dialog

Please help spread the word and use this in discussions with the people you work with (whose apps you—or they—are obviously most welcome to add to the showcase):

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2022/04/25/announcing-the-project-fugu-api-showcase/.

iOS Browser Engine Choice

I'm following the (Twitter) conversation on browser engines other than WebKit to be allowed on iOS very closely. When the United Kingdom's Competition and Markets Authority (CMA) solicited responses from Web developers to their mobile ecosystems market study interim report, I sent one where I spoke as the developer of SVGcode and told the CMA about my experience with making the app performantly available on iOS Safari:

To whom it may concern,

I'm an employee of Google Germany, but also a hobbyist Web developer. Recently, I have built an application, SVGcode (https://svgco.de/), which I wanted to be performing well on all browsers, so I have put a lot of time and effort into making it as compatible and progressively enhanced as I could. Unfortunately, Safari is the one browser that constantly requires the most hoops to get to the same baseline experience as on other browsers like Firefox, Edge, or Chrome.

For example, it does not offer proper installation support, so rather than use my built-in Install button, I need to hope my users are aware of the hidden away "Add to Home Screen" feature in Safari.

Another missing feature is OffscreenCanvas, which would greatly improve the app's performance, but as is, the performance on Safari leaves to be desired. On macOS, I can just tell users that I have made the maximum effort to be compatible with all browsers, but if people wish to get the maximum performance, they are free to switch their browser to a one with the maximum amount of features supported.

On iOS and iPadOS, however, there is nothing I could tell my users, since even alternative browsers have to use WebKit's rendering engine under the hood. I do hope your legislation can help improve upon the situation and lift Apple's browser ban.

Respectfully yours,
Thomas Steiner

——
P.S. While I am employed by Google, I am speaking in a personal capacity for my work as a hobbyist developer outside of Google.

More impactful and lawyer-approved than mine are the responses from Mozilla and Google, though, which I invite you to read in their entirety. Below just two significant quotes:

Without regulatory intervention we believe there will be no change to the status quo, harming competition in browser engines and browsers, and harming innovation online.—Mozilla

Competition between browser engines—and freedom of choice for developers—means browser apps on Android can differentiate themselves by incorporating a range of features and functionalities that are not available on iOS, where all browsers are required to use Apple's WebKit browser engine.—Google

(It goes without saying but restating again: While I am employed by Google, I am speaking in a personal capacity for my work as a hobbyist developer outside of Google.)

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2022/03/25/ios-browser-engine-choice/.

Releasing SVGcode

Just a quick note to say that I have released SVGcode, a Progressive Web App that lets you convert raster images like JPG, PNG, GIF, WebP, AVIF, etc. to vector graphics in SVG format. You can find the source code on GitHub.

SVGcode app screenshot.

To learn more about the features of the app, read my article SVGcode: a PWA to convert raster images to SVG vector graphics or watch the video that is also embedded below.

SVGcode is starting to get some coverage, for example, from XDA Developers and even a Chinese website called 软餐. To help discoverability, I have also listed it on Stefan Judis' collection of Tiny Helpers. With the orange site it is always give and take, but for now (🤞), Hacker News treats the app quite well. Looking forward to seeing where the app goes.

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2021/11/22/releasing-svgcode/.

Things mode and strings mode in Google Trends

Google Trends has essentially two modes:

A colleague of mine fell for this and was looking at the landing page for Progressive Web Apps in strings mode and was confused. The page the colleague should have looked at is the landing page for Progressive Web Apps in things mode. Its URL is https://trends.google.com/trends/explore?q=%2Fg%2F11bzxympx6.

You can recognize things mode by looking at the q query parameter in the URL. If it starts with %2Fg%2F (URL-decoded: /g/), you are in things mode. The funny code 11bzxympx6 after that is the Knowledge Graph identifier. When you search for "11bzxympx6" on Google, you end up with exactly one search result that points to the Wikidata page for Progressive Web Apps. If you know the Knowledge Graph ID of something, you can hand-craft a URL that points people at exactly the right semantic search result on Google: https://www.google.com/search?kgmid=/g/11bzxympx6. See the bold Knowledge Graph ID at the end of the URL.

Google Trends showing "strings" and "things" mode side by side.

Note how Google Trends in the screenshot above even helpfully points out that…

[t]his comparison contains both Search terms and Topics, which are measured differently.

…and directs the reader to a help resource to learn more about the difference.

I happen to know all this because this is what I did my PhD in, and I have a paper at the ACM that describes the process we used for migrating our proprietary Knowledge Graph predecessor Freebase to the community-maintained Wikidata.

It's rare that I get to tell anyone about this stuff, so now you know more than you probably wanted to ever hear about this… You can learn more about this time of my Google life in my previous blog post. My manager back in the days didn't care about any of this, but maybe it's at least interesting to you… :-)

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2021/11/08/things-mode-and-strings-mode-in-google-trends/.

14 years at Google

Yesterday marked my 14 year Googleversary. I joined Google full time on October 1, 2007 as a new-grad straight from university. While for the Googleversary stats all that counts is full time employment, I was with Google way earlier. First as an intern between my second and third year at university starting on February 1, 2005, and then continuously throughout the rest of my studies as a temporary worker and via other internship contracts. The way this actual employment age shows is through the employee ID. Mine is in the 9,000 range, but people who joined about the time when I joined full-time have a 50,000 range ID. At the time of writing, 98.08871% of full time employees and extended workers have been at Alphabet for less time than me. During these 14 years, I've had 15 managers, some of them multiple times. I have 2.85-ified my salary (sounds impressive maybe, but I simply started very low), and have gone through three promotions. That's one promotion less than I think I could have had, but instead I enjoyed a different perk: I did my PhD on company time.

The PhD time (2010–2014) 🔗

While I wanted to do a PhD after three years on the job, I wasn't initially planning on doing it on company time. Quite the opposite. From February 1, 2010, I had reduced my work load to 60% to work on my PhD in the remaining 40%. After having this arrangement for two or three months, one evening my at the time manager's manager called to make me an offer I couldn't resist: to come back full time and work on I-SEARCH (A unIfied framework for multimodal content SEARCH), a three-year European project funded under FP7-ICT. This very manager left the company a couple of months later and his successor didn't see the same value in EU projects than the manager who left, and while they let me continue my (multi-year) work, my previous (Strongly) Exceeds ratings that I received for several quarters went down to regular Meets Expectations. Lesson learned in hindsight:

Never make your personal work arrangement depend on the goodwill of a sole manager, as powerful as this manager may appear.

During this time, I cranked out a number of publications (some of them fine, some of them mediocre), but above all made great friends and traveled the world. You can see me co-present the result of the project, a multimodal search engine, and to my surprise the user interface of I-SEARCH is still up.

My internship time (2005–2006) 🔗

My internship project—that sort of just evolved—was the Google AdWords PHP client library APIlity. At the time, the AdWords API (a very enterprise SOAP API) was brand new, and I happened to be the intern who was able to make it work. I had some experience with REST APIs from my Master's thesis, you can enjoy my first ever tech talk on the topic below.

The first few years (2007–2010) 🔗

During my first few full time years, I continued my work on the AdWords API as a Customer Solutions Engineer, but my heart always was with developer advocacy. I took on any opportunity I could get to hack my job and work with developers. One of my best memories is the 2008 series of Google Developer Days, where we toured all of Europe. Embedded below a presentation of mine on the Google Web Toolkit. An advantage of the early years was that Google was a lot smaller and job roles that were distinct in the US were still not present in Europe, so others like me who were just somewhat technical enough needed to jump in and represent locally.

After the PhD (2014–2018) 🔗

After finishing my PhD, I was (very naively so) disappointed that no one at the company cared. No pay raise. No job offer. I actually had to beg to go back to my previous Customer Solutions Engineer job that was the reason why I had started the PhD in the first place. While I tried for a while to get hired elsewhere and also switch jobs internally, nothing really worked out for various reasons (mostly location constraints and failed interviews). Another lesson learned:

Don't assume anyone in the company will care for your self-arranged further education. Having a PhD or not makes a difference as a new hire, but not later.

Getting into Chrome Developer Relations (2018) 🔗

Location always was a big factor in what roles you could get at Google. I made no secret of my interest in developer advocacy, but not being in one of the hub engineering offices meant this door was closed. I lobbied Paul Kinlan long enough until he eventually let me apply for a role on the Chrome Developer Relations team. The time between the interviews and the (thankfully positive) decision of the hiring committee was one of the most nerve-wrecking in my life. Long story short, it took me more than ten years to get the job I actually wanted. Not a real lesson, but more a reflection:

Taking an educated risk and doing what you really want while doing just enough to not get fired for doing too little of the things you actually get paid for is a strategy that sometimes works out. I wouldn't recommend it, unless you really, really want something.

Reflections on the present (2018–present) 🔗

Now I'm in Chrome Developer Relations since May 28, 2018 and it's an honestly great team to be on. My work is about evolving the Web and making things possible on the platform that were unthinkable before. I spoke twice at Google I/O, was part of Chrome Dev Summits, and presented at more international conferences than I can remember.

Ironically the corona crisis demonstrated that location didn't matter that much after all, at least for a distributed team like Chrome Developer Relations. Had corona come a couple of years ago, maybe they would have let me apply for the Developer Relations team way earlier, who knows. Since I started working for Google, I always lived a ten minute walk away from the office, but despite this short distance and even if I enjoy working in an office, I've now successfully applied for my position to be permanently remote. Mostly to secure the right.

What's next? 🔗

Is it time for the next gig? Maybe. It's very unusual for people in IT to stay on the same job for as long as I did. Will I see 15 years at Google? Who knows. Very probably so. For now, I'm definitely still having fun, at least most of the days. Have I become more cynical? Definitely. Do I panic when yet another re-org is being announced? Nope. One thing is certain, though: my heart still beats for the Web. Reach out if you have questions on anything that I wrote or if you want to discuss ideas. My DMs are open and my email is right on my About page.

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2021/10/02/14-years-at-google/.

Public statement of support for Annalena Baerbock and die Grünen for #BTW21

It's not often that I post something with the Political tag on my blog. In the recent months and probably years, I've in the majority sticked to Technical posts, but this one is different. For folks like me in tech, it's way too easy to limit oneself to just the mostly uncontroversial (as in: it truly matters) technical stuff and stay silent about other aspects of life. Yesterday, I watched the Triell (the TV debate between the three candidates for the German chancellor, Armin Laschet, Olaf Scholz, and Annalena Baerbock) and I took this as an excuse to make my political standpoint public. It's uncomfortable and I hesitated a lot, but I think it's the right thing™ to do now.

As Annalena Baerbock from the Grünen party says: "The next government is the last one that can still actively influence the climate crisis." You may have heard of the 2021 floodings in Germany. Our response can't be to rebuild and move on. If we continue the laissez faire of the German car industry that Mr. Laschet, the candidate of the Christian Democratic Party CDU, demands, we mainly get electric (or worse, hybrid) SUVs for 50K€+, but not affordable small cars for regular incomes. We don't need a Merkel 2.0 that Mr. Scholz risks to become with a little bit of CO₂ pricing here and a little bit of exit from coal energy there.

We need a politics where "[o]ur children, our grandchildren shouldn't have to ask us: Why didn't you do anything? But: How did you do it?"—Annalena Baerbock.

If you're not super familiar with the current German political pre-election situation, here's some recommended background reading:

If you want to join me in going public with your political views, here's how I did it. It may feel uncomfortable, "cost" you followers or subscribers to your blog, or maybe even stop people from talking to you (I hope we keep talking, even if we don't agree with each other), but I think it's worth it.

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2021/09/13/public-statement-of-support-for-annalena-baerbock-and-die-gruenen-for-btw21/.

Dark Mode Web App Manifest App Icons

I was asked if one could use SVG web app manifest app icons that are reactive to prefers-color-scheme. To illustrate what this means, here is an excerpt of a manifest where I set the icon to an SVG that is reactive to the color scheme. You can play with it by navigating directly to icon.svg and toggling your operating system's color scheme setting.

{
"icons": [{
"src": "https://dark-mode-favicon.glitch.me/icon.svg",
"sizes": "144x144",
"type": "image/svg+xml"
}]
}

The icon itself is just an SVG with embedded CSS. You may remember it from my post prefers-color-scheme in SVG favicons for dark mode icons.

(Side remark about a little gotcha: Note how I need to "lie" about the icon's dimensions in the web app manifest, where I say it's 144x144 pixels compared to the width and height in the source code.)

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
<style>
circle {
fill: yellow;
stroke: black;
stroke-width: 3px;
}
@media (prefers-color-scheme: dark) {
circle {
fill: black;
stroke: yellow;
}
}
</style>
<circle cx="50" cy="50" r="47"/>
</svg>

So, to close this, the answer to the above question is yes, app icons will respect your preferred color scheme, but no, app icons won't update dynamically when you change your color scheme. Instead, they will keep their initial dark or light mode look from whatever you had your system set to at install time.

macOS Settings shows the system is set to light mode, but the app icon is still presented in dark mode, since it was installed when dark mode was enabled.

You can test it for yourself by installing the app embedded below (launch it in its own window).

(Credits: The app is a remix of Alexey Rodionov's app fir-skirt.glitch.me. Alexey, you guessed it, is also the one who asked me about this.)

Thomas Steiner
This post appeared first on https://blog.tomayac.com/2021/07/21/dark-mode-web-app-manifest-app-icons/.