
Faster AMP on the Origin: AMP and SSR - mpweiher
https://blog.amp.dev/2019/08/07/faster-amp-on-the-origin-amp-ssr/
======
londons_explore
So AMP is designed to be so so fast, and yet has such a big JavaScript library
attached that we need to process the content twice (once in a server-side
render, and then again when the client side JavaScript loads)?

Anyone fancy going through the AMP library and inspecting it for cruft?

~~~
dkh
I mean, there are valid concerns over the ethics or intentions behind AMP, but
let’s not kid ourselves—it’s definitely damn fast to load. Say what you will
about the implications or whatever, but they nailed it in a technical
performance sense.

~~~
chrismorgan
Strongly disagree. It’s way faster than a badly-implemented strawman (which
_is_ most media sites, admittedly), but markedly slower than implementing
basically the same thing but without AMP.

AMP’s main benefit has been making it harder to do expensive things. (Not
impossible, by a long shot; merely harder.) And they’re deliberately planning
to scuttle that benefit by allowing you to run your own scripts (see worker-
dom). At that point, I believe that the only benefit of AMP will be how Google
search treats it, rather than anything about actual performance.

~~~
ocdtrekkie
The fact that Google is also moving forward with AMP4Email, which has nothing
to do with fast-loading mobile websites, reveals that the true purpose of AMP
is simply to create a Google-proprietary replacement for HTML.

~~~
lern_too_spel
Another explanation for the name is that it uses a subset of the components of
normal AMP, which are all prefixed with "amp-". Microsoft, Yahoo!, and Mail.ru
are also moving forward with AMP4Email.

~~~
ocdtrekkie
As we've discussed previously, the other mail providers are being forced to
comply with Google's proprietary format since Google holds a near monopoly on
email and they want to remain compatible. It isn't a defense for Google's
behavior.

And Google has communicated in multiple other ways that it thinks websites
should be developed exclusively in AMP, a replacement of the open standard
everyone agreed upon in HTML5.

~~~
lern_too_spel
Your conspiracy theory doesn't explain mail.ru.

I'm also curious how you explain link aggregators other than Google using AMP
caches.

> And Google has communicated in multiple other ways that it thinks websites
> should be developed exclusively in AMP,

It doesn't support everything that full HTML supports, so this statement is
obviously false.

> a replacement of the open standard everyone agreed upon in HTML5.

That's like saying RSS is a replacement for XML. It's a replacement for Apple
News and Facebook Instant Articles, not for HTML5, which it is built on.

~~~
ocdtrekkie
You're literally arguing with Google's own statements about AMP now:
[https://www.youtube.com/watch?v=DXEdcNTs-
GE](https://www.youtube.com/watch?v=DXEdcNTs-GE) [AMP First: AMP as your main
framework (AMP Conf '19)]

"In this special episode of Amplify, discover how to go "AMP First" and use
AMP as your main development framework to significantly increase your
productivity as developer. You'll also learn why "paired AMP" was never really
meant to be an end state for AMP."

~~~
lern_too_spel
At the beginning of your video, the presenter says, "It's not a replacement
for HTML." This is obvious because HTML5 supports far more than what is
exposed in AMP. He later says they want it to be a natural choice for "web
development for everything content related." Again, this is not a "replacement
for HTML" any more than RSS is a replacement for XML.

I take it you've admitted the rest of your mistakes as you have left them
unanswered?

------
amluto
> With this attribute being set, the validator treats SSR’d AMP as valid AMP.
> SSR’d AMP optimizations break the rules of the AMP spec, hence making the
> document invalid, which is why it’s necessary to indicate this case with
> this new flag. With the flag and the optimizations both being in place, the
> document is considered valid and you’re good to go.

Wait, does this mean that websites could serve plain HTML but set this flag
and this avoid being penalized by Google? Win!

------
londons_explore
Take a look at Google's AMP script:

[https://www.google.com/xjs/_/js/k=xjs.av.en.1ic8JaUStX4.O/m=...](https://www.google.com/xjs/_/js/k=xjs.av.en.1ic8JaUStX4.O/m=jsa,r,d,hsm,ampsa,amp,tnqaT/am=AACAAORCDwDgqwFWAg/d=1/br=1/rs=ACT90oFDGnudWjXLeDH-
NewC5hLtO_NGLw)

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.

~~~
jspash
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?

~~~
vsviridov
You can have try/finally without the catch.

~~~
jspash
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.

~~~
dmitriid
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.

~~~
vimslayer
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.

------
RobLach
Every developer second put into AMP is a waste of cosmic resources.

------
greyskull
I don't fully understand the implications here, and I know I'm oversimplifying
given the SSR half, but I find it amusing that part of this feature is "remove
the code we told you to add".

------
dvt
> It doesn’t make sense to hand-write SSR’d AMP. Instead, use a tool to
> automatically transform your AMP files into a SSR’d version, like a compiler
> would.

"Compiling HTML" would've been Star Trekian techo-babble a few years ago. And
yet, here we are, where a straight-faced Google developer advocate is telling
us to do just that. Should we laugh or should we cry?

------
codegladiator
Make your site fast so that Google can avoid the traffic to your fast site.

------
asadkn
It's just sad that enormous amount of developer resources are being wasted
into a tech which should have been used for the standard web instead. It's not
just the developer hours put into the AMP project itself. Thanks to all the
SEO blogs, every site out there has to wasted resources into an AMP
implementation.

The days of maintaining two versions of a website - a "mobile version" (in
AMP) and the normal - are back again. Takes me back to the WAP days (not
saying it's that bad). Then there are those that are going AMP-only - getting
locked into AMP and all the excessive-yet-limited JS baggage (try building a
full-fledged site and you will have a lot of AMP JS). JS compilation and
execution isn't cheap on phones either. I sure as hell can make faster-
rendering sites without that AMP bloat that can compete despite their
prefetch.

This proprietary tech isn't helpful and is a massive dev resource sink. And
let's not kid ourselves, there were many better ways for Google to prioritize
and encourage speedy websites.

~~~
sverige
>And let's not kid ourselves, there were many better ways for Google to
prioritize and encourage speedy websites.

That's not the goal, though. Better tracking of your social graph is the goal
of AMP. It's like alt.test to see how fast your link propagates, and where it
goes. Useful information for influencing you and others.

~~~
lern_too_spel
With signed exchanges, they won't have any information about when people share
AMP cache links, so that conspiracy theory doesn't work.

------
fartcannon
No thanks!

Is there a term for creating something with two purposes? Where one seemingly
benevolent purpose hides a malevolent one?

~~~
predakanga
A Trojan horse?

~~~
ben_jones
Is it a Trojan Horse when the strategy is so blatantly obviously? Google
exists to turn this path:

User -> Internet -> Website

Into

User -> Google -> Internet -> Google -> Website

So that they can sell more ads.

~~~
predakanga
Perhaps a poisoned chalice, then?

------
dmitriid
It’s called HTML. Google reinvents HTML and calls it an amazing innovation.

------
NetOpWibby
I look forward to never using this nonsense.

------
craftinator
Favorite excerpt:

" AMP SSR is for everyone

If you publish AMP pages, you should publish server-side-rendered AMP pages.
Similar to minifying your HTML or CSS, running AMP Optimizer or the Go
transformers should be a normal part of your build / rendering chain. The
improved rendering performance makes a big difference in FCP times, but more
importantly, in the user experience.

" Other than being the most heavy handed, imperative/authoritarian style call
to arms I've seen, the part of this that really bakes my cake is "makes a big
difference... in the user experience." Ya know what makes the experience of
visiting my website great for a user? When they actually visit MY website.
It's like, the single most fundamental part of a website visiting experience.
When their browser and my server host kanoodle around in cyber space together,
instead of having some creepy cuckold experience involving Google's server. So
I'm thinking that AMP, and all derivative technologies, should really make
like 'Google Health' and retire to the trash bin.

