I wrote a about my experiences with this same issue. At Google we do something I think is very valuable - we have "Google-2G" wifi all around, which allows us to test our devices and all the...
At Google we do something I think is very valuable - we have "Google-2G" wifi all around, which allows us to test our devices and all the services we use at 2G speeds, which is much closer to average than the Wifi we normally have in Mountain View.
Regular folk can do this using the dev tools in firefox and chrome as well, at least for testing things in the browser. On linux you can also run individual applications using trickle to limit...
Regular folk can do this using the dev tools in firefox and chrome as well, at least for testing things in the browser.
On linux you can also run individual applications using trickle to limit bandwidth.
More people should use these and other tools available to test these things more.
Seconding the chrome dev tools as an excellent resource. When I wrote my website I ran everything at the worst settings and in retrospect if I had known how slow the web app approach would make...
Seconding the chrome dev tools as an excellent resource. When I wrote my website I ran everything at the worst settings and in retrospect if I had known how slow the web app approach would make things, I would have opted for a traditional architecture. Size isn't even the worst part. My site is <200KB, but it still takes two seconds to draw and another second to become interactive (with simulated mobile slowdown). That's after I went over the whole thing with a fine-toothed comb -- it started out taking 14 (!) seconds just to draw because my approach to performance was "well it's not a very complicated website and computers are pretty fast".
Absolutely. It's more about the mindset (and for android). When it's not just a dev environment it puts things in perspective - your email loads painfully slow, refreshes for everything skyrocket,...
Absolutely.
It's more about the mindset (and for android). When it's not just a dev environment it puts things in perspective - your email loads painfully slow, refreshes for everything skyrocket, poorly-built websites start timing out.
In my opinion one of the biggest issues with tech in general is that pretty much the only people you interact with on a day to day basis are other techie folks. At Google the expectation is that the person next to you is able to open up a terminal and debug some networking problem, so it skews your perception of the real world. The vast majority of people can't (and shouldn't need to know how to) do that. I don't think there's a clean solution though - forcing people to spend less time around techie folks seems like an exercise in futility, and a horrible waste of company resources.
Fortunately Google is very good at this - we spend a lot of effort building tools and services for everyone. Google.com loads blazingly fast pretty much everywhere in the world, even on 2G, and we have fallbacks for everything. The emphasis on performance is fairly astounding (although it can be a bit of a pain sometimes).
Slightly off topic, but this is a much bigger issue. Politicians like to point to the successes of tech applications (in the general sense) and think with a few incentives Silicon Valley will...
Slightly off topic, but this is a much bigger issue.
Politicians like to point to the successes of tech applications (in the general sense) and think with a few incentives Silicon Valley will solve all the world's problems.
Unfortunately, most product and systems developers are only able to solve problems they themselves face.
I find the problem with Google products is not the weight of the resources, it's the weight of the JavaScript processing. Its somewhat understandable given that the problems come from web...
I find the problem with Google products is not the weight of the resources, it's the weight of the JavaScript processing. Its somewhat understandable given that the problems come from web applications, but in many cases when Microsoft has a similar product, their version is more responsive. You guys do test your products on low-end machines, right?
I try to do this whenever I can, simply because I loathe JavaScript. Browsers would be faster, more reliable, and easier to maintain if they didn't have to serve as virtual machines while also...
I try to do this whenever I can, simply because I loathe JavaScript.
Browsers would be faster, more reliable, and easier to maintain if they didn't have to serve as virtual machines while also rendering hypertext documents.
I do a lot of website optimizations so have some thoughts on this topic. I'm also a developer, and really enjoy working with Javascript on the web. In some cases JS can even be used to speed up...
I do a lot of website optimizations so have some thoughts on this topic. I'm also a developer, and really enjoy working with Javascript on the web. In some cases JS can even be used to speed up websites (loadCSS, service workers, clever ajax), so these two interests come together.
Javascript however is constantly abused by websites that use huge libraries to solve simple problems. This is a big part of where page bloat comes from (the other biggest offender is uncompressed images).
I've seen Wordpress themes that require 15+ JS libraries and CSS files just for core features. Then site owners will go and install 30 Wordpress plugins on top of that which "sound cool", each of which likely inserts their own scripts and styles onto the page. It balloons very quickly.
Javascript is fine, but is not always the right tool for the job. Or more importantly, consider if the job even needs to be done. I'm going to put a bit of blame on devs and designers here who love to add more features to pages than are necessary. It might be easy to insert that weather widget on a site, but it really doesn't add much except extra load times and clutter.
I do think the New York Times example is probably one of the worst offenders though, and not representative of the web as a whole. I repeated the test with the top three links[0] on Hacker News. They weighed in at 2.0MB, 422KB, and 30KB each. The first result (the worst offender) still felt like it loaded quickly enough, and some quick testing showed that most assets were non-blocking. The data was loaded after page rendering such as Youtube embeds. That's why page size is not by itself a great metric for page speed. Other tools like WebPageTest will give a much more comprehensive overview in showing page speed.
I mostly work on backend systems, but don't mind frontend work...when it's simple. Sadly the frontend we have at $dayjob is extremely complicated, with Polymer web components, a ton of custom CSS,...
I mostly work on backend systems, but don't mind frontend work...when it's simple. Sadly the frontend we have at $dayjob is extremely complicated, with Polymer web components, a ton of custom CSS, and so on. I just can't wrap my head around it.
This article is making me pine for the days when I was working on an internal tool that was simple HTML-templated forms generated by the server, Bootstrap for CSS styling, and jQuery for some simple interactions. It wasn't going to win any design awards but it worked.
I agree with the author, but I think he's bashing Google for AMP while not being informed about PageSpeed which provides a way to measure page load time, offers suggestions on how to improve it,...
I agree with the author, but I think he's bashing Google for AMP while not being informed about PageSpeed which provides a way to measure page load time, offers suggestions on how to improve it, and has modules for Apache and Nginx to automate a lot of the process.
Google's a multi-faceted company. I don't think he's bashing Google as a whole, but specifically bashing that they're pushing AMP. (emphasis added)
Google's a multi-faceted company. I don't think he's bashing Google as a whole, but specifically bashing that they're pushing AMP.
And if anyone at Google is reading, you should try recommending these strategies for speeding up pages instead of pushing self-serving faux standards like AMP.
...Yeah, no thank you. CSS is the bane of my existence. Good luck getting that "clever" CSS to work cross-platform and have it support older browsers because your clients absolutely insist on...
Use no, or very little, JavaScript
Provide interactivity with. . .clever CSS
...Yeah, no thank you. CSS is the bane of my existence. Good luck getting that "clever" CSS to work cross-platform and have it support older browsers because your clients absolutely insist on still using IE 8.
Don't get me wrong, I completely get where the article is coming from and to an extent I agree. I do have a more lax view of what "conservative" would be, however, but that's an argument I'm not about to get into.
Yeah, I can muddle my way through with Javascript, because the devtools in Chrome are excellent, including a very nice debugger. But...CSS is an absolute black-box to me. I can't debug it the same...
Yeah, I can muddle my way through with Javascript, because the devtools in Chrome are excellent, including a very nice debugger.
But...CSS is an absolute black-box to me. I can't debug it the same way I can actual code. Just change something, see if that fixes it, lather rinse and repeat. Particularly when there's existing complex CSS and I try to make changes to it. Feels like trying to make a marionette dance, where you have to pull on a dozen different strings at once in just the right way.
CSS is even trickier to write in a maintainable fashion than JS is, in my opinion. CSS is, by its very nature, very entangled and dependent on other pieces, particularly the structure of your...
CSS is even trickier to write in a maintainable fashion than JS is, in my opinion. CSS is, by its very nature, very entangled and dependent on other pieces, particularly the structure of your HTML. You often can't touch something in CSS or HTML without potentially touching several other pieces. If you rely on "clever" CSS in particular, that's only going to make the problem worse.
At least with JS I can sit there and reason about it and only ever have to make minimal changes.
IMO it's less the structure of your HTML that causes issues with CSS and more to do with shoddy, incomplete and slightly varied implementations of the standards by web browsers. (I'm looking at...
IMO it's less the structure of your HTML that causes issues with CSS and more to do with shoddy, incomplete and slightly varied implementations of the standards by web browsers. (I'm looking at you Safari and IE/Edge!). But regardless of the reason why, I do agree with you that CSS is often a nightmare to work with and this gif is still as true as ever. :(
Good luck getting that "clever" CSS to work cross-platform and have it support older browsers because your clients absolutely insist on still using IE 8.
That is not just NSFW, but disturbingly close to CP (having images of nude kids mixed in with actual porn image results). You may want to remove that link since, even as a commentary for how shit...
That is not just NSFW, but disturbingly close to CP (having images of nude kids mixed in with actual porn image results). You may want to remove that link since, even as a commentary for how shit those DDG results are, it's pretty inappropriate.
p.s. Just google "Family Guy CSS" if you want to see the gif I linked.
Amen to that... the second I see a nag screen for an app on a site, I immediately vow never to download it. There are better ways of making people aware of your apps that don't involve degrading...
Amen to that... the second I see a nag screen for an app on a site, I immediately vow never to download it. There are better ways of making people aware of your apps that don't involve degrading the experience on your site.
I'll never go to the extent of developing an SPA, but I will never do front-end web development ever again without a framework like Vue.js. The de-spaghettification of the jQuery-based code base I...
I'll never go to the extent of developing an SPA, but I will never do front-end web development ever again without a framework like Vue.js. The de-spaghettification of the jQuery-based code base I used to work with was amazing, and the admin web portal I put in place for the current code base I work with was ridiculously easy to spin up and it's completely modular and easy to rearrange as I see fit. The best part is that instead of focusing on manipulating the DOM, I can focus primarily on manipulating the state of my data.
Why anyone would want to work with JavaScript without a modern framework, without a very good reason to do so, is beyond me.
Personally, I hate JavaScript because it's a mess with many many flawed aspects - to the point that seasoned developers outright tell others to avoid certain parts of it. There is a reason why one...
Personally, I hate JavaScript because it's a mess with many many flawed aspects - to the point that seasoned developers outright tell others to avoid certain parts of it. There is a reason why one of the most recommended books on the language is called "JavaScript: The Good Parts".
What I don't get is why people have such problems with CSS. I have come to the opinion that people who complain about it just don't know enough about it; once you understand the working of the different display models, cascading, and specificity, everything falls into place. It is harder if you are coming from a programming background because you come from a world where everything is abstracted, but with CSS you need to understand what most of the properties do.
Yeah, I enjoy CSS. I do get frustrated with the large javascript libraries that are seemingly used to create every simple function though. I just don't think it's necessary to use 10 scripts for a...
Yeah, I enjoy CSS.
I do get frustrated with the large javascript libraries that are seemingly used to create every simple function though. I just don't think it's necessary to use 10 scripts for a basic contact form.
Here's the problem: I've learned a lot about CSS over the last coupe of years, specificity and cascading among them. That doesn't help you avoid issues, however, with bad legacy CSS or how...
Here's the problem: I've learned a lot about CSS over the last coupe of years, specificity and cascading among them. That doesn't help you avoid issues, however, with bad legacy CSS or how entangled that logic can end up getting. It also doesn't help you avoid issues with having to support older legacy web browsers, which can make problems that are a breeze in modern browsers engineering feats in their own right in older ones.
There's also definitely a mile-wide line between understanding CSS and knowing how to write good, maintainable CSS. If you're not a dedicated front-end dev, you're probably not going to be crossing that line for a while.
Bad legacy code of any nature is going to be difficult to maintain. And any coder who is working on CSS will need to learn best practices just like you would for any other programming language....
Bad legacy code of any nature is going to be difficult to maintain. And any coder who is working on CSS will need to learn best practices just like you would for any other programming language.
Supporting older browsers is much less important for most use cases. Most people are using browsers that update themselves automatically. The only reason why you would need to support old browsers (in actuality, old versions of Internet Explorer) is for corportations who are unwilling to make the investment to modernize their systems. Microsoft doesn't even support older versions of IE, so I personally would avoid jobs that require supporting them if at all possible.
I wrote a about my experiences with this same issue.
At Google we do something I think is very valuable - we have "Google-2G" wifi all around, which allows us to test our devices and all the services we use at 2G speeds, which is much closer to average than the Wifi we normally have in Mountain View.
Regular folk can do this using the dev tools in firefox and chrome as well, at least for testing things in the browser.
On linux you can also run individual applications using
trickleto limit bandwidth.More people should use these and other tools available to test these things more.
Seconding the chrome dev tools as an excellent resource. When I wrote my website I ran everything at the worst settings and in retrospect if I had known how slow the web app approach would make things, I would have opted for a traditional architecture. Size isn't even the worst part. My site is <200KB, but it still takes two seconds to draw and another second to become interactive (with simulated mobile slowdown). That's after I went over the whole thing with a fine-toothed comb -- it started out taking 14 (!) seconds just to draw because my approach to performance was "well it's not a very complicated website and computers are pretty fast".
Absolutely.
It's more about the mindset (and for android). When it's not just a dev environment it puts things in perspective - your email loads painfully slow, refreshes for everything skyrocket, poorly-built websites start timing out.
In my opinion one of the biggest issues with tech in general is that pretty much the only people you interact with on a day to day basis are other techie folks. At Google the expectation is that the person next to you is able to open up a terminal and debug some networking problem, so it skews your perception of the real world. The vast majority of people can't (and shouldn't need to know how to) do that. I don't think there's a clean solution though - forcing people to spend less time around techie folks seems like an exercise in futility, and a horrible waste of company resources.
Fortunately Google is very good at this - we spend a lot of effort building tools and services for everyone. Google.com loads blazingly fast pretty much everywhere in the world, even on 2G, and we have fallbacks for everything. The emphasis on performance is fairly astounding (although it can be a bit of a pain sometimes).
Slightly off topic, but this is a much bigger issue.
Politicians like to point to the successes of tech applications (in the general sense) and think with a few incentives Silicon Valley will solve all the world's problems.
Unfortunately, most product and systems developers are only able to solve problems they themselves face.
I find the problem with Google products is not the weight of the resources, it's the weight of the JavaScript processing. Its somewhat understandable given that the problems come from web applications, but in many cases when Microsoft has a similar product, their version is more responsive. You guys do test your products on low-end machines, right?
I try to do this whenever I can, simply because I loathe JavaScript.
Browsers would be faster, more reliable, and easier to maintain if they didn't have to serve as virtual machines while also rendering hypertext documents.
I do a lot of website optimizations so have some thoughts on this topic. I'm also a developer, and really enjoy working with Javascript on the web. In some cases JS can even be used to speed up websites (loadCSS, service workers, clever ajax), so these two interests come together.
Javascript however is constantly abused by websites that use huge libraries to solve simple problems. This is a big part of where page bloat comes from (the other biggest offender is uncompressed images).
I've seen Wordpress themes that require 15+ JS libraries and CSS files just for core features. Then site owners will go and install 30 Wordpress plugins on top of that which "sound cool", each of which likely inserts their own scripts and styles onto the page. It balloons very quickly.
Javascript is fine, but is not always the right tool for the job. Or more importantly, consider if the job even needs to be done. I'm going to put a bit of blame on devs and designers here who love to add more features to pages than are necessary. It might be easy to insert that weather widget on a site, but it really doesn't add much except extra load times and clutter.
I do think the New York Times example is probably one of the worst offenders though, and not representative of the web as a whole. I repeated the test with the top three links[0] on Hacker News. They weighed in at 2.0MB, 422KB, and 30KB each. The first result (the worst offender) still felt like it loaded quickly enough, and some quick testing showed that most assets were non-blocking. The data was loaded after page rendering such as Youtube embeds. That's why page size is not by itself a great metric for page speed. Other tools like WebPageTest will give a much more comprehensive overview in showing page speed.
[0] https://news.ycombinator.com/item?id=17917479, https://news.ycombinator.com/item?id=17918467, https://news.ycombinator.com/item?id=17910089
I mostly work on backend systems, but don't mind frontend work...when it's simple. Sadly the frontend we have at $dayjob is extremely complicated, with Polymer web components, a ton of custom CSS, and so on. I just can't wrap my head around it.
This article is making me pine for the days when I was working on an internal tool that was simple HTML-templated forms generated by the server, Bootstrap for CSS styling, and jQuery for some simple interactions. It wasn't going to win any design awards but it worked.
jfc this is just ridiculous
I agree with the author, but I think he's bashing Google for AMP while not being informed about PageSpeed which provides a way to measure page load time, offers suggestions on how to improve it, and has modules for Apache and Nginx to automate a lot of the process.
Google's a multi-faceted company. I don't think he's bashing Google as a whole, but specifically bashing that they're pushing AMP.
(emphasis added)
The author is also missing that a lot of what he's preaching actually is advocated by Google through their RAIL performance model.
...Yeah, no thank you. CSS is the bane of my existence. Good luck getting that "clever" CSS to work cross-platform and have it support older browsers because your clients absolutely insist on still using IE 8.
Don't get me wrong, I completely get where the article is coming from and to an extent I agree. I do have a more lax view of what "conservative" would be, however, but that's an argument I'm not about to get into.
Yeah, I can muddle my way through with Javascript, because the devtools in Chrome are excellent, including a very nice debugger.
But...CSS is an absolute black-box to me. I can't debug it the same way I can actual code. Just change something, see if that fixes it, lather rinse and repeat. Particularly when there's existing complex CSS and I try to make changes to it. Feels like trying to make a marionette dance, where you have to pull on a dozen different strings at once in just the right way.
CSS is even trickier to write in a maintainable fashion than JS is, in my opinion. CSS is, by its very nature, very entangled and dependent on other pieces, particularly the structure of your HTML. You often can't touch something in CSS or HTML without potentially touching several other pieces. If you rely on "clever" CSS in particular, that's only going to make the problem worse.
At least with JS I can sit there and reason about it and only ever have to make minimal changes.
IMO it's less the structure of your HTML that causes issues with CSS and more to do with shoddy, incomplete and slightly varied implementations of the standards by web browsers. (I'm looking at you Safari and IE/Edge!). But regardless of the reason why, I do agree with you that CSS is often a nightmare to work with and this gif is still as true as ever. :(
We're on the same page there ;)
That is not just NSFW, but disturbingly close to CP (having images of nude kids mixed in with actual porn image results). You may want to remove that link since, even as a commentary for how shit those DDG results are, it's pretty inappropriate.
p.s. Just google "Family Guy CSS" if you want to see the gif I linked.
No worries... and yeah Imgur is sadly getting worse and worse. It's practically unusable on mobile these days. :(
Amen to that... the second I see a nag screen for an app on a site, I immediately vow never to download it. There are better ways of making people aware of your apps that don't involve degrading the experience on your site.
I'll never go to the extent of developing an SPA, but I will never do front-end web development ever again without a framework like Vue.js. The de-spaghettification of the jQuery-based code base I used to work with was amazing, and the admin web portal I put in place for the current code base I work with was ridiculously easy to spin up and it's completely modular and easy to rearrange as I see fit. The best part is that instead of focusing on manipulating the DOM, I can focus primarily on manipulating the state of my data.
Why anyone would want to work with JavaScript without a modern framework, without a very good reason to do so, is beyond me.
Personally, I hate JavaScript because it's a mess with many many flawed aspects - to the point that seasoned developers outright tell others to avoid certain parts of it. There is a reason why one of the most recommended books on the language is called "JavaScript: The Good Parts".
What I don't get is why people have such problems with CSS. I have come to the opinion that people who complain about it just don't know enough about it; once you understand the working of the different display models, cascading, and specificity, everything falls into place. It is harder if you are coming from a programming background because you come from a world where everything is abstracted, but with CSS you need to understand what most of the properties do.
Yeah, I enjoy CSS.
I do get frustrated with the large javascript libraries that are seemingly used to create every simple function though. I just don't think it's necessary to use 10 scripts for a basic contact form.
Here's the problem: I've learned a lot about CSS over the last coupe of years, specificity and cascading among them. That doesn't help you avoid issues, however, with bad legacy CSS or how entangled that logic can end up getting. It also doesn't help you avoid issues with having to support older legacy web browsers, which can make problems that are a breeze in modern browsers engineering feats in their own right in older ones.
There's also definitely a mile-wide line between understanding CSS and knowing how to write good, maintainable CSS. If you're not a dedicated front-end dev, you're probably not going to be crossing that line for a while.
Bad legacy code of any nature is going to be difficult to maintain. And any coder who is working on CSS will need to learn best practices just like you would for any other programming language.
Supporting older browsers is much less important for most use cases. Most people are using browsers that update themselves automatically. The only reason why you would need to support old browsers (in actuality, old versions of Internet Explorer) is for corportations who are unwilling to make the investment to modernize their systems. Microsoft doesn't even support older versions of IE, so I personally would avoid jobs that require supporting them if at all possible.
"brevity is the soul of wit" Polonius, Hamlet Act II, Scene 2, Line 92.
For a second there, I thought you were talking about web development that hates immigrants and is against gay marriage.