Comments for The "Developer Experience" Bait-and-Switch
"When developers produce a website, they do so for their intended audience" That's a pretty bold statement. I would argue that there are plenty of companies out there who commission websites from agencies and who don't have any idea the whole performance debate even exists. Agencies rush to deliver a product and if the client sees it perform well on their desktop, they move on. And the web holds one more website that is slow for everyone but recent desktop computers.
"If they are developing an e-commerce website, they don’t develop for the poor" I had never heard this argument. I suspect you wrote that quickly so I won't comment on the idea itself, which is kind of shocking, but the argument itself doesn't hold water. Speed is not just about money/social status, it's also about connectivity. And because of that, I'll refer you to this 10-year-old article: https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/
"Most sites are now mobile friendly" No they're not, that is the very reason Alex is writing articles like these!
"If I developing for the government then you need to go even farther because you need to addresses disabilities. Actually if there is a huge problem, it isn’t JavaScript, it is the total lack of consideration of people with disabilities." I don't mean to pick on you, but you go from basically saying "only government websites need to worry about a11y" to "we should care more about a11y".
"Also this whole drive to make everything work on a cell phone is just a ridiculous idea" You're not even arguing it's impossible to make things work on cell phones, you're saying you don't see why we should. I think we've been past that debate for a good 5 years now.
I don't understand why this was aimed at JS like it was.
Bloat isn't the fault of any particular 3-50k framework.
The fact our current JS ecosystem is increasingly modular is both the cause and the solution to this problem.
Lots of people lazily include all of lodash or moment. While this is typically easy to remedy, ideally only what you need of these libraries. (Btw, Plenty of native and 3rd party alternatives exist for moment.)
NPM's vast module ecosystem makes replacing old bloated libraries an easier proposition than in many other environments.
As an example, I wrote an alternative to bluebird in 300-400 lines (functional-promises - fpromises.io). It's a drop-in for 80% of the API, and 90% smaller.
This is how the ecosystem evolves. Needs get met with better suited options.
It's unfortunate devs tend to wait until problems blow up. Ultimately this is a bug in human nature, not JavaScript.
For the record, Tom Dale and I discussed Chad's traces and the questions above. Thread here: https://twitter.com/slightlylate/status/1040270680179335168
ISTM that the tests are noisy on a large critical-path factor and seem mostly to measure the effect of loading script in parallel or serial; unsurprisingly, parallel is faster.
Chris Rosenau (above) makes a some interesting statements. I work for a company whose aim is to sell its products worldwide. So, the need for mobile speed on our site is real - and we fail, horribly. We are working to repair this, all the while being sensitive to accessibility as well. Developers need to advocate continually to our leaders and the businesses in which we work to provide visitors to our digital properties the best experience possible -- and DEFINE for them what that is. Good experience is not shiny, over-the-top interactivity.
Unfortunately, I think a lot of designers and developers got excited about the really cool stuff that could be done, that they forgot how to edit their work to make sure the really cool stuff was applied intelligently, at the right time instead of to ALL. THE. THINGS.
As for going back to paper, Chris Rosenau, sure. Why not? If you look at where we are headed in language today, emojis are taking over. We are not that far away from returning to hieroglyphics on cave walls. :-)
Can you use examples where the public sector sites where bad but have now been improved? That's a much more positive take.
Arthur:
I share that concern and I think it's a big part of why I haven't leant into the public-sector exclusion until now, several years past when this has become clear to me as an ecosystem-wide crisis.
Something I've been mulling over is a variant on a 90-day disclosure policy: https://en.wikipedia.org/wiki/Project_Zero#Bug_finding_and_reporting
E.g., if I privately report to you that your site is suuuuuper slow, I'd then reserve the right to note as much publicly 90 days later or whenever it gets significantly faster, whichever comes first. That would allow me to treat public and private sector slowness the same.
I do still worry that will raise the antagonism level to a place where folks won't want to partner on getting issues resolved, but it would increase the available data set I can talk about.
WDYT?
Thanks for the trace, Chad! It raises some questions (particularly as I can't re-run these tests since the script isn't available and I presume the experiments have been taken down):
- Why a desktop-class browser and CPU?
- Why is a Cable connection the right baseline?
- Does LinkedIn care about mobile users on these stacks? Is LinkedIn expecting growth to come from primarily desktop-oriented users?
- What causes hero images to be so frequently delayed?
- The time to deliver
https://www.linkedin.com/sailfish/api/feed/sailfishFeedUpdates?q=feedseems pretty variable. How was that controlled for, as it seems to be critical-path?
Thanks again for adding context. I wish the original post had included this link so that the conversation could have been data-driven at the time.
The goals and means of any product are driven by its management, and that is where the responsibility to the customer lies. Developers only have a "privileged position" if their management allows it to be so.
Calling out javscript specifically as a culprit is also nonsense, especially when comparing it to CO2 emissions. I don't have much choice about the air I breathe, but I sure have a choice when it comes to what web content I consume. Websites that are not accessed due to their bloat don't make up part of any ecosystem.
When developers produce a website, they do so for their intended audience. If they are developing an e-commerce website, they don't develop for the poor. They develop for an audience that can afford their product and that audience in most cases has the technology to see the website just fine.
If I was a developer in Ghana for example, I would know my audience. That audience is about 90% cell phone users. Maybe 20-30% have smart phones. Thus I would develop for only for mobile devices and I would use almost no JavaScript.
Now if you are a corporation who wants the entire world to view your website. Well then I imagine more of them might be listening to your point of view. Yet that is already where things are headed. Most sites are now mobile friendly. Google has AMP which strips down what is delivered to mobile devices. As you say there are new frameworks like Vue.
If I developing for the government then you need to go even farther because you need to addresses disabilities.
Actually if there is a huge problem, it isn't JavaScript, it is the total lack of consideration of people with disabilities.
Also this whole drive to make everything work on a cell phone is just a ridiculous idea. We might as well go back to the origin of the World Wide Web and just have everything be text. Remember libraries and internet cafes? These still have a use in many places in the world. Or maybe we should go back to paper. Paper actually is a bigger screen size than stupid cell phones and requires zero energy to use.
(Appreciate the article)
Hey Bill,
Sorry about that. You can see the source side-by-side here: https://www.webpagetest.org/video/compare.php?tests=180831_25_3a7e0326e5deb329b760f6241b3a87f5-r%3A1-c%3A0%2C180831_Q2_36cc2c3f96e11252eb47d7ce521891bf-r%3A1-c%3A0&thumbSize=200&ival=500&end=full
"Sorry for the delay, just waiting for my computer system to load up"... sound familiar?
I'm surprised you left out tracking. Though IME it's used reasonably in the public sector, go to a news site without an ad blocker and it's not the framework that hits you, it's the 50 ad trackers.