How JS Ruined the Web  ## Metadata - Author: [[Theo - t3․gg]] - Full Title: How JS Ruined the Web - Category: #articles - Document Note: --- tags: [#javascript, #webdevelopment, #frontend] - #javascript - #webperformance - #webculture Author: Jonno (critiqued by Theo) Source: YouTube - [How JS ruined the web](https://www.youtube.com/watch?v=O-QS_Cp_zXg) Reference: Transcript + Video date created: 2025-08-21 12:00 --- # Title: How JavaScript “Ruined” the Web – A Sarcastic Debate on Complexity vs Usability ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The video critiques Jonno’s article claiming JavaScript “ruined” the web. Theo, the YouTuber, argues that while modern sites are indeed bloated and often frustrating, the fault lies less with JavaScript itself and more with poor developer decisions, corporate culture, and ad-driven design. The discussion balances nostalgia for a simpler HTML-based web with acknowledgment that modern interactive apps (Gmail, Twitter, etc.) are only possible because of JavaScript. --- ## 📖 Main Content: The dialogue frames JavaScript as a double-edged sword: - It enables powerful interactivity, but also encourages complexity. - It creates both new user benefits (apps, instant feedback, real-time updates) and new user frustrations (slow loads, complicated builds). - Theo highlights cultural issues in software engineering: valuing complexity, DX (developer experience), and flashy frameworks over simplicity and actual user needs. ### 🗒️ Notes - [00:04](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=4): JS critiqued as bloating and slowing the web. - [05:26](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=326): Simplicity lost; now requires teams, pipelines, frameworks. - [11:25](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=685): Client-side rendering improves perceived responsiveness. - [17:10](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=1030): App-like promises fueled arms race of complexity. - [24:07](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=1447): Ads and incentives, not JS alone, “ruined” web. - [29:27](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=1767): DX ≠ UX, though tools like linters improve both. - [32:58](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=1978): WEBP shows how DX/UX align. - [34:41](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=2081): Complexity rewarded in teams, simple fixes ignored. - [47:58](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=2878): Web dev culture mirrors Linux modularity, but critics see “plugin hell.” - [52:51](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=3171): Most websites don’t need JS-heavy frameworks, but apps do. --- ## 📖 References: - Jonno’s original article (SEO consultant perspective) - Theo’s critique video - Historical examples: Yahoo Mail vs Gmail, WordPress, Angular, React --- ## 🗣️ Paraphrase: 1. Original: *“Most websites are awful: bloated, fragile, overengineered disasters.”* Paraphrase: Many sites today load poorly and are built with fragile over-complex systems, leaving users frustrated. 2. Original: *“We created an industry where complexity is celebrated more than usability.”* Paraphrase: Web development culture rewards intricate, flashy code rather than practical solutions that help users. --- ## 📰 Newsletter: 🎉 This week’s hot debate: *Did JavaScript ruin the web?* Theo’s breakdown of Jonno’s article pulls no punches—calling out bloated websites, endless frameworks, and developer-first culture. But the nuance? JS also powers everything from Gmail to ad-blockers. So is it the villain, or the tool we misuse? 👉 Dive deeper: [Watch the video](https://www.youtube.com/watch?v=O-QS_Cp_zXg) 👉 Pro tip for devs: don’t use React for a static blog. Consider Astro or plain PHP/HTML. WordPress folks, this should sound familiar: balancing DX vs UX, plugins vs performance, and marketers vs dev pipelines. Let’s keep building responsibly. --- ## ✅ Action Items: - Position critique of JS bloat in WordPress advocacy (ties to plugin misuse, performance debates). - Highlight parallels for contributor onboarding: tools should empower, not obstruct. - Connect complexity critique to OSPO goals: governance = ensuring tech serves *users* first. - Use as teaching moment: history of frameworks (Angular, React) shows cultural shifts in dev practice. --- ## 🧪 Hypotheses: - H1: DX improvements (frameworks, compilers) correlate with worse UX only when cultural incentives reward complexity. - H2: Sites using minimal JS for static content rank higher in SEO than heavy SPA sites. ### 📊 Methodology: - Data collection: Compare Lighthouse scores for SPA vs SSR vs static WordPress. - Qualitative: Developer surveys on DX vs UX priorities. - Historical: Archive analysis of pre- and post-JS adoption websites. ### ❓ Questions: - Does client-side rendering *always* feel faster to end users? - Are compilers and build steps inherently distancing devs from users? ### 🔮 Future Research: - Study of “perceived speed” vs actual latency in web UX. - Tracking plugin/JS framework misuse across CMS ecosystems. ### 💡 Implications: - Could reshape training: devs should learn UX trade-offs, not just frameworks. - Policy for OSPOs: promote modularity and accessibility over trendy frameworks. --- ## 🧠 Learning Styles Assessment: - Visual: Diagrams of latency perception were present (good). More infographics would help. - Auditory: No podcast/audio version. Suggest transcript-to-audio conversion. - Verbal: Strong narrative + analogies (email, SEO). Effective for linguistic learners. - Kinesthetic: Few actionable demos; could add hands-on coding challenges. - Logical: Solid causal reasoning diagrams, but some leaps lacked data. - Social: Chat interactions helped, but no structured forums. - Solitary: No reflection prompts; could add journaling exercises. - Naturalistic: No nature metaphors; analogy to ecosystems could work. --- ## 📊 Accessibility Assessment: - Semantic HTML not visible (since it’s video). Needs captions + alt-text for visuals. - Keyboard navigation not applicable. - Color/contrast: reliant on video editor’s theme—unclear. - Suggest: full accessible transcript with structured headers. --- ## 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - Cultural Relevance: Narrow framing—WordPress vs React; no global perspective. - Inclusive Language: Casual, sometimes dismissive (“slop”, “dumbass”). Could alienate. - Neurodiversity: Video fast-paced, sarcastic. Not accessible for ADHD/autistic learners. Needs summaries. - Representation: Mostly dev-culture centric, lacking diverse voices. - Psychological Safety: Tone is combative, not welcoming. --- ## ✅ Logical validity: **Strengths** - Strong causal reasoning: latency perception tied to UX ([11:25](https://www.youtube.com/watch?v=O-QS_Cp_zXg&t=685)). - Coherent analogies: comparing “most websites” to old SEO scams. - Ethical reasoning: Critique of ad-driven incentives damaging user trust. **Fallacies** - Strawman: Overgeneralizing “all marketers” or “all SEO consultants” as bad actors. - Ad Hominem: Attacking Jonno’s profession instead of only arguments. - False Cause: Attributing complexity solely to JS instead of corporate incentives. --- ## 🔍 DARVO Analysis: - **Deny**: Author downplays role of ads/tracking, blames JS instead. - **Attack**: Theo calls out SEO consultants as harmful to the web. - **Reverse Victim/Offender**: Author frames marketers as victims of - Summary: "JavaScript ruined the web". Oh boy... Thank you Sevalla for sponsoring! Check them out at: https://soydev.link/sevalla SOURCE https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/ Want to sponsor a video? Learn more here: https://soydev.link/sponsor-me Check out my Twitch, Twitter, Discord more at https://t3.gg S/O Ph4se0n3 for the awesome edit 🙏 - URL: https://youtube.com/watch?v=O-QS_Cp_zXg&si=LHTgEfSi2kGyHWmX JavaScript is terrible. It's absolutelyruined the web. I miss the days where Icould just go to a website and read thetext on it. I didn't have to deal withthings like interactive pages, actuallyuseful applications and features, andthe occasional popup or ad. I'm being abit sarcastic. This article is not. According to Jonno, JavaScript broke theweb and called it progress. I have afeeling I know where this one's going togo, and I have a feeling I'm not goingto be very pumped about the tone anddirection of this article. While I doagree that most websites are awful, Ihave a feeling the way that we get thereis going to be quite a bit different. Everyone who's been sending this to mehas been telling me excitedly how muchI'm going to hate it. So, this iseffectively an act of—I'd be carefulsaying self-harm because of YouTubecensorship, but uh, you get the idea.This one's going to hurt me a lot. Ineed to be compensated for my pain. So,quick word from today's sponsor, and thenwe'll dive right in. You're usingNext.js. You're probably using Vercel.It's the best cloud for Next. What ifyou're using literally anything else? What cloud gives you that level ofquality experience and all the piecesyou need in order to build good apps foryour users? You can go set it up yourself inAWS. You can figure out everything elseyourself. Or you can use today'ssponsor, Savala, who has figured all ofthis out for you. Regardless of whatstack you want to ship on, if you're onRails, PHP, Python, or WordPress,whatever the hell you're using, there'sa very good chance that not only does itwork well on Savala, they actually haveexamples on how to configure it, right? These guys make it so even my dumb selfcan deploy tons of random services. Theyeven now have templates for a bunch ofdifferent things you might want todeploy. Obviously, frameworks like Djangoand Laravel, but also CMSs like Ghost.Moodle is going to give me trauma. I'vebeen through it with Moodle when I wasin high school. It's a learningmanagement system. But also even Nex. Soif you do want to use Next ontraditional servers, you're good to go.And then other companies that I'veworked with, like Firecrawl, the open-source scraper for websites, are all justone click away from deploying. I mean it. I've clicked it, and I'vedeployed it. And when you go in, you cansee everything about your service. Itwill automatically set up Cloudflarein front with DOS protection, so youdon't have to go set these other piecesup yourself. If you want to cache partson a CDN, you click settings, you turnon CDN. You don't have to go configure abunch of other places. It's so niceto be able to do these types of thingswith two clicks instead of being anexpert in multiple different cloudplatforms and different infrastructure. On one hand, Savala is a cloud, but moreimportantly, they're an alternative tohiring a team to build your cloud foryou. The real world is multi-cloud. Youneed servers, you need CDNs, you needfirewalls, you need so many otherpieces. In Savala, instead of pretendingthey're an all-in-one, they are anall-in-one by giving you all of thedifferent clouds and their best parts.Get started today, and you'll get $50 offree credit. Check them out now atsoy.link/savala. Most websites are awful. I'm sure thatthis will be a very well-justifiedstatement in that it won't be thingsThat were true before JavaScript areactually mostly due to advertising,analytics, tracking, and all these otherthings and nothing to do with JavaScriptitself. I’m sure that will be the case. And I’m sure that things beforeJavaScript, back in like the Flash andJava error, were also obviously waybetter. Most websites are awful—notjust slow, awful, bloated, fragile,overengineered disasters. They loadslowly, render erratically, and hide thecontent behind megabytes of JavaScript.They glitch on mobile, frustrateusers, and confuse search engines.They’re impossible to maintain. Andsomehow, we’re calling this progress. Iwill say I am increasingly frustrated atthe number of these types of things thatI experience on the web. The slowloading things that should be fast, the erratic render conditions that I hit. Ijust had a bug earlier on Twitter wherewhen I went to one of my friends'profiles, it would say I was followingthem and then would flicker back to thefollow back button over and over again.These types of things happen a lot. Oh,that’s a fun quote from chat. The authoris an SEO consultant. SEO consultantsAre making the web worse. This is anobjective fact. I cannot imagineanyone saying otherwise, that SEOconsultants have been a net positive forthe web. No, that is obviously the case. Is this whole thing just going to belike pandering because he wants to be anSEO consultant, and JavaScript made thatmarginally harder, but also actuallybenefits the web, unlike stuffingkeywords and backlinks all over theinternet, effectively being a spam bot asa service. I’m sure this one will begood. Oh boy. Oh, even better. Maybe theauthor’s upset because AI is making hisjob irrelevant and he’s going to take itout on JavaScript instead. That wouldmake sense. I, okay, walk it back. Don’tcome in so hostile. The fact that somany websites are as bloated and slowand miserable to use as they are is areal problem. The fact that mobile websucks is also a real problem. I wouldblame a lot of different parties forthat fact. Hopefully, we could findthings to agree on in this article thatI’m sure I’m going to love a lot. Thetragedy is none of this is necessary. Once upon a time, we had a fast, stable,and resilient web, but we replaced itWith a JavaScript cargo cult, now ittakes four engineers, three frameworks,and a CI/CD pipeline just to change aheading. It's inordinately complex tosimply push a web page. Oh boy, I havethoughts already. I'm going to proposean alternative challenge. What ifinstead of a heading, which in this caseI'm certain means changing the title on apage or something? What if instead wewanted to change the top navigation? What ifinstead we wanted to change this part ofyour site, the thing at the top of it? If this is not using a framework orsomething like JavaScript, you probablyneed to go change that in a lot ofdifferent files or use crazy tools thathave reusable pieces called componentsso you can change it in just one placeand move on. It's crazy, I know, but tothink that it takes fourengineers to change a heading. No,you're hiring bad engineers or stuckdealing with bad teams. There's no worldin which my one-off commit that I pushstraight to GitHub that builds anddeploys immediately is that much worsethan whatever the [ \_\_ ] you think you're talking about here. On top of that, twopeople can build crazy things. Mark andI was able to build a realcompetitor to ChatGPT and Claude withT3 Chat. We didn't do that because we'regods. We certainly didn't do thatbecause we relied on old faithfulstandards like HTML. In fact, we wentharder on the client side than we've ina long time. The vast majority, like 99%of the code on T3 Chat is client-sideJavaScript because it has to be to makea good interactive experience like that. If your view of the web is blog postsand marketing that you sell as a servicebecause you're an SEO consultant, I cansee why you're upset at JavaScript.JavaScript is using the web as aplatform for actual applications andsoftware, not for writing ineffectivemarketing blogs in order to make peoplebuy your service. This isn't evolution;it's self-inflicted complexity. Andwe've normalized it because somewherealong the way, we started buildingwebsites for developers, not for users.I talked about this in other videos,including the different ways to renderHTML video that I'm really proud of. Wegot here because we started buildingmore complex websites that did moreText content or a form that, on submit,would have to reload the entire page inorder to make a post in a forum. Wemoved towards a dynamic web, aninteractive web, a web where we couldactually do things that weren’t justwriting in a form and hitting submit. Thingslike Gmail were only possible becausethey moved beyond the idea of the webjust being HTML files. This is from the author. Nothing says our devs don’t knowwhat they’re doing more than when yourwebsite has a loading bar, skeletonlayouts, or progress indicators. Theirony is that these things almost alwaysslow down the loading process. Just makethe thing inherently fast. It’s easierthan ever. No, it is not. As I haveestablished many different times, and Iwill continue to demonstrate throughexamples. I built a lot of differentservices using a lot of differentstrategies. This is one of them. This isping.gg. It’s like Zoom but forstreamers. This app uses effectively noserver-side rendering at all. It is aclient-side app. It’s also a client-sideapp that doesn’t work in Firefox becausewe’re focused entirely on good WebRTCexperiences, which is all words thatFirefox doesn’t know how to say. Andhere is my dashboard on Ping. I clickjoin room and as soon as I click it, itmoves. I click home to go back and assoon as I click it, it goes back. If Iclick join, I’m clicking now. Immediately something happens. That’sthe difference when you do client-siderendering. Was there a loading spinnerwhen I clicked that join button? Yes,very briefly as it got the rightpermissions and did other complexthings. Some part of the loading spinnerwas more data loading in. Yeah. Somepart of that loading spinner was doingthings that require time to be spent onthe client side. That is the nature ofhow interactions work. Loading doesn’talways mean loading from the server,unless your job is selling marketingslop to random companies. Realapplications do things. Sometimes theyneed to go get some data. Sometimes theyneed to just interact with your device. All of those things feel significantlybetter if on clicking them they happenimmediately. I know this for a factbecause Ping is objectively a bit slow.We used old tools and technologiesbefore they were well established andBefore, we had good workarounds. Andsometimes the cold starts for a lambdafor navigating around ping are 1 to 2seconds long. It's kind of nuts. Theproblem is that when you click a buttonand you wait for the server to generatethe page to avoid the loading spinner,you get something different. You get theloading bar on the top of the pageinstead. And that loading bar feelsawful. It doesn't happen in the placewhere you clicked. So when I click hereand the loading bar appears at the topof the page, I'm still on the same page. It's unclear if my click went through.So I'll click a few more times,sometimes submitting more requests andgenerating more things. Even ifrendering it on the server is faster, itwill often end up feeling slower. I knowthis for a fact because to this day,despite ping being objectively slower than almost everythingelse I have built, I regularly getcompliments and questions asking, "Wow,ping is so fast. How did you make it sofast?" It's not. It's slow, but it feelsfast because whenever you clicksomething, something changesimmediately. When you click something or when youinteract, you might see a loadingspinner, but you’ll see one loadingspinner until the rest of the content isdone. I’ve done this diagram so manydifferent times. I don’t care; we’redoing it once more. The user clicks,the server renders the HTML, and the answer comesout the other side. Even if it’s a CDNor static content that doesn’t need tobe waited on the server for, it’ssomething that takes time. And here’sthe difference. If we client-side renderit or use something like a frameworklike React on the client-side todo traditional single-page app style development, even if it takes longer,because there are multiple differentsteps, there’s a big difference. So if ittakes longer for us to get to this endpoint, there are other things that happenthat are really cool. The big one isthat instantaneously you will seesomething. So you click, and immediatelyyou have different content on the page.So, we’ll put this as over here loading.This is the loading spinner moment.We’ll make this yellow because thedifference I want to emphasize is itfeels way better to see something. Immediately on click than to have towait until after you clicked and theserver rendered and sent a response.Especially if you have high latencyor a bad internet connection, having towait after a click to see if the thinghappened or not sucks. So, weimmediately show loading spinners. Atthe same time that we're now showingthese spinners, we are kicking off somework too. We are going to make some APIrequests. And I'm going to make thisworst case. We'll do API request one. And we're going to pretend that you suckand you didn't set things up so that youonly do one request. We're going topretend that we have to cascade them. Wehave to do some waterfalling. Since wedon't have to render the HTML, theresponse will be a little faster oncewe've done those API calls. But we'lleven exaggerate this a bit. We show thespinners. So the spinners are stillshowing. I'll emphasize that by doingthis. So the spinners are showing. Oncewe figure out what components we want torender, we poorly render API request oneand then API request two. And then oncethat second request finishes, we have toon client process the data. A lot shorter, depending on how slowyour database calls are and whatnot. It's alittle bit more realistic.You have to process the things you got back,generate an HTML response that the usercan see, and now the user sees whatthey're here for. This is when you wouldget the final content. I don’t feel likedrawing a better diagram for this.You've seen me and others do it in thepast. I couldn't even find the old onefor some reason. But the point hereis that even if the client-siderendering thing takes longer, it ends uptaking significantly less time from whenyou click to when a change happens inthe thing that you're clicking on. Andhumans perceive those things bothwell and poorly. They perceive the timebetween when you do something to when achange happens really, really strongly. There are a lot of studies about thisabout how many milliseconds andseconds an action to interaction takesand the likelihood that you feel likeit's fast or slow. If it takes more than100 milliseconds, your brain stopsthinking about the thing the same way.It starts to feel slow. If it takes morethan a second, if it takes more than 10Seconds, you're going to churn and go dosomething else. But making sure the usersees something, ideally in under 30milliseconds, but at least under 100is really important. And if you have todo a whole call out to a server, waitfor a response to come back and thenrender it, you will click and wait andnot know if the thing is working or not. Especially because that loading bar atthe top of a lot of these pages is slowand not very visible. So you might noteven notice it. It sucks. If you'vetried to build a real app that has databeing rendered from real databases thataren't immediate or not just like acrappy WordPress blog, you know how slowsome of those pages can take. And moreimportantly, how miserable it feelsbecause when you click, nothing happens.Even if it takes 30% to even like doublethe amount of time to do it the clientrendered way, the client rendered slowsite will feel faster than the SSRversion because when you click, a thinghappens. On top of that, there aremethods to reduce these loading times.Let's say we figured out how to do theseAPI requests at the same time and thenwe can process it way earlier. All of a sudden, oh, we're actuallyrendering it faster than if we wait forthe server to rerender the entire page.Or if you fetch these ahead of time, wemove these out to before. So we alreadyhave the data. Now we just process thedata that we already have, and now we'reshowing the content even sooner. Themagic here is that we have differentstrategies when we do client-siderendering because we control the client. We control what goes into the datafetching mechanisms, what data we'refetching, when we fetch it, and how weturn that data into HTML. With SSR,we send a request to a URL. The URLpoints at a server. It has to figure outeverything about that user again, fetchall the data and context it needs,generate an HTML page, send it down tothe user, and now finally they seesomething. The fact that we have moreoptions, all of which are better thanthe SSR strategy when we do more clientside rendering is not a flaw of clientside rendering. It's one of the benefitsof JavaScript that we as devs can choosedifferent ways to fetch data when wefetch that data and how we turn it intoHTML. Those options mean that more badDevelopers are making more baddecisions. But that’s the nature of any skilled force or any skilled place. Ifthere are ways to do things dumb, theywill be done in those dumb ways. I knowthat for a fact, and the author shouldtoo, because I have browsed a lot ofWordPress sites, and I can’t believeyou’re complaining about the state ofthe web today with all these tools andtechnologies that are owned by devs. Howmany WordPress sites have beencompromised? I have personally lost alot of time and money, and moreimportantly, information that I can’trecover because I had one old WordPressdeployment on an old server that gothacked and used to take over my entireservice. It sucks. And that was the webwe had before. So sure, if you thinkthat’s cool and good and dandy, awesome. Good for you. But it’s bad faith. Backto the article. I’m badmouthing too muchwithout even reading it yet. How did weget here? Around 2010, somethingshifted. The iPhone was ascendant.Native apps were sleek, fast, and fluid.Angular, the first mainstream JSframework for the web, had justemerged. And suddenly, every CMO startedSaying the same thing in website briefs. Can we make it feel like an app? Thefact that you’re thinking in CMO termsabout web apps says so much.We’ve had the word developer come uponce so far, and the next proper noun for ajob role that we had was CMO.Developers armed with new frameworks andgood intentions said yes. JavaScriptcould, in theory, do seamless transitionsin slick UI. So we built towards thatpromise, or at least we tried to. Spoileralert, we didn’t get app-likeperformance. We didn’t get better userexperiences. What we got was an armsrace of complexity. Do you sincerelythink that the old Yahoo Mail websitewas better than Gmail or better thanSuperhuman or Mail Zero, which I’m aninvestor in—biased, of course? Do yousincerely think that we didn’t get anybetter user experiences on the web as aresult of these tools and technologies? That we don’t have teams of dozens ofpeople building things that would havebeen either impossible or takenthousands before? Do you sincerely thinkeither that T3 chat is a bad experienceor that T3 chat could have been builteven easier and been better if we didn’tUse JavaScript on the client side forit? Like are you joking? Itwould have taken a hundred people minimum tomake something close to the quality ofT3 chat where everything is server side. Actually, it couldn't be done becausethe way SSC streams work would not be aparticularly viable experience on theclient side without a lot of JavaScript.But even if you like self-rolled alittle bit of JavaScript to make theupdate layer functional and dideverything else server side, it would bea comically worse experience. I'm sayingthis as somebody who went too far thewrong way. We went all in on local firstand local first is a disaster.That's a video waiting for another time. The fact that the potential forcomplexity resulted in unnecessarycomplexity when bad developers used itdoesn't mean that these tools are theproblem. I say this all the time. Whensomething becomes popular enough tobecome the default, that means it's thedefault. The fun thing about any fieldis that when you look at an average,half the people are below that line.Just imagine an average dev in yourhand, not even a web, just an averageA developer is somebody totally in the middle. Half of developers are worse programmers and developers than they are. The majority of them are going to pick the default tool because they don't know any better.The fact that these JavaScript based frameworks like React, Angular, Node, and all of these became popular enough to be the default means that the majority of less skilled developers are going to adopt them. That's the nature of being popular: less capable people will pick the popular thing.That doesn't mean the popular thing is bad. That means bad people pick the popular thing because, again, it's popular.You can't use something's success against it. You have to at least understand what this is.We started solving simple problems like navigation or layout with tools built for full-blown applications. I kind of agree. I'll admit, like if this was an attack on Gatsby, I'd be all in on it.There are a lot of tools and technologies that use things like React very incorrectly.If your site is mostly, if not entirely static, you don't need a JavaScript framework.Use one if you want to. If it makes your life easier to use Next.js instead of Astro, then do so. For your static site, fine, whatever. Ifas long as the content loads without theJS, you're fine. But I would pick Astrofor a static site still. I still use itfor things like my personal blog andwhatnot. But that's not the majority ofwhere we're spending our time as devs.That's the important thing. Everyoneloves the stat that's like the majorityof websites aren't using React; they'reusing jQuery and PHP. Yeah, if wemeasure the web by the number of URLs,sure. I don't know about you guys, butI'm a pretty heavy web user. I'm on theweb for hours a day. I'm on like sixwebsites. If instead of measuring thenumber of URLs with a given technology, we were to measure the number ofemployees working with a giventechnology, the number of employeesworking on a given URL, or just thenumber of hours being spent on thewebsites, the hours spent on sites basedon React is a much bigger number thanthe hours spent on websites based onPHP. Someone just pointed out in chatthat this entire article is like aPostman's review of how email shouldwork. Yeah. Yeah, I'm excited to seewhere this one goes. I'm not going toLie. At the same time, JavaScriptstopped being just a front-end language. With the rise of Node.js, JavaScriptmoved to server side. And with it came awave of app developers entering the webecosystem. I, huh. Can someone elsetranslate this sentence for me? I justI'm not following. Are you saying thatapp developers were server side and now, nowlike Node.js got backend developers tostart building for the web? I, I'm genuinely so confused about what hethinks this sentence means. Dude thinksJS was for apps before the web.Translation syntax error. What? Yeah, everyone understands this isa mess. Also, on the topic of WordPress,WordPress is an unauthenticated remoteshell that, as a useful side effect, alsocontains a blog. That's so good. That's so good.Apparently, according to this at least,the reason that the web sucks is allthese app developers from backendsuddenly learned JavaScript because ofNode, and now they're ruining the web. Is that right? These weren't webdesigners or content publishers.They were engineers trained to buildapplications, not documents. Quiet part out loud. He does not wantthe web to be for apps; he wants the webto be for slop. Suddenly, it all clicks.And also, this first sentenceemphasizes how little he understands theworld outside of his bubble. The onlyway you think that Node resulted in allof these existing app developers from serversto suddenly infect the browser with thislanguage that they learned because ofthat requires a level ofdelusion and false understanding of thehistory of all of this that has taintedmy ability to be of good faith for the restof this reading. I will try my best, butit is getting increasingly hard as hismisunderstanding of the web isconfidently stated over and over again. They brought with them the architectfirst mindset: patterns, statemanagement, dependency injection,and abstracted logic. The result: a slowcultural shift from building pages toengineering systems, even when all theuser needed was to load an article. Whatif I told you most of these things areoverused and that I agree here?Actually, the fact that model viewcontroller patterns infected the web forlike 10 years, and we're still working onClawing them back is absurd. The factthat I'm still talking to engineers thatare senior to principal level atthese big real companies and explainingto them that their weird MVC model beingshoved into the browser is actuallyslowing them down, but they're convincedthey're right because they have a 500person team shipping slop that neverworks. If Jonno got into all of this during the Angular era and saw whatAngular was doing to the web, I canactually understand where hisperspective comes from because the waythat Angular initially, especiallythought about building applications wasso wrong that it was dangerous. That'swhy I don't believe in this separationof concerns. And it's why I lovethings like Tailwind. It's why I loveReact, especially post functioncomponents into hooks because it letsyou not think in architectures; youthink in experiences. You build thefeature you want to build and now it isa component that could be reused inother places. I'm actually moresympathetic because of this. If he wasthere for the Angular era and he watchedthat all happen, I could understand why. He is so skeptical about everything elsegoing forward. But I would encouragehim to actually look into how Reactworks and why it was made, or watch therethinking best practices talk that Ijust did a video on that I loved becauseit's a really good talk. Back to thearticle. And so we rewrote the rules ofweb development around entirely different needs,almost overnight. Not content, notspeed, not interoperability,not discoverability, just code. Might Iremind you what the web used to looklike? I am exactly old enough that I wasthere for this, that I saw all of thedisasters that occurred whenever you browsed the web—all of this slopcovering everything you tried to find onthe internet. And the reason SEO wasvaluable was primarily because if yougot people to go to your site, you wouldmake money off of these ads.Specifically, you would make money offof some random grandfather clicking thedownload button that wasn’t the realdownload button and getting a virus ontheir computer, and then the scamcompany pays you 50 cents for the click.Do you really think the web used to begreat and virtuous, and it got ruined byReact and not this? Are you kidding? There is some good news though. We have JavaScript. I can click thislittle button in the corner of mybrowser for Ublock, which is aJavaScript-based extension. And when Iclick it, the ads all disappear. JavaScript saved the web. It made itmore interactive. It made it morefunctional. And it gave us, as users, morecontrol over how we experience it aswell. I will never understand why somany of these people go so hard onJavaScript and won't even acknowledgethat advertising, viruses, and badincentives are what actually ruined theweb. Much worse than all of the thingsthey're complaining about in the samecategories they are complaining about. The furtherwe went down this road, the more thestack drifted from the fundamentals. Semantic HTML, optional server-siderendering, rebuilt from scratch. Accessibility,maybe if there's time. Performance, who cares when you can savecost by putting load burdens onto theuser's device instead of your server?This is the biggest cell phone. I seethis one a lot. I actually wrote a blogI’m posting for the first time in years becauseof this particular bad take and howoften I’ve been seeing it. It’s becomingincreasingly common to see claims thatserver-side rendering (SSR) is expensive, unnecessary, or solelya ploy by cloud providers to inflateyour bills. The sentiment oversimplifiesthe reality. SSR probably saves youmoney; the overhead is minimal. TurningJSON into HTML is relatively cheap. Things that aren’t so cheap are databasequeries and authentication checks. Andif you have to make a ton ofauthentication checks, you’re probablyspending more time on server code thanyou would if you just had to make one.To be fair, this is kind of a caseagainst single-page apps. But if he’sgoing to critique SSR, I’m going torespond because he’s wrong. SSR is socheap. The reason you move to client sidehas nothing to do with cost savings. Thereason you move to client is experiencesavings. You know, the thing I diagrammedearlier, because now when you click, yousee something sooner. Again, we have anew service that’s more successful than anything else we’ve built in a long time,with T3 Chat. We’re doing all of therendering on the client, not because itSaves money. We do it because it makesthe app feel way faster. We areintentionally eating the hit on SEO inorder to make a site that is better touse. We, as competent developers, thatunderstand JavaScript, picked client-siderendering because it makes ourapplication faster. You, as a marketer,that thinks they know how to writesoftware, confidently claim that we areonly putting a burden on the user's deviceto save costs. Are you joking? Gradually, the web became something youhad to compile before you could publish,not because users needed it, but becausedevelopers wanted it to feel modern. Here aresome things that we got from compilers. We got more efficient code being sent toour users. We got better reliability ofthe things that we wrote, with checkingand error handling as part of our buildprocess, so we knew if mistakes weremade. We got the ability to composesoftware from lots of different sourcesas we build better things. We got theability to reuse parts in multipleplaces instead of copy-pasting the sameHTML across hundreds of pages, needing tochange it in all of them at the sametime. Hot take: compilers are a goodThe replies to this are, "Yeah, they are." I made a jokeabout people who think compilers are a badthing, Ruby devs. Point being, compilersare not a bad thing. They allow us tocreate better, more reliable software thatis more complex. If your softwaredoesn't need a compiler, I’m happy foryou and the one to two people max thatyou work with every day. But for thoseof us building real applications,compilers make life much better. The cult of developer experience. Today, weoptimize for DX—developer experience,not user experience, not performance,not outcomes. The only DX I’ve mentionedso far in my response to all of this hasbeen the DX of updating the banner ortop nav of your website, which in yourworld either sucks or you’re usingWordPress where somebody wrote all thedynamic parts for you. Anyway, today’spopular frameworks are sold on their DX.No, React is sold on its maintainability,performance characteristics, andsimplification of annoying things. Butdo you think server components were soldpurely on DX? The frustrationpeople have is that they’re not—the docsare slick. Oh man, this tells so. Much about this author. You have no ideahow long the documentation for thesetools was horrible, and how long ittook for it to get good. The onboardingis smooth. The tooling is smart,integrated, and clever. You can spin upa new app with a CLI command and feelproductive before you’ve even written aline of content. But good DX doesn’tguarantee good UX. In fact, it’s oftenthe opposite. No, they’re unrelated.Ideally, you can make the happy paththat brings the best user experience bethe best DX. Do you know what’s a goodexample of something that makes the UXbetter through a DX improvement? Linters and compiler checks for thingslike accessibility. It’s really nicehaving a compiler in a build step thatchecks to make sure all of my image tagshave ARIA labels and ARIA attributes sothat they can be used and experienced bypeople who are vision impaired or blind.That’s a thing that I would miss a lotbefore I introduced build tools,compiler tools, and linters to myapplications. That is a DX win thatimproves the user experience as well.There are so many of these, and I cannotthink of very many, if any, times thatLike we picked DX over UX with any ofthe architectural decisions that wemade. If this is a comment aboutFlutter, I’m with you, sir. But if it’sa comment about the web, it’s amisunderstanding of the web at best. Themore comfortable we make things fordevs, the more abstractions that we add. And every abstraction creates distancebetween the thing being built and thepeople that it’s for. This is anotherone I could actually very slightly getbehind. There are absolutelyabstractions, like really heavy thingslike Flutter that very much abstract youfrom the user, the user experience, thedevice, and the standards. But how doesan abstraction like TypeScript, forexample, move us away from the users?What about type systems and compilersmake it so that we are putting distancebetween us and the people that we’rebuilding for? Now we havecomponent libraries generating buttonmarkup. We have page metadata managed inJS functions. We have image loadingstrategies buried in config files. Allof these are good things. Literally,everything he listed here is a goodthing. You can reuse, having style guarantees,usability guarantees, contrast ratiosthat are reliable, area attributes thatare accurate, and all these other pieces.As silly as it sounds, making agood button isn’t as easy as renderingthe button HTML. Page metadata managed inJS functions is also a good thingbecause page metadata usually requiresdata. It’s right there in the word "data."How are you fetching that data? How areyou getting that dynamic data? Youroptions are to use a server language likePHP to fetch it from the database andthen stuff it into an HTML template witha weird templating syntax or, crazily, use a language that’s alreadystandard on the web platform to do allthe exact same things so you can reusethe data-fetching and collectionlogic on client and server. Crazy. Youalready have to manage your metadata.If it isn’t a static HTML file, you alreadyhave to manage it in functions. It’s amatter of whether you prefer the functionsthat are PHP or do you prefer thefunctions that are JavaScript? And ifyou have an irrational hatred ofJavaScript, suddenly, functions are bad.And don’t even get me started on imageLoading strategies. Oh God. Oh God. Every time I do this rant, people getmad at me. I don't care. They're allwrong. WEBP is one of the best thingsthat ever happened to the internet. Thefact that most web pages are stillserving unoptimized, poorly, if at all,compressed PNGs and JPEGs. Like 90 plus%of the images on the web are JPEGs andPNGs that are huge and way slower toload. If your complaint is that theinternet is too slow, you should reallylike image loading strategies that makethat problem go away. The fact that wehave all these awesome new codecs andnow we have these awesome tools like configurations in things like Next.jsthat make it really easy to just load animage via the URL the way that you wantto do. And now the user doesn't get thisgiant 20 megabyte JPEG. They get a 12 to20 kilobyte WEBP without you having todo anything differently. That's a greatthing. That's the perfect balance. Thatis a UX win and a DX noop. We haven'tchanged the developer experience at all,but we've made the user experiencesignificantly better. The paragraphafter complaining that DX doesn'tguarantee good UX. You got to pick one. Argument, bud, or at the very least,understand the points that you'rearguing with. Everything's optimized fordevelopers and hostile to everyone else. Whois image loading strategies and configurationfiles hostile to? It seems like the wayyou phrase this, the problem here isthe developer experience with thesethings. That is an unnecessary level ofdeveloper involvement. All of thesethings make stuff better for users.Anyways,this isn't accidental; it's cultural.We've created an industry wherecomplexity is celebrated, wherecleverness is rewarded, whereengineering sophistication is valuedmore than clarity, usability, orcommercial effectiveness. I fully agree with this one. I'll die onthat hill. Actually, the fact thatcomplexity is as celebrated as it is, isdisastrous on so many different levels.I've seen this in enterprise especiallyoften. The person who writes a 30-pagereport on a change that is a regressionfor users and then goes through and doesit with a 20-person team gets apromotion. But the individual developerwho notices problems that users areHaving someone go and fix problems andmaybe write a one to two page reportafterwards on how they did it andwhy, is common. The person who looks like they didmore work gets the promotion. And the one who is actually fixing problems theway they should be fixed not onlydoesn't get the promotion, they mighteven get written up for it. That's a veryreal situation. I don’t think that hasanything to do with the technologiesthat we are using. In fact, one of thefun things when we moved to React atTwitch is that a lot of that culture hadto die on the website, and the few peoplewho still engaged with it ended upembarrassed because building things theright, simple way to solve user problemsis always the best approach. I think this might be whereI can start finding agreement with the authorif he honestly perceivesthese tools as the cause of all thisor inversely, he sees this as theproblem and these tools came out of it.I can understand why he's being soirate here, because this is a realproblem that sucks. If you've ever beenon one of those teams where a randomperson wrote this crazy proposal thatIt was full of fancy words and terms, anddoesn't actually do anything for theusers, or it makes things worse for them. If you're the type of person thatwatches this type of video, that sucksreally hard. That sucks so hard that Iwouldn't blame you for getting a littlebit delusional as a result ofexperiencing that, especially if youexperience it for an extended amount oftime. I can sympathize with him a lotmore because of this paragraph. And I'mgoing to do my best to try going forwardto read it from the lens of what he saidhere, but again, as Chad's pointing outcorrectly here, what he's describingsounds more like Corpo Java than it does like React. Also, another good thingfrom Demi here, to be fair, I think weall have bad takes that are informed bytrauma. We might even rant a bit in theteam meetings, but we're generally smartenough not to make a blog post and say,"Hey, you should hire me because of thistake. That's bad." Yep, totally agree.The fact that he is putting his traumaout there by [ \_\_ ] on a whole worldhe doesn't understand is not good. ButI can sympathize with the trauma he isfeeling if it is rooted in this part. Here. And then immediately takes away somuch of my good faith. It's easier towin an argument by citing SSRcompatibility issues than it is to askwhy we are using React for a blog.Three thoughts there. Don't use Reactfor blogs unless you have a good reasonto. Hydration issues aren't that hard tosolve; they're almost always relatedto datetime. Like 90% of the time, especially for ablog, it's just datetime stuff. Andthird, caching is hard. Period. And a fourth one: don't use React for a blogunless you have a reason to. Yeah, thissounds like an actual experience he had,and I can sympathize because of that.But I promise you, the teams I havedealt with on the blog and contentmanagement side have been some of theworst over-engineering dumbasses I'veever met in my life. I got in a longfight that almost got me in trouble atTwitch because the person in charge ofthe blog didn’t know how to embedanything other than an MP4 or a PNG. So,when we actually didn’t even know how toembed the MP4, the way they would embedMP4s is they would upload them on Twitchback when you could still upload videosand then embed the video player. Mod view launch, one of the productsthat I built, we had a little four-second example of how it was usedthat looked really cool, that my designerand product manager put a lot of timeinto to make a really good four-second view of it. It was meant to belike a small web type thing you'd embedin a blog post to show off the product.The guy running the blog was like,"Okay, cool. Yeah, we'll get that done."And then they put up the blog post forour launch, and it has five manualclick-to-play Twitch players that arecovered in poor UI that make you pressa button to see a three to five at mostsecond clip. I go out; I immediately DMlike, "What the [ \_\_ ] did you do? We sentyou these small MP4s to embed." He sayshe can't get them to embed and autoplay. I think he was using WordPress orsomething. I say, "Okay, fine, whatever."Here is the HTML to embed in the post.He does it, but he doesn't point theURLs at the right files. At this point,I'm frustrated. So I take the files; Ire-encode them as web. I put them on ourown S3 bucket, mark it public, and hand himthe exact HTML with the exact URLsalready embedded to make it work. I correctly tested it byembedding it in the page myself to makesure everything was good. I spent like fourdays back and forth doing this [ \_\_ ]with this guy. And then he goes andpastes in the HTML, doesn’t even checkif it works, and ships it. His inadequateinterface for doing that, which he builthimself and claims to be an engineer,escaped the URL characters for the URLbecause it expected to be a local URL to hisasset management tool that he doesn’teven know how to use. And it broke allof the embeds. At that point, I gave upand gave him what he had been asking for thewhole time: 20 megabyte gifts. I amsorry. The fact that that dude gotanother promotion before getting laidoff is worse than anything that is being cited in this [ \_\_ ] article. I amsorry. I almost got in trouble for noteven raging at him, just venting to my teambecause of how upset Iwas about that. I got a warningfrom a manager saying, “Hey, chillout, man. You’re going to get in troubleif you go this hard on this thing.” Isaid, “This dude isn’t doing his [ \_\_ ]job. He shouldn’t be employed here.” Icould dedicate my spare hour onThe weekend does his entire job for himmore effectively. And I would never getpromoted for it because I wouldn’tpretend it’s more complex than it[ \_\_ ] is. So I feel you here. ButJono, the world you come from does thisoften [ \_\_ ] times more than mine does. But it’s also possible we are cominghere from the same place. That you’vehad one or two experiences with web devsand they sucked. And I’ve had 10 to 20experiences with SEO managers and blogmanagers that were even worse. We’ve allbeen there. We’ve all done that. I don’twrite blog posts about how CMSs areevil, but you just have a strongerfeeling. And that’s fine. It’s wrong,but it’s fine. We keep optimizing thewrong things because it feels good,because it’s fun, because it looksmodern, and because nobody stops us. Doyou think these super smart peopleinvented these incredible technologiesbecause it was fun and felt good? Maybeto some amount, but most of them do itbecause they perceive a specific problemthat they want to solve, usually aroundperformance and experience ormaintainability and complexity. Complexity becomes the default. This isHow it spirals. We don't just toleratecomplexity anymore; we expect it. Weassume every site needs a build step, abundler, a hydration strategy, a routinglayer, an API layer, a design system,and some clever cache invalidationlogic. We build in microservices, hoston edge networks, and deploy pipelinesto ship basic content. This guy seems tothink the whole web is basic content. Iguess if you think of all of thesethings by their specific termsinstead of what it brings you,this is scary. A build step is acommand. A bundler is how you turn thecode into a thing users get. Hydrationstrategy is only relevant if you'rerunning the same code on client andserver, and the client needs to pick upwhere the server left off. If you'reclient rendering or you're usingsomething like Astro which is fullyserver rendered, there is no need forhydration. The idea ofhydration strategy? No, there are nostrategies. No devs are coming up withtheir own unique way to handlehydration; they are rendering the codeon the server and then picking up on theclient by just using React and Next.js. Say that for all of these. None of thesethings are stuff that people arebuilding or even thinking about. Therouting layer in most of these modernframeworks is files and folders thatmatch the URL patterns. The API layer isfunctions you call to get data. Thedesign system is components that youreuse. I know, crazy thought fromsomebody that likes to just paste HTMLall around the place. And some clevercache invalidation logic. No, if thesite's static, it's static. You don'tneed any invalidation. If the site'sfully dynamic, it's fully dynamic. Youdon't need any invalidation. If you'rebuilding something that updatespartially regularly, having the abilityto invalidate it on demand is reallypowerful and helps reduce load. Something you wouldn't understand ifyou're building SEO tools and not thingsthat get actual users. It doesn't matterif you're publishing a blog post or ane-commerce site, the stack's the same.Heavy abstract engineered to the edge ofusefulness. I can sympathize a bit here.The fact that we're using React for likeeverything is really cool; that we canuse this one thing and it works well. Enough in most places to be livable isnuts. Like, the same framework is usedfor building the operating systems onMetaQuest and PlayStation 5. Theintegrated experiences on things likeTwitter and Facebook and for e-commercesites like Shopify are actually kind ofcool. But at the same time, it meansthat the ecosystem has things that arebuilt for one of those solutions and notothers. And you can end up in a placewhere if you use the same tools foreverything, you're in a bad spot. Thisis why I refuse to make a template repofor the T3 stack, and instead the communitymade a CLI because I don't want peopleinstalling off libraries in TRPC ontheir blogs. The solution tothis problem is modular design andpicking the right pieces as you needthem, not complaining about how heavyand abstracted everything is. Theabstractions are actually the solutionto this because they mean we can add andremove modular pieces as we need them. This is another fun one. Nobodyunderstands it. Not fully. Are yousaying they do? There's two paths we cango from this statement. Either you'resaying that people do fully understandThe alternative, which is WordPress. Iknow a lot of WordPress devs, and zero ofthem will claim that they fullyunderstand WordPress. Or you are using amore general definition of understandingand you genuinely believe that theaverage WordPress dev has a betterunderstanding of PHP than the averageReact dev does of JavaScript in the web. And even there, I kind of agree. I'mon the line for it. But that's becausethere's a hundred times more devs and a lotmore devs using React than there aredevs that ever used WordPress. But thisis a non-statement, especially when youcontrast it with the fact that no alternativeis presented here at all, and the reasonno alternative is presented is becausethey look even worse. Not the marketers,not the SEOs, not even the developerswho built it six months ago. Every newtool brings new abstractions, newsyntax, new mental models. Making asimple tweak to a headline, a meta tag,or a layout becomes a three-stepdeployment process. It's madness. I'drather... okay, again, swap headline withtopnav, and the argument flips entirely. I would much rather a three-stepdeployment process which is build, lintI would prefer to edit thesame five lines of code across 400 filesand then push them all up manually viaFTP. If you think too deep in the weeds,it feels like too much work ishappening. But there's this really coolthing about computers. They can kind ofjust do [\_\_]. It's magical that athree-step deploy process can be runautomatically in parallel, and the wholething is 10 lines of YAML code that youcopied and pasted from another project or fromChatGPT. Now, every time anyone atthe company makes changes, you know ifthey are safe. You know if the lintingpasses. You know if there are someaccessibility checks done, that thingsare, for probably the most part,accessible, and you know when you clickmerge, that those checks will be runagain just to make sure everything'sokay. That's an awesome thing. Butapparently that awesome thing ismadness. We rebuilt the web like anerror traffic control system just toserve a few kilobytes of text. Fine. Don't use React for your blogs.WordPress is really heavy too, though.The worst part, most of the complexityexists just to retrofit things we used. To get by default: routing, metadata,caching, templating, and layout. You gottemplating and layout by default. I’dlove to see how you got caching bydefault. If you change the top nav onyour site, how long does it take forusers to see the new version? It is alsofunny because air traffic control isnotoriously outdated. As someone in chatjust pointed out, it’s extra funny sinceair traffic control is running on floppydiscs and [ \_\_ ]. We’re not innovating.We’re rebuilding broken versions oftools that the web already gave us, andwe’re doing it badly. Oh, you mean likethe loading bar at the top of the pagethat sucks and is objectively measuredto be bad user experience? Anyway, thestack’s rebuilding itself in its ownimage. Fast forward to today.Ironically, after years of chasingabstraction and complexity, the JSecosystem is now scrambling toreintroduce the things that we lost. SSRis back in fashion, routing carefullymanaged, URL structures, metadata, evenHTML output, all being rebuilt, oneplugin at a time. Does he think of libraries as plugins? That would explaina lot. Actually, if you come from theIn the WordPress world, maybe you see the waythat we build now less like Unix andLinux and more like a WordPress installthat comes with 50 plugins installed. Ifyou did your time in WordPress, youknow that every time you install a plugin,you are exponentially increasing thechance that your whole platformfalls apart and everything breaks. Andthat’s traumatizing and hellish. Ifthat’s how you’re thinking of thepackage JSON, I can understand wherethis fear comes from. But in the realworld, reusing battle-tested solutionsthat were built to solve real problemsis a good thing. That’s why the entireUnix and Linux ecosystems are built onthese ideas. I think that the webtooling becoming more like the Linuxworld is a good thing. Apparently, theauthor disagrees. It looks increasinglylike the thing we started with: aconventional CMS serving HTML renderedon the server, cached close to the user. Cached close to the user was not the casebefore. That’s delusional. ConventionalCMS, we’re still not close to backthere. And every time someone starts togo that way, something crazy happens—like payload gets bought out by Figma. So, no, we're not there at all. This isa wild take. Would you call Twitter aCMS? Would you call YouTube a CMS? Whatis a CMS to you? Is it the thingyou open as an SEO consultant? Or is ita tool people engage with? We'rerebuilding platforms. Oh god, he evencalls out WordPress positively. Areyou joking? Are you actually joking? I'mgoing to go insane. It would be funny ifit weren't so exhausting. This is theendgame of a development cultureobsessed with novelty. We're notshipping better sites. We're reinventingbasic infrastructure in increasinglyconvoluted ways, and then celebrating thefact that it almost works. Thisarticle is a lot longer than I expected. If you want to read the whole thing, asalways, the link is in the description.I’m going to summarize the last pointsto not make you suffer any longer andalso to reduce my own suffering. Iam afraid that this next section iscollateral damage to marketers andusers, literally putting marketersbefore users. Like, literally, just didthat. Are you joking? That’s how hethinks. That’s why ads are okay andbloating the web with spyware is fine. No word about that anywhere. Yet, forsome reason, React is inherentlyontologically evil. Wild. Almost likeyou think about marketers more than youthink about users, and you're accusingus of thinking about devs more thanusers. Anyways, marketers can't update,copy, or run experiments without raisingtickets. They can't preview content,test layouts, or launch pages. Everychange has to go through devs, pipelines,approvals, and rebuilds. On one hand, I can sympathize if you are a marketerthat is upset because you used to beable to change everything in WordPressand now you can't. I get it. Butchanging things in WordPress is notgoing to make a site that works onmobile. It's not going to make a mobileapp that users can actually engage withand use. It's not going to makeinteractive pages that are complexviable at all. But it does suck ifyou're used to the WordPress experienceof anyone could go in and updatesomething and there's only like a 30%chance it breaks everything. Yeah, sure,that does suck. But the things thatwe're building are more complex. It would render in one type of browser inone aspect ratio with the same standardtype of internet connection across theworld. Everything on each side hasgotten more complex. That's the natureof things improving. But I do agree thatit sucks now for non-technicalpeople that they can't contribute. Butyeah, a lot of the things that they wantto contribute to are things theyshouldn't be able to anyways. So it's 50/50on this one. But if you're coming fromthis entirely from the angle of likedevs building their blogs the way thatTwitter's built and now marketers can'tchange things, yeah, that does kind of suck. I'm with you there. Okay, we cando some more agreement. JavaScript'spowerful, but it's misused. Let's beclear. JS isn't the villain. It'spowerful. It's essential. It enablesrich interactivity, dynamic content,real-time updates, etc. It lets us buildtools, not just pages. Is Twitter a toolor is it an app? 'Cause I feel like youdon't like apps. Most websites don'tneed to be tools. I actually agree fullyhere. Most websites don't need to betools or applications. But this is againthe distinction between different URLs. Versus hours spent. I hope we can allagree that the majority of time spent on the web is not reading old blogposts. It's engaging in these tools andapplications on the web. Way more timeis spent on Twitter than most WordPressblogs combined. Right now, there are waymore WordPress blogs than there aretwitter.coms. But when we look at it asa function of time spent or engineersworking on the thing, or level ofcomplexity of the problem being solved,suddenly this argument goes away. I amso tired of the "most websites" argumentbecause the majority of websites have not been updated for 15 plus years. It's not a real argument foranything. I'll even fully cave here. Themajority of websites shouldn't be usingReact because the majority of websitesshould be left to quietly die in theircold coffins in the corners of the webthat nobody goes to anymore. That's thereality of the internet. The majority ofwebsites will get zero users and acouple of bots. Not only do most websitesnot need to be tools, most websitesdon't even have users, so who cares? While on one hand, I agree thateven e-commerce doesn't need aA framework does benefit greatly fromit if you can make things that feelfaster to browse. You can have searchexperiences that don't require a ton ofcustom code to be written. You have cartmanagement that doesn't suck, and alsomodals. Don't pretend you can do modalspurely like vanilla. I've tried this fartoo many times; you cannot do it. Theweb standards for these things areabsolute trash. You have towrite some dynamic code, and using aframework makes it significantly easier,especially if you care about things likeaccessibility. I love this. Some sitesdo have genuine client-side state needs,like login states. The fact that he'sdownplaying login as something some sitesneed says everything I think I need to. It's a shame how I never see thesepeople talking about Astro. They alwayscite things that intentionally fullyavoid JavaScript,like WordPress and 11. You know, thereare better modern tools that give youthe things you're looking for here thatallow you to bring in sensibleJavaScript where it does add that realvalue. Apparently, the author installeda WordPress plugin for view transitions. That's named "Death to Spas." I can't takethe article seriously. It feels like asalty WordPress dev being upset withlong package.json files. I feel you,man. I can understand where the authoris coming from, but where he's comingfrom is a small bubble that feels bigbecause it's a lot of websites, but issmall because it's a very small amountof traffic. I would encourage him tospend more time talking with developerswho care about developer tools andabout their users. Not necessarilylike me, because I'm annoyingto talk to, especially nowadays. I'm waytoo busy. But the nice peoplewho hang out here, I hope none of youhave to suffer too much more. If youwant to, links are in the description.And if you deal with people like this, I'msorry. I got nothing else on this one., How JS Ruined the Web, Theo - t3․gg, 01k0qhdz2271t23dfwpe5t7xn2.