No disrespect to PPK, but he needs to cite some examples.
If he's talking about jQuery, then I disagree. It's gotten faster, and it's a tiny download when you compare it to videos, images, or webfonts.
If he's talking about front-end MVC-ish frameworks, they're not completely blameless, but generally speaking, the sites that use them feel fast once you get past the initial load.
I think his premise is off. He's talking about front-end performance. Tools aren't the problem. Content is the problem.
Images are huge. Videos are huge. What we need are tools to help us get around this. And we're getting them. Talk to any serious front-end developer, and they'll tell you all about what they're doing to improve performance. Critical CSS, asynchronous CSS and JS, the picture element, Web Page Test, PageSpeed, better Inspector tools, etc. Even Google Fonts warns you very clearly about the impact your choices will have on download times. There's no shortage of tools, but tools aren't the problem.
There's no denying that the web can be faster, but we've been doing an admirable job of keeping up with rich content.
So yes, images and video is the largest section of content, but it's not helping that nearly half as much again is executable code that needs to be not only downloaded, but then executed (and it doesn't help that this code produced ~20 errors depending on which browser it ran on).
There is an actual problem here, a lot of the tools out there do make apps perform poorly.
> If he's talking about front-end MVC-ish frameworks, they're not completely blameless, but generally speaking, the sites that use them feel fast once you get past the initial load.
This is one of the symptoms of bad tools, you need to a get past an "initial load" instead of your UI just appearing immediately. This wouldn't be a problem in itself if the user would get some value in return for the UX regression, however most of the time the reason for the splash screen is just caused by the tool itself. Not supporting server side rendering of the HTML is just an ignorant architectural decision.
The root of the problem is that the creators of these tools focus on architecture and ease of development, which is something you can get away with on the server side, unfortunately on the client side you just have to deal with user experience.
No.. I didn't quite get it either. People blindly including every js lib under the sun and not optimising at all, sure. Using "tools" ? What. Surely he wasn't suggestin people reinvent the wheel?
I feel the need to link this rant, as I have a number of times as a response to overdesigning until you've half-solved the problems you've created by overdesigning. http://motherfuckingwebsite.com/
No disrespect to PPK, but he needs to cite some examples.
If he's talking about jQuery, then I disagree. It's gotten faster, and it's a tiny download when you compare it to videos, images, or webfonts.
If he's talking about front-end MVC-ish frameworks, they're not completely blameless, but generally speaking, the sites that use them feel fast once you get past the initial load.
I think his premise is off. He's talking about front-end performance. Tools aren't the problem. Content is the problem.
Images are huge. Videos are huge. What we need are tools to help us get around this. And we're getting them. Talk to any serious front-end developer, and they'll tell you all about what they're doing to improve performance. Critical CSS, asynchronous CSS and JS, the picture element, Web Page Test, PageSpeed, better Inspector tools, etc. Even Google Fonts warns you very clearly about the impact your choices will have on download times. There's no shortage of tools, but tools aren't the problem.
There's no denying that the web can be faster, but we've been doing an admirable job of keeping up with rich content.