Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for The "Developer Experience" Bait-and-Switch


I really didn't expect to agree with this article... But I do. I don't see why you're squeamish about naming and shaming. Web sites are inherently public, and the tools used to access them come with the tools to profile them. Honestly, I needed to be reminded how bad things are for some people.

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.

by Sam at
Another metric is how much basic site functionality can be achieved with scripting disabled? Plenty of sites do not even display any text with JS disabled, use JS only links etc. i.e. not even basic site navigation / reading of content is possible
by Ken Brown at
Chris Rosenau,

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

by Mikael Gramont at
awesome
by Brisn at
This is a good argument to pay attention to code bloat, UX, tti, and perhaps scope creep.

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.

I worry that there don't tend to be a lot of people looking out for the well-being of developers, so many developers are forced to focus on themselves. The relationship between developers and all other teams in an organization tend to be adversarial: Mangers want tighter deadlines, Product Management wants more features. QA wants fewer regressions, Sales makes all sorts of promises that Developers are on the hook to deliver, Customer Support wants fewer bugs and more fixes, etc. The only people left to really worry about improving developer experience are the developers themselves. This, as you point out, leads to a really warped focus on the self and less on the customer and the marketplace. We've still got a lot to learn about how developers and the rest of the world interact and conversations like this one are priceless parts of that.
by Andrew Whitworth at

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.

by alex at
Thank you for advocating as you are. Like you, I love what Javascript is capable of providing, but I am not pleased with the resulting bloat of the "developer experience" designed solutions.

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

by Bridget M Stewart at
The only problem with picking public sector websites as examples is that it, however hedged, will feed the narrative of "private good, public bad" when, as you say, it's an equal problem in the private sector.

Can you use examples where the public sector sites where bad but have now been improved? That's a much more positive take.

by Arthur at

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?

by alex at
http://www.webpagetest.org/video/compare.php?tests=180202_67_ae21f1a34a7f570599edae125e1c292a%2C180202_RZ_4b410646d168afd7a5738f5325790254%2C180202_YB_3bf4cd9abf749f0a891451bac3d1f579%2C180202_VF_84ae556dc7c51e405d5fccccccb383ae&thumbSize=200&ival=16.67&end=visual
by Chad at

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=feed seems 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.

by alex at
Calling out developers for such issues is as much nonsense as calling out developers for the proliferation of loot boxes in modern video games (which I hear of quite a bit).

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.

by Dave at
I see your point, yet there are many different cases where this just doesn't apply.

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.

by Chris Rosenau at
Your video doesn't load for me.

(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

by alex at
Not just lower-tech phones that miss out, but call centers with 40+ older desktops on a single broadband connection can't handle our magnificent enterprise software creations.

"Sorry for the delay, just waiting for my computer system to load up"... sound familiar?