This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland.
I think maps are one widget where having a browser-/platform-level implementation has definite advantages. To be sure, depending on the browser to arrange geocoding is hazardous (I’d expect you’d get better results if you had to specify lat/long and could merely give a label to that point), and for that reason a consistent geocoding implementation as seen in a web component is good; but for the actual map rendering at least, fitting in with the platform would be good. For example, my user agent may know where I live and thus show me this place relative to that place—the sort of thing that a web component can’t possibly do.
I’m cautiously in favour of making a standardised map canvas element, without any form of geocoding (thus reducing its usefulness, admittedly), leaving it to a web component to handle geocoding through any particular provider.
> For example, my user agent may know where I live and thus show me this place relative to that place—the sort of thing that a web component can’t possibly do.
I didn’t say where I am, I said where I live. I didn’t make the distinction clear enough, but I did mean it. The user agent may know more things that are able to make the map more useful for me.
> This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland.
'Userland' isn't really the right word here: web components aren't from my land; they just execute there — they are from some server.
And that's the problem: to display a map (which is, really, just an image, something HTML has been able to display inline since the late 90s) I have to grant execute permissions on my computer to some random piece of JavaScript written by a programmer of unknown competence and beneficence, and reviewed by precisely no-one.
If it's in-browser, the implementation is auditable. It doesn't change on a per-page-load basis. It doesn't require JavaScript. It can be made to work for anyone, on any platform (even if all 'work' means on a particular platform is 'there's a map of $LAT, $LONG here'). It is far less likely to be an intrusion vector. It is far less likely to violate my privacy. It is far less likely to beacon to half a dozen advertisers.
JavaScript isn't just killing the Web: it's murdering it. I sometimes think that JavaScript developers would like to just get rid of HTML entirely: just build the entire page dynamically. HTML is just their bootloader.
> I sometimes think that JavaScript developers would like to just get rid of HTML entirely
Well, the DOM is still useful. Controlling all rendering using a canvas is going too far for most things. But yes, the actual serialised HTML that the browser loads is commonly merely bootstrapping.
I may be being naive, but how is that different than including Google Maps JS lib on your page? I assume that component is just a wrapper around the GMaps JS lib?
It allows you to use the <good-maps> element in your markup, rather than <div class="map">. Tbf, it would be more of an advantage if it used a better name than 'good-map'.
That's a remarkable perspective, and one I happen to disagree with. The great thing about standardising elements is that we can standardise behaviour without having to grant every server in the world execute access on clients. HTML can be used simply as a bootloader to start up a JavaScript DOM-manipulator, but it shouldn't be, because it is far more secure and private to read a static web page than it is to execute untrusted code.
Example: https://www.webcomponents.org/element/keanulee/good-map