Hacker News Reader

Comment by londons_explore | Hacker News Reader

Take a look at Google's AMP script:

https://www.google.com/xjs/_/js/k=xjs.av.en.1ic8JaUStX4.O/m=...

Ask yourself... Is that really the minimum amount of script needed to render a basic fast text and images only webpage? Notice the handcoded crypto functions? Notice the copious numbers of debugging functions and log messages and error messages? Notice the large numbers of copyright notices and complete license texts.

This stuff, if Google's dream comes to fruition, will be downloaded billions of times per day. For every byte of cruft in this file, an ethernet cable needs to be installed/upgraded somewhere.

We shouldn't let Google get away with such massive inefficiency in the name of efficiency.

View on HN

The sad truth is that Google's goal isn't efficiency, it is keeping people on Google's property. The best way to do this is to make people package their websites into little bundles that are safe for Google to preload. They're even working on a way to capture sites that don't want to invest in AMP (signed exchanges).

I count 185 "try" statements with only 162 "catch".

I don't know much about javascript, but could someone explain what happens with the 20 that don't get caught? Do they bubble up and get caught by another "catch"? Or is this indicative of lots of "holes" in the code path?

You can have try/finally without the catch.

Ok, fair enough. But then does that lead to a "fatal error" of some sort? I'm curious because I find AMP page quite buggy. ie. not loading at all. Or loading, then reloading a blank page. And thought maybe these were the "dead end" code paths.

It’s caught by a higher-level catch if there is one.

Try blocks without a catch are a sign of any of these: poor coding, remnants from refactoring, features started and abandoned, possibly result of some build steps combining and optimising code.

Try without a catch is fairly common and IMO quite fine when it's not the current method's job to deal with an error but it is its job to clean up state or some resources.

  async showImage() {
    this.showLoadingSpinner = true
    try {
      this.imageData = await fetchImageData()
    } finally {
      this.showLoadingSpinner = false
    }
  }

There might be a parent class/component/whatever that deals with errors and shows them to the user. The image component is responsible for showing the loading spinner and it shouldn't be left spinning if there's an error.

An aside: one interesting thing about this is that Google's lawyers believe that copyright notices are required in minified JavaScript, and other people don't.

Who's right? Is everyone else breaking copyright agreements?

Many licenses require that the license be distributed with the code. uglifyjs, babel minifier, and google closure compiler all try to preserve license information.

Surely it should be downloaded rarely and cached heavily?

Check the advertised site, https://amp.dev/, and look at the headers for v0.js.

I'm seeing an "expires" tag of "now", a cache-control header of 'private' and 'max-age' of 50 minutes. You'll also see the 105KB Javascript used to support animated gifs, 46KB amp-bind which allows documents to "add interactivity", and several others.

How does one even begin to understand this script. I feel dumb.

You're not meant to. It's minified and rewritten by the Javascript compilers. I believe this would be the place to find anything you want to read:

https://github.com/ampproject/amphtml

Reply on news.ycombinator.com