Good point, but to be fair, author probably doesn't have any control over this, as this is default for all Medium blogs. It's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.
> author probably doesn't have any control over this, as this is default for all Medium blogs
The author made a statement
> Ship less JavaScript
They chose to post on medium, they could have posted the content anywhere. They chose to give us the above lesson, while ignoring it. Do as I say, not as I do.
> it's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.
Who cares? Why not simply stop using such shitty services?
Relax, friend. The majority of people are not freaking out over this. Surely you have better things to do than nitpick about this and call other people's products shitty. I recommend choosing to be more positive instead. Have a nice day.
Nobody is freaking out about anything in this thread. I'm pointing out legitimate facts, contrary to some of the other comments. Reality isn't nitpicking. And yes, it's a shitty product. And don't worry, I'm multitasking.
And yet another question is why would a technically apt person, and one obviously concerned with page optimization, choose to give up control of how their content is served.
Time is this really scarce thing that technically apt people often have a limited supply of. He can spend days rolling his own blog app from his own super custom optimized framework and then do all the additional work of getting that content indexed on Google and sprinkle SEO black magic all over it, or he can just put up a blog post on a service where somebody else does all of that for him.
Unless you're really into that sort of thing or are not fully employed, the time saving option is the most sensible one to do if it's "good enough." Which medium is, as evidenced by the fact that we're all talking about it.
As to why he chose medium over his existing blogs only he can tell you. My guess would be that he is using Medium to reach a bigger audience.
The confusing thing is when he he says we and us (talking about his team) it's confusing since it's on Medium. This really should be up on the Google dev blogs if it's official.
Or choose one of the many open source blog engines out there and maybe contribute to it.
It was, of course, a retorical question. We all know the answer.
People publish on Medium because we messed up. RSS died/was killed and we turned to these centralized solutions, instead. Even its name "Medium" is telling.
No, people publish to Medium because it's very easy to do, and looks great. RSS doesn't solve the problem of having to create your own blog, host it, maintain it.
When your blog isn't your main job (or anything close to it), I really don't see the problem with using a service like Medium. We're all busy.
But is the audience for his post the same as the audience he's talking about in the post? I'd wager: no. Not only do developers tend to have more high-powered machines, this is a post we're much more likely to be reading on a desktop that a mobile device, compared to average. Plus, the post makes the point that a delay is hugely detrimental to any UI on a page, like buttons that won't do anything. Blog posts don't have that issue - you can start reading the article without JS having loaded yet.
The blog post repeatedly makes the point that you should measure everything you do and that you shouldn't apply blanket rules to your coding. I think the same logic applies here. The post being on Medium just isn't that relevant.
So we should only care when it's our job to, otherwise we're just too busy?
Even if one agrees with that attitude, which I don't, I'd argue it is the author's job to care.
Contributing to a bloated centralized service is not healthy for the Web. Making sure it remains a relevant platform is in his best interests, even from a purely egoistic point of view.
You still have to either create a template from scratch or modify existing ones to your needs, configure the generator, set up hosting, domain and many other things. Things that take time which could be otherwise used for something better than devops if that is not your are of work :).
> Time is this really scarce thing that technically apt people often have a limited supply of. He can spend days rolling his own blog app from his own super custom optimized framework and then do all the additional work of getting that content indexed on Google and sprinkle SEO black magic all over it, or he can just put up a blog post on a service where somebody else does all of that for him.
Or use one of the existing Google portals they use for sharing content about their products, research, technical findings...
It's probably a mixture of potential impact (Medium posts will always be much more popular and easier to find on Google than some static page he could set up) and ease of publishing (just write the article and publish it, versus managing your own blog platform), plus some added bonuses (sharing widgets, analytics, etc.).
Just because the author works at Google doesn't mean that "they" had anything to do with the blog post. It doesn't follow that "they" would allow their resources to be used in that way, and it also doesn't tell us anything about what the more time efficient choice for the author is.
Interestingly enough this is one of the websites where deactivating JavaScript results in a much _bigger_ payload (mostly because images are eagerly loaded without JavaScript and lazily with JavaScript activated).
True, but the driving force of TFA is about the time it takes to get to interactivity. Loading 1.2MB less out of the gate is going to help that significantly.
In what browser does eager image loading interfere with "interactivity"? Let's face it, they know most readers probably don't read/scroll to the end so it saves transfer costs on a decent scale --- which is fair enough.
"Half a megabyte of packed JS" still sounds way overkill for delayed image loading.. =)
Please show your working. Downloading >400KB, unpacking it, parsing it, running it is always faster across the board than just downloading the images? Interactivity? Please, I can scroll the page without the images or vast amount of JavaScript being loaded. What gain has interactivity on this article? How does your point related to the fact that there's a vast amount of JS in the page, where the author tells us no to do so.
I had to laugh at this but, and I'm not making excuses for Medium here, that is sadly lightweight compared with a lot of sites on the web.
Still, the "ship less JavaScript" comment rings true: people need to stop cargo-culting all the things into their front-ends. It's colossally annoying at the best of times, and the more-so when you're browsing over a 3G connection. You can basically forget using a lot of websites nowadays if you haven't at least got 3G, and plenty aren't that great on anything less than a 4G connection.
posted on a site shipping 456.1KB of packed JavaScript