The "Developer Experience" Bait-And-Switch - <AUTHOR> https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ <comment><USER2> 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.

<comment><USER3> > 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.

<comment><USER4> 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.

<comment><USER5> 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.

<comment><USER6> 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.

<comment><USER7> 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.

<comment><USER8> 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.

<comment><USER7> 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.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> 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.

<comment><USER11> 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.

<comment><USER10> 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.

<comment><USER12> 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.

<comment><USER10> > 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.

<comment><USER13> > 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.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> 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)

<comment><USER16> 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?

<comment><USER17> 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)

<comment><USER16> Thank you!

</comment></comment></comment></comment></comment><comment><USER18> 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.

<comment><USER8> 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?

<comment><USER19> > 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.

<comment><USER20> 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.

<comment><USER21> 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?

<comment><USER20> 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.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> 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.

<comment><USER22> 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.

<comment><USER23> 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.

<comment><USER24> 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.

<comment><USER25> even the nexus5x is a magnitude beyond what actually poor low income households typically have access to. think feature phones not smartphones

</comment></comment></comment></comment></comment><comment><USER26> 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.

<comment><USER27> 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.

<comment><USER28> _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.

<comment><USER27> 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.

</comment></comment></comment></comment><comment><USER29> 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?

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

<comment><USER31> 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

<comment><USER30> 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.

</comment></comment></comment></comment><comment><USER32> 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.

<comment><USER33> Cheers to this! ...so much bitching and moaning around here

</comment></comment><comment><USER34> "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.

</comment><comment><USER35> "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?

<comment><USER36> Author of the article here; you'd be truly shocked.

<comment><USER35> 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.

<comment><USER36> 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)

</comment></comment></comment></comment><comment><USER37> 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.

</comment><comment><USER38> 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.

<comment><USER39> 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.

</comment></comment><comment><USER40> 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.

</comment><comment><USER41> 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.

</comment><comment><USER42> 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.

<comment><USER43> 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.

</comment></comment><comment><USER44> _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.

</comment><comment><USER45> 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.

</comment><comment><USER46> 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!

<comment><USER47> 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)

</comment></comment><comment><USER48> > _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.)

</comment><comment><USER49> 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?

<comment><USER43> 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 ;)

</comment></comment><comment><USER50> 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.

</comment><comment><USER51> 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" ?

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

</comment></comment><comment><USER53> 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.

</comment><comment><USER54> 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).

</comment><comment><USER55> >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.

</comment><comment><USER56> 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.

</comment><comment><USER57> When your website has a "loading screen", you fucked something up.

<comment><USER58> This metric is over-simplified by a huge degree. I also agree with you completely. Made me laugh, too.

</comment></comment><comment><USER59> 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.

</comment><comment><USER60> 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

<comment><USER36> 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.

<comment><USER21> 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.

<comment><USER36> 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.

<comment><USER21> 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.

<comment><USER36> 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.

<comment><USER61> 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.

<comment><USER36> 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.

<comment><USER61> 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?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER62> You can call me a small town coal miner then.

</comment><comment><USER63> 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?</comment>


Facebook considers your current IP address to be "public information" as well - <AUTHOR> http://jwz.livejournal.com/1234802.html

<comment><USER2> Okay, this is getting out of hand. And by this, I mean everyone crying wolf at Facebook. I'm none to pleased about the way the site is going these days either, but IP addresses = "public information"? Did someone forget how email headers _work_?

<comment><USER3> There is no reason any Facebook user (including hackers) would expect this information to be available.

Scenario: I would like to know your IP. I sign up for a throwaway FB account (perhaps through a proxy), send you a message designed to evoke a response (even if it's "Who is this?"). I have your IP.

Typically websites will only reveal users' IPs to administrators, moderators, owners, and/or peers when direct P2P is involved.

I also highly doubt this practice is described in their privacy policy.

<comment><USER4> I used to curate a small social site whose topic was somewhat sensitive. IP address exposure became a significant concern with the population. An earlier administration had left it on. Particularly as the site grew and became less "cozy", and as the user base become more informed on the topic of IP addresses, users including old-timers used to the extant exposure became worried. When control started to be passed off to me and a few others, we turned it off.

A significant fraction of the lack of concern in such situations is due to lack of knowledge and understanding. Once users -- users in general, and not just the "technophiles" -- become aware of the situation and potential issues, a significant fraction DO have concerns are very explicitly DO NOT want the "features"/exposure.

A specific example of the latter. Our site was, aside from IP addressing, totally anonymous. Pick a pseudonym, create an account, and you were in. If you caused problems, you would be warned and, if you didn't get a clue, eventually banned.

There was, as there is in most populations, a subset of particularly manipulative users, some with what I guess might be described as "borderline personality issues". One of these went on a kick, including possible multiple identities, causing me to dig in a bit. The combination of IP address -- with attendant locality -- and a reference an unusual hobby -- meant that in under five minutes, I could have driven up to her doorstep. (And, BTW, that would have been in a rural location where help is not a few minutes away.)

Of course, I didn't use the information that way, but it was useful in reminding her, in a suitably oblique and non-threatening but pointed enough message, that her shenanigans were a bit more transparent than she might have thought.

The premise that "privacy is dead" and that there is no real value for users in maintaining it, is completely fallacious. I've personally witnessed, very often, very significant, meaningful exchanges occur in the context of and precisely because of such privacy and anonymity. There are sensitive issues that you may NOT share in common with your neighbors, family, friends. Even when some of those people are supportive, they may not share the actual experience, nor be sources of useful information and counseling on how to address it. And not infrequently, those people are actually the source of problems. And they often know each other, so that if you speak with one, it influences other relationships.

People on the community I curated did expose their real identities to each other. But it was usually in private -- out of band -- via email, IM, and the like. And it was after getting to know one another within the context of the community and coming to trust each other enough to do so.

If a stranger walks up to you and asks you for your phone number, it's unlikely you will provide it -- not solely on that basis. Online social networks need similar contexts. You exchange personally identifiable information if and only if it suits you and AFTER you've established some trust.

ADDENDUM: Facebook, per its terms of service, does insist on a real name. Depending on one's name, that is more or less unique. But it doesn't (so far, at least) insist on your location (or maybe I've forgotten this, having entered a very "vague" big city name, myself) nor necessarily expose it as text. They turned off privacy for profile pictures, but as of this point at least, you don't have to provide one or a picture that is of you.

Their message facility implies privacy. It's a principal means for communicating with another user who is not a friend. Exposing IP addresses can provide fairly specific locality. (Comcast DNS entries are one example I can think of that narrow things down considerably.) The stalker potential is not inconsiderable. (And, to bring the topic of forced public profile pictures up again, combine this with a pretty picture, and you may have one source for a potential problem.)

In the past, social communities have served specifically as a layer of abstraction between users and IP addressing. Administrators had access to addresses, and so one needed to establish trust for a site. But other users did not. Kind of like going to a party. The host may have invited you, and you might wear a name tag, but you don't write your address on the tag.

Have you ever gone to a party or meeting where they surprise you with an attendee address list to be shared publicly? Feel a bit queasy when you learn of this? Start trusting the host less? Just write down your name, or name and a suitably large city name that you live in or near?

Actually, I recall something like that, a few years ago, having both U.S. citizens and Canadians. The U.S. citizens coughed up their full addresses and phone numbers. The Canadians almost all kept it to "Vancouver, BC" or similar, and if they provided any specific means of contact, it was an email address -- mostly of the gmail or hotmail variety.

</comment></comment></comment><comment><USER5> Interesting, of course your ip address is normally present in the headers of your email anyway, but using a service like facebook (which has a pretty high stalking potential) you might not want to give that much away, especially not when you think that such info is safe.

<comment><USER6> Use a webmail service which doesn't purposefully append this information to headers and your machine's IP never surfaces. Gmail is one, I believe.

</comment></comment><comment><USER7> Many webmail providers put the originating IP address in the headers in order to be able act later if the message turns out to be spam. Hotmail, Gmail and Yahoo all do it - I just checked. As others have said, this is not news.

Correction: Gmail does not do it when submitting using webmail, only when submitting via SMTP.

</comment><comment><USER8> The difference between sending a message via facebook and via smtp, is that in this case facebook is appending your ip address on purpose. I mean, if I wanted to do the same with my web apps, I'd have to specifically tell my email framework to include the ip of the user.

</comment><comment><USER9> Is there anything that Facebook doesn't consider "public information" anymore?

<comment><USER10> Anything Zuck writes. Their code.</comment></comment>