From 923865782b7912f5830255f263916f15278f2c10 Mon Sep 17 00:00:00 2001 From: David Eisinger Date: Mon, 3 Jul 2023 21:53:13 -0400 Subject: [PATCH] Status quo --- content/notes/first-it-must-work/index.md | 33 +- static/archive/dev-to-ptnb0b.txt | 2595 +++++++++++++++++++++ static/archive/macwright-com-vvkegs.txt | 284 +++ 3 files changed, 2902 insertions(+), 10 deletions(-) create mode 100644 static/archive/dev-to-ptnb0b.txt create mode 100644 static/archive/macwright-com-vvkegs.txt diff --git a/content/notes/first-it-must-work/index.md b/content/notes/first-it-must-work/index.md index e9dbc8f..40876b4 100644 --- a/content/notes/first-it-must-work/index.md +++ b/content/notes/first-it-must-work/index.md @@ -3,6 +3,14 @@ title: "First, It Must Work" date: 2023-05-11T23:00:26-04:00 draft: false references: +- title: "Second-guessing the modern web - macwright.com" + url: https://macwright.com/2020/05/10/spa-fatigue.html + date: 2023-07-04T01:51:17Z + file: macwright-com-vvkegs.txt +- title: "In defense of the modern web - DEV Community" + url: https://dev.to/richharris/in-defense-of-the-modern-web-2nia + date: 2023-07-04T01:51:24Z + file: dev-to-ptnb0b.txt - title: "The Grug Brained Developer" url: https://grugbrain.dev/ date: 2023-05-12T13:08:33Z @@ -30,17 +38,22 @@ references: * So much stuff doesn't work -- bugs stop you from accomplishing your desired task * Over time, complexity creeps in, making changes gets harder * The focus on performance, serverless, microservices, etc. -- these increase complexity, reduce reliability +* Everyone agrees that the current status quo sucks, but we disagree on the solution: go back to how things worked in the past, or continue down the path we're on with the hope that things will improve + * Reference ["Second-guessing the modern web"][1] and ["In defense of the modern web"][2] + +[1]: https://macwright.com/2020/05/10/spa-fatigue.html +[2]: https://dev.to/richharris/in-defense-of-the-modern-web-2nia ### Links -* [The Grug Brained Developer][1] -* [Even Amazon can't make sense of serverless or microservices][2] -* [Imaginary Problems Are the Root of Bad Software][3] -* [When to Build Millennia Sewers][4] -* [We are wasting up to 20% of our time on computer problems, says study][5] +* [The Grug Brained Developer][3] +* [Even Amazon can't make sense of serverless or microservices][4] +* [Imaginary Problems Are the Root of Bad Software][5] +* [When to Build Millennia Sewers][6] +* [We are wasting up to 20% of our time on computer problems, says study][7] -[1]: https://grugbrain.dev/ -[2]: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 -[3]: https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software -[4]: https://taylor.town/millennium-sewer -[5]: https://techxplore.com/news/2023-06-problems.html +[3]: https://grugbrain.dev/ +[4]: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 +[5]: https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software +[6]: https://taylor.town/millennium-sewer +[7]: https://techxplore.com/news/2023-06-problems.html diff --git a/static/archive/dev-to-ptnb0b.txt b/static/archive/dev-to-ptnb0b.txt new file mode 100644 index 0000000..7aed9d8 --- /dev/null +++ b/static/archive/dev-to-ptnb0b.txt @@ -0,0 +1,2595 @@ + #[1]DEV Community + + [2]Skip to content + + (BUTTON) [3]DEV Community + ____________________ (BUTTON) + [4]Log in [5]Create account + +DEV Community + + (BUTTON) + + (BUTTON) + [heart-plus-active-9ea3b22f2bc311281db911d416166c5f430636e76b15cd5df6b3 + b841d830eefa.svg] Add reaction + (BUTTON) + [sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382 + d02920cf.svg] Like (BUTTON) + [multi-unicorn-b44d6f8c23cdd00964192bedc38af3e82463978aa611b4365bd33a0f + 1f4f3e97.svg] Unicorn (BUTTON) + [exploding-head-daceb38d627e6ae9b730f36a1e390fca556a4289d5a41abb2c35068 + ad3e2c4b5.svg] Exploding Head (BUTTON) + [raised-hands-74b2099fd66a39f2d7eed9305ee0f4553df0eb7b4f11b01b6b1b49997 + 3048fe5.svg] Raised Hands (BUTTON) + [fire-f60e7a582391810302117f987b22a8ef04a2fe0df7e3258a5f49332df1cec71e. + svg] Fire + (BUTTON) Jump to Comments (BUTTON) Save + (BUTTON) + (BUTTON) Copy link + Copied to Clipboard + [6]Share to Twitter [7]Share to LinkedIn [8]Share to Reddit [9]Share to + Hacker News [10]Share to Facebook [11]Share to Mastodon + [12]Share Post via... [13]Report Abuse + + [14]Rich Harris + [15]Rich Harris + + Posted on May 15, 2020 + [sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382 + d02920cf.svg] + [multi-unicorn-b44d6f8c23cdd00964192bedc38af3e82463978aa611b4365bd33a0f + 1f4f3e97.svg] + [exploding-head-daceb38d627e6ae9b730f36a1e390fca556a4289d5a41abb2c35068 + ad3e2c4b5.svg] + [raised-hands-74b2099fd66a39f2d7eed9305ee0f4553df0eb7b4f11b01b6b1b49997 + 3048fe5.svg] + [fire-f60e7a582391810302117f987b22a8ef04a2fe0df7e3258a5f49332df1cec71e. + svg] + +In defense of the modern web + + [16]#javascript [17]#react [18]#svelte [19]#webdev + + I expect I'll annoy everyone with this post: the anti-JavaScript + crusaders, justly aghast at how much of the stuff we slather onto + modern websites; the people arguing the web is a broken platform for + interactive applications anyway and we should start over; React users; + the old guard with their artisanal JS and hand authored HTML; and + [20]Tom MacWright, someone I've admired from afar since I first became + aware of his work on Mapbox many years ago. But I guess that's the + price of having opinions. + + Tom recently posted [21]Second-guessing the modern web, and it took the + front end world by storm. You should read it, or at the very least the + [22]CliffsNotes. There's a lot of stuff I agree with to varying + degrees: + + There is a sweet spot of React: in moderately interactive interfaces + ... But there’s a lot on either side of that sweet spot. + + It's absolutely the case that running React in the client for a largely + static site is overkill. It's also true that you have to avoid React if + your app is very heavily interactive — it's widely understood that if + you want 60fps animation, you will likely have to bypass the React + update cycle and do things in a more imperative fashion (indeed, this + is what libraries like [23]react-spring do). But while all this is true + of React, it's much less true of component frameworks in general. + + User sessions are surprisingly long: someone might have your website + open in a tab for weeks at a time. I’ve seen it happen. So if they + open the ‘about page’, keep the tab open for a week, and then + request the ‘home page’, then the home page that they request is + dictated by the index bundle that they downloaded last week. This is + a deeply weird and under-discussed situation. + + It's an excellent point that isn't really being addressed, though (as + Tom acknowledges) it's really just exacerbating a problem that was + always there. I think there are solutions to it — we can iterate on the + 'index bundle' approach, we could include the site version in a cookie + and use that to show actionable feedback if there's a mismatch — but we + do need to spend time on it. + + It’s your startup’s homepage, and it has a “Sign up” button, but + until the JavaScript loads, that button doesn’t do anything. So you + need to compensate. + + This is indeed very annoying, though it's easy enough to do this sort + of thing — we just need to care enough: + + + But I'm not sure what this has to do with React-style frameworks — this + issue exists whatever form your front end takes, unless you make it + work without JS (which you should!). + + Your formerly-lightweight application server is now doing quite a + bit of labor, running React & making API requests in order to do + this pre-rendering. + + Again, this is true but more React-specific than anything. React's + approach to server-side rendering — constructing a component tree, then + serialising it — involves overhead that isn't shared by frameworks + that, for example, compile your components ([24]hi!) to functions that + just concatenate strings for SSR, which is faster by a dramatic amount. + And those API requests were going to have to get made anyway, so it + makes sense to do them as early as possible, especially if your app + server and API server are close to each other (or even the same thing). + + The dream of APIs is that you have generic, flexible endpoints upon + which you can build any web application. That idea breaks down + pretty fast. + + Amen. [25]Just go and read the whole 'APIs' section several times. + __________________________________________________________________ + + Minor quibbles aside, Tom identifies some real problems with the state + of the art in web development. But I think the article reaches a + dangerous conclusion. + + Let's start by dissecting this statement: + + I can, for example, guarantee that this blog is faster than any + Gatsby blog (and much love to the Gatsby team) because there is + nothing that a React static site can do that will make it faster + than a non-React static site. + + With all due respect to those involved, I don't think Gatsby is a + particularly relevant benchmark. The gatsby new my-site starter app + executes 266kB of minified JavaScript for a completely static page in + production mode; for [26]gatsbyjs.org it's 808kB. Honestly, these are + not impressive numbers. + + [27]The Lighthouse performance score for gatsbyjs.org + The [28]Lighthouse score for Gatsby's homepage, obtained via + [29]webpagetest.org/easy. + + Leaving that aside, I disagree with the premise. When I tap on a link + on Tom's JS-free website, the browser first waits to confirm that it + was a tap and not a brush/swipe, then makes a request, and then we have + to wait for the response. With a framework-authored site with + client-side routing, we can start to do more interesting things. We can + make informed guesses based on analytics about which things the user is + likely to interact with and preload the logic and data for them. We can + kick off requests as soon as the user first touches (or hovers) the + link instead of waiting for confirmation of a tap — worst case + scenario, we've loaded some stuff that will be useful later if they do + tap on it. We can provide better visual feedback that loading is taking + place and a transition is about to occur. And we don't need to load the + entire contents of the page — often, we can make do with a small bit of + JSON because we already have the JavaScript for the page. This stuff + gets fiendishly difficult to do by hand. + + Beyond that, vanilla static sites are not an ambitious enough goal. + Take transitions for example. Web developers are currently trapped in a + mindset of discrete pages with jarring transitions — click a link, see + the entire page get replaced whether through client-side routing or a + page reload — while native app developers are thinking on another + level: + + unknown tweet media content Play butt + + Ryan Florence profile image + Ryan Florence + [30]@ryanflorence + twitter logo + This is what I've had in mind for the web with React Router. We say + these kinds of animations are "good for phones but not desktop". + My iPad pro is as big as my laptop and these apps are shopping/content + (most of the web). + These transitions are such a great UX. + 16:06 PM - 22 Oct 2019 + [31]Twitter reply action [32]Twitter retweet action 20 [33]Twitter like + action 197 + + It will take more than technological advancement to get the web there; + it will take a cultural shift as well. But we certainly can't get there + if we abandon our current trajectory. Which is exactly what Tom seems + to be suggesting. + __________________________________________________________________ + + I'm not aware of any other platform where you're expected to write the + logic for your initial render using a different set of technologies + than the logic for subsequent interactions. The very idea sounds daft. + But on the web, with its unique history, that was the norm for many + years — we'd generate some HTML with PHP or Rails or whatever, and then + 'sprinkle some jQuery' on it. + + With the advent of Node, that changed. The fact that we can do + server-side rendering and communicate with databases and what-have-you + using a language native to the web is a wonderful development. + + There are problems with this model. Tom identifies some of them. + Another major issue he doesn't discuss is that the server-rendered SPA + model typically 'hydrates' the entire initial page in a way that + requires you to duplicate a ton of data — once in the HTML, once in the + JSON blob that's passed to the client version of the app to produce the + exact same result — and can block the main thread during the period the + user is starting to interact with the app. + + But we can fix those problems. [34]Next is doing amazing innovation + around (for example) mixing static and dynamic pages within a single + app, so you get the benefits of the purely static model without ending + up finding yourself constrained by it. [35]Marko does intelligent + component-level hydration, something I expect other frameworks to + adopt. [36]Sapper, the companion framework to [37]Svelte, has a stated + goal of eventually not sending any JS other than the (tiny) router + itself for pages that don't require it. + + The future I want — the future I see — is one with tooling that's + accessible to the greatest number of people (including designers), that + can intelligently move work between server and client as appropriate, + that lets us build experiences that compete with native on UX (yes, + even for blogs!), and where upgrading part of a site to 'interactive' + or from 'static' to 'dynamic' doesn't involve communication across + disparate teams using different technologies. We can only get there by + committing to the paradigm Tom critiques — the JavaScript-ish component + framework server-rendered SPA. (Better names welcomed.) + + The modern web has flaws, and we should talk about them. But let's not + give up on it. + +Top comments (98) + + (BUTTON) Crown + +Sort discussion: + + * Top + Most upvoted and relevant comments will be first + * Latest + Most recent comments will be first + * Oldest + The oldest comments will be first + + Subscribe + pic + + ____________________________________________________________ + ____________________________________________________________ + ____________________________________________________________ + ____________________________________________________________ + + (BUTTON) Personal (BUTTON) Trusted User + [38]Create template + + Templates let you quickly answer FAQs or store snippets for re-use. + (BUTTON) Submit (BUTTON) Preview [39]Dismiss + + [40]twigman08 profile image + [41]Chad Smith + (BUTTON) Chad Smith + [42]Chad Smith + (button) Follow + Work with C# all day everyday creating web applications. Huge baseball + buff. + * Location + Texas + * Education + B.S in Computer Science + * Joined + Dec 17, 2017 + + • [43]May 15 '20 + (BUTTON) + * [44]Copy link + * + * (BUTTON) Hide + * + * + * + + Honestly my biggest issue with the current state of the web is the + current state of how complex the tools or build process is. + + I miss the days of some html, add a bit of JavaScript to the page and + you were done. You didn't worry about going and making sure you had a + complete build or bundling process to get everything good. You spent + your time worrying about how to develop your app. Which in my opinion + was better for the users. There was less bugs. We actually spent more + time making sure the application worked rock solid. + + Nowadays to get anything cool to be be ready for production you have + spend needless time on the configuration. Did you do this? Did you + configure it to do that? Oh you can't do that unless you eject it that + build tool and use this build tool. That's where the current state of + the web is failing. + + Sure we have taken steps forward in some areas. But we have to be + honest with ourselves. We took major steps back in other areas of the + web. Sometimes I wonder if we took too many steps back. + + (BUTTON) 61 likes Like Reply + + [45]gotofritz profile image + [46]fritz + (BUTTON) fritz + [47]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [48]May 18 '20 + (BUTTON) + * [49]Copy link + * + * (BUTTON) Hide + * + * + * + + I don't get it. Nobody's stopping you from firing up an HTML doc in + Notepad and FTPing the result to a web server, if that's all you need. + But other people have more complex needs (in the "good ole days" there + were no smart phones, to mention just one thing) and therefore we need + more complex tools. Why do you want to force me to party like it's + 1999? + + (BUTTON) 23 likes Like Reply + + [50]twigman08 profile image + [51]Chad Smith + (BUTTON) Chad Smith + [52]Chad Smith + (button) Follow + Work with C# all day everyday creating web applications. Huge baseball + buff. + * Location + Texas + * Education + B.S in Computer Science + * Joined + Dec 17, 2017 + + • [53]May 19 '20 + (BUTTON) + * [54]Copy link + * + * (BUTTON) Hide + * + * + * + + My issue isn't with applications are too complex really. I develop + complex applications too at work. + + My issue is with all the moving parts with a modern web application. + Fighting if I can use certain language features. Oh I can't, now I have + to bother with setting up and making sure I can use Babel or something + to do it properly, or even loading in polyfills (cool just added + another dependency the browser has to load before the application can + be used). + + That still hasn't covered bundling everything. What's the correct way + bundle this? Well crap I now have to go and correctly configure + WebPack. Unless you're one of the VERY FEW experts on that ,that will + take time to figure out to get right. Ok so I think it bundles right, + well now how should I lazy load this code for the user? What should be + lazy loaded? What should i use to set it up? + + That's just the beginning. I could go on and on about the other complex + moving parts with a modern web application. + + I am not asking anyone to make applications like it is 1999. All I'm + asking for is a more modern and simpler process that is a STANDARD. + + Maybe it is because I come from compiled language background. Where I + have to worry about that one single binary. I only have to worry if the + compiler supports the language version I'm using. Where I can just pass + in a single flag to the compiler for the optimization level I want. + + Yes I will be the first to say that in some areas of modern web + application development we have taken steps forward. I just wonder if + we have taken steps back in some areas to take those steps forward. + + (BUTTON) 13 likes Like Thread + + [55]gotofritz profile image + [56]fritz + (BUTTON) fritz + [57]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [58]May 22 '20 • Edited on May 22 • Edited + (BUTTON) + * [59]Copy link + * + * (BUTTON) Hide + * + * + * + + All I'm asking for is a more modern and simpler process that is a + STANDARD ... + Maybe it is because I come from compiled language background ... + + Well I am sorry, but web development is a complete different kettle of + fish. We download all the parts that make up an application + asynchronously, on a wide variety of devices, with different specs and + rendering capabilities - all things which the app, once downloaded, + need to adapt to. We have progressive rendering and respond to all sort + of sensors. All while ensuring boot up time for the app is in the + microseconds range and security for both you who download the code and + the server. + + Your expectations are simply unrealistic, sorry. + + Also, we always had polyfills, even "back in the day". Except that back + then everyone had to bake their own. In fact, we had browser wars and + appalling browser (IE5 for the Mac, anyone??!?) and it was a real pain + in the neck. + + (BUTTON) 10 likes Like Reply + + [60]adrianus profile image + [61]Adrianus + (BUTTON) Adrianus + [62]Adrianus + (button) Follow + Running a small company based in Kent. + * Location + Chatham, Kent + * Education + autodidactic + * Work + Entrepreneur at AVANDERGRINTEN Ltd. + * Joined + Jan 21, 2020 + + • [63]May 19 '20 • Edited on May 20 • Edited + (BUTTON) + * [64]Copy link + * + * (BUTTON) Hide + * + * + * + + Bingo, the complexity today is a must, at least because of the growing + smartphone usage. The simple reason why "Native Apps didn't kill the + web even with all their superior capabilities" (Ryan) is simply UX. As + internet usage often starts with searching for something having in + mind, that all-app-thinking interrupts exactly this flow, leaving at + least 30% of all traffic untouched. For what? For 5-minutes-crafts + skyrocketing their YouTube traffic? Although not everything needs + server side complexity plus having API's and webhooks easily integrated + using browser capabilities not existing in the god old days, the + architecture underneath is not the real issue. + + (BUTTON) 3 likes Like Reply + + [65]techbelle profile image + [66]rachelle palmer + (BUTTON) rachelle palmer + [67]rachelle palmer + (button) Follow + I decided I would try to build an app in every programming language. + That didn't happen, but what I learned along the way was really + valuable. + * Location + Raleigh, NC + * Joined + Sep 23, 2020 + + • [68]Feb 25 '21 + (BUTTON) + * [69]Copy link + * + * (BUTTON) Hide + * + * + * + + re: sessions --> I keep tabs open for months at a time, not sure about + anyone else + + (BUTTON) 1 like Like Reply + + [70]ojrask profile image + [71]Otto Rask + (BUTTON) Otto Rask + [72]Otto Rask + (button) Follow + A software engineer, mainly PHP, Rust, and related things. + * Location + Finland + * Joined + Mar 12, 2019 + + • [73]May 28 '21 + (BUTTON) + * [74]Copy link + * + * (BUTTON) Hide + * + * + * + + You fight complexity with ... more complexity? + + (BUTTON) 1 like Like Thread + + [75]gotofritz profile image + [76]fritz + (BUTTON) fritz + [77]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [78]May 28 '21 + (BUTTON) + * [79]Copy link + * + * (BUTTON) Hide + * + * + * + + You are getting it wrong. The aim is not "to fight complexity". The aim + is to fulfil complex needs. I am saying for that you often need more + complex tools. + + (BUTTON) 1 like Like Thread + + [80]ojrask profile image + [81]Otto Rask + (BUTTON) Otto Rask + [82]Otto Rask + (button) Follow + A software engineer, mainly PHP, Rust, and related things. + * Location + Finland + * Joined + Mar 12, 2019 + + • [83]May 28 '21 + (BUTTON) + * [84]Copy link + * + * (BUTTON) Hide + * + * + * + + What percentage of modern web is a "complex needs" target that requires + a complex solution such as React or Vue or perhaps something custom + written in WASM? 50% 25%? 5% 1%? + + (BUTTON) 2 likes Like Thread + + [85]gotofritz profile image + [86]fritz + (BUTTON) fritz + [87]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [88]May 28 '21 + (BUTTON) + * [89]Copy link + * + * (BUTTON) Hide + * + * + * + + All of it. Unless you have actual data that proves otherwise... + + (BUTTON) 2 likes Like Thread + + [90]jacobmakestheweb profile image + [91]Jacob Ybarra + (BUTTON) Jacob Ybarra + [92]Jacob Ybarra + (button) Follow + dank web dev + * Education + school + * Work + nada + * Joined + Sep 21, 2021 + + • [93]Sep 21 '21 + (BUTTON) + * [94]Copy link + * + * (BUTTON) Hide + * + * + * + + uh what? the web is about content and media. not a software + environment. + + (BUTTON) 1 like Like Reply + + [95]mark_saward profile image + [96]Mark Saward + (BUTTON) Mark Saward + [97]Mark Saward + (button) Follow + CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go, + Rust, SQL, Devops + * Location + Victoria, Australia + * Education + BA/Bsc in Philosophy and Physics. PhD in Philosophy. + * Work + CEO/Software Developer at Episub + * Joined + May 13, 2020 + + • [98]May 15 '20 + (BUTTON) + * [99]Copy link + * + * (BUTTON) Hide + * + * + * + + Some interesting thoughts, in the original article and your response. + Certainly good for generating discussion :) + + It will take more than technological advancement to get the web + there; it will take a cultural shift as well. But we certainly can't + get there if we abandon our current trajectory. + + The problem as I see it is that the web -- in terms of client-side + executed markup and code (HTML/CSS/JavaScript) just wasn't designed + with these kinds of interactions in mind (the interactions that Ryan + Florence highlighted). It's the wrong foundation for it. + + I don't think that "getting there" should be through bending original + web technologies, but rather with something else entirely -- perhaps + WebAssembly, or a return to actual native applications much like we've + come to depend on on our tablets and phones. We already can do nice + animations like that iPad demo with native desktop applications. + There's many advantages to websites over native desktop apps, with the + standout one being that they don't require someone to install an + application on their machine. Maybe WebAssembly can give us a + compromise -- desktop apps built with technology designed for that job, + but available in a way that doesn't require any local installation. + Then we can use tools that were purpose built for those kinds of tasks, + instead of trying to wrangle the foundations of the web to fit + something they were never built for. + + When I think back to how we used to build websites back in the day, and + how we build sites with technologies in tools like React now, I'm + honestly not sure that we've gained anything of great enough value + relative to the simplicity we've lost. In short, I'd be happy to + abandon our current trajectory and put our hope in alternative + solutions for those situations where what we really need is a native + application. Leave the web for what it's good at. + + (BUTTON) 23 likes Like Reply + + [100]ryansolid profile image + [101]Ryan Carniato + (BUTTON) Ryan Carniato + [102]Ryan Carniato + (button) Follow + Frontend performance enthusiast and Fine-Grained Reactivity super fan. + Author of the SolidJS UI library and MarkoJS Core Team Member. + * Location + San Jose, California + * Education + Computer Engineering B.A.Sc, University of British Columbia + * Work + Principal Engineer, Open Source, Netlify + * Joined + Jun 25, 2019 + + • [103]May 15 '20 + (BUTTON) + * [104]Copy link + * + * (BUTTON) Hide + * + * + * + + That's interesting. I mean I was there too, and the extent of what I + can build with a modern library so extends what I could reasonably do + before. And the reason for that is JavaScript. When I was building + sites in the late 90s so many things weren't possible and you had no + choice but to pay these costs for interactivity. Sure I view sourced a + few cool tricks.. image maps etc, but with my table based layouts and a + little JavaScript I could do very little. Part of it was the available + DOM api's. My lack of understanding of the language but I think we look + at the past with rose colored glasses. + + It's more interesting to me that native platforms have borrowed + concepts from libraries like React in terms of declarative views etc. + I'm not saying React invented this stuff but that the trend would + suggest the contrary. These trends could be mistakes but popularity has + as much stake in the course of events as innate value. + + I think this comes down to really this hope of a Silver Bullet. It + doesn't exist. Instead we have momentum of a ubiquitous platform that + just is constantly aiming to improve. It's not only that the other + approaches have already lost, we're getting to a point where any new + approach will have to atleast acknowledge the current web. At this + point a competitor isn't going to change the tide, but something from + within. It's more likely that the web addresses those fundamental + shortcomings than people moving to a different platform. Native Apps + didn't kill the web even with all their superior capabilities. And on a + similar note it is going to take monumental change for this to + fundamentally change. Even with React's reach, it wasn't alone in a + movement that started years before. This is bigger than any particular + library or framework. + + (BUTTON) 13 likes Like Reply + + [105]mark_saward profile image + [106]Mark Saward + (BUTTON) Mark Saward + [107]Mark Saward + (button) Follow + CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go, + Rust, SQL, Devops + * Location + Victoria, Australia + * Education + BA/Bsc in Philosophy and Physics. PhD in Philosophy. + * Work + CEO/Software Developer at Episub + * Joined + May 13, 2020 + + • [108]May 16 '20 • Edited on May 16 • Edited + (BUTTON) + * [109]Copy link + * + * (BUTTON) Hide + * + * + * + + There is absolutely no doubt that you can do incredible things with + modern web, and the power unlocked by having a programming language in + the browser has been amazing. However, when I think about a great deal + of the websites I interact with, and ones I build, there would not be + much lost if they significantly simplified the tech stack they work + with to be closer to the core technologies of the web (including a + splash of JavaScript). + + What I'm trying to convey is that I think our move to make everything a + web app has been a mistake, for multiple reasons. You are absolutely + right to say that this tide is going to be very hard (perhaps + impossible) to turn, and I absolutely agree there is no silver bullet + (I've looked), but that doesn't mean we haven't taken a worse path and + shouldn't lament for what could have been. + + The advantages of web apps are compelling for developers -- they are + easy to distribute, update, control, make cross platform, when compared + to native apps. It is not hard to understand why and how we have ended + up where we are. I just wish we were somewhere else -- but it would + take a lot of work to create that 'silver bullet'. + + (BUTTON) 11 likes Like Thread + + [110]adrianus profile image + [111]Adrianus + (BUTTON) Adrianus + [112]Adrianus + (button) Follow + Running a small company based in Kent. + * Location + Chatham, Kent + * Education + autodidactic + * Work + Entrepreneur at AVANDERGRINTEN Ltd. + * Joined + Jan 21, 2020 + + • [113]May 19 '20 • Edited on May 20 • Edited + (BUTTON) + * [114]Copy link + * + * (BUTTON) Hide + * + * + * + + That whole app environment was basically triggered by one need, and one + need only: bandwidth. No idea if anyone remembers when they launched + this WAP protocol, making the internet available on smartphones, what + failed for two reasons. The providers made it easy to access on their + own portals aka AOL strategy at beginning of the web, leaving the rest + of the market untouched, secondly the site performance was ridiculous. + Apple stepped in, put a bunch of intelligence into the app, + dramatically reducing the load time, did not convert so much traffic on + their own apps and let developers do what they do best. By 2008 more + than 50% of the whole mobile internet traffic was iPhone traffic. + + Bandwidth is no longer the breaking point. + + Google has for years campaigned the untapped goldmine local traffic, + experience flows that often start at the search for getting something + done in time, monetising on micro moments as more than half of all + mobile searches have a local intend. I posted an example how something + to get done interferes cross-applicational from the perspective of a + user. With an app-only scheme this is getting impossible. Sure it is + understandable that nobody pays so much attention. Most search engines + run a change and heavily invested in AI to optimise traffic at the + client's frontend. But even this is not enough, when it comes to + intends other than something very individualised. I wouldn't care so + much about the user, but more about what the user wants to achieve. + + (BUTTON) 1 like Like Reply + + + [115]oenonono profile image + [116]Junk + (BUTTON) Junk + [117]Junk + (button) Follow + * Joined + Mar 12, 2017 + + • [118]May 17 '20 + (BUTTON) + * [119]Copy link + * + * (BUTTON) Hide + * + * + * + + React definitely didn't invent HTML. + + Declarative views, indeed. + + (BUTTON) 1 like Like Reply + + + [120]v6 profile image + [121]🦄N B🛡 + (BUTTON) 🦄N B🛡 + [122]🦄N B🛡 + (button) Follow + // , “It is not so important to be serious as it is to be serious about + the important things. The monkey wears an expression of seriousness... + but the monkey is serious because he itches."(No/No) + * Location + (No/No) + * Education + (No/No) + * Work + Security + * Joined + Mar 1, 2018 + + • [123]May 15 '20 + (BUTTON) + * [124]Copy link + * + * (BUTTON) Hide + * + * + * + + The problem as I see it is that the web -- in terms of client-side + executed markup and code (HTML/CSS/JavaScript) just wasn't designed + with these kinds of interactions in mind (the interactions that Ryan + Florence highlighted). It's the wrong foundation for it. + + Yes. Please. Can we please just accept that it's all broken. + + (BUTTON) 4 likes Like Reply + + + [125]gotofritz profile image + [126]fritz + (BUTTON) fritz + [127]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [128]May 18 '20 • Edited on May 18 • Edited + (BUTTON) + * [129]Copy link + * + * (BUTTON) Hide + * + * + * + + Not at all. + + CSS has media queries and all sort of crazy and wonderful stuff. HTML + has tags for responsive design. JS has (in the browser) access to apis + like mutation observer and orientation and speech recognition. It's + TOTALLY built for that. Enough of the "get off my lawn" negativity + + (BUTTON) 8 likes Like Thread + + [130]v6 profile image + [131]🦄N B🛡 + (BUTTON) 🦄N B🛡 + [132]🦄N B🛡 + (button) Follow + // , “It is not so important to be serious as it is to be serious about + the important things. The monkey wears an expression of seriousness... + but the monkey is serious because he itches."(No/No) + * Location + (No/No) + * Education + (No/No) + * Work + Security + * Joined + Mar 1, 2018 + + • [133]May 18 '20 • Edited on May 18 • Edited + (BUTTON) + * [134]Copy link + * + * (BUTTON) Hide + * + * + * + + shakes his cane at you + + mutters incomprehensibly + + (BUTTON) 4 likes Like Reply + + + [135]stew_sims profile image + [136]Stewart Sims + (BUTTON) Stewart Sims + [137]Stewart Sims + (button) Follow + * Joined + May 31, 2019 + + • [138]May 15 '20 • Edited on May 15 • Edited + (BUTTON) + * [139]Copy link + * + * (BUTTON) Hide + * + * + * + + There's a lot to agree with in both of these takes. However, one + criticism of this one (and I realise we're getting into hugely + subjective territory) is the assumption that the goal should be to + 'build experiences that compete with native on UX'. It strikes me that + the web never was and never will be anything like any other platform + for building applications. Whether or not someone wants to turn it into + that is their prerogative and any success they have probably will help + others build better things. But it ultimately depends on what you want + to build and why, and emulating a native application might not always + be the best option. I think the key is to allow ourselves to question + the assumptions we all hold which seems to be exactly what both of you + are doing with different approaches, reaching different conclusions. So + I would say; keep doing that and keep doing your thing, but just don't + expect everyone to agree and do things the same way. The world is a + better place when we allow and encourage people not to homogenise in + their thinking. + + (BUTTON) 34 likes Like Reply + + + [140]rhymes profile image + [141]rhymes + (BUTTON) rhymes + [142]rhymes + (button) Follow + Such software as dreams are made on. I mostly rant about performance, + unnecessary complexity, privacy and data collection. + * Joined + Feb 2, 2017 + + • [143]May 18 '20 • Edited on May 18 • Edited + (BUTTON) + * [144]Copy link + * + * (BUTTON) Hide + * + * + * + + It strikes me that the web never was and never will be anything like + any other platform for building applications. Whether or not someone + wants to turn it into that is their prerogative and any success they + have probably will help others build better things. But it + ultimately depends on what you want to build and why, and emulating + a native application might not always be the best option. + + this :-) + + (BUTTON) 5 likes Like Reply + + + [145]oenonono profile image + [146]Junk + (BUTTON) Junk + [147]Junk + (button) Follow + * Joined + Mar 12, 2017 + + • [148]May 17 '20 + (BUTTON) + * [149]Copy link + * + * (BUTTON) Hide + * + * + * + + points up + + (BUTTON) 1 like Like Reply + + + [150]holdit profile image + [151]holdit + (BUTTON) holdit + [152]holdit + (button) Follow + * Joined + May 15, 2020 + + • [153]May 15 '20 + (BUTTON) + * [154]Copy link + * + * (BUTTON) Hide + * + * + * + + Looking at the criticism made about some recent redesigns (reddit, + facebook, etc) it seems that the main complaint (from a user point of + view, at least) is how slow it feels compared to the previous version + or to a "simple" site with HTML, CSS, and a little bit of javascript. + + I haven't checked it recently, but when the new reddit UI was released, + scrolling was terrible on my $2500k laptop. It felt slow. Everything + was sluggish. It also downloaded a few MB of javascript on pages that + essentially had a thumbnail, a title, and some comments (not everyone + lives in a big city or is connected to a super fast internet + connection!). When the page was loaded, I was seeing more scrolling lag + because they lazyload some content. I mean, it's hard to like this + "modern web". + + As a user, I don't care about how things work behind the scenes. I + don't mind some javascript on a page, after all we don't need a page + reload just to preview a comment or "like" something. You can even use + javascript for everything, I don't mind. But it needs to be fast and it + needs to work well... and right now some "modern" sites provide a worse + experience than before. + + (BUTTON) 24 likes Like Reply + + + [155]iamschulz profile image + [156]Daniel Schulz + (BUTTON) Daniel Schulz + [157]Daniel Schulz + (button) Follow + Hi! I'm a frontend guy. + * Location + Germany + * Education + Studied Media Art and Design + * Work + Performance Engineer at Baqend + * Joined + Sep 17, 2018 + + • [158]May 15 '20 • Edited on May 15 • Edited + (BUTTON) + * [159]Copy link + * + * (BUTTON) Hide + * + * + * + + Tom identified the main weakness of modern web development correctly: + It's based on javascript. He points out the sluggishness and + accessibility problems that stem from that attitude, and hes absolutely + right to do so. Static pages (as a paradigm, not as Gatsby in + particular) are maybe not the cure for that, but they are definitely a + step into the right direction. + I just rewrote my website with hugo and specifically without a major JS + framework, but settled for a vanilla approach rooted in a progressive + enhancement mindset. I didn't even run into the problems that are + inherent to React, Vue and Angular. + Sure, you can serve HTML with SSR, but you still have to wait for the + bundle in order to have a functional site, plus a truckload of + ssr-related complexity. And that is utter rubbish. JS should never be a + requirement, it needs to be put in its place as the cherry on top of + the cake. + Progressive enhancement needs not only to be a major approach to + webdevelopment again, it needs to be out default mode of operation. + This is also the core of Toms article. And I agree with him. + + That said, nothing stops you from adding features like nice + transitions. But please be sure not to break standard web features + while doing so. + Transitions need to add to hyperlinks, not replace them. + + (BUTTON) 21 likes Like Reply + + + [160]richharris profile image + [161]Rich Harris + (BUTTON) Rich Harris + [162]Rich Harris + (button) Follow + I like turtles + * Location + Behind you + * Work + Graphics editor at the New York Times + * Joined + Jun 20, 2019 + + • [163]May 15 '20 + (BUTTON) + * [164]Copy link + * + * (BUTTON) Hide + * + * + * + + I feel like you didn't quite read the article closely enough ;) Of + course progressive enhancement needs to be the default — that's why + there's so much focus on SSR in all major meta-frameworks. + + Sure, you can serve HTML with SSR, but you still have to wait for + the bundle in order to have a functional site + + This isn't true! Take [165]sapper.svelte.dev, which is a site built + with Sapper and baked out as static pages. It works just fine without + JavaScript, you just don't get client-side routing. It's a small site, + but the same thing applies to larger ones like Gatsby's homepage — no + JS? No problem. + + (BUTTON) 20 likes Like Reply + + + [166]iamschulz profile image + [167]Daniel Schulz + (BUTTON) Daniel Schulz + [168]Daniel Schulz + (button) Follow + Hi! I'm a frontend guy. + * Location + Germany + * Education + Studied Media Art and Design + * Work + Performance Engineer at Baqend + * Joined + Sep 17, 2018 + + • [169]May 15 '20 + (BUTTON) + * [170]Copy link + * + * (BUTTON) Hide + * + * + * + + It certainly is true for standard implementations of React-, Vue- and + Angular- based sites. There may be a focus on SSR, but it still isn't + close enough to deserve to be the default. It needs to come without + extra complexity. Only then we're ready to take the step to fully + embrace those solution. + + And this is my point. You need to take one step after the other. It was + a mistake to build everything with javascript first and then try to + look if it still works without afterwards. The damage to the web has + been done. + + I didn't take a look at Sapper/Svelte. Though, in comparison, those are + still a nieche product. + + (BUTTON) 7 likes Like Thread + + [171]martinmalinda profile image + [172]Martin Malinda + (BUTTON) Martin Malinda + [173]Martin Malinda + (button) Follow + * Joined + Apr 7, 2020 + + • [174]May 18 '20 + (BUTTON) + * [175]Copy link + * + * (BUTTON) Hide + * + * + * + + The damage to the web has been done. + + JS certainly caused a lot of damage on many websites. But now - finally + - we're getting to the point of having frameworks which can, by + default, offer client-side routing with SSR and hydration without + shipping large bundles of JS. Up to this point the frontend devs should + have been more conservative and they should have thought twice whether + they should really go all-in into an SPA. But now's the time when it's + really starting to be a viable option. Next, Nuxt, Marko and Sapper are + finally technologies highly worth pursuing, even for content-based + websites. + + (BUTTON) 2 likes Like Reply + + + [176]ben profile image + [177]Ben Halpern + (BUTTON) Ben Halpern + [178]Ben Halpern + (button) Follow + A Canadian software developer who thinks he’s funny. + * Email + [179]ben@forem.com + * Location + NY + * Education + Mount Allison University + * Pronouns + He/him + * Work + Co-founder at Forem + * Joined + Dec 27, 2015 + + • [180]May 15 '20 + (BUTTON) + * [181]Copy link + * + * (BUTTON) Hide + * + * + * + + The future I want — the future I see — is one with tooling that's + accessible to the greatest number of people (including designers), + that can intelligently move work between server and client as + appropriate, that lets us build experiences that compete with native + on UX (yes, even for blogs!), and where upgrading part of a site to + 'interactive' or from 'static' to 'dynamic' doesn't involve + communication across disparate teams using different technologies. + We can only get there by committing to the paradigm Tom critiques — + the JavaScript-ish component framework server-rendered SPA. (Better + names welcomed.) + + I like this takeaway because it's heavy on acknowledging the process + behind the technology which is often disparate and confusing. Even the + most well-intentioned and organized dev team is going to get out of + wack if succeeding with the tooling is experts only. We need to be able + to achieve great performance, UX and accessibility even under + conditions where designers do some work, devs pop in some hotfixes here + and there, old devs leave with some of the knowledge, priorities + change, etc. + + (BUTTON) 19 likes Like Reply + + + [182]v6 profile image + [183]🦄N B🛡 + (BUTTON) 🦄N B🛡 + [184]🦄N B🛡 + (button) Follow + // , “It is not so important to be serious as it is to be serious about + the important things. The monkey wears an expression of seriousness... + but the monkey is serious because he itches."(No/No) + * Location + (No/No) + * Education + (No/No) + * Work + Security + * Joined + Mar 1, 2018 + + • [185]May 15 '20 • Edited on May 15 • Edited + (BUTTON) + * [186]Copy link + * + * (BUTTON) Hide + * + * + * + + I like this aspect of Mr. Harris' article, too. It's the first + principle of the Tao of HashiCorp: [187]Workflows, not Technologies. + + The HashiCorp approach is to focus on the end goal and workflow, + rather than the underlying technologies. Software and hardware will + evolve and improve, and it is our goal to make adoption of new + tooling simple, while still providing the most streamlined user + experience possible. Product design starts with an envisioned + workflow to achieve a set goal. We then identify existing tools that + simplify the workflow. If a sufficient tool does not exist, we step + in to build it. This leads to a fundamentally technology-agnostic + view — we will use the best technology available to solve the + problem. As technologies evolve and better tooling emerges, the + ideal workflow is just updated to leverage those technologies. + Technologies change, end goals stay the same. + + And it's why Sacrificial Architecture appeases the dark ones. + + (BUTTON) 4 likes Like Reply + + + [188]phlash profile image + [189]Phil Ashby + (BUTTON) Phil Ashby + [190]Phil Ashby + (button) Follow + 30+ years of tech, retired from an identity intelligence company, job + done! Dev community mod - mostly light gardening & weeding out spam :) + * Location + Felixstowe, UK + * Education + M.Eng (hons) Electronics, MIET, MBCS, AMCIISec, CEH + * Pronouns + he/him + * Work + Retired! + * Joined + Apr 2, 2017 + + • [191]May 15 '20 + (BUTTON) + * [192]Copy link + * + * (BUTTON) Hide + * + * + * + + Good response, opinions are always worth having, as long as you are + prepared to discuss/defend/change them! I had a few thoughts on this + topic last year in response to your good self and web components that I + think is worth referring back to: [193]dev.to/phlash909/comment/cghl + + In essence, the DOM and page model of HTML is a constraint around the + outside of applications that might be better inverted: I'd like to see + browsers that support HTML/DOM content if required, but do not + constrain devs to always go though it. Let's stop thinking of them as + HTML rendering engines, and start thinking of pre-installed runtimes + with excellent web-based application management! + + We'll want to retain the benefits of dynamic software running on the + client (native UX, easy architecture changes, no user-install step, + etc.), while leveraging the effort that goes into making that a + portable & safe thing to do (common APIs, sandboxes, browsers as the + standard runtime for client-side applications). We are nearly there + with PWAs perhaps? WASM then expands the available languages for the + runtime, allowing common client/server languages and development + processes to ease developer adoption. As/when a document needs + rendering, then HTML/DOM/CSS is there to perform it's proper function, + however many apps many be better off with a UX library (eg: SDL) or + widget set (eg: wxWidgets) atop the runtime bindings. + + (BUTTON) 11 likes Like Reply + + + [194]v6 profile image + [195]🦄N B🛡 + (BUTTON) 🦄N B🛡 + [196]🦄N B🛡 + (button) Follow + // , “It is not so important to be serious as it is to be serious about + the important things. The monkey wears an expression of seriousness... + but the monkey is serious because he itches."(No/No) + * Location + (No/No) + * Education + (No/No) + * Work + Security + * Joined + Mar 1, 2018 + + • [197]May 15 '20 + (BUTTON) + * [198]Copy link + * + * (BUTTON) Hide + * + * + * + + start thinking of pre-installed runtimes with excellent web-based + application management! + + If you were to remove the "web-based" part, it'd almost describe the + beginning of OSes back in the day. + + Which is perhaps what they are: The UI part of a vast "operating + system" by which we access the "applications" of the internet. + + (BUTTON) 4 likes Like Reply + + + [199]panesofglass profile image + [200]panesofglass + (BUTTON) panesofglass + [201]panesofglass + (button) Follow + * Joined + Jul 23, 2020 + + • [202]Jul 23 '20 + (BUTTON) + * [203]Copy link + * + * (BUTTON) Hide + * + * + * + + I believe at the point you fundamentally push to render things other + than markup, you start making a different application. And that is + perfectly reasonable. I’m frankly surprised how well HTTP has held up + to so many use cases. I long ago expected to see far more protocols for + more kinds of apps, but HTTP seems to have solved so many problems well + enough that it now hosts other protocols. + + There are probably more protocols that could be written and hosted on + other ports. Those would likely address many of these issues in a far + better way. I just wonder when the industry will pivot back to building + protocols and leave HTTP well enough alone. + + (BUTTON) 1 like Like Reply + + + [204]rhymes profile image + [205]rhymes + (BUTTON) rhymes + [206]rhymes + (button) Follow + Such software as dreams are made on. I mostly rant about performance, + unnecessary complexity, privacy and data collection. + * Joined + Feb 2, 2017 + + • [207]Jul 23 '20 + (BUTTON) + * [208]Copy link + * + * (BUTTON) Hide + * + * + * + + I think we're past that as most recent innovations in the web space are + either formats or evolutions of HTTP. Why reinvent the wheel if the + wheel works well? What do you think? + + (BUTTON) 1 like Like Thread + + [209]panesofglass profile image + [210]panesofglass + (BUTTON) panesofglass + [211]panesofglass + (button) Follow + * Joined + Jul 23, 2020 + + • [212]Jul 23 '20 + (BUTTON) + * [213]Copy link + * + * (BUTTON) Hide + * + * + * + + HTTP/3 with QUIC seems like a great improvement, but it is changing + HTTP. I don’t see why HTTP needs changing for most things. Why not + update SMTP or FTP, as well? QUIC solves specific problems, and it + might be better for those who need QUIC for it to have features better + suited to their needs. + + In some ways, this also feels like the mash of several formats into + HTML5 to avoid name spacing. While we focus on and champion components + within our own apps, we continue to avoid and break components in the + infrastructure. + + Therefore, I think we may see new protocols emerge as the weight of + these complexities begin to cause problems. That could still be some + way off. + + (BUTTON) 1 like Like Thread + + [214]rhymes profile image + [215]rhymes + (BUTTON) rhymes + [216]rhymes + (button) Follow + Such software as dreams are made on. I mostly rant about performance, + unnecessary complexity, privacy and data collection. + * Joined + Feb 2, 2017 + + • [217]Jul 23 '20 + (BUTTON) + * [218]Copy link + * + * (BUTTON) Hide + * + * + * + + I'm not sure it is changing HTTP, it's HTTP over UDP. The protocol is + basically the same as HTTP/1 and HTTP/2. + + QUIC solves specific problems, and it might be better for those who + need QUIC for it to have features better suited to their needs. + + QUIC solves a specific problem HTTP has because it sits on top of TCP + though, basically pipelining + + In some ways, this also feels like the mash of several formats into + HTML5 to avoid name spacing. While we focus on and champion + components within our own apps, we continue to avoid and break + components in the infrastructure. + + I'm not sure I follow the analogy with HTML5, sorry :( IIRC HTML5 was + created to stop having to revise HTML as a a single unit and let things + evolve at their own pace. Same with CSS 3 I guess. I don't think it's + the same thing here: HTTP/3 is the result of the entire world using + HTTP and needing to improve performance. + + Could they have created a new protocol? Sure, but why break + compatibility with millions of browsers, proxies, machines, software + application and so on that understand and function through HTTP? I + think the decision to rewrite the transport layer to be a smart one. + + This doesn't mean that other protocols can't emerge, but it's okay not + to throw away those that work already + + (BUTTON) 1 like Like Reply + + + [219]gregfletcher profile image + [220]Greg Fletcher + (BUTTON) Greg Fletcher + [221]Greg Fletcher + (button) Follow + loop { refactoring() } + * Work + Full Stack at Freelance + * Joined + Mar 16, 2019 + + • [222]May 15 '20 + (BUTTON) + * [223]Copy link + * + * (BUTTON) Hide + * + * + * + + Great article! + + Doesn't a lot of this disagreement stem from --> "keep the web as it + is, coz it's fine" vs "let's make it better by making mistakes along + the way coz that's how software development works"? + + (BUTTON) 14 likes Like Reply + + + [224]v6 profile image + [225]🦄N B🛡 + (BUTTON) 🦄N B🛡 + [226]🦄N B🛡 + (button) Follow + // , “It is not so important to be serious as it is to be serious about + the important things. The monkey wears an expression of seriousness... + but the monkey is serious because he itches."(No/No) + * Location + (No/No) + * Education + (No/No) + * Work + Security + * Joined + Mar 1, 2018 + + • [227]May 15 '20 + (BUTTON) + * [228]Copy link + * + * (BUTTON) Hide + * + * + * + + What about making it better by [229]sacrificing it? + + We can [230]learn this lesson from Biology, that the best way to avoid + excessive optimization is the ultimate flexibility: Keeping the option + on the table to throw out the code, or well abstracted parts of it, and + rewrite that code or product from scratch. + + It's a little known "dark" pattern of Software Design, from the shadows + of Agile, called "Sacrificial Architecture." + + [231]exponential growth isnt kind to architectural decisions + + (BUTTON) 5 likes Like Reply + + + [232]richharris profile image + [233]Rich Harris + (BUTTON) Rich Harris + [234]Rich Harris + (button) Follow + I like turtles + * Location + Behind you + * Work + Graphics editor at the New York Times + * Joined + Jun 20, 2019 + + • [235]May 15 '20 + (BUTTON) + * [236]Copy link + * + * (BUTTON) Hide + * + * + * + + Is the Web for applications? + + I feel like this question sort of answers itself! Have you heard of + Amazon? Gmail? Facebook? + + (BUTTON) 13 likes Like Reply + + + [237]ben profile image + [238]Ben Halpern + (BUTTON) Ben Halpern + [239]Ben Halpern + (button) Follow + A Canadian software developer who thinks he’s funny. + * Email + [240]ben@forem.com + * Location + NY + * Education + Mount Allison University + * Pronouns + He/him + * Work + Co-founder at Forem + * Joined + Dec 27, 2015 + + • [241]May 15 '20 + (BUTTON) + * [242]Copy link + * + * (BUTTON) Hide + * + * + * + + My perpective: The web is for applications. The web is also for rich + documents where reading and simple linking can take priority. + + And there is an uncanny valley when you the latter is the sensible + choice, but the former is the approach taken. + + And many, the web is whatever Google tells them it is. Is AMP the web? + + (BUTTON) 22 likes Like Reply + + + [243]gotofritz profile image + [244]fritz + (BUTTON) fritz + [245]fritz + (button) Follow + * Location + Berlin + * Joined + Sep 28, 2018 + + • [246]May 22 '20 + (BUTTON) + * [247]Copy link + * + * (BUTTON) Hide + * + * + * + + We need to have a similar approach in client side frameworks. + + No we don't... if the The One True Omniscient God Framework approach + that Rails developers are constantly pining for was really the best + one, then Rails would be ruling. It isn't; it peaked in 2012 or + thereabouts, knocked off its perch by Node, among other technologies. + It's a single point of failure and it cannot adapt quickly enough to + the bewilderingly fast changing environment in which we operate. + + Alternatively, you can pick one of the two frameworks that follow the + model you advocate: Ember (actually inspired by Rails) or Angular (more + of a C# flavour), both of which strive to be a nanny that remove as + much as possible the need to (god forbid!) make your own decisions or + (the horror!) having to learn new tools + + If I could have the framework of my dreams ... It would allow me to + focus on HTML with a sprinkle of JavaScript. + + You may want to consider [248]stimulusjs.org/, which comes from the + Rails universe (it was created by no other than David Heinemeier + Hansson, the Rails Superstar) and does exactly what you want + + (BUTTON) 5 likes Like Thread + + [249]loilo profile image + [250]Florian Reuschel + (BUTTON) Florian Reuschel + [251]Florian Reuschel + (button) Follow + Web developer (JS, PHP), OSS enthusiast, loves to explain things to + beginners + * Location + Karlsruhe, DE + * Joined + Jan 14, 2017 + + • [252]May 22 '20 + (BUTTON) + * [253]Copy link + * + * (BUTTON) Hide + * + * + * + + Can confirm that the Stimulus framework works great for that exact use + case. But if you're used to the more common frameworks, you might + quickly miss the declarative "give me data, I give you DOM" approach + they provide. + + I haven't tried it myself yet, but [254]Alpine.js gained some steam + lately and might be a good middle ground between Stimulus and the "top + dogs". + + (BUTTON) 4 likes Like Reply + + + [255]mattwelke profile image + [256]Matt Welke + (BUTTON) Matt Welke + [257]Matt Welke + (button) Follow + Back end software developer, open source enthusiast. + * Location + Ontario, Canada + * Education + Seneca College + * Work + Backend software engineer at DigitalOcean + * Joined + Aug 16, 2019 + + • [258]May 27 '20 + (BUTTON) + * [259]Copy link + * + * (BUTTON) Hide + * + * + * + + writing an Express API requires "old javascript" unless you want to + go through the hassle of setting Babel up + + Not sure what you mean here. You can use very recent JS features in + Node. We have async/await, async iteration, ES module imports, and more + now. I've never felt the need to set up Babel in an Express project. + + (BUTTON) 5 likes Like Reply + + + [260]mattgperry profile image + [261]Matt Perry + (BUTTON) Matt Perry + [262]Matt Perry + (button) Follow + Creator of Framer Motion, Popmotion and Pose + * Location + Amsterdam + * Joined + May 15, 2020 + + • [263]May 15 '20 + (BUTTON) + * [264]Copy link + * + * (BUTTON) Hide + * + * + * + + it's widely understood that if you want 60fps animation, you will + likely have to bypass the React update cycle and do things in a more + imperative fashion (indeed, this is what libraries like react-spring + do) + + Probably aside from the article, which I largely agree with, but I + think this is an odd point to try and make. This is true of any + component library that has overhead above imperative JS. But there's + nothing stopping you from using CSS in React, which is all Svelte does + anyway. + + (BUTTON) 9 likes Like Reply + + + [265]richharris profile image + [266]Rich Harris + (BUTTON) Rich Harris + [267]Rich Harris + (button) Follow + I like turtles + * Location + Behind you + * Work + Graphics editor at the New York Times + * Joined + Jun 20, 2019 + + • [268]May 15 '20 + (BUTTON) + * [269]Copy link + * + * (BUTTON) Hide + * + * + * + + Wrong, sorry :) + + This isn't a CSS demo: [270]twitter.com/Rich_Harris/status/120... + + (BUTTON) 11 likes Like Reply + + + [271]daniel15 profile image + [272]Daniel Lo Nigro + (BUTTON) Daniel Lo Nigro + [273]Daniel Lo Nigro + (button) Follow + Australian living in the San Francisco Bay Area. Front End Engineer at + Facebook. + * Location + Palo Alto, CA + * Education + Swinburne University, Australia + * Work + Front End Engineer at Facebook + * Joined + Jan 11, 2017 + + • [274]May 15 '20 • Edited on May 15 • Edited + (BUTTON) + * [275]Copy link + * + * (BUTTON) Hide + * + * + * + + We can provide better visual feedback that loading is taking place + + I'm not so sure about that... IMO, so many single-page apps get this + wrong. The native browser loading indicator is still a lot better than + many SPAs, and unfortunately it's something that can't be triggered + from JS (apart from ugly hacks like infinitely-loading iframes) + + With the advent of Node, that changed. The fact that we can do + server-side rendering and communicate with databases and + what-have-you using a language native to the web is a wonderful + development. + + Server-side JS was a thing looooong before Node. I remember using + Microsoft's version of JavaScript ("JScript") server-side via Classic + ASP in the early 2000s. The issue back then was that JavaScript just + wasn't quite that popular yet. ES5 wasn't around yet (it was all ES3), + and there was a lack of good third-party libraries. But still, it was + absolutely in use long before Node even existed. + + What Node did do was cross-platform support, introduce a module system + (CommonJS) as standard, and introduced the concept of easily obtaining + third-party packages via "npm", taking ideas from similar systems like + Perl's CPAN. + + (BUTTON) 4 likes Like Reply + + + [276]mrispoli24 profile image + [277]Mike Rispoli + (BUTTON) Mike Rispoli + [278]Mike Rispoli + (button) Follow + I'm an award-winning designer, engineer and creative technologist that + helps daring founders ship valuable software. + * Location + New York City + * Work + Co-founder & CTO at Cause of a Kind + * Joined + Mar 8, 2019 + + • [279]May 15 '20 + (BUTTON) + * [280]Copy link + * + * (BUTTON) Hide + * + * + * + + So one thing I wondered after reading Tom's article and now yours is + how you feel about modern UI being so tied to node or javascript run + times on the backend specifically. For instance if you were to be + running something in Go and Phoenix you could dynamically render HTML + on the back end and serve it up quite a bit faster that the current SSR + environments based in Next or Nuxt or Sapper? So essentially somewhat + the way Stimulus JS works where you can send over static HTML, rendered + anywhere, by any type of server and the frontend could just hydrate + that and build components from it. + + (BUTTON) 3 likes Like Reply + + + [281]richharris profile image + [282]Rich Harris + (BUTTON) Rich Harris + [283]Rich Harris + (button) Follow + I like turtles + * Location + Behind you + * Work + Graphics editor at the New York Times + * Joined + Jun 20, 2019 + + • [284]May 15 '20 + (BUTTON) + * [285]Copy link + * + * (BUTTON) Hide + * + * + * + + This is the 'PHP with jQuery sprinkles' approach I mention in the + article, except with shinier things than PHP and jQuery. I'm not a fan, + personally. + + Phoenix LiveView is an interesting take on the problem, but I suspect + you hit a limit as to how ambitious your UI can be when deltas have to + come across web sockets at a consistent 60fps. + + (BUTTON) 5 likes Like Reply + + + [286]mrispoli24 profile image + [287]Mike Rispoli + (BUTTON) Mike Rispoli + [288]Mike Rispoli + (button) Follow + I'm an award-winning designer, engineer and creative technologist that + helps daring founders ship valuable software. + * Location + New York City + * Work + Co-founder & CTO at Cause of a Kind + * Joined + Mar 8, 2019 + + • [289]May 15 '20 + (BUTTON) + * [290]Copy link + * + * (BUTTON) Hide + * + * + * + + So do you think it’s impossible for a framework to effectively hydrate + static HTML not rendered by that frameworks specified renderToString + method? + + I really don’t know what these functions do under the hood to allow + rehydration so I’m just curious if it would be possible and achieve a + good frame rate. + + (BUTTON) 2 likes Like Reply + + + [291]lawwantsin profile image + [292]Lawrence Whiteside + (BUTTON) Lawrence Whiteside + [293]Lawrence Whiteside + (button) Follow + I'm a freelance web developer working remotely. Inquire about projects. + * Location + Austin, TX + * Work + Freelance Web Developer at Self-employeed + * Joined + Jun 19, 2019 + + • [294]May 15 '20 + (BUTTON) + * [295]Copy link + * + * (BUTTON) Hide + * + * + * + + Universal Javascript is a need for only Juniors out of Bootcamp. And + the cost is great. Just learn about parsers and you'll never look at a + framework or template library ever again. Good on you for jumping on + how terrible Gatsby is. + + (BUTTON) 3 likes Like Reply + + [296]View full discussion (98 comments) + + [297]Code of Conduct • [298]Report abuse + + Are you sure you want to hide this comment? It will become hidden in + your post, but will still be visible via the comment's [299]permalink. + [ ] + + Hide child comments as well + + (BUTTON) Confirm + + For further actions, you may consider blocking this person and/or + [300]reporting abuse + +Read next + + franciscomendes10866 profile image + +Next.js and GraphQL: The Perfect Combination for Full Stack Development + + Francisco Mendes - Jul 1 + + bdbch profile image + +Sharing your Tailwind Configuration between Monorepo Packages + + bdbch - Jun 23 + + desoga profile image + +How to Fetch Data using the provideHttpClient in Angular + + deji adesoga - Jul 1 + + jeetvora331 profile image + +React Hooks vs Functions made easy + + jeetvora331 - Jun 19 + + [301]Rich Harris + (button) Follow + I like turtles + * Location + Behind you + * Work + Graphics editor at the New York Times + * Joined + Jun 20, 2019 + +More from [302]Rich Harris + + [303]Stay alert + #javascript + [304]A new technique for making responsive, JavaScript-free charts + #dataviz #svelte #javascript + + Once suspended, richharris will not be able to comment or publish posts + until their suspension is removed. + Note: + ______________________________________________________________________ + ______________________________________________________________________ + ______________________________________________________________________ + ______________________________________________________________________ + + (BUTTON) Submit & Suspend + + Once unsuspended, richharris will be able to comment and publish posts + again. + Note: + ______________________________________________________________________ + ______________________________________________________________________ + ______________________________________________________________________ + ______________________________________________________________________ + + (BUTTON) Submit & Unsuspend + + Once unpublished, all posts by richharris will become hidden and only + accessible to themselves. + + If richharris is not suspended, they can still re-publish their posts + from their dashboard. + + Note: + ____________________________________________________________ + ____________________________________________________________ + ____________________________________________________________ + ____________________________________________________________ + (BUTTON) Unpublish all posts + + Once unpublished, this post will become invisible to the public and + only accessible to Rich Harris. + + They can still re-publish the post if they are not suspended. + (BUTTON) Unpublish Post + + Thanks for keeping DEV Community safe. Here is what you can do to flag + richharris: + (*) Make all posts by richharris less visible + + richharris consistently posts content that violates DEV Community's + code of conduct because it is harassing, offensive or spammy. + [305]Report other inappropriate conduct + + (BUTTON) Confirm Flag + + Unflagging richharris will restore default visibility to their posts. + (BUTTON) Confirm Unflag + + [306]DEV Community — A constructive and inclusive social network for + software developers. With you every step of your journey. + * [307]Home + * [308]Listings + * [309]Podcasts + * [310]Videos + * [311]Tags + * [312]FAQ + * [313]Forem Shop + * [314]Sponsors + * [315]About + * [316]Contact + * [317]Guides + * [318]Software comparisons + + * [319]Code of Conduct + * [320]Privacy Policy + * [321]Terms of use + + Built on [322]Forem — the [323]open source software that powers + [324]DEV and other inclusive communities. + + Made with love and [325]Ruby on Rails. DEV Community © 2016 - 2023. + + DEV Community + + We're a place where coders share, stay up-to-date and grow their + careers. + [326]Log in [327]Create account + +References + + Visible links: + 1. https://dev.to/open-search.xml + 2. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#main-content + 3. file:/// + 4. file:///enter + 5. file:///enter?state=new-user + 6. https://twitter.com/intent/tweet?text="In defense of the modern web" by @Rich_Harris #DEVCommunity https://dev.to/richharris/in-defense-of-the-modern-web-2nia + 7. https://www.linkedin.com/shareArticle?mini=true&url=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&title=In defense of the modern web&summary=I expect I'll annoy everyone with this post: the anti-JavaScript crusaders, justly aghast at how much...&source=DEV Community + 8. https://www.reddit.com/submit?url=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&title=In defense of the modern web + 9. https://news.ycombinator.com/submitlink?u=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&t=In defense of the modern web + 10. https://www.facebook.com/sharer.php?u=https://dev.to/richharris/in-defense-of-the-modern-web-2nia + 11. https://toot.kytta.dev/?text=https://dev.to/richharris/in-defense-of-the-modern-web-2nia + 12. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html + 13. file:///report-abuse + 14. file:///richharris + 15. file:///richharris + 16. file:///t/javascript + 17. file:///t/react + 18. file:///t/svelte + 19. file:///t/webdev + 20. https://twitter.com/tmcw + 21. https://macwright.org/2020/05/10/spa-fatigue.html + 22. https://twitter.com/tmcw/status/1259600386094030848 + 23. https://www.react-spring.io/ + 24. https://svelte.dev/ + 25. https://macwright.org/2020/05/10/spa-fatigue.html + 26. https://gatsbyjs.org/ + 27. https://res.cloudinary.com/practicaldev/image/fetch/s--L4S_VLxO--/c_limit,f_auto,fl_progressive,q_auto,w_880/https://user-images.githubusercontent.com/1162160/82001896-43e38b00-962a-11ea-9ae7-bda853a8cec1.png + 28. https://webpagetest.org/lighthouse.php?test=200515_N4_a92cbdd5b87d402522f710a8d82d2228&run=1 + 29. https://webpagetest.org/easy + 30. https://dev.to/ryanflorence + 31. https://twitter.com/intent/tweet?in_reply_to=1186675229621248000 + 32. https://twitter.com/intent/retweet?tweet_id=1186675229621248000 + 33. https://twitter.com/intent/like?tweet_id=1186675229621248000 + 34. https://nextjs.org/ + 35. https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec + 36. https://sapper.svelte.dev/ + 37. https://svelte.dev/ + 38. file:///settings/response-templates + 39. file:///404.html + 40. https://dev.to/twigman08 + 41. https://dev.to/twigman08 + 42. file:///twigman08 + 43. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6 + 44. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6 + 45. https://dev.to/gotofritz + 46. https://dev.to/gotofritz + 47. file:///gotofritz + 48. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj + 49. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj + 50. https://dev.to/twigman08 + 51. https://dev.to/twigman08 + 52. file:///twigman08 + 53. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke + 54. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke + 55. https://dev.to/gotofritz + 56. https://dev.to/gotofritz + 57. file:///gotofritz + 58. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob + 59. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob + 60. https://dev.to/adrianus + 61. https://dev.to/adrianus + 62. file:///adrianus + 63. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5 + 64. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5 + 65. https://dev.to/techbelle + 66. https://dev.to/techbelle + 67. file:///techbelle + 68. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j + 69. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j + 70. https://dev.to/ojrask + 71. https://dev.to/ojrask + 72. file:///ojrask + 73. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh + 74. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh + 75. https://dev.to/gotofritz + 76. https://dev.to/gotofritz + 77. file:///gotofritz + 78. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk + 79. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk + 80. https://dev.to/ojrask + 81. https://dev.to/ojrask + 82. file:///ojrask + 83. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5 + 84. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5 + 85. https://dev.to/gotofritz + 86. https://dev.to/gotofritz + 87. file:///gotofritz + 88. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h + 89. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h + 90. https://dev.to/jacobmakestheweb + 91. https://dev.to/jacobmakestheweb + 92. file:///jacobmakestheweb + 93. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc + 94. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc + 95. https://dev.to/mark_saward + 96. https://dev.to/mark_saward + 97. file:///mark_saward + 98. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0 + 99. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0 + 100. https://dev.to/ryansolid + 101. https://dev.to/ryansolid + 102. file:///ryansolid + 103. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369 + 104. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369 + 105. https://dev.to/mark_saward + 106. https://dev.to/mark_saward + 107. file:///mark_saward + 108. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8 + 109. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8 + 110. https://dev.to/adrianus + 111. https://dev.to/adrianus + 112. file:///adrianus + 113. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka + 114. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka + 115. https://dev.to/oenonono + 116. https://dev.to/oenonono + 117. file:///oenonono + 118. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk + 119. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk + 120. https://dev.to/v6 + 121. https://dev.to/v6 + 122. file:///v6 + 123. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a + 124. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a + 125. https://dev.to/gotofritz + 126. https://dev.to/gotofritz + 127. file:///gotofritz + 128. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf + 129. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf + 130. https://dev.to/v6 + 131. https://dev.to/v6 + 132. file:///v6 + 133. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf + 134. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf + 135. https://dev.to/stew_sims + 136. https://dev.to/stew_sims + 137. file:///stew_sims + 138. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kj + 139. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kj + 140. https://dev.to/rhymes + 141. https://dev.to/rhymes + 142. file:///rhymes + 143. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm + 144. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm + 145. https://dev.to/oenonono + 146. https://dev.to/oenonono + 147. file:///oenonono + 148. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hm + 149. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hm + 150. https://dev.to/holdit + 151. https://dev.to/holdit + 152. file:///holdit + 153. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4 + 154. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4 + 155. https://dev.to/iamschulz + 156. https://dev.to/iamschulz + 157. file:///iamschulz + 158. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk + 159. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk + 160. https://dev.to/richharris + 161. https://dev.to/richharris + 162. file:///richharris + 163. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2 + 164. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2 + 165. https://sapper.svelte.dev/ + 166. https://dev.to/iamschulz + 167. https://dev.to/iamschulz + 168. file:///iamschulz + 169. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id + 170. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id + 171. https://dev.to/martinmalinda + 172. https://dev.to/martinmalinda + 173. file:///martinmalinda + 174. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6 + 175. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6 + 176. https://dev.to/ben + 177. https://dev.to/ben + 178. file:///ben + 179. mailto:ben@forem.com + 180. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk + 181. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk + 182. https://dev.to/v6 + 183. https://dev.to/v6 + 184. file:///v6 + 185. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f + 186. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f + 187. https://www.hashicorp.com/tao-of-hashicorp#workflows,-not-technologies + 188. https://dev.to/phlash + 189. https://dev.to/phlash + 190. file:///phlash + 191. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3 + 192. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3 + 193. https://dev.to/phlash909/comment/cghl + 194. https://dev.to/v6 + 195. https://dev.to/v6 + 196. file:///v6 + 197. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348 + 198. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348 + 199. https://dev.to/panesofglass + 200. https://dev.to/panesofglass + 201. file:///panesofglass + 202. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20 + 203. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20 + 204. https://dev.to/rhymes + 205. https://dev.to/rhymes + 206. file:///rhymes + 207. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40 + 208. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40 + 209. https://dev.to/panesofglass + 210. https://dev.to/panesofglass + 211. file:///panesofglass + 212. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2 + 213. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2 + 214. https://dev.to/rhymes + 215. https://dev.to/rhymes + 216. file:///rhymes + 217. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6 + 218. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6 + 219. https://dev.to/gregfletcher + 220. https://dev.to/gregfletcher + 221. file:///gregfletcher + 222. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2 + 223. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2 + 224. https://dev.to/v6 + 225. https://dev.to/v6 + 226. file:///v6 + 227. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d + 228. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d + 229. https://martinfowler.com/bliki/SacrificialArchitecture.html + 230. https://youtu.be/oKg1hTOQXoY?t=1754 + 231. https://res.cloudinary.com/practicaldev/image/fetch/s--KIKmJfBA--/c_limit,f_auto,fl_progressive,q_66,w_880/https://dev-to-uploads.s3.amazonaws.com/i/5ehz4jt3d7skefmuwg6d.gif + 232. https://dev.to/richharris + 233. https://dev.to/richharris + 234. file:///richharris + 235. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0 + 236. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0 + 237. https://dev.to/ben + 238. https://dev.to/ben + 239. file:///ben + 240. mailto:ben@forem.com + 241. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd + 242. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd + 243. https://dev.to/gotofritz + 244. https://dev.to/gotofritz + 245. file:///gotofritz + 246. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom + 247. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom + 248. https://stimulusjs.org/ + 249. https://dev.to/loilo + 250. https://dev.to/loilo + 251. file:///loilo + 252. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c + 253. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c + 254. https://github.com/alpinejs/alpine + 255. https://dev.to/mattwelke + 256. https://dev.to/mattwelke + 257. file:///mattwelke + 258. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g + 259. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g + 260. https://dev.to/mattgperry + 261. https://dev.to/mattgperry + 262. file:///mattgperry + 263. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0 + 264. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0 + 265. https://dev.to/richharris + 266. https://dev.to/richharris + 267. file:///richharris + 268. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je + 269. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je + 270. https://twitter.com/Rich_Harris/status/1200807516529147904 + 271. https://dev.to/daniel15 + 272. https://dev.to/daniel15 + 273. file:///daniel15 + 274. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6 + 275. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6 + 276. https://dev.to/mrispoli24 + 277. https://dev.to/mrispoli24 + 278. file:///mrispoli24 + 279. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc + 280. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc + 281. https://dev.to/richharris + 282. https://dev.to/richharris + 283. file:///richharris + 284. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5 + 285. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5 + 286. https://dev.to/mrispoli24 + 287. https://dev.to/mrispoli24 + 288. file:///mrispoli24 + 289. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p + 290. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p + 291. https://dev.to/lawwantsin + 292. https://dev.to/lawwantsin + 293. file:///lawwantsin + 294. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i8 + 295. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i8 + 296. file:///richharris/in-defense-of-the-modern-web-2nia/comments + 297. file:///code-of-conduct + 298. file:///report-abuse + 299. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html + 300. file:///report-abuse + 301. file:///richharris + 302. file:///richharris + 303. file:///richharris/stay-alert-d + 304. file:///richharris/a-new-technique-for-making-responsive-javascript-free-charts-gmp + 305. javascript:void(0); + 306. file:/// + 307. file:/// + 308. file:///listings + 309. file:///pod + 310. file:///videos + 311. file:///tags + 312. file:///faq + 313. https://shop.forem.com/ + 314. file:///sponsorships + 315. file:///about + 316. file:///contact + 317. file:///guides + 318. file:///software-comparisons + 319. file:///code-of-conduct + 320. file:///privacy + 321. file:///terms + 322. https://www.forem.com/ + 323. https://dev.to/t/opensource + 324. https://dev.to/ + 325. https://dev.to/t/rails + 326. file:///enter + 327. file:///enter?state=new-user + + Hidden links: + 329. file://localhost/search + 330. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=top#toggle-comments-sort-dropdown + 331. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=latest#toggle-comments-sort-dropdown + 332. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=oldest#toggle-comments-sort-dropdown + 333. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j6 + 334. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5gj + 335. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/paob + 336. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6g5 + 337. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1bp6j + 338. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1i7gc + 339. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2k0 + 340. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p369 + 341. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p7ka + 342. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p4hk + 343. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34a + 344. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5lf + 345. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2kj + 346. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6cm + 347. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p4hm + 348. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p4 + 349. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2hk + 350. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i2 + 351. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5d6 + 352. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2jk + 353. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34f + 354. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j3 + 355. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p348 + 356. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12d20 + 357. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12df6 + 358. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j2 + 359. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34d + 360. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n0 + 361. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2nd + 362. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pb3c + 363. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pg9g + 364. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i0 + 365. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2je + 366. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n6 + 367. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2kc + 368. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p5 + 369. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p35p + 370. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i8 + 371. file://localhost/franciscomendes10866/nextjs-and-graphql-the-perfect-combination-for-full-stack-development-18l7 + 372. file://localhost/bdbch/sharing-your-tailwind-configuration-between-monorepo-packages-4o5k + 373. file://localhost/this-is-angular/how-to-fetch-data-using-the-providehttpclient-in-angular-5h47 + 374. file://localhost/jeetvora331/react-hooks-vs-functions-made-easy-2g2l diff --git a/static/archive/macwright-com-vvkegs.txt b/static/archive/macwright-com-vvkegs.txt new file mode 100644 index 0000000..b0b0eba --- /dev/null +++ b/static/archive/macwright-com-vvkegs.txt @@ -0,0 +1,284 @@ + #[1]macwright.com [2]macwright.com + +Tom MacWright + + tom@macwright.com + +Tom MacWright + + * [3]Writing + * [4]Reading + * [5]Photos + * [6]Projects + * [7]Drawings + * [8]About + +Second-guessing the modern web + + The emerging norm for web development is to build a React single-page + application, with server rendering. The two key elements of this + architecture are something like: + 1. The main UI is built & updated in JavaScript using React or + something similar. + 2. The backend is an API that that application makes requests against. + + This idea has really swept the internet. It started with a few major + popular websites and has crept into corners like marketing sites and + blogs. + + I’m increasingly skeptical of it. + + There is a sweet spot of React: in moderately interactive interfaces. + Complex forms that require immediate feedback, UIs that need to move + around and react instantly. That’s where it excels. I helped build the + editors in [9]Mapbox Studio and [10]Observable and for the most part, + React was a great choice. + + But there’s a lot on either side of that sweet spot. + + The high performance parts aren’t React. [11]Mapbox GL, for example, is + vanilla JavaScript and probably should be forever. The level of + abstraction that React works on is too high, and the cost of using + React - in payload, parse time, and so on - is too much for any company + to include it as part of an SDK. Same with the [12]Observable runtime, + the juicy center of that product: it’s very performance-intensive and + would barely benefit from a port. + + The less interactive parts don’t benefit much from React. Listing + pages, static pages, blogs - these things are increasingly built in + React, but the benefits they accrue are extremely narrow. A lot of the + optimizations we’re deploying to speed up these things, things like + bundle splitting, server-side rendering, and prerendering, are + triangulating what we had before the rise of React. + + And they’re kind of messy optimizations. Here are some examples. + +Bundle splitting. + + As your React application grows, the application bundle grows. Unlike + with a traditional multi-page app, that growth affects every visitor: + you download the whole app the first time that you visit it. At some + point, this becomes a real problem. Someone who lands on the About page + is also downloading 20 other pages in the same application bundle. + Bundle splitting ‘solves’ this problem by creating many JavaScript + bundles that can lazily load each other. So you load the About page and + what your browser downloads is an ‘index’ bundle, and then that ‘index’ + bundle loads the ‘about page’ bundle. + + This sort of solves the problem, but it’s not great. Most bundle + splitting techniques require you to load that ‘index bundle’, and then + only once that JavaScript is loaded and executed does your browser know + which ‘page bundle’ it needs. So you need two round-trips to start + rendering. + + And then there’s the question of updating code-split bundles. User + sessions are surprisingly long: someone might have your website open in + a tab for weeks at a time. I’ve seen it happen. So if they open the + ‘about page’, keep the tab open for a week, and then request the ‘home + page’, then the home page that they request is dictated by the index + bundle that they downloaded last week. This is a deeply weird and + under-discussed situation. There are essentially two solutions to it: + 1. You keep all generated JavaScript around, forever, and people will + see the version of the site that was live at the time of their + first page request. + 2. You create a system that alerts users when you’ve deployed a new + version of the site, and prompt them to reload. + + The first solution has a drawback that might not be immediately + obvious. In those intervening weeks between loading the site and + clicking a link, you might’ve deployed a new API version. So the user + will be using an old version of your JavaScript frontend with a new + version of your API backend, and they’ll trigger errors that none of + your testing knows about, because you’ll usually be testing current + versions of each. + + And the second solution, while it works (and is what we implemented for + Mapbox Studio), is a bizarre way for a web application to behave. + Prompting users to ‘update’ is something from the bad old days of + desktop software, not from the shiny new days of the web. + + Sure: traditional non-SPA websites are not immune to this pitfall. + Someone might load your website, have a form open for many weeks, and + then submit it after their session expired or the API changed. But + that’s a much more limited exposure to failure than in the SPA case. + +Server-Side Rendering + + Okay, so the theory here is that SPAs are initially a blank page, which + is then filled out by React & JavaScript. That’s bad for performance: + HTML pages don’t need to be blank initially. So, Server-Side Rendering + runs your JavaScript frontend code on the backend, creating a + filled-out HTML page. The user loads the page, which now has + pre-rendered content, and then the JavaScript loads and makes the page + interactive. + + A great optimization, but again, caveats. + + The first is that the page you initially render is dead: you’ve created + the [13]Time To Interactive metric. It’s your startup’s homepage, and + it has a “Sign up” button, but until the JavaScript loads, that button + doesn’t do anything. So you need to compensate. Either you omit some + interactive elements on load, or you try really hard to make sure that + the JavaScript loads faster than users will click, or you make some + elements not require JavaScript to work - like making them normal links + or forms. Or some combination of those. + + And then there’s the authentication story. If you do SSR on any pages + that are custom to the user, then you need to forward any cookies or + authentication-relevant information to your API backend and make sure + that you never cache the server-rendered result. Your + formerly-lightweight application server is now doing quite a bit of + labor, running React & making API requests in order to do this + pre-rendering. + +APIs + + The dream of APIs is that you have generic, flexible endpoints upon + which you can build any web application. That idea breaks down pretty + fast. + + Most interactive web applications start to triangulate on “one query + per page.” API calls being generic or reusable never seems to persist + as a value in infrastructure. This is because a large portion of web + applications are, at their core, query & transformation interfaces on + top of databases. The hardest performance problems they tend to have + are query problems and transfer problems. + + For example: a generically-designed REST API that tries not to mix + ‘concerns’ will produce a frontend application that has to make lots of + requests to display a page. And then a new-age GraphQL application will + suffer under the [14]N+1 query problem at the database level until an + optimization arrives. And a traditional “make a query and put it on a + page” application will just, well, try to write some good queries. + + None of these solutions are silver bullets: I’ve worked with + overly-strict REST APIs, optimization-hungry GraphQL APIs, and + hand-crafted SQL APIs. But no option really lets a web app be careless + about its data-fetching layer. Web applications can’t sit on top of + independently-designed APIs: to have a chance at performance, the + application and its datasource need to be designed as one. + +Data fetching + + Speaking of data fetching. It’s really important and really bizarre in + React land. Years ago, I expected that some good patterns would emerge. + Frankly, they didn’t. + + There are decent patterns in the form of GraphQL, but for a React + component that loads data with fetch from an API, the solutions have + only gotten weirder. There’s great documentation for everything else, + but old-fashioned data loading is relegated to one example of how to + mock out ‘fetch’ for testing, and lots of Medium posts of varying + quality. + __________________________________________________________________ + + Don’t read this as anti-React. I still think React is pretty great, and + for a particular set of use cases it’s the best tool you can find. And + I explicitly want to say that – from what I’ve seen – most other + Single-Page-Application tools share most of these problems. They’re + issues with the pattern, not the specific frameworks used to implement + it. React alternatives have some great ideas, and they might be better, + but they are ultimately really similar. + + But I’m at the point where I look at where the field is and what the + alternative patterns are – taking a second look at unloved, unpopular, + uncool things like Django, Rails, Laravel – and think what the heck is + happening. We’re layering optimizations upon optimizations in order to + get the SPA-like pattern to fit every use case, and I’m not sure that + it is, well, worth it. + + And it should be easy to do a good job. + + Frameworks should lure people into the [15]pit of success, where + following the normal rules and using normal techniques is the winning + approach. + + I don’t think that React, in this context, really is that pit of + success. A naïvely implemented React SPA isn’t stable, or efficient, + and it doesn’t naturally scale to significant complexity. + + You can add optimizations on top of it that fix those problems, or you + can use a framework like Next.js that will include those optimizations + by default. That’ll help you get pretty far. But then you’ll be lured + by all of the easy one-click ways to add bloat and complexity. You’ll + be responsible for keeping some of these complex, finicky optimizations + working properly. + + And for what? Again - there is a swath of use cases which would be hard + without React and which aren’t complicated enough to push beyond + React’s limits. But there are also a lot of problems for which I can’t + see any concrete benefit to using React. Those are things like blogs, + shopping-cart-websites, mostly-[16]CRUD-and-forms-websites. For these + things, all of the fancy optimizations are trying to get you closer to + the performance you would’ve gotten if you just hadn’t used so much + technology. + + I can, for example, guarantee that this blog is faster than any Gatsby + blog (and much love to the Gatsby team) because there is nothing that a + React static site can do that will make it faster than a non-React + static site. + __________________________________________________________________ + + But the cultural tides are strong. Building a company on Django in 2020 + seems like the equivalent of driving a PT Cruiser and blasting Faith + Hill’s “Breathe” on a CD while your friends are listening to The Weeknd + in their Teslas. Swimming against this current isn’t easy, and not in a + trendy contrarian way. + + I don’t think that everyone’s using the SPA pattern for no reason. For + large corporations, it allows teams to work independently: the + “frontend engineers” can “consume” “APIs” from teams that probably work + in a different language and can only communicate through the hierarchy. + For heavily interactive applications, it has real benefits in + modularity, performance, and structure. And it’s beneficial for + companies to shift computing requirements from their servers to their + customers browsers: a real win for reducing their spend on + infrastructure. + + But I think there are a lot of problems that are better solved some + other way. There’s no category winner like React as an alternative. + Ironically, backends are churning through technology even faster than + frontends, which have been loyal to one programming language for + decades. There are some age-old technologies like Rails, Django, and + Laravel, and there are a few halfhearted attempts to do templating and + “serve web pages” from Go, Node, and other new languages. If you go + this way, you’re beset by the cognitive dissonance of following in the + footsteps of enormous projects - Wikipedia rendering web pages in PHP, + Craigslist rendering webpages in Perl - but being far outside the norms + of modern web development. If Wikipedia were started today, it’d be + React. Maybe? + + What if everyone’s wrong? We’ve been wrong before. + Follow-ups & commmentary + * [17]"In defense of the modern web", Rich Harris + * [18]Friday Night Deploys (Podcast) #22: A Brief Discussion On The + State Of The Modern Web + * [19]Frontend First (Podcast): Read & Discuss + * [20]A Ready-To-Try Concept in Response to “Second-guessing the + modern web” + + May 10, 2020 [21]@tmcw + +References + + 1. https://macwright.com/rss.xml + 2. https://macwright.com/atom.xml + 3. file:/// + 4. file:///reading/ + 5. file:///photos/ + 6. file:///projects/ + 7. file:///drawings/ + 8. file:///about/ + 9. https://www.mapbox.com/mapbox-studio/ + 10. https://observablehq.com/ + 11. https://docs.mapbox.com/mapbox-gl-js/api/ + 12. https://github.com/observablehq/runtime + 13. https://web.dev/interactive/ + 14. https://engineering.shopify.com/blogs/engineering/solving-the-n-1-problem-for-graphql-through-batching + 15. https://blog.codinghorror.com/falling-into-the-pit-of-success/ + 16. https://en.wikipedia.org/wiki/Create,_read,_update_and_delete + 17. https://dev.to/richharris/in-defense-of-the-modern-web-2nia + 18. https://dev.to/devplebs/friday-night-deploys-22-a-brief-discussion-on-the-state-of-the-modern-web-2961 + 19. https://frontendfirst.fm/episodes/read-and-discuss-second-guessing-the-modern-web + 20. https://medium.com/@kevinkirchner/a-ready-to-try-concept-in-response-to-second-guessing-the-modern-web-6946ec4d0598 + 21. https://twitter.com/intent/follow?screen_name=tmcw&user_id=1458271