Mika Tuupola

You mistake everyone using javascript to do those things as the only way it's possible to do those things. That's certainly not true.

You can use HTML, Canvas, and CSS to do just about everything you mentioned.

Video is easy. In pure HTML: <video autoplay loop muted playsinline src="..."></video>. No Javascript (or even CSS) required. You can certainly expand on that as well.

Google Maps does not require Javascript to provide it's core and common functionality either: https://appelsiini.net/2008/google-maps-without-javascript/ You would have to make some changes, but core functionality still exists.

Github does not require Javascript to function. You can toggle JS off and still use it pretty much as is, and the features that do break are trivial to implement without it.

Interactive realtime chat does not require javascript. https://github.com/kkuchta/css-only-chat , and the same principals can be applied to online docs and editors as well.

Javascript is the norm because it has inertia behind it - largely due to circumstance more than any inherent natural benefit, not because it has some secret sauce that the internet needs that couldn't be easily replaced should it be Thanos-meets-Tron-Crossover Snapped out of existence.

A much stronger argument in favor of Javascript would not be pointing to all the good things you can do with it, but rather, with how well and optimized and streamlined doing those things with Javascript is these days. Just to clarify, I'm not saying…

Here are a few that were not mentioned:

- If you have a lot of images like in a product catalog, try lazy loading the images - http://www.appelsiini.net/projects/lazyload

- For sprite-ing your images, use some tool which will automatically generate the css for you: http://spritepad.wearekiss.com

- Have a git commit hook for compressing images. (It could be part of your build, but then you are doing the work every time and the build will be slow if you have a lot of images.)

- If you are using LessCSS or something similar (hint: you should), have your compiler compress the css for you. - http://wearekiss.com/simpless

- Have multiple hosts referring to your CDN to facilitate parallel downloads in the browser.

- Compress your HTML too before deploying - http://code.google.com/p/htmlcompressor/

- Have proper versioning in the name of your JS/CSS files and then cache them for ever. Whenever you change your files, the version should change and only that file will be updated in the client. We normally take the hash of the latest git commit on that file:

cookie-wrapper.js -> cookie-wrapper.bb9303b809210674.js

- Offload whatever you can from your cookies to localStorage or things like that to reduce request size.

The interface would be slightly different but there's no reason why an interactive map viewer couldn't be done in pure HTML and CSS without JS, and then JS added for more enhancements like AJAX loading.

In fact... it's been done eight years ago:

http://www.appelsiini.net/2008/google-maps-without-javascript

http://www.appelsiini.net/2008/google-maps-without-javascript-part-2

Look at where the map images are coming from, copy the link, and play around with the URL parameters. Yes, this still works.

I also distinctly remember playing some HTML adventure games with similar pan/zoom/click interfaces before the millenium, and they didn't require JS either (nor took quite as long as the apps of today to load, on hardware that was probably an order of magnitude or more less powerful.)

Not an exaggeration—Apple’s primary “location services” API, used on iOS/macOS, is just a lookup table for wireless APs’ MAC addresses. [1]

WiFi scanning is much less power intensive than GPS, much more reliable indoors, and often (in dense areas) more accurate even outdoors. iirc the iPhone only connects to “real” GPS in specific situations, such as when visible wifi signals are insufficient (e.g. highway driving).

[1]: https://www.appelsiini.net/2017/reverse-engineering-location-services/