
The “Developer Experience” Bait-And-Switch - feross
https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/
======
vorpalhex
I'm a javascript developer, and I agree heavily with this article.

The web experience has gotten worse these past few years. I don't want a
stupid autoplaying video following me around on the damned page. I don't want
Facebook to track me endlessly and mastermind what I see.

There are some really cool things the web has gained. WebRTC, ubiquitous web
previews, and using mp4s to add cheap animation. I'm also glad Flash has
finally been killed off.

We should be focusing on providing well crafted, clean and slim experiences
that are thoughtful and not bloated. Get rid of the 10+ trackers, the kitchen
sink approaches, and all the cruft that isn't directly useful. At the same
time, let's maybe not have a single entity own this slimmed down platform
(AMP), but have it be the normal experience.

~~~
dunpeal
> I don't want a stupid autoplaying video following me around on the damned
> page. I don't want Facebook to track me endlessly and mastermind what I see.

Those autoplaying videos and trackers are the reason these pages are there in
the first place. All the free content and services on the web has to be paid
for somehow, and that is the way.

It's not as simple as:

> Get rid of the 10+ trackers

Sites like Facebook can't just do that, that's how they make money and stay in
business.

This is a business-model problem, not a technical problem. If anything, new
technology allowed these business models to be slightly less annoying and
damaging to the user experience.

~~~
drb91
This is an easy argument to make when there's conveniently no way for
consumers to decide how they want to pay. Realistically, humans are just lazy
about finding decent ways of monetizing their time. I can't say I'll shed any
tears if a business relying on ads goes out of business from my ad blocker:
they always could have asked me for my cash.

~~~
prostoalex
Consumers will pay for the services that _consistently_ deliver value, but
most of media out there delivers value occasionally. And that’s assuming some
exclusives, where a competing publication is not a click away.

When even the mighty NYT and WSJ have issues monetizing their Web presence,
what hope is there for smaller fish?

Do I read an occasional article from The Guardian or Venture Beat? Yeah,
happens every now and then. Am I willing to pay for it? Unlikely.

~~~
mcbits
Where media struggles is in spending hundreds of dollars per page of content
that has an effective lifespan of about 1 to 5 days before it goes off to the
virtual landfill (formerly a real landfill), never to be seen again.

Maybe they need to ditch the daily blog-feed style of journalism and direct
their resources toward building a more cohesive/holistic archive of events
that provides some lasting interest and value, so they won't need to
desperately squeeze revenue from each article as aggressively as possible
before the aggregators drop it.

~~~
omnimus
I think they try to. But it might be that it is actually much cheaper to write
small daily articles that junior people can write than to write extensive high
quality stuff. That puts you under constant pressure.

~~~
TeMPOraL
Which is precisely why they have a problem with monetizing. I can't really
sympathise with that. Why should I care if the business model of flooding
people with crap, occasionally containing some gems, is in trouble? Drop the
crap, drop the frequency, send only gems when you have them.

~~~
omnimus
Well that goes against attention economy we have today. Slow news are not
news. I think what you want are magazines. It is precisely why they are not
dead. In fact they had dip but now they are growing again.

------
xenadu02
Is no one on HN willing to wrestle with the actual premise of the article?

> A rhetorical substitution of developer value for user value [...] > The
> “developer experience” bait-and-switch works by appealing to the listener’s
> parochial interests as developers or managers, claiming supremacy in one
> category in order to remove others from the conversation [...] The unstated
> agreement is that developers share all of the same goals with the same
> intensity as end users and even managers. This is not true. > Shifting the
> conversation away from actual user experiences to team-level advantages
> enables a culture in which the folks who receive focus and attention are
> developers, rather than end-users or the business. It naturally follows that
> teams can then substitute tools for goals.

Our community is absolutely infested with this attitude right now.

Tell me: When was the last time someone provided battery life impact numbers
for React Native? If you use it, was that even part of your evaluation
criteria?

The OP is absolutely right: there is massive conflation of _developer
convenience_ with _user experience_. The modern frontend web dev scene is
merely one of the symptoms. The fundamental assumption that "good for
developers" must by definition equal "good for users" is a) usually unstated
and b) absolutely unquestioned. I agree with the OP that it is also often c)
wrong.

In some cases necessity has caused some developers to internalize and
stockholm-syndrome themselves into believing some cross-platform monstrosity
or PWA-in-a-mobile-app is better or just as good as a native mobile app. Not
because it is, but because they have no choice given their current budget and
staffing constraints.

A successful startup requires clear level-headed thinking. Do not mistake
expedient or necessary decisions for optimal ones and be willing to re-
evaluate your strategy at any time. Above all don't talk yourself into
believing user experience doesn't matter.

~~~
linuxftw
We live in a world of 'ship MVP, gather customers, exit'

Of course the developer experience is going to be front and center, when
you're trying to start a new product and don't want to invest actual money
into it for real developers, you need something quick and dirty to move the
project along.

I'm firmly in the camp that javascript 'webapps' are crap and make the web
less web-like, the web I came to enjoy. I reluctantly admit that the ship has
sailed and I enjoy the web less now.

~~~
chillacy
Customers are somewhat complicit too, by choosing buggy products with more
features over stable products with less. It turns out having a buggy product
is still more desirable than not having the product at all. Also if asked to
put a price on stability or performance... I suspect that number is going to
be smaller than necessary.

~~~
linuxftw
I think the take away lesson is: Don't write great software, have a great
sales team. At least, that seems to be the sentiment of all the failure
stories posted around these parts.

~~~
TheHegemon
Working in enterprise software I unfortunately agree with that statement.

Our product is terrible and yet we can signing all of these giant contracts.
It is a bit disheartening to realize as long our stuff "almost works" and we
keep pushing out features then we will keep growing.

~~~
linuxftw
> Our product is terrible and yet we can signing all of these giant contracts.
> It is a bit disheartening to realize as long our stuff "almost works" and we
> keep pushing out features then we will keep growing.

If you have an enterprise support model for your product, client turnover
would be a leading indication of how successful the software really is. High
renewals and good margin is a successful software product. Whether or not the
companies that buy it are completely wasting their money doesn't seem to
matter much as long as they all don't go belly up at the same time.

It's also important to realize, if your company is so bad, yet getting so many
contracts, how bad could those other companies actually be? The answer is:
really, really bad. Fortunately, the IT industry as a whole has convinced the
entire world it needs to 'go digital' or their competitors are going to beat
them to the market with their 'data analytics.' While it's probably true for
many businesses, I think the vast majority is companies wanting to appear cool
and hip.

~~~
flukus
> client turnover would be a leading indication of how successful the software
> really is

Not necessarily, after the original investment and installation there is a
least one person and possible several higher ups with a vested interest in the
project being a success and ending the support would make them look bad. Going
through all that again and replacing your software won't happen until a new
batch of managers champion the cause and will possibly happen even if your
software is best in class.

I think a better measure would be their willingness to adopt other products
your company builds.

------
dreamcompiler
The _vast_ majority of modern websites could easily deliver their existing
functionality (except with better interactivity) with server-side rendering
and just enough plain-vanilla javascript to handle ajax calls.

If you don't believe this, I suggest you carefully reexamine your assumptions.
A number of them are almost certainly false.

~~~
mrdoops
Don't even need Ajax anymore. You can render on the fly, and deliver new HTML
over websockets. The gap between SPA and classic server-side rendering is
getting smaller fast.

[https://youtu.be/Z2DU0qLfPIY?t=14m58s](https://youtu.be/Z2DU0qLfPIY?t=14m58s)

~~~
Noumenon72
I watched 3:15 of that and he was still just getting started. Do you think you
could provide a link to the good part?

~~~
mercer
I can recommend watching the whole thing, but I thought this bit was a pretty
cool demo:
[https://youtu.be/Z2DU0qLfPIY?t=41m20s](https://youtu.be/Z2DU0qLfPIY?t=41m20s)

~~~
Noumenon72
Thank you!

------
jbeckham
Honestly, I didn't read the entire article. By the sixth paragraph, I already
identified that the author was blaming the use of a tool for bad product
management and software development practices.

All of the problems blamed on "javascript" in this article aren't a problem
with javascript itself, but the improper usage of certain frameworks in
certain circumstances. Using a big bulky framework for an internal application
where you know the user is constrained to machines that can perform well with
that stack is fine. Using that same framework on a public web application that
will also be hit by mobile applications is not. The problem isn't the
framework, it is that the product team did not properly vet the performance
impacts of the development team's choice of framework or did not properly
specify the performance requirements for the product. One other option would
be that the governance structure for ensuring that those requirements are met
before release was insufficient. Either way, the problem isn't "javascript",
but the SDLC processes used to build the software.

~~~
TeMPOraL
Now if majority of new websites exhibit that problem, how do you classify it?
Can you really blame the whole world for misusing a tool, without taking a
critical look at the tool itself?

~~~
rauhl
> Can you really blame the whole world for misusing a tool, without taking a
> critical look at the tool itself?

I’m reminded of all the folks who — in 2018! — try to claim that C is a
perfectly good tool for writing large, secure systems. Never mind that it
loads a gun, puts it in your hand, cocks the hammer, points it at your foot,
puts your finger on the trigger, and pulls back _just_ to the release: the
fault is really only yours if you shoot your foot — or so these folks say.

~~~
philwelch
C is more like operating a very large saw without a handguard. If you're
skilled and you know what you're doing, you won't cut off your fingers. Which
means the median developer cuts off his fingers.

JS (and, more to the point, heavyweight JS framework code) is more like
driving a massive SUV around everywhere because you think having to drive
through snow and mud is more likely than having to park downtown, when really,
all you do is drive around downtown in the summer. But you don't care, because
you have a parking valet.

~~~
pjmlp
We all know how scrutinized Linux and BSD kernel development is and yet CVEs
due to memory corruption happen all the time, to the point Kernel safety was
the major topic all Linux Security Summit 2018.

If the best aren't able to write safe C what to say about everyone else?

~~~
philwelch
I wouldn't use a power saw without a handguard, either. But I'm not gonna tell
Linus the master carpenter that he can't use his antiquated power saw. Sure,
he only has eight fingertips, but he also built the tower we're all standing
on right now and continues working on it to this day, so if he's really doing
something wrong, the only way to prove it is for someone to get a newfangled
power saw, with handguards, and build their own tower. And maybe, someday,
someone will do that, and we will look back on the days of poor old Linus and
his seven fingertips and wonder.

------
feross
Alex Russell first diagnosed this problem at Chrome Dev Summit in 2016 in a
really amazing talk:
[https://www.youtube.com/watch?v=4bZvq3nodf4](https://www.youtube.com/watch?v=4bZvq3nodf4)

He makes the point that lots of JS frameworks are so large that you're already
doomed before you write the first line of real "app code". The framework
itself has already blown your performance budget.

~~~
MentallyRetired
This argument comes up frequently though. As computing power increases, the
complexity of applications (no matter what machine they're running on) will
increase. What's the point of having faster hardware if the experience is only
the same but faster? People want more capabilities, and JavaScript provides
that.

~~~
jazzyjackson
One point made in OP is that not everyone has the latest fastest hardware. Did
you check out the clip comparing code.gov rendering their SPA on a new iphone
vs a lowend android device ? Millions of people are dealing with extremely
subpar experiences because developers are building their website on a work-
provided macbook pro on a gigabit connection to their office...

Sure, chrome lets you simulate 2G connections and all that, but last time I
checked it didn't simulate the slowdown of compiling 2MB of javascript on an
old phone. Could be a revealing constraint to put in the developer tools.

~~~
gboss
You actually can throttle your cpu with chrome developer tools. I often use it
when profiling my client side code. I also don't like to have the fastest
phone, I have a Nexus5x, because it helps me know if it works on my phone it
will run great elsewhere. I recommend other front end developers do the same.

~~~
kkarakk
even the nexus5x is a magnitude beyond what actually poor low income
households typically have access to. think feature phones not smartphones

------
andrewstuart2
The argument of "JavaScript is bad" or even "JavaScript is necessary but only
in small amounts" is getting pretty tired. I don't think anybody could
possibly hope to argue that all client-side code is bad, but that's all
web+JavaScript is: an easy deployment platform, for both content creator and
consumer, for client-side code. Where else could you deploy and within seconds
your customers have your new code?

If you're worried about how easy it's becoming to track people in the browser,
or to track people in the Internet ecosystem in general, that's an entirely
different conversation. JavaScript has absolutely nothing to do with the
security and privacy status of the web aside from what it is allowed to do per
web standards.

Stop blaming a language or the ability to write anything Turing complete when,
clearly, it's just a tool and the same problems exist in every single code
distribution arena.

~~~
jondubois
Agreed, it's a poor argument.

I once worked for a hardware company which manufactured Set Top Boxes (like
TiVO). They could have developed the UI engine in any language, but they chose
JavaScript (running on their own custom JS engine). It's surprising how many
companies use JavaScript to implement the UI for their hardware devices; to
infer that developers only use JS because they don't have a choice is
inaccurate.

JavaScript has become a great language. I've programmed in pretty much
everything else so I think I'm qualified to say this. In my opinion, if a
developer needs to know just two languages today, it's JavaScript and C/C++.

With knowledge of JavaScript and C/C++, you can do anything on any device. A
developer who knows JavaScript and C/C++ is usually a pragmatic developer; a
good developer.

~~~
scarface74
_I once worked for a hardware company which manufactured Set Top Boxes (like
TiVO). They could have developed the UI engine in any language, but they chose
JavaScript (running on their own custom JS engine). It 's surprising how many
companies use JavaScript to implement the UI for their hardware devices; to
infer that developers only use JS because they don't have a choice is
inaccurate._

This is true. Another example is the 2nd and 3rd gen AppleTVs. They were based
on iOS but the “apps” for it were all hosted on top of WebKit using Apple’s
own markup language - TVML.

While I’m definitely not a fan of the movement toward JS everywhere, I have to
admit that of you want to tie your horse to one language, JS is the way to go.

~~~
jondubois
I remember at the company I worked for, we used AppleTV as inspiration for our
own UI so it makes sense why we would use similar tech.

------
mifreewil
This article seems to start with the premise that JS-heavy frontends improve
the developer experience. This, I would heavily challenge.

Compared to a Rails, Django, Express.js, or any similar more-traditional
framework that does server-side rendering with HTML templates, a little bit of
JS and AJAX sprinkled in, SPA apps with frameworks like React are
significantly more complex and requires more specialized knowledge on the
frontend. I'm just starting to dive into React and Redux, and the amount of
jargon and complexity is mind-blowing. All to solve the complexities of what?
Bigco's massive bloated app with thousands of developers working on it?

~~~
wgerard
> Compared to a Rails, Django, Express.js, or any similar more-traditional
> framework... SPA apps with frameworks like React are significantly more
> complex

Hmm, I don't agree with that at all. I work with Rails and React daily, and
they're about equal complexity to me - React just tries to hide it less.

Rails especially can get incredibly complex the second you try to do something
in a way that's not the "approved way".

~~~
dagoat
Do you have any examples of incredibly complex rails? Also, I thought rails
was supposed to be a lot of magic - hiding the complexity from the developer

~~~
wgerard
Hey! Sorry, I missed this comment.

It's changed recently I've heard, but up until recently making a model without
using ActiveRecord was a huge PITA that mostly engendered "don't do that"
comments.

------
davnicwil
I really disagree with the philosophy espoused in the article, which is that
the web will not succeed for 'users' in this or that place on this or that
hardware unless 'developers' decide to do things in a certain way.

This is not what the web is about, at all. The web is not centralised, relying
on all-powerful 'developers' to decide to build things for 'users' who are
powerless and must accept what they are given. It's the opposite. If people
don't like things they can build better things themselves. If something
doesn't work for them, they can build something that does. The tools are out
there, the knowledge of how to use them is out there and freely available,
there are practically no barriers to entry to building stuff assuming you have
a computer and an internet connection.

So, yeah, just build things in the way you think is best. If people don't like
it they won't use your thing, and will use someone else's thing that serves
them better or just build their own. That's both the greatest beauty and the
greatest strength of the web.

~~~
seandoe
Cheers to this! ...so much bitching and moaning around here

------
headcanon
"More JS" vs "Less JS" is oversimplified - what are we building here?

\- A web _app_ that exists as a tool users log into? This kind of thing would
have used to be a desktop app. I'm perfectly fine with a 1-2MB JS bundle. The
images and other data you're downloading will soon be much greater than that
size. App too big? split it up into modules. Targeting users with 3G or worse
connections? Ok, lets look at server-side rendering with a simplified
experience. I don't think apps like this are really the problem here. If it is
a powerful app I don't mind waiting 5-10 seconds for everything to load, so
long as there is a good user experience around loading. These are the kind of
apps I build in React and they load fast and feel fast, even on cell
connections. Our speed issues and optimizations are generally elsewhere,
usually on server-side data fetching. Granted I haven't worked anywhere that
has users with flip phones in far-off countries. I would probably choose a
different strategy in that case.

\- A media-heavy web _site_ that displays content for non-authenticated users?
These have tons and tons of tracking JS and other things, not to mention the
hated auto-play videos and intrusive ads - I think thats the "CO2" that the
author is talking about, but the issue is mostly organizational and economical
- these companies are made up of large numbers of people who all need "just
one more script", or are getting paid to insert garbage into their page. This
is a shame and we can complain about it all we want to but until the economics
behind web content improve I don't see that underlying issue getting fixed.
This is the problem that AMP is trying to solve. I agree that it shouldn't be
proprietary, but you can't expect everyone at a media company to think like an
engineer and prioritize site load time over the big bucks in analytics and
internet chum, unless it gets too bad. Companies will do what they can get
away with, whether its CO2 or JS.

------
hyperpape
"A decent hedge-fund strategy would be to run a private WPT instance and track
JS bloat and TTI for commercial-intent sites — and then short firms that
regress because they just spend 3-8 quarters rewriting everything in The One
True Framework."

For a post that weighs so heavily on the need for evidence, this claim doesn't
have any. There have to be cases where bloat has a material impact on a
company's finances, but how frequent are they?

~~~
slightlyoff
Author of the article here; you'd be truly shocked.

~~~
hyperpape
I have carefully considered this comment, and decided that it's not evidence.

Now, you're working at Google, and it's definitely possible you're privy to
great evidence that you're not sharing. But saying "you'd be truly shocked" is
still not really good evidence.

I know there were the Amazon studies where there's a tight link between
latency sales. I don't dispute that latency matters. I personally love
websites that load fast, have no JS on my personal site and no more than 20
rules. I just haven't seen actual up to date reasons to believe that modern
web development is hurting the bottom line for most businesses.

~~~
slightlyoff
The entire post is premised on frustration in my ability to share what I know
in order to avoid punching down. That I can't share specifics is the whole
reasonto try another tack.

See also: [https://wpostats.com](https://wpostats.com)

------
sequoia
re: "is it the tool or is it developers using it wrong" it's clearly the
tool(s). It's like the JS scene can't leave well enough alone and must
constantly reinvent everything, and anyone who preaches restraint is regarded
as a luddite who "just doesn't get it."

I mostly blame the "JS thought leaders" i.e. people who should know better.
They hype one tool after the next with little to no concept of the cost of
obsolescence (having to throw out your 2 year old new web app), which is yet
another major issue with JS hype. Then employers ask for the tool, then devs
_have to_ learn the tool whether they want to or not if they want to match job
descriptions. Everyone's afraid of "falling behind" and as a consequence
everyone rushes headlong.

Ironically, given that this article is about DX, the JavaScript ecosystem has
in recent years been regarded by many as an insane mess of infinite
complexity, majorly frustrating many developers who have jobs besides just
learning (or teaching) new frameworks. That is to say, _I don 't think these
costs have even bought us good DX._ They've bought a "lowest common
denominator" environment where you can hire a new dev bootcamp grad to build
your website and your app quickly and cheaply and agile-ly and quickly and
cheaply and... did I say quickly? Nevermind the mess you'll spend years
cleaning up.

Summary: JS (and beyond) thought leaders & framework authors are selling
silver bullets and businesses just can't say no.

------
icameron
I think of a site like Wix that enable anyone to build a website in minutes in
a point-and-click interface. Very heavy javascript. A basic template makes it
super easy for the 'developer' and the result is huge mess. The landing page
I'm looking at loads 102 scripts, 2.0MB 23 fonts and stylesheets, 13.8 second
total load time.

~~~
superkuh
It doesn't matter to the devs behind wix because people like me are so few,
but I always close wix sites instantly.

That's because not only do they load a lot of JS but they load it serially.
Each domain requests JS from a new domain and it takes 3+ interactions of
noscript + reloading to get anything rendered at all. If they'd just have all
the script domains requesting in the first load it'd be fine.

------
reissbaker
I hate autoplaying videos and bloated adware as much as anyone else on here,
and I'm very partial to arguments in favor of increased accessibility. But the
thesis of the article is that optimizing cost-to-produce at the expense of
time-spent-waiting-for-the-page-to-load is an optimization that fundamentally
undercuts the poor.

There wasn't much data showing this to be true, and I suspect the opposite may
be. If reducing pageload time increased costs, would poor people be happy to
pay more for the faster product, or would it just drive them out from being
able to afford it? Or in the case of free services that make money via
advertising and tracking, would it be better to do more of that to pay for the
extra cost needed to produce the good in order to shave off pageload time? I'm
not so sure. "Make it better and more expensive" is an easy argument to make
if you're a wealthy software engineer, but I'm not convinced that applying
"better and more expensive" as a value helps those lower on the socioeconomic
ladder.

Focusing on "make it cheaper to be better" seems like it would do more to make
experiences more equitable — i.e. we should improve the developer experience
of high-performance open-source tools so that it takes less time and costs
less to make better products, rather than driving up the cost of production at
the (literal monetary or privacy) expense of users in order to produce a
faster product.

Edit: Or, y'know, we should pay CEOs less and use those savings to make better
products without increasing the costs passed on to our users... But somehow I
don't see that happening any time soon.

------
cozuya
Probably off topic, but I have to relate this anecdote because its just so
funny to me.

I took a new job at the beginning of the year. It was to lead development of
v2 of an internal app originally written in Angular and convert/upgrade it to
React.

I poked around at it a bit before getting started. It seemed fine, maybe a
little slow.

My version got to the point where it could get up to a dev environment. It
again seemed a bit slow. I took a look at the build process and realized it
did not include gzip (express/compression). I added that in and yeah it seemed
about right.

I then took a look at legacy production and... you guessed it, in production
for over a year this product had no gzip and was serving a JS payload of 5x
what it could be, around 5mb. And no one noticed!

My point is people just don't care or maybe they're just inured to it at this
point. There's a lot of "oh for every 100ms of loading time Amazon.com loses
$xxMM" talk but in the real world? Not what I'm seeing.

------
strken
Every time I read an article like this, I agree with it, and a lot of
developers seem to be the same.

Two things are stopping me from actually doing this. Firstly, and most
importantly, my boss isn't reading articles explaining why accessibility and
quick load times will make him more money. Secondly, I've been present for
some absolute disasters that happened because of the combination of AJAX,
jquery/vanilla js, server-side MVC, and scope creep, and I don't know which
frameworks or development patterns I can use to stop that happening on a
project that I have more control over while still keeping that project
lightweight.

Articles that give clear and actionable suggestions, or are targeted at the
people who make high-level decisions about what features go into a product and
how many third-party scripts should be installed, would be more useful than
articles about how developers are very naughty for adding 10+ ad trackers and
UX tools.

~~~
n_ary
Agreed. No dev in their right mind would intentionally attach these bloaty 20x
more script spawny advert/trackers or put an irritating popup, most of these
are signs that at some point in time, there was a bad decision and dev had a
gun at their head to make that decision material.

------
gramstrong
_I hope that by talking about what it means to build well when trying to serve
everybody, we can show businesses how short they’re falling of the mark — and
why those common root-causes in JS-centric development are so toxic._

I guess I hope that you're successful, but one would assume that if today's
Javascript climate was so toxic and having a tangible effect on your average
user (not just the Hacker News user), then...there would already be swarms of
clever individuals capitalizing greatly on this apparently obvious state of
the web.

------
jasim
This will fall in deaf ears, and maybe rightly so, if computing history is any
guide.

In 1954, the biggest issue John Backus had to overcome for FORTRAN was
performance: "it is difficult to convey to a reader in the late seventies the
strength of the skepticism about "automatic programming" in general and about
its ability to produce efficient programs in particular, as it existed in
1954."

But the world went on to use higher-level languages with worse and worse
performance characteristics.

We can't blame developers trying to use better tools (we could, but that
wouldn't change a thing). DOM, CSS, and the imperative mutation model was a
curse on front-end development, ensuring that only companies as big as Google
could write something like GMail (for which they wrote their own Java-to-
Javascript compiler first). If something needs fixing it is the underlying
browser model. Maybe it will get fixed sometime if this trend continues to its
terrible but logical extreme, and something finally gives.

This is also purely a matter of cost - if businesses do care about performance
then they'll have to put more developers per team, spend money on training,
ask for fewer features slower. If performance _really_ mattered, then they'd
see a loss in revenue, and as a natural response start talking about
performance in their agile meetings, and JIRA cards.

------
jpochtar
It's an incentives problem.

We could solve it if we checked performance like we do unit tests, and held
developers accountable to a literal performance budget set by the business.

> Few teams I’ve encountered have actionable metrics associated with the real
> experiences of their users.

Imagine getting latency numbers on load times, bundle sizes, TTI, and so forth
on every commit. PRs that blow the performance budget would be immediately
flagged. You could plan for performance like any other business cost.

Even nontechnical business leaders can understand reports like "3s load time",
and set tech team goals based on a relationship between load times and lost
sales. "Load time must be under 2s, even on old Android + Edge" is something
everyone can understand.

The article is right: what's most pleasant for the developer isn't necessarily
what's best for the business. If metrics like load times are only being seen
by developers, the developers have a moral hazard: either they

1\. make choices that benefit themselves, at a cost to the business

2\. make their own lives voluntarily worse, without recognition

The article is right again that sometimes, better DX is in fact worth worse
performance for the user. As with anything, it depends on the business.

But businesses won't accurately and fairly decide on their preferred tradeoff
if only engineers are in charge of it.

We need better performance infrastructure!

~~~
gergoerdi
As a positive example, GHC has tests that are run for PRs that check
performance (in terms of memory allocation):
[https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/...](https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding#Performancetests)

------
xg15
> _This argument substitutes good intentions and developer value (“moving
> faster”, “less complexity”)_

How can one even argue that as "less complexity"? Using a framework vastly
increases the complexity of a site. (Though it may hide a lot of it under a
rug, at least until the first bug occurs.)

------
xanderjanz
Have the people who complain about javascript page load performance read about
netflix.com? Netflix uses JS to render their landing page server side. No
client JS necessary. How can a page load faster than raw HTML?

~~~
n_ary
You do realise that Netflix doesn't need to depend-on/load adverts and mass
tracking scripts and given the company itself is tech based their sales
doesn't get the mighty power to force their devs inserting x40
tracking/adverts scripts and annoying popups? P.S. Netflix does ~17 ajax calls
immediately after loading to hydrate its SSRd page ;)

------
weberc2
I’m not a JS developer and I don’t have a dog in the fight, but the author’s
rhetoric is on point. No idea if it’s legitimate at all, but the carbon
emissions analogy seems rhetorically masterful.

------
ozorOzora
What if the issue was not restrained to javascript? What if the state of the
web was just another case of "victim of its own success" ?

~~~
tensor
In my experience, it's not only a problem with javascript. Developers putting
themselves above their users and non-developer teammates seems fairly
widespread.

------
y3sh
The problem goes beyond dev choices and UX. As an FE dev, it's advantageous to
your hiring options to gain experience with the latest shiniest frameworks. I
don't see any FE job postings asking for
YUI/Dojo/Mootools/Backbone/JavaScript-native anymore.

------
moron4hire
While I do agree with the general point of the article, I think that, like
most conservation arguments, it lumps the responsibility of cleaning up after
the sins of the biggest polluters on the daily habits of working class people.

We aren't going to make up for the emissions of shipping bottled water in
barges across the Pacific Ocean by taking shorter showers. And the issue is
not using JavaScript for features. The issue is the gigantic ad and tracking
networks that are being included, sometimes 10 or 20 at a time, in projects to
rob users of their valuable behavioral data. That also just so happens to be
written in JavaScript.

But in a world where one can get entire VR experiences out in less than half a
Megabyte of payload, it's ludicrous to think that something as simple as a
messaging app should take so much in comparison. But it's comparing apples and
oranges. The VR experience isn't spying on you (despite the fear mongering to
the contrary).

------
forgottenpass
>We’re meant to take it on faith that it will all work out if only the well
intentioned people are never questioned about the trajectory of the outcomes.

What a phenomenally articulated phrase with so many applications beyond
JavaScript.

------
iamleppert
Try championing any of this at any company. The thinking these days is if you
aren’t using react and webpack and a god awful bloat that comes with it you’re
not building a real application. There are so many new developers working at
companies that only know react. They don’t know anything else and they
certainly aren’t engineers. They have been taught one thing and the groupthink
is so thick you can cut it with a knife.

The problem is every react codebase I’ve ever worked on in my full time and
freelance work have been an absolute mess and downright painful to work in.
They don’t even fulfill on the developer promises. Can anyone even point to a
successful open source project using it?

I’ve literally made quite a good freelance business by targeting failed react
projects and rewriting them with vanilla js.

------
nothis
When your website has a "loading screen", you fucked something up.

~~~
tapvt
This metric is over-simplified by a huge degree. I also agree with you
completely. Made me laugh, too.

------
newnewpdro
I _feel_ like web sites are actively becoming hostile to drive users into
running proprietary mobile apps instead of spending time on the open web.

------
keithnz
well, WASM is going to change things a lot I think over the next 5 or so
years.

Things like [https://blazor.net/](https://blazor.net/) (though not necessarily
the first wave of these frameworks) are going to become more popular, and
there are various variants in other languages. I think there will be a slow
(very very slow) decline of js

~~~
slightlyoff
The "hello world" demo app appears to require ~1.3MB of transfer, nearly all
of it critical-path: [https://blazor-demo.github.io/](https://blazor-
demo.github.io/)

This future isn't better.

~~~
pjmlp
Most images on the modern Web are bigger than that and pages are full of them.

Also that is still WIP and doesn't yet make use of .NET linker.

~~~
slightlyoff
Images aren't as expensive as critical-path code as we (the browser) parse and
raster them off-thread. Outlined some of the costs here:
[https://infrequently.org/2017/10/can-you-afford-it-real-
worl...](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-
performance-budgets/)

Excited to see how much smaller a good linker can make this.

~~~
pjmlp
JavaScript JIT compilers also don't compile everything on one go.

I can easily imagine asynchronous compilation of Web Assembly modules in
background threads as its use increases.

~~~
slightlyoff
WASM streaming compilation is possible today and runtimes are adding tiered
compilers:
[https://v8project.blogspot.com/2018/08/liftoff.html](https://v8project.blogspot.com/2018/08/liftoff.html)

Regardless, as long as you're network-bound in the critical-path, that will
only help to the extent that partial execution works well. That is baked into
HTML/CSS/JS; not so much with WASM.

~~~
dikaiosune
How is partial execution baked into JS? IIUC, my whole JS file is fully parsed
an resolved before it is evaluated. If you're referring to the use of multiple
files for parallelism here, then the obstacle there is not wasm itself but the
work that's still in progress to define a dynamic linking story for it.

I'd point out that the need for better dynamic linking to enable lower TTI is
also a problem faced in the bundling/tooling heavy JS community.

~~~
slightlyoff
JavaScript can be evaluated top-level function by top-level function and file-
by-file, modulo variable hoisting. You _can_ create situations where
everything is blocked, but that's not the norm.

~~~
dikaiosune
Do you have numbers for how much of the web avoids variable hoisting? How much
of the web has more than one top-level fn per file? Do these numbers shift
significantly between different toolchains or methods of delivering JS?

------
darepublic
You can call me a small town coal miner then.

------
draw_down
A huge majority of the JavaScript for the project I work on is tracking
scripts explicitly requested by _marketing people_. They all disagree on where
analytic data should be sent to, so it ends up in Google Analytics, and
LinkedIn, and FB, and and and...

The developers on my team try to use just enough JS to accomplish what we
need, and almost all of the rendering happens server-side.

I think what I'm describing is an under-appreciated piece of the puzzle. How
many developers have you met who just _loooove_ Google Tag Manager?

