AMP (or something like it) makes it easier to push recommended practices to upper management and your team though. A site is either an AMP site or it isn't; you can't selectively ignore some of the recommended practices. If you're not using AMP, you've got to convince your team to follow the recommendations and get management to schedule time for it. For example, it's probably a tough sell to refactor an existing page to remove blocking JavaScript unless you can prove it's going to lead to a big speedup and so on for all recommendations.
I'm not saying that it's impossible to do this, just that something opinionated like AMP helps everyone follow recommended practices with less friction. It's similar to having a compiler that gives an error for a recommended practice vs it being in your coding style guide that you have to manually enforce.
Of course, we could argue till the cows come home about what "good" judgement is :)
Well, when you've got your project managers, marketing people, coders etc. all trying to optimise for different things, each group doesn't understand each other and team member expertise differs I don't think it's that weird that issues like blocking JavaScript, encoding image sizes in HTML etc. aren't top priority.
For website speed, anything that makes it easier to know what the right thing to do is without debate is going to help. Even within a team of experienced web developers it isn't obvious what the best approach is because there's so many options.
Depends what you mean by technically superior. In terms of benchmarks, AMP pages are lightning fast. Isn't that the only metric that matters?
What I found unfair about AMP is Google preloading your AMP-enabled webpage. So that even if your not-AMP-enabled page is equally efficient, an AMP-enabled page would feel faster because Google preloads it in the background. And then there is the fact that Google hosts your own content under their domain, and all other points raised in the article.
If we want to defeat AMP, we have to beat it at its own game. That requires us to come up with an alternative that's equal or faster than AMP. And clearly we've failed as developers to push for non-bloated solutions.
It might be possible to create our own version of AMP -- to take the best ideas from AMP and integrate it into some centralized system that isn't controlled by Google. It'd be tough, but the alternative is to let AMP steamroll us. A few rebellious developers aren't going to make much difference in terms of total AMP adoption.
Even if the AMP alternative was just a standard way of stripping bloat from websites, that might get us 50% of the way toward beating AMP.
The technical work has been done for years. The problem is that currently the only decision which matters is Google's and they're treating performance concerns as a way to use other people's content to bolster their own brand. The only two ways that seems possible to change are either convincing Google to reverse that policy or getting more people to use non-Google search engines, which seems unlikely given the huge quality lead they have over Bing, DDG, etc.
What is the precise element of AMP you are trying to beat?
Part of what makes AMP fast is the preloading, so any AMP competitor would need to tackle that problem. You'd also need to demonstrate that websites rank better if they use your solution. And they should, if Google plays fair. If not, then at least this would be a public demo of that fact.
What can we do about this situation?
I found that AMP helps a lot in that marketing/exec teams see Google pushing AMP and think they need AMP.
My company built AMP equivalents, and honestly I wish we could ditch our entire React site for AMP.
Instead of an exec demanding a feature, we can now say "AMP doesn't support it." No matter how many times we've set performance budgets, management absolutely tears the budgets down the second we need to implement some flashy new feature (which for some reason is the perceived solution to every sales slump). A group of us has tried to use data against this at least a handful of times, but memories seem to be short lived.
Of course we need organizational change, but after pushing a stone up the hill over and over again you essentially just say "fuck it" and let it crush you. Bottom-up corporate change is a fool's errand.
But apparently not faster than doing it yourself.
"Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."[1]
[1] https://www.theregister.co.uk/2017/05/19/open_source_insider...
"I initially enabled AMP on my site for one reason only – ranking well in Google search results."
This reminds me about a friend of mine, his father used to run a restaurant and he enabled "donations" to the mob to get a "better ranking" (or not to suffer worse ranking as it were).
You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created?