AMPstinction
adactio.com
adactio.com
If you are building a webpage (a web document) its probably the goal of the user to go there and read some information and move on, they aren't there for an "experience" and if your javascript weighs more than the useful amount of text on that page you are probably doing something very wrong.
Oh well, you reap what you sow, I hope you're happy with your new proprietary web.
95% of the problem with web page performance today is ads. Google dominates the online ad business, and if they wanted they could have solved this problem from the ad provider end long ago. It wouldn't have been easy, but it would have been a tremendous use of their market clout.
Instead they decided it was an opportunity to squeeze all publisher content through a new shiny pipeline they created, that also coincidentally solves the issue of poorly performing ads. And then manually manipulated their search results page to pressure publishers into using their new format.
No. I use extremely strict ad-blocking and many website's performance is still shit, both concerning load times as well as CPU hogging.
The problem with web page performance is people believing that by distributing all their (mostly unnecessary) assets over two dozen unrelated origins they speed things up. They don't. That's what makes things slow.
The problem with web page performance is people believing they need some mirrored btree-reverse-hash-indexed shadow DOM, 1.5 MB of Angular, four to five more JS frameworks and 20000 NPM packages with a "ng build" time no less than 50 seconds to show a news article.
The problem with web page performance is people believing a page would render faster if, instead of sending HTML, you send a giant blob of JS which, after almost choking a parser to death, then does a XHR to actually fetch the content and then starts to render templates into actual HTML.
(You know, before everything went apeshit, we used to tell people to put <script> tags last in the document, because that way the browser can render your page without blocking on downloading, parsing and executing your scripts — no one would notice if the menu bars lacked soft animations for 0.3 s after a page load, but people would of course notice if the page stayed blank for another third of second.)
Ironically that is exactly what web developers were told to do for years:
https://developer.yahoo.com/performance/rules.html#split
I can't deny that a lot of web pages bundle far too much JS, but if you've been using a strict ad blocker for a long time you perhaps don't realise how bad the ad code has gotten. React loads in the blink of an eye compared to the multi-second load times for five-level embedded popover ads.
I was thinking of the choice to embed third party scripts or not, rather than what domain they're on.
"It's asynchronous, and that makes it soooo fast!"
So many people drank that async kool-aid, but didn't understand that the network is slower.
The problem is mostly that most clients nowadays don't want a webpage, they want a web application. Something similar to what they have on their phone, computer, ... But JS is no C++ and so Angular cannot be Qt. I use to make Qt application, now I work has a webdev. I do really see how web app are slugish and tend to lag everywhere. But the thing is, for most client, they don't really mind. What they see is that they can access the app from all their computer, phone and tablet, and that matters a lot more for them.
Plus, we will probably never come back to the era where most rendering was done server-side, it just cost too much.
Addendum: ... or if your content-based site fails to display more than a blank canvas without loading a bunch of scripts from third-party origins ...
https://nolanlawson.com/2016/10/13/progressive-enhancement-i...
[Note: I very strongly disagree with this position.]
Absolutely, and it is close to impossible to discuss rationally without the conversation being dominated by rhetoric.
https://dennisforbes.ca/index.php/2017/09/05/embrace-amp-or-...
The point of that piece is that AMP is filling a role -- a minimal web for document publishing -- and denying it, as always happens in AMP discussions, simply makes an easy road for AMP's domination.
But as with anything build on belief, social affinity, and fear of professional irrelevance, the tides are turning.
I always thought HTML 1.0 filled that role.
Checking out a competitor's site, I was flabbergasted to see its source was about 8 lines of HTML, one of which linked to a Mb's worth of entirely inscrutable and indecypherable Javascript, leaving me with no means of working out how they did what they dun.
Coupled with crap like Instagram with it's locked-in walled garden content you essentially need to sign up for to view (and then, practically, install an app to update (yes, i know there're workarounds!)) we've somewhere over the last few years encouraged a large chunk of the internet to become quite obnoxious and antithetical to everything I understood it was supposed to represent.
Bah blast and humbug!
I guess it doubles as a DRM mechanism preventing competitors from easily copying it. ;)
When I say 'competitor' I more meant 'equivalent' - it's a broad and unremarkable field and the 'competition' as such, actually fairly magnanimous.
I'm surprised with how vehemently I disagree with what you're suggesting. A big chunk of my web development experience was in content marketing, specifically in the top 5 most contested ad keyword space.
This is where 1) the most money is being spent on online content, 2) performance most matters, and 3) more time on site directly translates to more conversions.
People browsing the web for legal matters, car purchases and rehab aren't looking for small bits of information and to move on, they're looking for information and reassurance to help them make major decisions. Many of these users will spend hours on your site reading.
AMP is bad, like directly-harmful bad, for all of these businesses. So is Google's direction towards only giving you their top recommended result.
Google is the new Microsoft. Embrace, extend, and extinguish is alive and well, it just found a new home[1].
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
"Sorry this website only works in Chrome"
"Google Hangouts / Google Talk will no longer support XMPP / Jabber"
"Try our not-so-open source available mobile OS" We'll follow you across the web and in real life because our Open Source platforms are published as proprietary.
"Try our proprietary browser for which we release the code for but heavily modify before it gets to you"
At least Microsoft has open source projects that you get what they share published, no crazy surprises, telemetry aside for .NET tooling (which imho is seriously minuscule compared to what it could be).
Or was that the open source that RMS warned us about?
We could have had a Linux distribution tailored for mobile, instead we get that mess that is Android.
Exactly
Here is the license: https://code.visualstudio.com/License/
And yes, VSCode from this website includes tracking.
Though they clearly advertise this as "Free. Open source.". Which seems wrong to me. In my opinion, it's based on open source code at best.
I'm not attacking Microsoft and I'm not endorsing google. I actually agree with the rest of the parent's comment and with amp being bad. I do think selling anything as open source when it's not in a subtle way is shady and I won't comment on which is worse, I'm not in a position to compare. And VScode being an Electron app isn't relevant to me.
I also won't comment on Microsoft buying github, I'm not a fortune teller. As far as I'm concerned, I chose not to host my stuff on github anyway from the begining, since the platform is not open source. I won't rely on any feature of gitlab that is not in the community edition for the same reasons. I which gitlab sold support and hosting instead of proprietary software.
Because the Chrome team is consistently the fastest at supporting newly introduced standards.
A more accurate reading would be: "Sorry, this website only works in Chrome right now. Try Firefox in two weeks, and Edge and Safari in about six months".
I don't disagree at all. It's actually extremely respectable how much collaboration is involved in the process.
>Even though some people have changed their Firefox user agent and found that the web page still works under Firefox.
I'd blame site owners for that one.
>Edge isn't as behind as it once was either
Mixed thoughts. Edge is 100% better than IE used to be, but it still largely lags behind the other vendors.
I installed a Firefox plugin to support my YubiKey for two factor authentication. It worked fine for github, but Google login just locked me out saying Firefox doesn't support it.
So yeah, I blame the website owners, which means Google.
Yeah, that's an interesting way to see it when Google/Chrome dominates/finances the whole WHATWG web "standardization" process directly after "what Webkit is doing". Not saying there isn't bona fide work, but basically there are many ways to derail meaningful standardization efforts other than by not playing ball: by making it so fscking complicated and prohibitively expensive that nobody can't compete. HTML is over 25 years old. There should be no need to rush features all the time. If that's happening anyway (WHATWG's "living standard" nonsense), then something is seriously wrong with the scope and organization of WHATWG's work.
I agree AMP is an abomination and despise google for introducing it. They've abdicated their duty to nudge the advertising world forward.
In truth, once you peel away layers of marketing, AMP's purpose becomes clear [1] as an answer to Facebook's Instant Articles, which tries to chart a have-your-cake-and-eat-it-too course for Google to build consensus around lightweight payloads on the wild [2], open web, while morphing more and more of their products [3][4] to serve as windows to others' content.
It is useful for them to position it as a publishing platform, in a sense, because it furthers the ecosystem they're trying to encourage.
[1] https://news.ycombinator.com/item?id=14529691 [2] https://news.ycombinator.com/item?id=14465801 [3] https://news.ycombinator.com/item?id=14529691 [4] https://news.ycombinator.com/item?id=16367197
[1] https://www.politico.eu/article/google-amp-accelerated-mobil...
Of course this doesn't address Google's potential anti-competitive behaviour which is a case for antitrust investigation not witch hunt.
Friend, I use DDG and Firefox exclusively and still feel like this is not a useful thing to say
Also as always, discussion is void of alternate solutions.
I find it funny that so many of these threads fall back to, "If publishers would just stop stuffing megabytes of Javascript into their web pages we'd be fine!"
Isn't that what AMP is about? It's an open standard, one Javascript codebase that can be delivered once and cached.
AMP also doesn't "break normal links": https://news.ycombinator.com/item?id=13467736
If you think the future of the web --- even just reading articles --- is plain HTML and CSS, then it's no wonder you see AMP as a bad thing and not a good thing for users.
I'd love to hear alternate solutions. How can we deliver article content to users lightning-fast, and still deliver them the things they want like recommendations, sharing, image carousels, etc?
HN is just bursting with NIH on this issue. I'm not seeing any substantive arguments, no alternatives offered, and no consideration for what users actually want.
This article in particular seems to be droning on about "intentions", "messaging", and "long-term solutions".
To all of HN: if you don't like AMP, shut up and code :)
1) you either use amp or you lose out massively in google search rank (as in the links that appear at the top of the page, regaurdless of what semantic games you want to identify them with)
2) by using amp, you hand over all your search traffic to google.
No amount of "shut up and code" is going to fix this, because it is a business decision by Google, not a technical decision that they are going to entertain arguements about.
The open source aspect is a total smokescreen.
It’s not that hard to build a page using any of a handful modern frameworks that can outperform it. The trump card is Google’s preloading in searchresults, which AMP makes easy, but wouldn’t be impossible without it. If they stopped enforcing their own CDN/caching, wrapping the pages with their own UI, rewriting links, you could argue it’s a good thing, as a standard that anyone could adopt without commiting to one company. Until then, it’s just a path for vendor lock-in.
AMP pages are only potentially perceived as 'fast' when you access them through google's search. When you do that all the AMP links' assets are pre-loaded in the background so it seems fast when you click through. But AMP pages themselves are just the same speed as anything else or slower when access without google's monopoly position pre-load.
That makes no sense...
And "Google doesn't owe anybody anything." is just an incredibly lazy argument and not a good reason for why people shouldn't criticize what they do.