
Lesser-known Web APIs - Sandeepg33k
https://blog.greenroots.info/10-lesser-known-web-apis-you-may-want-to-use-ckejv75cr012y70s158n85yhn
======
matsemann
When introducing Web APIs for general use, I think it's a bad idea to show the
example code using react and it's useEffect. Makes the examples less
standalone, and harder for some to grok.

~~~
josteink
I noticed that too, and thought the very same thing.

At the same time you had stand-alone code-samples which were of dubious
quality at best:

    
    
        if (document.someBoolean) {
            setEnabled(true);
        } else {
            setEnabled(false);
        }
    

I mean... Really? :)

So yeah. Coupled with lots of Chrome-only APIs, I wouldn't consider this a
very high quality article.

~~~
ConcernedCoder
lol... yes, that's SMH level stuff...

how about:

    
    
      setEnabled(
        Boolean(
          document.someBoolean
        )
      )

~~~
lytedev
Just curious, but why `Boolean()` over `!!`?

~~~
angrais
I would imagine because it's much easier to read. What does '!!" Do again I
just thought :)

------
jeroenhd
A lot of these don't work in any browser other than Chrome. Demos that work in
Firefox:

\- Fullscreen

\- Image capture

\- Resize observer

\- Broadcast Channel

Demos that don't:

\- Clipboard API (not supported)

\- Battery API (not supported)

\- Performance information (says it's supported, but shows an empty page)

\- Vibration API (supported by the browser, but doesn't actually vibrate
because malvertisers abuse the API in their antivirus scams)

\- Bluetooth API (not supported)

The fullscreen, image capture and broadcast channel APIs are nice I suppose,
but the rest should probably be considered "Chrome APIs" rather than "web
APIs".

Edit: even in Chrome on Android, the battery API is reporting fake information
and the vibration demo doesn't work. That's the problem with experimental web
APIs, you can't rely on them at all.

~~~
onion2k
_...the rest should probably be considered "Chrome APIs" rather than "web
APIs"._

That's just plain wrong. They're web APIs that are maintained by the W3C (in
various states) that Firefox doesn't support yet. That doesn't make them
"Chrome APIs" just as a W3C spec that only Firefox supports isn't a "Firefox
API".

Clipboard API: [https://w3c.github.io/clipboard-
apis/](https://w3c.github.io/clipboard-apis/)

Battery API: [https://w3c.github.io/battery/](https://w3c.github.io/battery/)

Performance: [https://www.w3.org/TR/resource-
timing/](https://www.w3.org/TR/resource-timing/)

Bluetooth API: [https://webbluetoothcg.github.io/web-
bluetooth/](https://webbluetoothcg.github.io/web-bluetooth/)

The fact there isn't good cross-browser support is a reason to check whether
or not a user's browser has support and use progressive enhancement to only
show the feature to users who can benefit from it. It isn't a reason to avoid
using the API unless you want to stick to the lowest common denominator for
your users. In my case that would mean serving Chrome and Firefox users
content that's developed for IE10. That would suck for people who are able to
update their browser, so I prefer to put the effort in to adding features
progressively.

~~~
gardaani
Mozilla and Apple have publicly announced that they will not implement the
Bluetooth and Battery APIs [1][2], which makes them definitely Chrome
proprietary APIs.

These kind of proprietary APIs are exactly what Microsoft did 10-20 years ago
as part of their "embrace, extend and exterminate" process. They extended IE
with their proprietary APIs (such as HTML+TIME), which other browsers never
implemented.

Bluetooth, Battery and many other Chrome APIs are just Google's and
Microsoft's new attempt to "embrace, extend and exterminate" other browsers.

[1] [https://www.zdnet.com/article/apple-declined-to-
implement-16...](https://www.zdnet.com/article/apple-declined-to-
implement-16-web-apis-in-safari-due-to-privacy-concerns/) [2]
[https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/)

~~~
onion2k
_Mozilla and Apple have publicly announced that they will not implement the
Bluetooth and Battery APIs [1][2], which makes them definitely Chrome
proprietary APIs._

I realise this is a bit pedantic, but this is wrong. They're W3C specs that
Mozilla and Apple have chosen not to support. Calling them "Chrome proprietary
APIs" is loaded with unnecessary and unhelpful subtext.

~~~
realityking
If we really want to be pedantic, then I must point out that they're not W3C
standards and likely never will be.

\- Battery Status API was on a standards track but the last published version
is a Candidate Recommendation from 2016

\- Web Bluetooth is just a Community Group Draft. It's not even formally
adopted by a Working Group.

Neither is likely to progress to Recommendation status as the W3C - IMHO,
wisely - requires to independent implementations before a specification is
adopted as a web standard.

~~~
tssva
If we really want to be pedantic the post your comment refers to never said
they were W3C standards. It referred to them as W3C specs which since they are
api specifications and published by the W3C is accurate even if they are not
standards.

~~~
mumblemumble
It seems like we're really far down the "arguing semantics" curve at this
point.

The practical consideration is: These APIs are only supported by one browser.
Other major browsers have announced that they have no intention of supporting
them. Therefore, use them with caution. If it's an Electron app and nothing
but an Electron app, you're probably good to go. If, OTOH, it's a web page or
site, and you don't want to alienate non-Chrome users (which would include all
iOS users), then you should make sure you aren't doing anything janky when
these APIs aren't available or don't work as advertised.

~~~
tssva
If we really want to be pedantic these APIs are only supported by one browser
engine but are supported by multiple browsers.

~~~
tssva
It goes well beyond Opera and Edge.

Looking at the netmarketshare stats for August there are 14 browsers which use
the blink engine and have a reported market share. Brave is not on the list
since it currently reports itself as Chrome. 2 of those browsers have a market
share higher than Firefox, Microsoft Edge and Samsung Internet Browser.
Samsung Internet Browser is a mobile only browser which ships on Samsung
phones and tablets. Removing those and Chrome the remaining 9 blink based
browsers combined still have a higher market share than Firefox.

------
jarek-foksa
Native File System API [1] is going to be the biggest game changer in 2021. So
far it was little known and rarely used because of the origin trial
limitations, but it will become available to everyone soon [2].

[1] [https://web.dev/native-file-system/](https://web.dev/native-file-system/)

[2]
[https://bugs.chromium.org/p/chromium/issues/detail?id=853326...](https://bugs.chromium.org/p/chromium/issues/detail?id=853326#c231)

~~~
zelly
This is a security nightmare. It looks like major browser vendors have pushed
back against it and for good reason. Even a website I absolutely trust should
not be able to access my bare filesystem because I don't know if that website
will get compromised, XSS'd, DNS poisoned, etc.

I understand wanting to save files with a webapp, but why not just use
LocalStorage and deserialize/serialize from that? If you need persistence plug
in a cloud solution like Amazon S3. That's what the web is for.

~~~
t0astbread
Judging by the web.dev page this seems to be pretty well done though.
Permissions are only granted to a subset of files and new sessions will need
to ask for permission again.

LocalStorage is okay but a user might not be aware when LocalStorage is
cleared (f.ex. they might accidentally clear it when deleting cookies). Cloud
Storage might not be in the user's interest in terms of privacy. You kinda
have to add some export/import functionality on top in both cases.

------
kekub
I expected to find the Sharing-API [1] in the list. I just found out about it
recently and have used it multiple times since then. It even works on iOS.

[1]: [https://developer.mozilla.org/en-
US/docs/Web/API/Navigator/s...](https://developer.mozilla.org/en-
US/docs/Web/API/Navigator/share)

~~~
timendum
It only works on mobile (not Firefox) and on Safari.

It's also easy to abuse [1]

[1]: [https://blog.redteam.pl/2020/08/stealing-local-files-
using-s...](https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-
web.html)

~~~
kevincox
This looks more like an implementation flaw than being easy to abuse. The API
is still useful after it is patched.

------
areille
For a complete list of HTML5 APIs, with more details on browser support :

[https://whatwebcando.today/](https://whatwebcando.today/)

------
bawolff
Most of these i had heard of before, but bluetooth and network info api
surprised me. Sounds perfect for fingerprinting :S

The broadcast channel api is the only one i hadn't heard of that sounds
legitly useful in a normal web app.

~~~
matharmin
Bluetooth API won't give useful fingerprinting information unless the user
allows it with a very obtrusive prompt.

It's not something that's useful to the majority of websites, but I find it
extremely useful for hobby ESP32-based electronics projects. It gives an easy
way to configure individual boards, with no weird captive WiFi portal
required. It's cross-platform (Windows, Mac, Linux, Android, just not iOS),
and no native app required, an an easy-to-use API. This means means a lot less
development overhead for my hobby projects. And it means I can give devices to
family & friends without them needing to fiddle with firmware to configure the
device.

~~~
orobinson
I’ve got an ESP32 board sitting in a box somewhere that I’ve been meaning to
get out and fiddle with. This has certainly piqued my interest.

Are there any good resources you could link to that you found useful when
connecting to those kind of boards from Web APIs please?

~~~
matharmin
On the device side I've used a lot of code from the CanAirIO project:
[https://github.com/kike-canaries/CanAirIO](https://github.com/kike-
canaries/CanAirIO). I do want to switch my code to the NimBLE stack instead of
the default bluetooth stack at some point - apparently it uses a lot less
memory.

On the web side I don't currently have any good public examples, but the
generic Web Bluetooth samples here are a good starting point:
[https://googlechrome.github.io/samples/web-
bluetooth/](https://googlechrome.github.io/samples/web-bluetooth/)

Maybe I'll write a proper blog on this if I get some spare time.

------
Ciantic
I want SQLite back as an Web API.

I know the kerfuffle about it, but the browsers these days are so big and
complicated that only few are left anyway. So the idea that there needs to be
differing implementations are almost impossible to achieve.

~~~
pcwalton
SQLite semantics, in particular its loose typing, are pretty questionable. We
shouldn't bake those into the platform forever just for convenience' sake,
especially when you can have SQLite _now_ via sql.js.

~~~
filleduchaos
> in particular its loose typing

As opposed to, say, Javascript or IndexedDB, those famously strongly typed
technologies?

------
lwansbrough
Many of these don’t work on iOS (or outside of Chrome for that matter.) I
would add Web Share API to the list as it is well supported and provides a
nice native interface for commonly needed website functionality.

------
altdatathrow
Does anyone know of a way to do "fullscreen" where the screen is the window?
It bugs me that to watch a streaming video my options are: box inside their ui
which takes up a significant portion of my window real estate, or full screen
on my entire monitor.

can't I just have "fill window"?

~~~
sergeykish
Which UI?

Title bar displayed by window manager, not in xmonad by default. URL bar and
tabs are not displayed for popup window [1]. Document content is different for
each page, youtube embedded videos can be opened in new tab/window/popup by
right click on title, resulting URL
[https://www.youtube.com/embed/xxxxxxxxxxx](https://www.youtube.com/embed/xxxxxxxxxxx)

Unfortunately at least in chromium <video> has only "Open video in new tab"
and even than it does not fill available space.

[1] Convert To Popup [https://chrome.google.com/webstore/detail/convert-to-
popup/i...](https://chrome.google.com/webstore/detail/convert-to-
popup/ipbclffpmnocdigdcpmahfmdlibcggal)

~~~
altdatathrow
> Which UI

Just a few examples but Youtube, Vimeo, and Twitch have a lot of noise
(comments, chat, suggestions to watch next, etc) around the default video
before it's maximized. But if you press F11 that all disappears.

Didn't know about the embed link for YT, that's handy, same for the Chrome
extension. I just generally don't know why this isn't a standard feature by
now. Surely I'm not in the minority here.

------
badrabbit
Webauthn would be a good addition. Devs need to support it a lot more:
[https://webauthn.me/](https://webauthn.me/)

------
metafunctor
I would add this: webkitdirectory allows recursively uploading entire folders.

It works on the latest versions of Firefox, Chrome, Edge, and Safari. Not on
mobile browsers at the moment, though.

------
flingo
Here's one that's Firefox exclusive, and still seems to work:
[https://developer.mozilla.org/en-
US/docs/Web/HTML/Global_att...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Global_attributes/contextmenu)

It's something I've used on a few sites, and it's a shame chrome dropped
support.

------
leokennis
> Interestingly, copying content to the clipboard is open as in, there is no
> need of a user permission.

WTF...is there some way to block this API from being called in Safari?

~~~
esperent
Given that this says copying to the clipboard, not reading from it, I'm
curious, why would you want to block it? The worst a website could do it
mildly irritate you by copying junk to your clipboard.

~~~
leokennis
Like jacobush mentions: copy some shell code to clipboard, tell unknowing user
to open terminal and do CMD+V and enter.

Or indeed, put some malware site on my clipboard.

Either way, it’s my clipboard and no website should be able to change it
without my permission.

~~~
teichmann
I don't know about other browsers, but Webkit/Safari only allows writing to
the clipboard when triggered by a user interaction.

Copied from [https://webkit.org/blog/10855/async-clipboard-
api/](https://webkit.org/blog/10855/async-clipboard-api/):

"The request to write to the clipboard must be triggered during a user
gesture. A call to clipboard.write or clipboard.writeText outside the scope of
a user gesture (such as click or touch event handlers) will result in the
immediate rejection of the promise returned by the API call."

~~~
leokennis
That is reassuring to hear, thanks for digging that up

------
jacquesm
Personal favorite:

[https://github.com/google/lovefield](https://github.com/google/lovefield)

Thin layer on top of indexdb for local persistence.

Lovefield is a relational database written in pure JavaScript. It provides
SQL-like syntax and works cross-browser (currently supporting Chrome 37+,
Firefox 31+, IE 11+, Edge, and Safari 10+).

------
lachlan-sneff
It's a shame that Firefox has said they won't implement many of these. The
Bluetooth and USB apis would legitimately be really useful. I'm not sure the
privacy issues really matter if there's a dialog that the website is trying to
use one.

~~~
warkdarrior
> I'm not sure the privacy issues really matter if there's a dialog that the
> website is trying to use one.

If all we rely on to protect security & privacy of user data is a dialog, then
there is little hope.

~~~
lachlan-sneff
Not really, if the user wants they can post their location, credit card
number, etc online. They stand between themselves and their own exploitation.
Removing apis doesn't change that.

------
dheera
> Battery Status API

I wonder whether this could be abused by certain sellers to increase prices
when your battery is almost dead. That would be evil, I hope nobody does it,
but it is theoretically possible and I think the API should pre-emptively
require permissions to prevent people from abusing it in that way.

------
joseluisq
I got surprised by Network, Battery and Vibration info APIs built-in. I have
tested on my Android phone. Cool... but any user required permissions? So no
thanks.

------
ChrisMarshallNY
Many of these are quite cool, but give me the security heebie-jeebies.

For that reason, I don’t see them being implemented broadly, especially in
iOS.

------
a_imho
Thanks, I was not aware of these apis. I would really love to know more how
the image/video capture works.

------
andai
This page renders with part of the text cut off on my phone and I can't scroll
to it.

------
dzonga
you can't say well less known web api's. most of those api's are not
standardized.

------
joseluisq
I was thinking that this HN link was a CVE report.

------
ForHackernews
Most of these sound like terrible half-baked ideas that should be removed from
browsers quickly before anyone gets the idea to use them.

~~~
joseluisq
Concerned about why any of those APIs don't require user permissions.

------
irthomasthomas
Here is another good collection of free public APIs

[https://github.com/public-apis/public-apis](https://github.com/public-
apis/public-apis)

~~~
bmn__
This isn't what the article is about. In case you didn't read it: think
[https://developer.mozilla.org/docs/Web/Reference/API](https://developer.mozilla.org/docs/Web/Reference/API),
not
[https://www.programmableweb.com/apis/directory](https://www.programmableweb.com/apis/directory).

