{"id":3309,"date":"2020-01-23T15:44:57","date_gmt":"2020-01-23T13:44:57","guid":{"rendered":"https:\/\/blog.tomayac.com\/2020\/01\/23\/progressive-enhancement-in-the-age-of-fugu-apis\/"},"modified":"2020-01-23T15:44:57","modified_gmt":"2020-01-23T13:44:57","slug":"progressive-enhancement-in-the-age-of-fugu-apis","status":"publish","type":"post","link":"https:\/\/tomayac.com\/wordpress\/2020\/01\/23\/progressive-enhancement-in-the-age-of-fugu-apis\/","title":{"rendered":"Progressive Enhancement In the Age of Fugu APIs"},"content":{"rendered":"\n\t\t\t

Back in March 2003, Nick Finck<\/a> and\nSteven Champeon<\/a> stunned the web design world\nwith the concept of\nprogressive enhancement<\/a>:<\/p>\n

\n

Rather than hoping for graceful degradation, [progressive enhancement] builds documents\nfor the least capable or differently capable devices first,\nthen moves on to enhance those documents with separate logic for presentation,\nin ways that don't place an undue burden on baseline devices\nbut which allow a richer experience for those users with modern graphical browser software.<\/p>\n<\/blockquote>\n

While in 2003<\/em>, progressive enhancement was mostly about using presentational<\/em> features\nlike at the time modern CSS properties, unobtrusive JavaScript for improved usability,\nand even nowadays basic things like Scalable Vector Graphics;\nI see progressive enhancement in 2020<\/em> as being about using new functional<\/em> browser capabilities.<\/p>\n

Sometimes we agree to disagree \u2693<\/a><\/h2>\n

Feature support for core JavaScript language features by major browsers is great.\nKangax' ECMAScript 2016+ compatibility table<\/a>\nis almost all green, and browser vendors generally agree and are quick to implement.\nIn contrast, there is less agreement on what we colloquially call Fugu \ud83d\udc21<\/em> features.\nIn Project Fugu<\/a>,\nour objective is the following:<\/p>\n

\n

Enable web apps to do anything native apps can,\nby exposing the capabilities of native platforms to the web platform,\nwhile maintaining user security, privacy, trust, and other core tenets of the web.<\/p>\n<\/blockquote>\n

You can see all the capabilities we want to tackle in the context of the project\nby having a look at our Fugu API tracker<\/a>.\nI have also written about Project Fugu at W3C TPAC 2019<\/a>.<\/p>\n

To get an impression of the debate around these features\nwhen it comes to the different browser vendors, I recommend reading the discussions\naround the request for a\nWebKit position on Web NFC<\/a>\nor the request for a\nMozilla position on screen Wake Lock<\/a>\n(both discussions contain links to the particular specs in question).\nIn some cases, the result of these positioning threads might be a "we agree to disagree".\nAnd that's fine.<\/p>\n

Progressive enhancement for Fugu features \u2693<\/a><\/h2>\n

As a result of this disagreement, some Fugu features\nwill probably never be implemented by all browser vendors.\nBut what does this mean for developers?\nNow and then, in 2003 just like in 2020,\nfeature detection<\/a>\nplays a central role.\nBefore using a potentially future<\/em> new browser capability like, say, the\nNative File System API<\/a>,\ndevelopers need to feature-detect the presence of the API.\nFor the Native File System API, it might look like this:<\/p>\n

if<\/span> (<\/span>'chooseFileSystemEntries'<\/span> in<\/span> window)<\/span> {<\/span>
  \/\/ Yay, the Native File System API is available! \ud83d\udcbe<\/span>
}<\/span> else<\/span> {<\/span>
  \/\/ Nay, a legacy approach is required. \ud83d\ude14<\/span>
}<\/span><\/code><\/pre>\n
But in other cases, like with the Native File System API,\ndevelopers can fall back to\n<a download><\/code><\/a>\nfor saving and\n<input type="file"><\/code><\/a>\nfor opening files.\nThe experience will not be the same (while you can open a file, you cannot write back to it;\nyou will always create a new file that will land in your Downloads folder),\nbut it is the next best thing.<\/p>\n
A suboptimal way to deal with this situation would be to force users to load both code paths,\nthe legacy approach and the new approach.\nLuckily,\ndynamic import()<\/code><\/a>\nmakes differential loading feasible and\u2014as a\nstage 4 of the TC39 process<\/a>\nfeature\u2014has great browser support<\/a>.<\/p>\n
Experimenting with browser-nativefs<\/code> \u2693<\/a><\/h2>\n
I have been exploring this pattern of progressively enhancing a web application with Fugu features.\nThe other day, I came across an interesting project by\nChristopher Chedeau<\/a>, who also goes by\n@Vjeux<\/a> on most places on the Internet.\nChristopher blogged<\/a>\nabout a new app of his, Excalidraw<\/a>, and how the project "exploded"\n(in a positive sense).\nMade curious from the blog post, I played with the app myself\nand immediately thought that it could profit from the Native File System API.\nI opened an initial Pull Request<\/a>\nthat was quickly merged and that implements the fallback scenario mentioned above,\nbut I was not really happy with the code duplication I had introduced.<\/p>\n
\"Excalidraw<\/p>\n
As the logical next step, I created an experimental library\nthat supports the differential loading pattern via dynamic import()<\/code>.\nIntroducing browser-nativefs<\/code><\/a>,\nan abstraction layer that exposes two functions, fileOpen()<\/code> and fileSave()<\/code>,\nwhich under the hood either use the Native File System API or the <a download><\/code> and\n<input type="file"><\/code> legacy approach.\nA Pull Request based on this library is now merged<\/a>\ninto Excalidraw, and so far it seems to work fine (only the dynamic import()<\/code>\nbreaks CodeSandbox<\/a>,\nlikely a known issue<\/a>).\nYou can see the core API of the library below.<\/p>\n
\/\/ The imported methods will use the Native File<\/span>
\/\/ System API or a fallback implementation.<\/span>
import<\/span> {<\/span>
  fileOpen,<\/span>
  fileSave,<\/span>
}<\/span> from<\/span> 'https:\/\/unpkg.com\/browser-nativefs'<\/span>;<\/span>

(<\/span>async<\/span> (<\/span>)<\/span> =><\/span> {<\/span>
  \/\/ Open a file.<\/span>
  const<\/span> blob =<\/span> await<\/span> fileOpen<\/span>(<\/span>{<\/span>
    mimeTypes:<\/span> [<\/span>'image\/*'<\/span>]<\/span>,<\/span>
  }<\/span>)<\/span>;<\/span>

  \/\/ Open multiple files.<\/span>
  const<\/span> blobs =<\/span> await<\/span> fileOpen<\/span>(<\/span>{<\/span>
    mimeTypes:<\/span> [<\/span>'image\/*'<\/span>]<\/span>,<\/span>
    multiple:<\/span> true<\/span>,<\/span>
  }<\/span>)<\/span>;<\/span>

  \/\/ Save a file.<\/span>
  await<\/span> fileSave<\/span>(<\/span>blob,<\/span> {<\/span>
    fileName:<\/span> 'Untitled.png'<\/span>,<\/span>
  }<\/span>)<\/span>;<\/span>
}<\/span>)<\/span>(<\/span>)<\/span>;<\/span><\/code><\/pre>\n
Polyfill or ponyfill or abstraction \u2693<\/a><\/h2>\n
Triggered by this project, I provided some feedback on the Native File System specification:<\/p>\n
In the worst case, there is no legacy approach (the else<\/code> branch in the code snippet above).\nSome Fugu features are so groundbreakingly new that there simply is no replacement.\nThe Contact Picker API<\/a> (that allows users to select contacts\nfrom their device's native contact manager) is such an example.<\/p>\n