6 ms·

There is a growing confusion with web developers about what a webpage actually is, the conflation with web applications is getting rather harmful. If you are b

There is a growing confusion with web developers about what a webpage actually is, the conflation with web applications is getting rather harmful. 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.

untog 8y ago
That doesn't really have a whole lot to do with AMP, though. 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.
- blattimwind 8y ago
  > 95% of the problem with web page performance today is ads. 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.)
  - untog 8y ago
    > 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. Ironically that is exactly what web developers were told to do for years: https://developer.yahoo.com/performance/rules.html#split 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.
    - crtasm 8y ago
      That link recommends no more than 2-4 domains and gives an example of static.yourdomain.com, it's hardly suggesting embedding 20 third party scripts.
      - untog 8y ago
        I assumed the OP wasn't talking about third party assets since no-one chooses to distribute them across different domains, that's just how they have to be used.
        crtasm 8y ago
        Then perhaps I've misunderstood what they mean by mostly unnecessary assets. I was thinking of the choice to embed third party scripts or not, rather than what domain they're on.
  - theandrewbailey 8y ago
    > 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. "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.
blattimwind 8y ago
> if your javascript weighs more than the useful amount of text on that page 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 ...
- amiga-workbench 8y ago
  Damn right, what the hell happened to progressive enhancement?
  - tux1968 8y ago
    It's seen as a waste of time that is holding back innovation. When arguing for progressive enhancement, I've been essentially told "We're focused on customers who have a real browser, not old nerds who have javascript disabled".
    - Rjevski 8y ago
      It would be a good argument if this "innovation" actually had any value for the users, but it does not. I'll take a static webpage any day over some shit full of Javascript.
  - NoGravitas 8y ago
    According to thought-leaders, it isn't dead, but it smells funny. https://nolanlawson.com/2016/10/13/progressive-enhancement-isnt-dead-but-it-smells-funny/ https://nolanlawson.com/2016/10/13/progressive-enhancement-i... [Note: I very strongly disagree with this position.]
endorphone 8y ago
"I hope you're happy with your new proprietary web." 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-amp-wins/ 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.
- tannhaeuser 8y ago
  I agree, and looking at boards frequented by young "web developers" [1], there's the daily clueless "What framework should I be using?" question by novices (or bots?). Any attempt to tell them "it depends on whether you're doing a content-driven site vs an app" ends in downvotes, "it's 2018, dude" arguments or worse by wannabe developers too much in love with their framework of choice (currently React). But as with anything build on belief, social affinity, and fear of professional irrelevance, the tides are turning. [1]: https://old.reddit.com/r/webdev/ https://old.reddit.com/r/webdev/
- majewsky 8y ago
  > AMP is filling a role -- a minimal web for document publishing I always thought HTML 1.0 filled that role.
  - mcbits 8y ago
    HTML has had the potential to fill that role since day one, but while today we're talking about sites sitting blank for 5 seconds because they're downloading megabytes of garbage, back then we had pages sitting blank for 60 seconds because they were downloading 101KB+ of totally insane HTML and animated GIFs of dancing babies and nuclear explosions.
busterarm 8y ago
> 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... 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.
detritus 8y ago
I'm helping a friend with a site which needs some 'cleverness' (by my lowly standards) playing audio whilst pages are browsed. 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!
- Rjevski 8y ago
  > leaving me with no means of working out how they did what they dun I guess it doubles as a DRM mechanism preventing competitors from easily copying it. ;)
- selbyk 8y ago
  Sounds like the "competitor" made the right call then, wouldn't you say?
  - detritus 8y ago
    ha, i suppose you could look at it that way. I was simply trying to work out what presumably off the shelf tech they used. When I say 'competitor' I more meant 'equivalent' - it's a broad and unremarkable field and the 'competition' as such, actually fairly magnanimous.

untog 8y ago

That doesn't really have a whole lot to do with AMP, though. 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.

blattimwind 8y ago
> 95% of the problem with web page performance today is ads. 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.)
- untog 8y ago
  > 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. Ironically that is exactly what web developers were told to do for years: https://developer.yahoo.com/performance/rules.html#split 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.
  - crtasm 8y ago
    That link recommends no more than 2-4 domains and gives an example of static.yourdomain.com, it's hardly suggesting embedding 20 third party scripts.
    - untog 8y ago
      I assumed the OP wasn't talking about third party assets since no-one chooses to distribute them across different domains, that's just how they have to be used.
      - crtasm 8y ago
        Then perhaps I've misunderstood what they mean by mostly unnecessary assets. I was thinking of the choice to embed third party scripts or not, rather than what domain they're on.
- theandrewbailey 8y ago
  > 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. "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.

blattimwind 8y ago

> if your javascript weighs more than the useful amount of text on that page 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 ...

amiga-workbench 8y ago
Damn right, what the hell happened to progressive enhancement?
- tux1968 8y ago
  It's seen as a waste of time that is holding back innovation. When arguing for progressive enhancement, I've been essentially told "We're focused on customers who have a real browser, not old nerds who have javascript disabled".
  - Rjevski 8y ago
    It would be a good argument if this "innovation" actually had any value for the users, but it does not. I'll take a static webpage any day over some shit full of Javascript.
- NoGravitas 8y ago
  According to thought-leaders, it isn't dead, but it smells funny. https://nolanlawson.com/2016/10/13/progressive-enhancement-isnt-dead-but-it-smells-funny/ https://nolanlawson.com/2016/10/13/progressive-enhancement-i... [Note: I very strongly disagree with this position.]

endorphone 8y ago

"I hope you're happy with your new proprietary web." 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-amp-wins/ 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.

tannhaeuser 8y ago
I agree, and looking at boards frequented by young "web developers" [1], there's the daily clueless "What framework should I be using?" question by novices (or bots?). Any attempt to tell them "it depends on whether you're doing a content-driven site vs an app" ends in downvotes, "it's 2018, dude" arguments or worse by wannabe developers too much in love with their framework of choice (currently React). But as with anything build on belief, social affinity, and fear of professional irrelevance, the tides are turning. [1]: https://old.reddit.com/r/webdev/ https://old.reddit.com/r/webdev/
majewsky 8y ago
> AMP is filling a role -- a minimal web for document publishing I always thought HTML 1.0 filled that role.
- mcbits 8y ago
  HTML has had the potential to fill that role since day one, but while today we're talking about sites sitting blank for 5 seconds because they're downloading megabytes of garbage, back then we had pages sitting blank for 60 seconds because they were downloading 101KB+ of totally insane HTML and animated GIFs of dancing babies and nuclear explosions.

busterarm 8y ago

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

detritus 8y ago

I'm helping a friend with a site which needs some 'cleverness' (by my lowly standards) playing audio whilst pages are browsed. 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!

Rjevski 8y ago
> leaving me with no means of working out how they did what they dun I guess it doubles as a DRM mechanism preventing competitors from easily copying it. ;)
selbyk 8y ago
Sounds like the "competitor" made the right call then, wouldn't you say?
- detritus 8y ago
  ha, i suppose you could look at it that way. I was simply trying to work out what presumably off the shelf tech they used. When I say 'competitor' I more meant 'equivalent' - it's a broad and unremarkable field and the 'competition' as such, actually fairly magnanimous.