dev-to-ptnb0b.txt (82523B)
1 [1]Skip to content 2 [3] DEV Community 3 [4][ ] 4 [6] 5 [7] Log in [8] Create account 6 7 DEV Community 8 9 ● Add reaction 10 [sp] Like [mu] Unicorn [ex] Exploding Head [ra] Raised Hands [fi] Fire 11 Jump to Comments Save 12 Copy link 13 Copied to Clipboard 14 [20] Share to Twitter [21] Share to LinkedIn [22] Share to Reddit [23] Share to 15 Hacker News [24] Share to Facebook [25] Share to Mastodon 16 [26]Share Post via... [27]Report Abuse 17 [28]Rich Harris 18 [29]Rich Harris 19 20 Posted on May 15, 2020 21 22 ● ● ● ● ● 23 24 In defense of the modern web 25 26 [30]#javascript [31]#react [32]#svelte [33]#webdev 27 28 I expect I'll annoy everyone with this post: the anti-JavaScript crusaders, 29 justly aghast at how much of the stuff we slather onto modern websites; the 30 people arguing the web is a broken platform for interactive applications anyway 31 and we should start over; React users; the old guard with their artisanal JS 32 and hand authored HTML; and [34]Tom MacWright, someone I've admired from afar 33 since I first became aware of his work on Mapbox many years ago. But I guess 34 that's the price of having opinions. 35 36 Tom recently posted [35]Second-guessing the modern web, and it took the front 37 end world by storm. You should read it, or at the very least the [36] 38 CliffsNotes. There's a lot of stuff I agree with to varying degrees: 39 40 There is a sweet spot of React: in moderately interactive interfaces ... 41 But there’s a lot on either side of that sweet spot. 42 43 It's absolutely the case that running React in the client for a largely static 44 site is overkill. It's also true that you have to avoid React if your app is 45 very heavily interactive — it's widely understood that if you want 60fps 46 animation, you will likely have to bypass the React update cycle and do things 47 in a more imperative fashion (indeed, this is what libraries like [37] 48 react-spring do). But while all this is true of React, it's much less true of 49 component frameworks in general. 50 51 User sessions are surprisingly long: someone might have your website open 52 in a tab for weeks at a time. I’ve seen it happen. So if they open the 53 ‘about page’, keep the tab open for a week, and then request the ‘home 54 page’, then the home page that they request is dictated by the index bundle 55 that they downloaded last week. This is a deeply weird and under-discussed 56 situation. 57 58 It's an excellent point that isn't really being addressed, though (as Tom 59 acknowledges) it's really just exacerbating a problem that was always there. I 60 think there are solutions to it — we can iterate on the 'index bundle' 61 approach, we could include the site version in a cookie and use that to show 62 actionable feedback if there's a mismatch — but we do need to spend time on it. 63 64 It’s your startup’s homepage, and it has a “Sign up” button, but until the 65 JavaScript loads, that button doesn’t do anything. So you need to 66 compensate. 67 68 This is indeed very annoying, though it's easy enough to do this sort of thing 69 — we just need to care enough: 70 71 <button class="sign-up" disabled={!is_browser}> 72 {is_browser ? 'Sign up' : 'Loading'} 73 </button> 74 75 But I'm not sure what this has to do with React-style frameworks — this issue 76 exists whatever form your front end takes, unless you make it work without JS 77 (which you should!). 78 79 Your formerly-lightweight application server is now doing quite a bit of 80 labor, running React & making API requests in order to do this 81 pre-rendering. 82 83 Again, this is true but more React-specific than anything. React's approach to 84 server-side rendering — constructing a component tree, then serialising it — 85 involves overhead that isn't shared by frameworks that, for example, compile 86 your components ([38]hi!) to functions that just concatenate strings for SSR, 87 which is faster by a dramatic amount. And those API requests were going to have 88 to get made anyway, so it makes sense to do them as early as possible, 89 especially if your app server and API server are close to each other (or even 90 the same thing). 91 92 The dream of APIs is that you have generic, flexible endpoints upon which 93 you can build any web application. That idea breaks down pretty fast. 94 95 Amen. [39]Just go and read the whole 'APIs' section several times. 96 97 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 98 99 Minor quibbles aside, Tom identifies some real problems with the state of the 100 art in web development. But I think the article reaches a dangerous conclusion. 101 102 Let's start by dissecting this statement: 103 104 I can, for example, guarantee that this blog is faster than any Gatsby blog 105 (and much love to the Gatsby team) because there is nothing that a React 106 static site can do that will make it faster than a non-React static site. 107 108 With all due respect to those involved, I don't think Gatsby is a particularly 109 relevant benchmark. The gatsby new my-site starter app executes 266kB of 110 minified JavaScript for a completely static page in production mode; for [40] 111 gatsbyjs.org it's 808kB. Honestly, these are not impressive numbers. 112 113 [41]The Lighthouse performance score for gatsbyjs.org 114 115 The [42]Lighthouse score for Gatsby's homepage, obtained via [43] 116 webpagetest.org/easy. 117 118 Leaving that aside, I disagree with the premise. When I tap on a link on Tom's 119 JS-free website, the browser first waits to confirm that it was a tap and not a 120 brush/swipe, then makes a request, and then we have to wait for the response. 121 With a framework-authored site with client-side routing, we can start to do 122 more interesting things. We can make informed guesses based on analytics about 123 which things the user is likely to interact with and preload the logic and data 124 for them. We can kick off requests as soon as the user first touches (or 125 hovers) the link instead of waiting for confirmation of a tap — worst case 126 scenario, we've loaded some stuff that will be useful later if they do tap on 127 it. We can provide better visual feedback that loading is taking place and a 128 transition is about to occur. And we don't need to load the entire contents of 129 the page — often, we can make do with a small bit of JSON because we already 130 have the JavaScript for the page. This stuff gets fiendishly difficult to do by 131 hand. 132 133 Beyond that, vanilla static sites are not an ambitious enough goal. Take 134 transitions for example. Web developers are currently trapped in a mindset of 135 discrete pages with jarring transitions — click a link, see the entire page get 136 replaced whether through client-side routing or a page reload — while native 137 app developers are thinking on another level: 138 139 unknown tweet media content Play butt 140 Ryan Florence profile image 141 Ryan Florence 142 [44]@ryanflorence 143 twitter logo 144 This is what I've had in mind for the web with React Router. We say these 145 kinds of animations are "good for phones but not desktop". 146 147 My iPad pro is as big as my laptop and these apps are shopping/content 148 (most of the web). 149 150 These transitions are such a great UX. 151 16:06 PM - 22 Oct 2019 152 [45] Twitter reply action [46] Twitter retweet action 20 [47] Twitter like 153 action 197 154 155 It will take more than technological advancement to get the web there; it will 156 take a cultural shift as well. But we certainly can't get there if we abandon 157 our current trajectory. Which is exactly what Tom seems to be suggesting. 158 159 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 160 161 I'm not aware of any other platform where you're expected to write the logic 162 for your initial render using a different set of technologies than the logic 163 for subsequent interactions. The very idea sounds daft. But on the web, with 164 its unique history, that was the norm for many years — we'd generate some HTML 165 with PHP or Rails or whatever, and then 'sprinkle some jQuery' on it. 166 167 With the advent of Node, that changed. The fact that we can do server-side 168 rendering and communicate with databases and what-have-you using a language 169 native to the web is a wonderful development. 170 171 There are problems with this model. Tom identifies some of them. Another major 172 issue he doesn't discuss is that the server-rendered SPA model typically 173 'hydrates' the entire initial page in a way that requires you to duplicate a 174 ton of data — once in the HTML, once in the JSON blob that's passed to the 175 client version of the app to produce the exact same result — and can block the 176 main thread during the period the user is starting to interact with the app. 177 178 But we can fix those problems. [48]Next is doing amazing innovation around (for 179 example) mixing static and dynamic pages within a single app, so you get the 180 benefits of the purely static model without ending up finding yourself 181 constrained by it. [49]Marko does intelligent component-level hydration, 182 something I expect other frameworks to adopt. [50]Sapper, the companion 183 framework to [51]Svelte, has a stated goal of eventually not sending any JS 184 other than the (tiny) router itself for pages that don't require it. 185 186 The future I want — the future I see — is one with tooling that's accessible to 187 the greatest number of people (including designers), that can intelligently 188 move work between server and client as appropriate, that lets us build 189 experiences that compete with native on UX (yes, even for blogs!), and where 190 upgrading part of a site to 'interactive' or from 'static' to 'dynamic' doesn't 191 involve communication across disparate teams using different technologies. We 192 can only get there by committing to the paradigm Tom critiques — the 193 JavaScript-ish component framework server-rendered SPA. (Better names 194 welcomed.) 195 196 The modern web has flaws, and we should talk about them. But let's not give up 197 on it. 198 199 Top comments (98) 200 201 Subscribe 202 pic 203 [ ] 204 Personal Trusted User 205 [59] Create template 206 207 Templates let you quickly answer FAQs or store snippets for re-use. 208 209 Submit Preview [62]Dismiss 210 211 [63] twigman08 profile image 212 [64] Chad Smith 213 Chad Smith 214 [66] [71bd929d-4] Chad Smith 215 Follow 216 Work with C# all day everyday creating web applications. Huge baseball buff. 217 218 • Location 219 Texas 220 • Education 221 B.S in Computer Science 222 • Joined 223 Dec 17, 2017 224 225 • [68] May 15 '20 226 227 • [70]Copy link 228 • 229 • Hide 230 • 231 • 232 • 233 234 Honestly my biggest issue with the current state of the web is the current 235 state of how complex the tools or build process is. 236 237 I miss the days of some html, add a bit of JavaScript to the page and you were 238 done. You didn't worry about going and making sure you had a complete build or 239 bundling process to get everything good. You spent your time worrying about how 240 to develop your app. Which in my opinion was better for the users. There was 241 less bugs. We actually spent more time making sure the application worked rock 242 solid. 243 244 Nowadays to get anything cool to be be ready for production you have spend 245 needless time on the configuration. Did you do this? Did you configure it to do 246 that? Oh you can't do that unless you eject it that build tool and use this 247 build tool. That's where the current state of the web is failing. 248 249 Sure we have taken steps forward in some areas. But we have to be honest with 250 ourselves. We took major steps back in other areas of the web. Sometimes I 251 wonder if we took too many steps back. 252 253 61 likes Like [73] Reply 254 255 [74] gotofritz profile image 256 [75] fritz 257 fritz 258 [77] [4e77b2fc-1] fritz 259 Follow 260 261 • Location 262 Berlin 263 • Joined 264 Sep 28, 2018 265 266 • [79] May 18 '20 267 268 • [81]Copy link 269 • 270 • Hide 271 • 272 • 273 • 274 275 I don't get it. Nobody's stopping you from firing up an HTML doc in Notepad and 276 FTPing the result to a web server, if that's all you need. But other people 277 have more complex needs (in the "good ole days" there were no smart phones, to 278 mention just one thing) and therefore we need more complex tools. Why do you 279 want to force me to party like it's 1999? 280 281 23 likes Like [84] Reply 282 283 [85] twigman08 profile image 284 [86] Chad Smith 285 Chad Smith 286 [88] [71bd929d-4] Chad Smith 287 Follow 288 Work with C# all day everyday creating web applications. Huge baseball buff. 289 290 • Location 291 Texas 292 • Education 293 B.S in Computer Science 294 • Joined 295 Dec 17, 2017 296 297 • [90] May 19 '20 298 299 • [92]Copy link 300 • 301 • Hide 302 • 303 • 304 • 305 306 My issue isn't with applications are too complex really. I develop complex 307 applications too at work. 308 309 My issue is with all the moving parts with a modern web application. Fighting 310 if I can use certain language features. Oh I can't, now I have to bother with 311 setting up and making sure I can use Babel or something to do it properly, or 312 even loading in polyfills (cool just added another dependency the browser has 313 to load before the application can be used). 314 315 That still hasn't covered bundling everything. What's the correct way bundle 316 this? Well crap I now have to go and correctly configure WebPack. Unless you're 317 one of the VERY FEW experts on that ,that will take time to figure out to get 318 right. Ok so I think it bundles right, well now how should I lazy load this 319 code for the user? What should be lazy loaded? What should i use to set it up? 320 321 That's just the beginning. I could go on and on about the other complex moving 322 parts with a modern web application. 323 324 I am not asking anyone to make applications like it is 1999. All I'm asking for 325 is a more modern and simpler process that is a STANDARD. 326 327 Maybe it is because I come from compiled language background. Where I have to 328 worry about that one single binary. I only have to worry if the compiler 329 supports the language version I'm using. Where I can just pass in a single flag 330 to the compiler for the optimization level I want. 331 332 Yes I will be the first to say that in some areas of modern web application 333 development we have taken steps forward. I just wonder if we have taken steps 334 back in some areas to take those steps forward. 335 336 13 likes Like Thread 337 338 [95] gotofritz profile image 339 [96] fritz 340 fritz 341 [98] [4e77b2fc-1] fritz 342 Follow 343 344 • Location 345 Berlin 346 • Joined 347 Sep 28, 2018 348 349 • [100] May 22 '20 • Edited on May 22 • Edited 350 351 • [102]Copy link 352 • 353 • Hide 354 • 355 • 356 • 357 358 All I'm asking for is a more modern and simpler process that is a STANDARD 359 ... 360 Maybe it is because I come from compiled language background ... 361 362 Well I am sorry, but web development is a complete different kettle of fish. We 363 download all the parts that make up an application asynchronously, on a wide 364 variety of devices, with different specs and rendering capabilities - all 365 things which the app, once downloaded, need to adapt to. We have progressive 366 rendering and respond to all sort of sensors. All while ensuring boot up time 367 for the app is in the microseconds range and security for both you who download 368 the code and the server. 369 370 Your expectations are simply unrealistic, sorry. 371 372 Also, we always had polyfills, even "back in the day". Except that back then 373 everyone had to bake their own. In fact, we had browser wars and appalling 374 browser (IE5 for the Mac, anyone??!?) and it was a real pain in the neck. 375 376 10 likes Like [105] Reply 377 378 [106] adrianus profile image 379 [107] Adrianus 380 Adrianus 381 [109] [4e6de1e2-6] Adrianus 382 Follow 383 Running a small company based in Kent. 384 385 • Location 386 Chatham, Kent 387 • Education 388 autodidactic 389 • Work 390 Entrepreneur at AVANDERGRINTEN Ltd. 391 • Joined 392 Jan 21, 2020 393 394 • [111] May 19 '20 • Edited on May 20 • Edited 395 396 • [113]Copy link 397 • 398 • Hide 399 • 400 • 401 • 402 403 Bingo, the complexity today is a must, at least because of the growing 404 smartphone usage. The simple reason why "Native Apps didn't kill the web even 405 with all their superior capabilities" (Ryan) is simply UX. As internet usage 406 often starts with searching for something having in mind, that all-app-thinking 407 interrupts exactly this flow, leaving at least 30% of all traffic untouched. 408 For what? For 5-minutes-crafts skyrocketing their YouTube traffic? Although not 409 everything needs server side complexity plus having API's and webhooks easily 410 integrated using browser capabilities not existing in the god old days, the 411 architecture underneath is not the real issue. 412 413 3 likes Like [116] Reply 414 415 [117] ojrask profile image 416 [118] Otto Rask 417 Otto Rask 418 [120] [f4751361-7] Otto Rask 419 Follow 420 A software engineer, mainly PHP, Rust, and related things. 421 422 • Location 423 Finland 424 • Joined 425 Mar 12, 2019 426 427 • [122] May 28 '21 428 429 • [124]Copy link 430 • 431 • Hide 432 • 433 • 434 • 435 436 You fight complexity with ... more complexity? 437 438 1 like Like Thread 439 440 [127] gotofritz profile image 441 [128] fritz 442 fritz 443 [130] [4e77b2fc-1] fritz 444 Follow 445 446 • Location 447 Berlin 448 • Joined 449 Sep 28, 2018 450 451 • [132] May 28 '21 452 453 • [134]Copy link 454 • 455 • Hide 456 • 457 • 458 • 459 460 You are getting it wrong. The aim is not "to fight complexity". The aim is to 461 fulfil complex needs. I am saying for that you often need more complex tools. 462 463 1 like Like Thread 464 465 [137] ojrask profile image 466 [138] Otto Rask 467 Otto Rask 468 [140] [f4751361-7] Otto Rask 469 Follow 470 A software engineer, mainly PHP, Rust, and related things. 471 472 • Location 473 Finland 474 • Joined 475 Mar 12, 2019 476 477 • [142] May 28 '21 478 479 • [144]Copy link 480 • 481 • Hide 482 • 483 • 484 • 485 486 What percentage of modern web is a "complex needs" target that requires a 487 complex solution such as React or Vue or perhaps something custom written in 488 WASM? 50% 25%? 5% 1%? 489 490 2 likes Like Thread 491 492 [147] gotofritz profile image 493 [148] fritz 494 fritz 495 [150] [4e77b2fc-1] fritz 496 Follow 497 498 • Location 499 Berlin 500 • Joined 501 Sep 28, 2018 502 503 • [152] May 28 '21 504 505 • [154]Copy link 506 • 507 • Hide 508 • 509 • 510 • 511 512 All of it. Unless you have actual data that proves otherwise... 513 514 2 likes Like Thread 515 516 [157] jacobmakestheweb profile image 517 [158] Jacob Ybarra 518 Jacob Ybarra 519 [160] [ea7fc8c6-1] Jacob Ybarra 520 Follow 521 dank web dev 522 523 • Education 524 school 525 • Work 526 nada 527 • Joined 528 Sep 21, 2021 529 530 • [162] Sep 21 '21 531 532 • [164]Copy link 533 • 534 • Hide 535 • 536 • 537 • 538 539 uh what? the web is about content and media. not a software environment. 540 541 1 like Like [167] Reply 542 543 [168] techbelle profile image 544 [169] rachelle palmer 545 rachelle palmer 546 [171] [16c23058-3] rachelle palmer 547 Follow 548 I decided I would try to build an app in every programming language. That 549 didn't happen, but what I learned along the way was really valuable. 550 551 • Location 552 Raleigh, NC 553 • Joined 554 Sep 23, 2020 555 556 • [173] Feb 25 '21 557 558 • [175]Copy link 559 • 560 • Hide 561 • 562 • 563 • 564 565 re: sessions --> I keep tabs open for months at a time, not sure about anyone 566 else 567 568 1 like Like [178] Reply 569 570 [179] mark_saward profile image 571 [180] Mark Saward 572 Mark Saward 573 [182] [2c925970-7] Mark Saward 574 Follow 575 CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go, Rust, 576 SQL, Devops 577 578 • Location 579 Victoria, Australia 580 • Education 581 BA/Bsc in Philosophy and Physics. PhD in Philosophy. 582 • Work 583 CEO/Software Developer at Episub 584 • Joined 585 May 13, 2020 586 587 • [184] May 15 '20 588 589 • [186]Copy link 590 • 591 • Hide 592 • 593 • 594 • 595 596 Some interesting thoughts, in the original article and your response. Certainly 597 good for generating discussion :) 598 599 It will take more than technological advancement to get the web there; it 600 will take a cultural shift as well. But we certainly can't get there if we 601 abandon our current trajectory. 602 603 The problem as I see it is that the web -- in terms of client-side executed 604 markup and code (HTML/CSS/JavaScript) just wasn't designed with these kinds of 605 interactions in mind (the interactions that Ryan Florence highlighted). It's 606 the wrong foundation for it. 607 608 I don't think that "getting there" should be through bending original web 609 technologies, but rather with something else entirely -- perhaps WebAssembly, 610 or a return to actual native applications much like we've come to depend on on 611 our tablets and phones. We already can do nice animations like that iPad demo 612 with native desktop applications. There's many advantages to websites over 613 native desktop apps, with the standout one being that they don't require 614 someone to install an application on their machine. Maybe WebAssembly can give 615 us a compromise -- desktop apps built with technology designed for that job, 616 but available in a way that doesn't require any local installation. Then we can 617 use tools that were purpose built for those kinds of tasks, instead of trying 618 to wrangle the foundations of the web to fit something they were never built 619 for. 620 621 When I think back to how we used to build websites back in the day, and how we 622 build sites with technologies in tools like React now, I'm honestly not sure 623 that we've gained anything of great enough value relative to the simplicity 624 we've lost. In short, I'd be happy to abandon our current trajectory and put 625 our hope in alternative solutions for those situations where what we really 626 need is a native application. Leave the web for what it's good at. 627 628 23 likes Like [189] Reply 629 630 [190] ryansolid profile image 631 [191] Ryan Carniato 632 Ryan Carniato 633 [193] [a3d1cfed-a] Ryan Carniato 634 Follow 635 Frontend performance enthusiast and Fine-Grained Reactivity super fan. Author 636 of the SolidJS UI library and MarkoJS Core Team Member. 637 638 • Location 639 San Jose, California 640 • Education 641 Computer Engineering B.A.Sc, University of British Columbia 642 • Work 643 Principal Engineer, Open Source, Netlify 644 • Joined 645 Jun 25, 2019 646 647 • [195] May 15 '20 648 649 • [197]Copy link 650 • 651 • Hide 652 • 653 • 654 • 655 656 That's interesting. I mean I was there too, and the extent of what I can build 657 with a modern library so extends what I could reasonably do before. And the 658 reason for that is JavaScript. When I was building sites in the late 90s so 659 many things weren't possible and you had no choice but to pay these costs for 660 interactivity. Sure I view sourced a few cool tricks.. image maps etc, but with 661 my table based layouts and a little JavaScript I could do very little. Part of 662 it was the available DOM api's. My lack of understanding of the language but I 663 think we look at the past with rose colored glasses. 664 665 It's more interesting to me that native platforms have borrowed concepts from 666 libraries like React in terms of declarative views etc. I'm not saying React 667 invented this stuff but that the trend would suggest the contrary. These trends 668 could be mistakes but popularity has as much stake in the course of events as 669 innate value. 670 671 I think this comes down to really this hope of a Silver Bullet. It doesn't 672 exist. Instead we have momentum of a ubiquitous platform that just is 673 constantly aiming to improve. It's not only that the other approaches have 674 already lost, we're getting to a point where any new approach will have to 675 atleast acknowledge the current web. At this point a competitor isn't going to 676 change the tide, but something from within. It's more likely that the web 677 addresses those fundamental shortcomings than people moving to a different 678 platform. Native Apps didn't kill the web even with all their superior 679 capabilities. And on a similar note it is going to take monumental change for 680 this to fundamentally change. Even with React's reach, it wasn't alone in a 681 movement that started years before. This is bigger than any particular library 682 or framework. 683 684 13 likes Like [200] Reply 685 686 [201] mark_saward profile image 687 [202] Mark Saward 688 Mark Saward 689 [204] [2c925970-7] Mark Saward 690 Follow 691 CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go, Rust, 692 SQL, Devops 693 694 • Location 695 Victoria, Australia 696 • Education 697 BA/Bsc in Philosophy and Physics. PhD in Philosophy. 698 • Work 699 CEO/Software Developer at Episub 700 • Joined 701 May 13, 2020 702 703 • [206] May 16 '20 • Edited on May 16 • Edited 704 705 • [208]Copy link 706 • 707 • Hide 708 • 709 • 710 • 711 712 There is absolutely no doubt that you can do incredible things with modern web, 713 and the power unlocked by having a programming language in the browser has been 714 amazing. However, when I think about a great deal of the websites I interact 715 with, and ones I build, there would not be much lost if they significantly 716 simplified the tech stack they work with to be closer to the core technologies 717 of the web (including a splash of JavaScript). 718 719 What I'm trying to convey is that I think our move to make everything a web app 720 has been a mistake, for multiple reasons. You are absolutely right to say that 721 this tide is going to be very hard (perhaps impossible) to turn, and I 722 absolutely agree there is no silver bullet (I've looked), but that doesn't mean 723 we haven't taken a worse path and shouldn't lament for what could have been. 724 725 The advantages of web apps are compelling for developers -- they are easy to 726 distribute, update, control, make cross platform, when compared to native apps. 727 It is not hard to understand why and how we have ended up where we are. I just 728 wish we were somewhere else -- but it would take a lot of work to create that 729 'silver bullet'. 730 731 11 likes Like Thread 732 733 [211] adrianus profile image 734 [212] Adrianus 735 Adrianus 736 [214] [4e6de1e2-6] Adrianus 737 Follow 738 Running a small company based in Kent. 739 740 • Location 741 Chatham, Kent 742 • Education 743 autodidactic 744 • Work 745 Entrepreneur at AVANDERGRINTEN Ltd. 746 • Joined 747 Jan 21, 2020 748 749 • [216] May 19 '20 • Edited on May 20 • Edited 750 751 • [218]Copy link 752 • 753 • Hide 754 • 755 • 756 • 757 758 That whole app environment was basically triggered by one need, and one need 759 only: bandwidth. No idea if anyone remembers when they launched this WAP 760 protocol, making the internet available on smartphones, what failed for two 761 reasons. The providers made it easy to access on their own portals aka AOL 762 strategy at beginning of the web, leaving the rest of the market untouched, 763 secondly the site performance was ridiculous. Apple stepped in, put a bunch of 764 intelligence into the app, dramatically reducing the load time, did not convert 765 so much traffic on their own apps and let developers do what they do best. By 766 2008 more than 50% of the whole mobile internet traffic was iPhone traffic. 767 768 Bandwidth is no longer the breaking point. 769 770 Google has for years campaigned the untapped goldmine local traffic, experience 771 flows that often start at the search for getting something done in time, 772 monetising on micro moments as more than half of all mobile searches have a 773 local intend. I posted an example how something to get done interferes 774 cross-applicational from the perspective of a user. With an app-only scheme 775 this is getting impossible. Sure it is understandable that nobody pays so much 776 attention. Most search engines run a change and heavily invested in AI to 777 optimise traffic at the client's frontend. But even this is not enough, when it 778 comes to intends other than something very individualised. I wouldn't care so 779 much about the user, but more about what the user wants to achieve. 780 781 1 like Like [221] Reply 782 783 [222] oenonono profile image 784 [223] Junk 785 Junk 786 [225] [default_pr] Junk 787 Follow 788 789 • Joined 790 Mar 12, 2017 791 792 • [227] May 17 '20 793 794 • [229]Copy link 795 • 796 • Hide 797 • 798 • 799 • 800 801 React definitely didn't invent HTML. 802 803 Declarative views, indeed. 804 805 1 like Like [232] Reply 806 807 [233] v6 profile image 808 [234] 🦄N B🛡 809 🦄N B🛡 810 [236] [8267c2c7-f] 🦄N B🛡 811 Follow 812 // , “It is not so important to be serious as it is to be serious about the 813 important things. The monkey wears an expression of seriousness... but the 814 monkey is serious because he itches."(No/No) 815 816 • Location 817 (No/No) 818 • Education 819 (No/No) 820 • Work 821 Security 822 • Joined 823 Mar 1, 2018 824 825 • [238] May 15 '20 826 827 • [240]Copy link 828 • 829 • Hide 830 • 831 • 832 • 833 834 The problem as I see it is that the web -- in terms of client-side executed 835 markup and code (HTML/CSS/JavaScript) just wasn't designed with these kinds 836 of interactions in mind (the interactions that Ryan Florence highlighted). 837 It's the wrong foundation for it. 838 839 Yes. Please. Can we please just accept that it's all broken. 840 841 4 likes Like [243] Reply 842 843 [244] gotofritz profile image 844 [245] fritz 845 fritz 846 [247] [4e77b2fc-1] fritz 847 Follow 848 849 • Location 850 Berlin 851 • Joined 852 Sep 28, 2018 853 854 • [249] May 18 '20 • Edited on May 18 • Edited 855 856 • [251]Copy link 857 • 858 • Hide 859 • 860 • 861 • 862 863 Not at all. 864 865 CSS has media queries and all sort of crazy and wonderful stuff. HTML has tags 866 for responsive design. JS has (in the browser) access to apis like mutation 867 observer and orientation and speech recognition. It's TOTALLY built for that. 868 Enough of the "get off my lawn" negativity 869 870 8 likes Like Thread 871 872 [254] v6 profile image 873 [255] 🦄N B🛡 874 🦄N B🛡 875 [257] [8267c2c7-f] 🦄N B🛡 876 Follow 877 // , “It is not so important to be serious as it is to be serious about the 878 important things. The monkey wears an expression of seriousness... but the 879 monkey is serious because he itches."(No/No) 880 881 • Location 882 (No/No) 883 • Education 884 (No/No) 885 • Work 886 Security 887 • Joined 888 Mar 1, 2018 889 890 • [259] May 18 '20 • Edited on May 18 • Edited 891 892 • [261]Copy link 893 • 894 • Hide 895 • 896 • 897 • 898 899 shakes his cane at you 900 901 mutters incomprehensibly 902 903 4 likes Like [264] Reply 904 905 [265] holdit profile image 906 [266] holdit 907 holdit 908 [268] [6f8ff7f5-7] holdit 909 Follow 910 911 • Joined 912 May 15, 2020 913 914 • [270] May 15 '20 915 916 • [272]Copy link 917 • 918 • Hide 919 • 920 • 921 • 922 923 Looking at the criticism made about some recent redesigns (reddit, facebook, 924 etc) it seems that the main complaint (from a user point of view, at least) is 925 how slow it feels compared to the previous version or to a "simple" site with 926 HTML, CSS, and a little bit of javascript. 927 928 I haven't checked it recently, but when the new reddit UI was released, 929 scrolling was terrible on my $2500k laptop. It felt slow. Everything was 930 sluggish. It also downloaded a few MB of javascript on pages that essentially 931 had a thumbnail, a title, and some comments (not everyone lives in a big city 932 or is connected to a super fast internet connection!). When the page was 933 loaded, I was seeing more scrolling lag because they lazyload some content. I 934 mean, it's hard to like this "modern web". 935 936 As a user, I don't care about how things work behind the scenes. I don't mind 937 some javascript on a page, after all we don't need a page reload just to 938 preview a comment or "like" something. You can even use javascript for 939 everything, I don't mind. But it needs to be fast and it needs to work well... 940 and right now some "modern" sites provide a worse experience than before. 941 942 24 likes Like [275] Reply 943 944 [276] iamschulz profile image 945 [277] Daniel Schulz 946 Daniel Schulz 947 [279] [0f4b16d2-a] Daniel Schulz 948 Follow 949 Hi! I'm a frontend guy. 950 951 • Location 952 Germany 953 • Education 954 Studied Media Art and Design 955 • Work 956 Performance Engineer at Baqend 957 • Joined 958 Sep 17, 2018 959 960 • [281] May 15 '20 • Edited on May 15 • Edited 961 962 • [283]Copy link 963 • 964 • Hide 965 • 966 • 967 • 968 969 Tom identified the main weakness of modern web development correctly: It's 970 based on javascript. He points out the sluggishness and accessibility problems 971 that stem from that attitude, and hes absolutely right to do so. Static pages 972 (as a paradigm, not as Gatsby in particular) are maybe not the cure for that, 973 but they are definitely a step into the right direction. 974 I just rewrote my website with hugo and specifically without a major JS 975 framework, but settled for a vanilla approach rooted in a progressive 976 enhancement mindset. I didn't even run into the problems that are inherent to 977 React, Vue and Angular. 978 Sure, you can serve HTML with SSR, but you still have to wait for the bundle in 979 order to have a functional site, plus a truckload of ssr-related complexity. 980 And that is utter rubbish. JS should never be a requirement, it needs to be put 981 in its place as the cherry on top of the cake. 982 Progressive enhancement needs not only to be a major approach to webdevelopment 983 again, it needs to be out default mode of operation. 984 This is also the core of Toms article. And I agree with him. 985 986 That said, nothing stops you from adding features like nice transitions. But 987 please be sure not to break standard web features while doing so. 988 Transitions need to add to hyperlinks, not replace them. 989 990 21 likes Like [286] Reply 991 992 [287] richharris profile image 993 [288] Rich Harris 994 Rich Harris 995 [290] [92d6b6d1-4] Rich Harris 996 Follow 997 I like turtles 998 999 • Location 1000 Behind you 1001 • Work 1002 Graphics editor at the New York Times 1003 • Joined 1004 Jun 20, 2019 1005 1006 • [292] May 15 '20 1007 1008 • [294]Copy link 1009 • 1010 • Hide 1011 • 1012 • 1013 • 1014 1015 I feel like you didn't quite read the article closely enough ;) Of course 1016 progressive enhancement needs to be the default — that's why there's so much 1017 focus on SSR in all major meta-frameworks. 1018 1019 Sure, you can serve HTML with SSR, but you still have to wait for the 1020 bundle in order to have a functional site 1021 1022 This isn't true! Take [296]sapper.svelte.dev, which is a site built with Sapper 1023 and baked out as static pages. It works just fine without JavaScript, you just 1024 don't get client-side routing. It's a small site, but the same thing applies to 1025 larger ones like Gatsby's homepage — no JS? No problem. 1026 1027 20 likes Like [298] Reply 1028 1029 [299] iamschulz profile image 1030 [300] Daniel Schulz 1031 Daniel Schulz 1032 [302] [0f4b16d2-a] Daniel Schulz 1033 Follow 1034 Hi! I'm a frontend guy. 1035 1036 • Location 1037 Germany 1038 • Education 1039 Studied Media Art and Design 1040 • Work 1041 Performance Engineer at Baqend 1042 • Joined 1043 Sep 17, 2018 1044 1045 • [304] May 15 '20 1046 1047 • [306]Copy link 1048 • 1049 • Hide 1050 • 1051 • 1052 • 1053 1054 It certainly is true for standard implementations of React-, Vue- and Angular- 1055 based sites. There may be a focus on SSR, but it still isn't close enough to 1056 deserve to be the default. It needs to come without extra complexity. Only then 1057 we're ready to take the step to fully embrace those solution. 1058 1059 And this is my point. You need to take one step after the other. It was a 1060 mistake to build everything with javascript first and then try to look if it 1061 still works without afterwards. The damage to the web has been done. 1062 1063 I didn't take a look at Sapper/Svelte. Though, in comparison, those are still a 1064 nieche product. 1065 1066 7 likes Like Thread 1067 1068 [309] martinmalinda profile image 1069 [310] Martin Malinda 1070 Martin Malinda 1071 [312] [2ee5ec39-1] Martin Malinda 1072 Follow 1073 1074 • Joined 1075 Apr 7, 2020 1076 1077 • [314] May 18 '20 1078 1079 • [316]Copy link 1080 • 1081 • Hide 1082 • 1083 • 1084 • 1085 1086 The damage to the web has been done. 1087 1088 JS certainly caused a lot of damage on many websites. But now - finally - we're 1089 getting to the point of having frameworks which can, by default, offer 1090 client-side routing with SSR and hydration without shipping large bundles of 1091 JS. Up to this point the frontend devs should have been more conservative and 1092 they should have thought twice whether they should really go all-in into an 1093 SPA. But now's the time when it's really starting to be a viable option. Next, 1094 Nuxt, Marko and Sapper are finally technologies highly worth pursuing, even for 1095 content-based websites. 1096 1097 2 likes Like [319] Reply 1098 1099 [320] ben profile image 1100 [321] Ben Halpern 1101 Ben Halpern 1102 [323] [f451a206-1] Ben Halpern 1103 Follow 1104 A Canadian software developer who thinks he’s funny. 1105 1106 • Email 1107 [325][email protected] 1108 • Location 1109 NY 1110 • Education 1111 Mount Allison University 1112 • Pronouns 1113 He/him 1114 • Work 1115 Co-founder at Forem 1116 • Joined 1117 Dec 27, 2015 1118 1119 • [326] May 15 '20 1120 1121 • [328]Copy link 1122 • 1123 • Hide 1124 • 1125 • 1126 • 1127 1128 The future I want — the future I see — is one with tooling that's 1129 accessible to the greatest number of people (including designers), that can 1130 intelligently move work between server and client as appropriate, that lets 1131 us build experiences that compete with native on UX (yes, even for blogs!), 1132 and where upgrading part of a site to 'interactive' or from 'static' to 1133 'dynamic' doesn't involve communication across disparate teams using 1134 different technologies. We can only get there by committing to the paradigm 1135 Tom critiques — the JavaScript-ish component framework server-rendered SPA. 1136 (Better names welcomed.) 1137 1138 I like this takeaway because it's heavy on acknowledging the process behind the 1139 technology which is often disparate and confusing. Even the most 1140 well-intentioned and organized dev team is going to get out of wack if 1141 succeeding with the tooling is experts only. We need to be able to achieve 1142 great performance, UX and accessibility even under conditions where designers 1143 do some work, devs pop in some hotfixes here and there, old devs leave with 1144 some of the knowledge, priorities change, etc. 1145 1146 19 likes Like [331] Reply 1147 1148 [332] v6 profile image 1149 [333] 🦄N B🛡 1150 🦄N B🛡 1151 [335] [8267c2c7-f] 🦄N B🛡 1152 Follow 1153 // , “It is not so important to be serious as it is to be serious about the 1154 important things. The monkey wears an expression of seriousness... but the 1155 monkey is serious because he itches."(No/No) 1156 1157 • Location 1158 (No/No) 1159 • Education 1160 (No/No) 1161 • Work 1162 Security 1163 • Joined 1164 Mar 1, 2018 1165 1166 • [337] May 15 '20 • Edited on May 15 • Edited 1167 1168 • [339]Copy link 1169 • 1170 • Hide 1171 • 1172 • 1173 • 1174 1175 I like this aspect of Mr. Harris' article, too. It's the first principle of the 1176 Tao of HashiCorp: [341]Workflows, not Technologies. 1177 1178 The HashiCorp approach is to focus on the end goal and workflow, rather 1179 than the underlying technologies. Software and hardware will evolve and 1180 improve, and it is our goal to make adoption of new tooling simple, while 1181 still providing the most streamlined user experience possible. Product 1182 design starts with an envisioned workflow to achieve a set goal. We then 1183 identify existing tools that simplify the workflow. If a sufficient tool 1184 does not exist, we step in to build it. This leads to a fundamentally 1185 technology-agnostic view — we will use the best technology available to 1186 solve the problem. As technologies evolve and better tooling emerges, the 1187 ideal workflow is just updated to leverage those technologies. Technologies 1188 change, end goals stay the same. 1189 1190 And it's why Sacrificial Architecture appeases the dark ones. 1191 1192 4 likes Like [343] Reply 1193 1194 [344] phlash profile image 1195 [345] Phil Ashby 1196 Phil Ashby 1197 [347] [e6bffa0e-3] Phil Ashby 1198 Follow 1199 30+ years of tech, retired from an identity intelligence company, job done! Dev 1200 community mod - mostly light gardening & weeding out spam :) 1201 1202 • Location 1203 Felixstowe, UK 1204 • Education 1205 M.Eng (hons) Electronics, MIET, MBCS, AMCIISec, CEH 1206 • Pronouns 1207 he/him 1208 • Work 1209 Retired! 1210 • Joined 1211 Apr 2, 2017 1212 1213 • [349] May 15 '20 1214 1215 • [351]Copy link 1216 • 1217 • Hide 1218 • 1219 • 1220 • 1221 1222 Good response, opinions are always worth having, as long as you are prepared to 1223 discuss/defend/change them! I had a few thoughts on this topic last year in 1224 response to your good self and web components that I think is worth referring 1225 back to: [353]dev.to/phlash909/comment/cghl 1226 1227 In essence, the DOM and page model of HTML is a constraint around the outside 1228 of applications that might be better inverted: I'd like to see browsers that 1229 support HTML/DOM content if required, but do not constrain devs to always go 1230 though it. Let's stop thinking of them as HTML rendering engines, and start 1231 thinking of pre-installed runtimes with excellent web-based application 1232 management! 1233 1234 We'll want to retain the benefits of dynamic software running on the client 1235 (native UX, easy architecture changes, no user-install step, etc.), while 1236 leveraging the effort that goes into making that a portable & safe thing to do 1237 (common APIs, sandboxes, browsers as the standard runtime for client-side 1238 applications). We are nearly there with PWAs perhaps? WASM then expands the 1239 available languages for the runtime, allowing common client/server languages 1240 and development processes to ease developer adoption. As/when a document needs 1241 rendering, then HTML/DOM/CSS is there to perform it's proper function, however 1242 many apps many be better off with a UX library (eg: SDL) or widget set (eg: 1243 wxWidgets) atop the runtime bindings. 1244 1245 11 likes Like [355] Reply 1246 1247 [356] v6 profile image 1248 [357] 🦄N B🛡 1249 🦄N B🛡 1250 [359] [8267c2c7-f] 🦄N B🛡 1251 Follow 1252 // , “It is not so important to be serious as it is to be serious about the 1253 important things. The monkey wears an expression of seriousness... but the 1254 monkey is serious because he itches."(No/No) 1255 1256 • Location 1257 (No/No) 1258 • Education 1259 (No/No) 1260 • Work 1261 Security 1262 • Joined 1263 Mar 1, 2018 1264 1265 • [361] May 15 '20 1266 1267 • [363]Copy link 1268 • 1269 • Hide 1270 • 1271 • 1272 • 1273 1274 start thinking of pre-installed runtimes with excellent web-based 1275 application management! 1276 1277 If you were to remove the "web-based" part, it'd almost describe the beginning 1278 of OSes back in the day. 1279 1280 Which is perhaps what they are: The UI part of a vast "operating system" by 1281 which we access the "applications" of the internet. 1282 1283 4 likes Like [366] Reply 1284 1285 [367] panesofglass profile image 1286 [368] panesofglass 1287 panesofglass 1288 [370] [b5aa0a77-5] panesofglass 1289 Follow 1290 1291 • Joined 1292 Jul 23, 2020 1293 1294 • [372] Jul 23 '20 1295 1296 • [374]Copy link 1297 • 1298 • Hide 1299 • 1300 • 1301 • 1302 1303 I believe at the point you fundamentally push to render things other than 1304 markup, you start making a different application. And that is perfectly 1305 reasonable. I’m frankly surprised how well HTTP has held up to so many use 1306 cases. I long ago expected to see far more protocols for more kinds of apps, 1307 but HTTP seems to have solved so many problems well enough that it now hosts 1308 other protocols. 1309 1310 There are probably more protocols that could be written and hosted on other 1311 ports. Those would likely address many of these issues in a far better way. I 1312 just wonder when the industry will pivot back to building protocols and leave 1313 HTTP well enough alone. 1314 1315 1 like Like [377] Reply 1316 1317 [378] rhymes profile image 1318 [379] rhymes 1319 rhymes 1320 [381] [bfd9a4a5-9] rhymes 1321 Follow 1322 Such software as dreams are made on. I mostly rant about performance, 1323 unnecessary complexity, privacy and data collection. 1324 1325 • Joined 1326 Feb 2, 2017 1327 1328 • [383] Jul 23 '20 1329 1330 • [385]Copy link 1331 • 1332 • Hide 1333 • 1334 • 1335 • 1336 1337 I think we're past that as most recent innovations in the web space are either 1338 formats or evolutions of HTTP. Why reinvent the wheel if the wheel works well? 1339 What do you think? 1340 1341 1 like Like Thread 1342 1343 [388] panesofglass profile image 1344 [389] panesofglass 1345 panesofglass 1346 [391] [b5aa0a77-5] panesofglass 1347 Follow 1348 1349 • Joined 1350 Jul 23, 2020 1351 1352 • [393] Jul 23 '20 1353 1354 • [395]Copy link 1355 • 1356 • Hide 1357 • 1358 • 1359 • 1360 1361 HTTP/3 with QUIC seems like a great improvement, but it is changing HTTP. I 1362 don’t see why HTTP needs changing for most things. Why not update SMTP or FTP, 1363 as well? QUIC solves specific problems, and it might be better for those who 1364 need QUIC for it to have features better suited to their needs. 1365 1366 In some ways, this also feels like the mash of several formats into HTML5 to 1367 avoid name spacing. While we focus on and champion components within our own 1368 apps, we continue to avoid and break components in the infrastructure. 1369 1370 Therefore, I think we may see new protocols emerge as the weight of these 1371 complexities begin to cause problems. That could still be some way off. 1372 1373 1 like Like Thread 1374 1375 [398] rhymes profile image 1376 [399] rhymes 1377 rhymes 1378 [401] [bfd9a4a5-9] rhymes 1379 Follow 1380 Such software as dreams are made on. I mostly rant about performance, 1381 unnecessary complexity, privacy and data collection. 1382 1383 • Joined 1384 Feb 2, 2017 1385 1386 • [403] Jul 23 '20 1387 1388 • [405]Copy link 1389 • 1390 • Hide 1391 • 1392 • 1393 • 1394 1395 I'm not sure it is changing HTTP, it's HTTP over UDP. The protocol is basically 1396 the same as HTTP/1 and HTTP/2. 1397 1398 QUIC solves specific problems, and it might be better for those who need 1399 QUIC for it to have features better suited to their needs. 1400 1401 QUIC solves a specific problem HTTP has because it sits on top of TCP though, 1402 basically pipelining 1403 1404 In some ways, this also feels like the mash of several formats into HTML5 1405 to avoid name spacing. While we focus on and champion components within our 1406 own apps, we continue to avoid and break components in the infrastructure. 1407 1408 I'm not sure I follow the analogy with HTML5, sorry :( IIRC HTML5 was created 1409 to stop having to revise HTML as a a single unit and let things evolve at their 1410 own pace. Same with CSS 3 I guess. I don't think it's the same thing here: HTTP 1411 /3 is the result of the entire world using HTTP and needing to improve 1412 performance. 1413 1414 Could they have created a new protocol? Sure, but why break compatibility with 1415 millions of browsers, proxies, machines, software application and so on that 1416 understand and function through HTTP? I think the decision to rewrite the 1417 transport layer to be a smart one. 1418 1419 This doesn't mean that other protocols can't emerge, but it's okay not to throw 1420 away those that work already 1421 1422 1 like Like [408] Reply 1423 1424 [409] gregfletcher profile image 1425 [410] Greg Fletcher 1426 Greg Fletcher 1427 [412] [60dd3143-5] Greg Fletcher 1428 Follow 1429 loop { refactoring() } 1430 1431 • Work 1432 Full Stack at Freelance 1433 • Joined 1434 Mar 16, 2019 1435 1436 • [414] May 15 '20 1437 1438 • [416]Copy link 1439 • 1440 • Hide 1441 • 1442 • 1443 • 1444 1445 Great article! 1446 1447 Doesn't a lot of this disagreement stem from --> "keep the web as it is, coz 1448 it's fine" vs "let's make it better by making mistakes along the way coz that's 1449 how software development works"? 1450 1451 14 likes Like [419] Reply 1452 1453 [420] v6 profile image 1454 [421] 🦄N B🛡 1455 🦄N B🛡 1456 [423] [8267c2c7-f] 🦄N B🛡 1457 Follow 1458 // , “It is not so important to be serious as it is to be serious about the 1459 important things. The monkey wears an expression of seriousness... but the 1460 monkey is serious because he itches."(No/No) 1461 1462 • Location 1463 (No/No) 1464 • Education 1465 (No/No) 1466 • Work 1467 Security 1468 • Joined 1469 Mar 1, 2018 1470 1471 • [425] May 15 '20 1472 1473 • [427]Copy link 1474 • 1475 • Hide 1476 • 1477 • 1478 • 1479 1480 What about making it better by [429]sacrificing it? 1481 1482 We can [430]learn this lesson from Biology, that the best way to avoid 1483 excessive optimization is the ultimate flexibility: Keeping the option on the 1484 table to throw out the code, or well abstracted parts of it, and rewrite that 1485 code or product from scratch. 1486 1487 It's a little known "dark" pattern of Software Design, from the shadows of 1488 Agile, called "Sacrificial Architecture." 1489 1490 [431]exponential growth isnt kind to architectural decisions 1491 1492 5 likes Like [433] Reply 1493 1494 [434] richharris profile image 1495 [435] Rich Harris 1496 Rich Harris 1497 [437] [92d6b6d1-4] Rich Harris 1498 Follow 1499 I like turtles 1500 1501 • Location 1502 Behind you 1503 • Work 1504 Graphics editor at the New York Times 1505 • Joined 1506 Jun 20, 2019 1507 1508 • [439] May 15 '20 1509 1510 • [441]Copy link 1511 • 1512 • Hide 1513 • 1514 • 1515 • 1516 1517 Is the Web for applications? 1518 1519 I feel like this question sort of answers itself! Have you heard of Amazon? 1520 Gmail? Facebook? 1521 1522 13 likes Like [444] Reply 1523 1524 [445] ben profile image 1525 [446] Ben Halpern 1526 Ben Halpern 1527 [448] [f451a206-1] Ben Halpern 1528 Follow 1529 A Canadian software developer who thinks he’s funny. 1530 1531 • Email 1532 [450][email protected] 1533 • Location 1534 NY 1535 • Education 1536 Mount Allison University 1537 • Pronouns 1538 He/him 1539 • Work 1540 Co-founder at Forem 1541 • Joined 1542 Dec 27, 2015 1543 1544 • [451] May 15 '20 1545 1546 • [453]Copy link 1547 • 1548 • Hide 1549 • 1550 • 1551 • 1552 1553 My perpective: The web is for applications. The web is also for rich documents 1554 where reading and simple linking can take priority. 1555 1556 And there is an uncanny valley when you the latter is the sensible choice, but 1557 the former is the approach taken. 1558 1559 And many, the web is whatever Google tells them it is. Is AMP the web? 1560 1561 22 likes Like [456] Reply 1562 1563 [457] rhymes profile image 1564 [458] rhymes 1565 rhymes 1566 [460] [bfd9a4a5-9] rhymes 1567 Follow 1568 Such software as dreams are made on. I mostly rant about performance, 1569 unnecessary complexity, privacy and data collection. 1570 1571 • Joined 1572 Feb 2, 2017 1573 1574 • [462] May 18 '20 • Edited on May 18 • Edited 1575 1576 • [464]Copy link 1577 • 1578 • Hide 1579 • 1580 • 1581 • 1582 1583 It strikes me that the web never was and never will be anything like any 1584 other platform for building applications. Whether or not someone wants to 1585 turn it into that is their prerogative and any success they have probably 1586 will help others build better things. But it ultimately depends on what you 1587 want to build and why, and emulating a native application might not always 1588 be the best option. 1589 1590 this :-) 1591 1592 5 likes Like [467] Reply 1593 1594 [468] gotofritz profile image 1595 [469] fritz 1596 fritz 1597 [471] [4e77b2fc-1] fritz 1598 Follow 1599 1600 • Location 1601 Berlin 1602 • Joined 1603 Sep 28, 2018 1604 1605 • [473] May 22 '20 1606 1607 • [475]Copy link 1608 • 1609 • Hide 1610 • 1611 • 1612 • 1613 1614 We need to have a similar approach in client side frameworks. 1615 1616 No we don't... if the The One True Omniscient God Framework approach that Rails 1617 developers are constantly pining for was really the best one, then Rails would 1618 be ruling. It isn't; it peaked in 2012 or thereabouts, knocked off its perch by 1619 Node, among other technologies. It's a single point of failure and it cannot 1620 adapt quickly enough to the bewilderingly fast changing environment in which we 1621 operate. 1622 1623 Alternatively, you can pick one of the two frameworks that follow the model you 1624 advocate: Ember (actually inspired by Rails) or Angular (more of a C# flavour), 1625 both of which strive to be a nanny that remove as much as possible the need to 1626 (god forbid!) make your own decisions or (the horror!) having to learn new 1627 tools 1628 1629 If I could have the framework of my dreams ... It would allow me to focus 1630 on HTML with a sprinkle of JavaScript. 1631 1632 You may want to consider [477]stimulusjs.org/, which comes from the Rails 1633 universe (it was created by no other than David Heinemeier Hansson, the Rails 1634 Superstar) and does exactly what you want 1635 1636 5 likes Like Thread 1637 1638 [479] loilo profile image 1639 [480] Florian Reuschel 1640 Florian Reuschel 1641 [482] [13456f88-0] Florian Reuschel 1642 Follow 1643 Web developer (JS, PHP), OSS enthusiast, loves to explain things to beginners 1644 1645 • Location 1646 Karlsruhe, DE 1647 • Joined 1648 Jan 14, 2017 1649 1650 • [484] May 22 '20 1651 1652 • [486]Copy link 1653 • 1654 • Hide 1655 • 1656 • 1657 • 1658 1659 Can confirm that the Stimulus framework works great for that exact use case. 1660 But if you're used to the more common frameworks, you might quickly miss the 1661 declarative "give me data, I give you DOM" approach they provide. 1662 1663 I haven't tried it myself yet, but [488]Alpine.js gained some steam lately and 1664 might be a good middle ground between Stimulus and the "top dogs". 1665 1666 4 likes Like [490] Reply 1667 1668 [491] mattwelke profile image 1669 [492] Matt Welke 1670 Matt Welke 1671 [494] [666b194b-1] Matt Welke 1672 Follow 1673 Back end software developer, open source enthusiast. 1674 1675 • Location 1676 Ontario, Canada 1677 • Education 1678 Seneca College 1679 • Work 1680 Backend software engineer at DigitalOcean 1681 • Joined 1682 Aug 16, 2019 1683 1684 • [496] May 27 '20 1685 1686 • [498]Copy link 1687 • 1688 • Hide 1689 • 1690 • 1691 • 1692 1693 writing an Express API requires "old javascript" unless you want to go 1694 through the hassle of setting Babel up 1695 1696 Not sure what you mean here. You can use very recent JS features in Node. We 1697 have async/await, async iteration, ES module imports, and more now. I've never 1698 felt the need to set up Babel in an Express project. 1699 1700 5 likes Like [501] Reply 1701 1702 [502] mattgperry profile image 1703 [503] Matt Perry 1704 Matt Perry 1705 [505] [f6c730d5-6] Matt Perry 1706 Follow 1707 Creator of Framer Motion, Popmotion and Pose 1708 1709 • Location 1710 Amsterdam 1711 • Joined 1712 May 15, 2020 1713 1714 • [507] May 15 '20 1715 1716 • [509]Copy link 1717 • 1718 • Hide 1719 • 1720 • 1721 • 1722 1723 it's widely understood that if you want 60fps animation, you will likely 1724 have to bypass the React update cycle and do things in a more imperative 1725 fashion (indeed, this is what libraries like react-spring do) 1726 1727 Probably aside from the article, which I largely agree with, but I think this 1728 is an odd point to try and make. This is true of any component library that has 1729 overhead above imperative JS. But there's nothing stopping you from using CSS 1730 in React, which is all Svelte does anyway. 1731 1732 9 likes Like [512] Reply 1733 1734 [513] richharris profile image 1735 [514] Rich Harris 1736 Rich Harris 1737 [516] [92d6b6d1-4] Rich Harris 1738 Follow 1739 I like turtles 1740 1741 • Location 1742 Behind you 1743 • Work 1744 Graphics editor at the New York Times 1745 • Joined 1746 Jun 20, 2019 1747 1748 • [518] May 15 '20 1749 1750 • [520]Copy link 1751 • 1752 • Hide 1753 • 1754 • 1755 • 1756 1757 Wrong, sorry :) 1758 1759 This isn't a CSS demo: [522]twitter.com/Rich_Harris/status/120... 1760 1761 11 likes Like [524] Reply 1762 1763 [525] daniel15 profile image 1764 [526] Daniel Lo Nigro 1765 Daniel Lo Nigro 1766 [528] [91933] Daniel Lo Nigro 1767 Follow 1768 Australian living in the San Francisco Bay Area. Senior Front End Engineer at 1769 Meta 1770 1771 • Location 1772 San Francisco Bay Area 1773 • Education 1774 Swinburne University, Australia 1775 • Work 1776 Senior Front End Engineer at Meta 1777 • Joined 1778 Jan 11, 2017 1779 1780 • [530] May 15 '20 • Edited on May 15 • Edited 1781 1782 • [532]Copy link 1783 • 1784 • Hide 1785 • 1786 • 1787 • 1788 1789 We can provide better visual feedback that loading is taking place 1790 1791 I'm not so sure about that... IMO, so many single-page apps get this wrong. The 1792 native browser loading indicator is still a lot better than many SPAs, and 1793 unfortunately it's something that can't be triggered from JS (apart from ugly 1794 hacks like infinitely-loading iframes) 1795 1796 With the advent of Node, that changed. The fact that we can do server-side 1797 rendering and communicate with databases and what-have-you using a language 1798 native to the web is a wonderful development. 1799 1800 Server-side JS was a thing looooong before Node. I remember using Microsoft's 1801 version of JavaScript ("JScript") server-side via Classic ASP in the early 1802 2000s. The issue back then was that JavaScript just wasn't quite that popular 1803 yet. ES5 wasn't around yet (it was all ES3), and there was a lack of good 1804 third-party libraries. But still, it was absolutely in use long before Node 1805 even existed. 1806 1807 What Node did do was cross-platform support, introduce a module system 1808 (CommonJS) as standard, and introduced the concept of easily obtaining 1809 third-party packages via "npm", taking ideas from similar systems like Perl's 1810 CPAN. 1811 1812 4 likes Like [535] Reply 1813 1814 [536] mrispoli24 profile image 1815 [537] Mike Rispoli 1816 Mike Rispoli 1817 [539] [93acebe4-b] Mike Rispoli 1818 Follow 1819 I'm an award-winning designer, engineer and creative technologist that helps 1820 daring founders ship valuable software. 1821 1822 • Location 1823 New York City 1824 • Work 1825 Co-founder & CTO at Cause of a Kind 1826 • Joined 1827 Mar 8, 2019 1828 1829 • [541] May 15 '20 1830 1831 • [543]Copy link 1832 • 1833 • Hide 1834 • 1835 • 1836 • 1837 1838 So one thing I wondered after reading Tom's article and now yours is how you 1839 feel about modern UI being so tied to node or javascript run times on the 1840 backend specifically. For instance if you were to be running something in Go 1841 and Phoenix you could dynamically render HTML on the back end and serve it up 1842 quite a bit faster that the current SSR environments based in Next or Nuxt or 1843 Sapper? So essentially somewhat the way Stimulus JS works where you can send 1844 over static HTML, rendered anywhere, by any type of server and the frontend 1845 could just hydrate that and build components from it. 1846 1847 3 likes Like [546] Reply 1848 1849 [547] richharris profile image 1850 [548] Rich Harris 1851 Rich Harris 1852 [550] [92d6b6d1-4] Rich Harris 1853 Follow 1854 I like turtles 1855 1856 • Location 1857 Behind you 1858 • Work 1859 Graphics editor at the New York Times 1860 • Joined 1861 Jun 20, 2019 1862 1863 • [552] May 15 '20 1864 1865 • [554]Copy link 1866 • 1867 • Hide 1868 • 1869 • 1870 • 1871 1872 This is the 'PHP with jQuery sprinkles' approach I mention in the article, 1873 except with shinier things than PHP and jQuery. I'm not a fan, personally. 1874 1875 Phoenix LiveView is an interesting take on the problem, but I suspect you hit a 1876 limit as to how ambitious your UI can be when deltas have to come across web 1877 sockets at a consistent 60fps. 1878 1879 5 likes Like [557] Reply 1880 1881 [558] mrispoli24 profile image 1882 [559] Mike Rispoli 1883 Mike Rispoli 1884 [561] [93acebe4-b] Mike Rispoli 1885 Follow 1886 I'm an award-winning designer, engineer and creative technologist that helps 1887 daring founders ship valuable software. 1888 1889 • Location 1890 New York City 1891 • Work 1892 Co-founder & CTO at Cause of a Kind 1893 • Joined 1894 Mar 8, 2019 1895 1896 • [563] May 15 '20 1897 1898 • [565]Copy link 1899 • 1900 • Hide 1901 • 1902 • 1903 • 1904 1905 So do you think it’s impossible for a framework to effectively hydrate static 1906 HTML not rendered by that frameworks specified renderToString method? 1907 1908 I really don’t know what these functions do under the hood to allow rehydration 1909 so I’m just curious if it would be possible and achieve a good frame rate. 1910 1911 2 likes Like [568] Reply 1912 1913 [569] vintharas profile image 1914 [570] Jaime González García 1915 Jaime González García 1916 [572] [09d69d89-7] Jaime González García 1917 Follow 1918 Senior Software Engineer at Google working on Google Meet 👨💻 Helping 1919 developers be more awesome 🔥 author, speaker & nerd 🧙🏼♂️ into JavaScript, 1920 TypeScript, Vim & pixelart ❤️ 1921 1922 • Location 1923 Stockholm 1924 • Education 1925 MsC Telecommunications Engineering 1926 • Work 1927 Senior Software Engineer at Google 1928 • Joined 1929 Aug 15, 2018 1930 1931 • [574] May 15 '20 1932 1933 • [576]Copy link 1934 • 1935 • Hide 1936 • 1937 • 1938 • 1939 1940 Beautifully written and very inspiring 😀👏👏👏 1941 1942 4 likes Like [579] Reply 1943 [580] View full discussion (98 comments) 1944 [581]Code of Conduct • [582]Report abuse 1945 1946 Are you sure you want to hide this comment? It will become hidden in your post, 1947 but will still be visible via the comment's [586]permalink. 1948 1949 [588][ ] 1950 1951 Hide child comments as well 1952 1953 Confirm 1954 1955 For further actions, you may consider blocking this person and/or [590] 1956 reporting abuse 1957 1958 Read next 1959 1960 [591] 1961 tthroo profile image 1962 1963 Build your SaaS landing page in 15 minutes using Mantine 1964 1965 TThroo-Dev - Jan 11 1966 1967 [592] 1968 tlaloces profile image 1969 1970 Authentication example with FastAPI and JWT, is it as easy and straightforward 1971 as they claim? 1972 1973 Tlaloc-Es - Jan 11 1974 1975 [593] 1976 myogeshchavan97 profile image 1977 1978 I Launched The Most Awaited Complete React Course 1979 1980 Yogesh Chavan - Jan 13 1981 1982 [594] 1983 ziontutorial profile image 1984 1985 Build a Dynamic Currency Converter Beginner React Project 1986 1987 ziontutorial - Jan 11 1988 1989 [595] [92d6b6d1-4] Rich Harris 1990 Follow 1991 I like turtles 1992 1993 • Location 1994 Behind you 1995 • Work 1996 Graphics editor at the New York Times 1997 • Joined 1998 Jun 20, 2019 1999 2000 More from [597]Rich Harris 2001 2002 [598] Stay alert 2003 #javascript 2004 [599] A new technique for making responsive, JavaScript-free charts 2005 #dataviz #svelte #javascript 2006 2007 Once suspended, richharris will not be able to comment or publish posts until 2008 their suspension is removed. 2009 2010 [ ] 2011 [ ] 2012 [ ] 2013 Note: [ ] 2014 2015 Submit & Suspend 2016 2017 Once unsuspended, richharris will be able to comment and publish posts again. 2018 2019 [ ] 2020 [ ] 2021 [ ] 2022 Note: [ ] 2023 2024 Submit & Unsuspend 2025 2026 Once unpublished, all posts by richharris will become hidden and only 2027 accessible to themselves. 2028 2029 If richharris is not suspended, they can still re-publish their posts from 2030 their dashboard. 2031 2032 Note:[ ] 2033 2034 Unpublish all posts 2035 2036 Once unpublished, this post will become invisible to the public and only 2037 accessible to Rich Harris. 2038 2039 They can still re-publish the post if they are not suspended. 2040 2041 Unpublish Post 2042 2043 Thanks for keeping DEV Community safe. Here is what you can do to flag 2044 richharris: 2045 2046 [607]( ) Make all posts by richharris less visible 2047 2048 richharris consistently posts content that violates DEV Community's code of 2049 conduct because it is harassing, offensive or spammy. 2050 2051 [608] Report other inappropriate conduct 2052 2053 Confirm Flag 2054 2055 Unflagging richharris will restore default visibility to their posts. 2056 2057 Confirm Unflag 2058 2059 [611]DEV Community — A constructive and inclusive social network for software 2060 developers. With you every step of your journey. 2061 2062 • [612] Home 2063 • [613] Podcasts 2064 • [614] Videos 2065 • [615] Tags 2066 • [616] FAQ 2067 • [617] Forem Shop 2068 • [618] Advertise on DEV 2069 • [619] About 2070 • [620] Contact 2071 • [621] Guides 2072 • [622] Software comparisons 2073 2074 • [623] Code of Conduct 2075 • [624] Privacy Policy 2076 • [625] Terms of use 2077 2078 Built on [626]Forem — the [627]open source software that powers [628]DEV and 2079 other inclusive communities. 2080 2081 Made with love and [629]Ruby on Rails. DEV Community © 2016 - 2024. 2082 2083 DEV Community 2084 2085 We're a place where coders share, stay up-to-date and grow their careers. 2086 2087 [630] Log in [631] Create account 2088 ● ● ● ● ● 2089 2090 References: 2091 2092 [1] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#main-content 2093 [3] https://dev.to/ 2094 [6] https://dev.to/search 2095 [7] https://dev.to/enter 2096 [8] https://dev.to/enter?state=new-user 2097 [20] https://twitter.com/intent/tweet?text=%22In%20defense%20of%20the%20modern%20web%22%20by%20%40Rich_Harris%20%23DEVCommunity%20https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia 2098 [21] https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia&title=In%20defense%20of%20the%20modern%20web&summary=I%20expect%20I%27ll%20annoy%20everyone%20with%20this%20post%3A%20the%20anti-JavaScript%20crusaders%2C%20justly%20aghast%20at%20how%20much...&source=DEV%20Community 2099 [22] https://www.reddit.com/submit?url=https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia&title=In%20defense%20of%20the%20modern%20web 2100 [23] https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia&t=In%20defense%20of%20the%20modern%20web 2101 [24] https://www.facebook.com/sharer.php?u=https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia 2102 [25] https://toot.kytta.dev/?text=https%3A%2F%2Fdev.to%2Frichharris%2Fin-defense-of-the-modern-web-2nia 2103 [26] https://dev.to/richharris/in-defense-of-the-modern-web-2nia# 2104 [27] https://dev.to/report-abuse 2105 [28] https://dev.to/richharris 2106 [29] https://dev.to/richharris 2107 [30] https://dev.to/t/javascript 2108 [31] https://dev.to/t/react 2109 [32] https://dev.to/t/svelte 2110 [33] https://dev.to/t/webdev 2111 [34] https://twitter.com/tmcw 2112 [35] https://macwright.org/2020/05/10/spa-fatigue.html 2113 [36] https://twitter.com/tmcw/status/1259600386094030848 2114 [37] https://www.react-spring.io/ 2115 [38] https://svelte.dev/ 2116 [39] https://macwright.org/2020/05/10/spa-fatigue.html 2117 [40] https://gatsbyjs.org/ 2118 [41] https://res.cloudinary.com/practicaldev/image/fetch/s--L4S_VLxO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://user-images.githubusercontent.com/1162160/82001896-43e38b00-962a-11ea-9ae7-bda853a8cec1.png 2119 [42] https://webpagetest.org/lighthouse.php?test=200515_N4_a92cbdd5b87d402522f710a8d82d2228&run=1 2120 [43] https://webpagetest.org/easy 2121 [44] https://dev.to/ryanflorence 2122 [45] https://twitter.com/intent/tweet?in_reply_to=1186675229621248000 2123 [46] https://twitter.com/intent/retweet?tweet_id=1186675229621248000 2124 [47] https://twitter.com/intent/like?tweet_id=1186675229621248000 2125 [48] https://nextjs.org/ 2126 [49] https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec 2127 [50] https://sapper.svelte.dev/ 2128 [51] https://svelte.dev/ 2129 [59] https://dev.to/settings/response-templates 2130 [62] https://dev.to/404.html 2131 [63] https://dev.to/twigman08 2132 [64] https://dev.to/twigman08 2133 [66] https://dev.to/twigman08 2134 [68] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6 2135 [70] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6 2136 [73] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j6 2137 [74] https://dev.to/gotofritz 2138 [75] https://dev.to/gotofritz 2139 [77] https://dev.to/gotofritz 2140 [79] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj 2141 [81] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj 2142 [84] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5gj 2143 [85] https://dev.to/twigman08 2144 [86] https://dev.to/twigman08 2145 [88] https://dev.to/twigman08 2146 [90] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke 2147 [92] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke 2148 [95] https://dev.to/gotofritz 2149 [96] https://dev.to/gotofritz 2150 [98] https://dev.to/gotofritz 2151 [100] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob 2152 [102] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob 2153 [105] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/paob 2154 [106] https://dev.to/adrianus 2155 [107] https://dev.to/adrianus 2156 [109] https://dev.to/adrianus 2157 [111] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5 2158 [113] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5 2159 [116] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6g5 2160 [117] https://dev.to/ojrask 2161 [118] https://dev.to/ojrask 2162 [120] https://dev.to/ojrask 2163 [122] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh 2164 [124] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh 2165 [127] https://dev.to/gotofritz 2166 [128] https://dev.to/gotofritz 2167 [130] https://dev.to/gotofritz 2168 [132] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk 2169 [134] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk 2170 [137] https://dev.to/ojrask 2171 [138] https://dev.to/ojrask 2172 [140] https://dev.to/ojrask 2173 [142] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5 2174 [144] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5 2175 [147] https://dev.to/gotofritz 2176 [148] https://dev.to/gotofritz 2177 [150] https://dev.to/gotofritz 2178 [152] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h 2179 [154] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h 2180 [157] https://dev.to/jacobmakestheweb 2181 [158] https://dev.to/jacobmakestheweb 2182 [160] https://dev.to/jacobmakestheweb 2183 [162] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc 2184 [164] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc 2185 [167] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1i7gc 2186 [168] https://dev.to/techbelle 2187 [169] https://dev.to/techbelle 2188 [171] https://dev.to/techbelle 2189 [173] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j 2190 [175] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j 2191 [178] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1bp6j 2192 [179] https://dev.to/mark_saward 2193 [180] https://dev.to/mark_saward 2194 [182] https://dev.to/mark_saward 2195 [184] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0 2196 [186] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0 2197 [189] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2k0 2198 [190] https://dev.to/ryansolid 2199 [191] https://dev.to/ryansolid 2200 [193] https://dev.to/ryansolid 2201 [195] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369 2202 [197] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369 2203 [200] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p369 2204 [201] https://dev.to/mark_saward 2205 [202] https://dev.to/mark_saward 2206 [204] https://dev.to/mark_saward 2207 [206] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8 2208 [208] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8 2209 [211] https://dev.to/adrianus 2210 [212] https://dev.to/adrianus 2211 [214] https://dev.to/adrianus 2212 [216] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka 2213 [218] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka 2214 [221] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p7ka 2215 [222] https://dev.to/oenonono 2216 [223] https://dev.to/oenonono 2217 [225] https://dev.to/oenonono 2218 [227] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk 2219 [229] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk 2220 [232] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p4hk 2221 [233] https://dev.to/v6 2222 [234] https://dev.to/v6 2223 [236] https://dev.to/v6 2224 [238] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a 2225 [240] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a 2226 [243] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34a 2227 [244] https://dev.to/gotofritz 2228 [245] https://dev.to/gotofritz 2229 [247] https://dev.to/gotofritz 2230 [249] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf 2231 [251] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf 2232 [254] https://dev.to/v6 2233 [255] https://dev.to/v6 2234 [257] https://dev.to/v6 2235 [259] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf 2236 [261] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf 2237 [264] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5lf 2238 [265] https://dev.to/holdit 2239 [266] https://dev.to/holdit 2240 [268] https://dev.to/holdit 2241 [270] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4 2242 [272] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4 2243 [275] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p4 2244 [276] https://dev.to/iamschulz 2245 [277] https://dev.to/iamschulz 2246 [279] https://dev.to/iamschulz 2247 [281] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk 2248 [283] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk 2249 [286] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2hk 2250 [287] https://dev.to/richharris 2251 [288] https://dev.to/richharris 2252 [290] https://dev.to/richharris 2253 [292] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2 2254 [294] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2 2255 [296] https://sapper.svelte.dev/ 2256 [298] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i2 2257 [299] https://dev.to/iamschulz 2258 [300] https://dev.to/iamschulz 2259 [302] https://dev.to/iamschulz 2260 [304] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id 2261 [306] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id 2262 [309] https://dev.to/martinmalinda 2263 [310] https://dev.to/martinmalinda 2264 [312] https://dev.to/martinmalinda 2265 [314] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6 2266 [316] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6 2267 [319] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5d6 2268 [320] https://dev.to/ben 2269 [321] https://dev.to/ben 2270 [323] https://dev.to/ben 2271 [325] mailto:[email protected] 2272 [326] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk 2273 [328] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk 2274 [331] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2jk 2275 [332] https://dev.to/v6 2276 [333] https://dev.to/v6 2277 [335] https://dev.to/v6 2278 [337] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f 2279 [339] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f 2280 [341] https://www.hashicorp.com/tao-of-hashicorp#workflows,-not-technologies 2281 [343] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34f 2282 [344] https://dev.to/phlash 2283 [345] https://dev.to/phlash 2284 [347] https://dev.to/phlash 2285 [349] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3 2286 [351] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3 2287 [353] https://dev.to/phlash909/comment/cghl 2288 [355] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j3 2289 [356] https://dev.to/v6 2290 [357] https://dev.to/v6 2291 [359] https://dev.to/v6 2292 [361] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348 2293 [363] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348 2294 [366] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p348 2295 [367] https://dev.to/panesofglass 2296 [368] https://dev.to/panesofglass 2297 [370] https://dev.to/panesofglass 2298 [372] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20 2299 [374] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20 2300 [377] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12d20 2301 [378] https://dev.to/rhymes 2302 [379] https://dev.to/rhymes 2303 [381] https://dev.to/rhymes 2304 [383] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40 2305 [385] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40 2306 [388] https://dev.to/panesofglass 2307 [389] https://dev.to/panesofglass 2308 [391] https://dev.to/panesofglass 2309 [393] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2 2310 [395] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2 2311 [398] https://dev.to/rhymes 2312 [399] https://dev.to/rhymes 2313 [401] https://dev.to/rhymes 2314 [403] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6 2315 [405] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6 2316 [408] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12df6 2317 [409] https://dev.to/gregfletcher 2318 [410] https://dev.to/gregfletcher 2319 [412] https://dev.to/gregfletcher 2320 [414] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2 2321 [416] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2 2322 [419] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j2 2323 [420] https://dev.to/v6 2324 [421] https://dev.to/v6 2325 [423] https://dev.to/v6 2326 [425] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d 2327 [427] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d 2328 [429] https://martinfowler.com/bliki/SacrificialArchitecture.html 2329 [430] https://youtu.be/oKg1hTOQXoY?t=1754 2330 [431] https://res.cloudinary.com/practicaldev/image/fetch/s--KIKmJfBA--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/5ehz4jt3d7skefmuwg6d.gif 2331 [433] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34d 2332 [434] https://dev.to/richharris 2333 [435] https://dev.to/richharris 2334 [437] https://dev.to/richharris 2335 [439] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0 2336 [441] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0 2337 [444] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n0 2338 [445] https://dev.to/ben 2339 [446] https://dev.to/ben 2340 [448] https://dev.to/ben 2341 [450] mailto:[email protected] 2342 [451] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd 2343 [453] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd 2344 [456] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2nd 2345 [457] https://dev.to/rhymes 2346 [458] https://dev.to/rhymes 2347 [460] https://dev.to/rhymes 2348 [462] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm 2349 [464] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm 2350 [467] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6cm 2351 [468] https://dev.to/gotofritz 2352 [469] https://dev.to/gotofritz 2353 [471] https://dev.to/gotofritz 2354 [473] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom 2355 [475] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom 2356 [477] https://stimulusjs.org/ 2357 [479] https://dev.to/loilo 2358 [480] https://dev.to/loilo 2359 [482] https://dev.to/loilo 2360 [484] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c 2361 [486] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c 2362 [488] https://github.com/alpinejs/alpine 2363 [490] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pb3c 2364 [491] https://dev.to/mattwelke 2365 [492] https://dev.to/mattwelke 2366 [494] https://dev.to/mattwelke 2367 [496] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g 2368 [498] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g 2369 [501] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pg9g 2370 [502] https://dev.to/mattgperry 2371 [503] https://dev.to/mattgperry 2372 [505] https://dev.to/mattgperry 2373 [507] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0 2374 [509] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0 2375 [512] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i0 2376 [513] https://dev.to/richharris 2377 [514] https://dev.to/richharris 2378 [516] https://dev.to/richharris 2379 [518] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je 2380 [520] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je 2381 [522] https://twitter.com/Rich_Harris/status/1200807516529147904 2382 [524] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2je 2383 [525] https://dev.to/daniel15 2384 [526] https://dev.to/daniel15 2385 [528] https://dev.to/daniel15 2386 [530] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6 2387 [532] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6 2388 [535] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n6 2389 [536] https://dev.to/mrispoli24 2390 [537] https://dev.to/mrispoli24 2391 [539] https://dev.to/mrispoli24 2392 [541] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc 2393 [543] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc 2394 [546] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2kc 2395 [547] https://dev.to/richharris 2396 [548] https://dev.to/richharris 2397 [550] https://dev.to/richharris 2398 [552] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5 2399 [554] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5 2400 [557] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p5 2401 [558] https://dev.to/mrispoli24 2402 [559] https://dev.to/mrispoli24 2403 [561] https://dev.to/mrispoli24 2404 [563] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p 2405 [565] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p 2406 [568] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p35p 2407 [569] https://dev.to/vintharas 2408 [570] https://dev.to/vintharas 2409 [572] https://dev.to/vintharas 2410 [574] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hp 2411 [576] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hp 2412 [579] https://dev.to/richharris/in-defense-of-the-modern-web-2nia#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2hp 2413 [580] https://dev.to/richharris/in-defense-of-the-modern-web-2nia/comments 2414 [581] https://dev.to/code-of-conduct 2415 [582] https://dev.to/report-abuse 2416 [586] https://dev.to/richharris/in-defense-of-the-modern-web-2nia# 2417 [590] https://dev.to/report-abuse 2418 [591] https://dev.to/tthroo/build-your-saas-landing-page-in-15-minutes-using-mantine-111a 2419 [592] https://dev.to/tlaloces/authentication-example-with-fastapi-and-jwt-is-it-as-easy-and-straightforward-as-they-claim-16m1 2420 [593] https://dev.to/myogeshchavan97/i-launched-the-most-awaited-complete-react-course-1efe 2421 [594] https://dev.to/ziontutorial/build-a-dynamic-currency-converter-beginner-react-project-5cb8 2422 [595] https://dev.to/richharris 2423 [597] https://dev.to/richharris 2424 [598] https://dev.to/richharris/stay-alert-d 2425 [599] https://dev.to/richharris/a-new-technique-for-making-responsive-javascript-free-charts-gmp 2426 [608] javascript:void(0); 2427 [611] https://dev.to/ 2428 [612] https://dev.to/ 2429 [613] https://dev.to/pod 2430 [614] https://dev.to/videos 2431 [615] https://dev.to/tags 2432 [616] https://dev.to/faq 2433 [617] https://shop.forem.com/ 2434 [618] https://dev.to/advertise 2435 [619] https://dev.to/about 2436 [620] https://dev.to/contact 2437 [621] https://dev.to/guides 2438 [622] https://dev.to/software-comparisons 2439 [623] https://dev.to/code-of-conduct 2440 [624] https://dev.to/privacy 2441 [625] https://dev.to/terms 2442 [626] https://www.forem.com/ 2443 [627] https://dev.to/t/opensource 2444 [628] https://dev.to/ 2445 [629] https://dev.to/t/rails 2446 [630] https://dev.to/enter 2447 [631] https://dev.to/enter?state=new-user