WEBVTT 1 00:00:00.120 --> 00:00:02.919 Have you ever been like staring at your phone waiting 2 00:00:02.919 --> 00:00:05.599 for a web page to load and it's just this glaring, 3 00:00:06.320 --> 00:00:07.639 blank white screen. 4 00:00:07.879 --> 00:00:09.759 Oh yeah. Or you go to share a link in 5 00:00:09.800 --> 00:00:13.800 a work channel and the preview is just completely empty. 6 00:00:13.560 --> 00:00:16.039 Right, it just says loading, and you're sitting there thinking, 7 00:00:16.120 --> 00:00:18.399 you know, the modern Internet should really be past this 8 00:00:18.440 --> 00:00:19.079 point by now. 9 00:00:19.120 --> 00:00:22.559 It really should. Yeah, but the stakes in this architectural 10 00:00:22.559 --> 00:00:27.679 battle are actually incredibly high, especially for the businesses running these. 11 00:00:27.600 --> 00:00:30.480 Platforms, which is exactly what we're getting into today. Welcome 12 00:00:30.480 --> 00:00:33.359 to the deep dive. By the time we finish this conversation, 13 00:00:33.479 --> 00:00:36.320 you are going to understand the invisible high stakes war 14 00:00:36.399 --> 00:00:41.439 waging right behind your browser screen to fix that exact frustration. 15 00:00:41.280 --> 00:00:43.679 Because we are looking at an arms race here where 16 00:00:44.079 --> 00:00:47.000 literally a fraction of a second dictates millions of dollars 17 00:00:47.039 --> 00:00:48.119 in revenue totally. 18 00:00:48.320 --> 00:00:50.600 So our mission today is to explore how web developers 19 00:00:50.600 --> 00:00:52.679 are hunting for what's been called the holy grail of 20 00:00:52.679 --> 00:00:55.920 web architecture. They're trying to find this perfect elusive balance 21 00:00:55.960 --> 00:01:01.200 between lightning fast speed, a seamless user experience, and ensuring 22 00:01:01.240 --> 00:01:03.359 search engines can actually index the content. 23 00:01:03.640 --> 00:01:06.040 And to guide us through this We're pulling from a 24 00:01:06.079 --> 00:01:11.439 really fantastic O'Reilly book. It's called Building Isomorphic JavaScript Apps, 25 00:01:11.760 --> 00:01:15.400 written by software engineers Jason Strimple and maxim Nea Gene. 26 00:01:15.879 --> 00:01:18.319 Yeah, and what I love about their book is how 27 00:01:18.319 --> 00:01:20.799 it frames the evolution of the web. It treats the 28 00:01:20.840 --> 00:01:24.319 history of web development not just as this sterile timeline 29 00:01:24.319 --> 00:01:27.359 of faster machines, but as a series of very human 30 00:01:27.439 --> 00:01:28.640 choices exactly. 31 00:01:28.680 --> 00:01:32.319 I mean, developers made pragmatic decisions to solve immediate problems, 32 00:01:32.799 --> 00:01:36.599 realized the unintended consequences of those choices a few years later, 33 00:01:36.920 --> 00:01:39.079 and then had to drastically course correct. 34 00:01:39.280 --> 00:01:42.719 It's entirely a human journey of trial and error. There's 35 00:01:42.760 --> 00:01:46.319 this great self deprecating anecdote in the preface that sets 36 00:01:46.359 --> 00:01:47.599 the tone perfectly well. 37 00:01:47.640 --> 00:01:48.480 The spell check one. 38 00:01:48.560 --> 00:01:51.519 Yes, when he started out as a webmaster about fifteen 39 00:01:51.560 --> 00:01:54.200 years ago, he was so inexperienced that he honestly thought 40 00:01:54.200 --> 00:01:56.400 if he sent an email with misspellings in it, the 41 00:01:56.439 --> 00:01:59.159 person receiving the email would also see the red squiggly 42 00:01:59.200 --> 00:02:00.000 lines under the tech. 43 00:02:00.400 --> 00:02:03.079 I love that so much. It perfectly illustrates the environment 44 00:02:03.120 --> 00:02:05.400 we're talking about, the people building the foundation of the 45 00:02:05.400 --> 00:02:08.240 modern Web. We're literally figuring it out on the fly. 46 00:02:08.520 --> 00:02:11.680 Right, because the Internet didn't start as the robust application 47 00:02:11.800 --> 00:02:13.080 platform we know today. 48 00:02:13.240 --> 00:02:16.000 No, not at all. It started as a rudimentary system 49 00:02:16.039 --> 00:02:20.319 to just share static text documents linked together by academic. 50 00:02:19.840 --> 00:02:24.319 Institutions, basically a giant virtual filing cabinet. And to understand 51 00:02:24.319 --> 00:02:27.280 the cutting edge solutions we have today, we really have 52 00:02:27.360 --> 00:02:30.360 to look at the technical debt we accumulated getting here. 53 00:02:30.520 --> 00:02:33.520 Yeah, the pendulum of web history has basically been swinging 54 00:02:33.599 --> 00:02:35.479 wildly from one extreme to another. 55 00:02:35.759 --> 00:02:38.639 So let's talk about the classic web application model. First, 56 00:02:39.360 --> 00:02:42.000 the server does all the heavy lifting, renders the full 57 00:02:42.120 --> 00:02:44.719 HTML document and sends it to the browser. 58 00:02:44.439 --> 00:02:46.879 Which is great for search engines they could read everything perfectly, 59 00:02:47.240 --> 00:02:50.240 but it's terrible for page to page transitions because of 60 00:02:50.280 --> 00:02:52.719 the full tear down and reload. Every single time you 61 00:02:52.719 --> 00:02:53.120 click a. 62 00:02:53.039 --> 00:02:55.520 Link, right, the whole screen goes white for a second. 63 00:02:55.719 --> 00:02:58.520 So ajax stepped in to fix that by allowing a 64 00:02:58.599 --> 00:03:00.840 synchronous updates to parts of a page. 65 00:03:01.080 --> 00:03:05.439 Yeah, the introduction of XMLHTTP request completely transformed the web. 66 00:03:05.599 --> 00:03:08.159 Suddenly you didn't need to refresh the entire page just 67 00:03:08.199 --> 00:03:09.360 to update your shopping cart. 68 00:03:09.520 --> 00:03:12.159 Okay, let's unpack this for a second. The classic Web 69 00:03:12.199 --> 00:03:15.879 is essentially like ordering an entirely new car. Every time 70 00:03:15.919 --> 00:03:18.599 you want to change the radio station, AJAX, let us 71 00:03:18.639 --> 00:03:19.680 just replace the radio. 72 00:03:19.960 --> 00:03:23.960 That is a perfect analogy, but that leap forward introduced 73 00:03:24.039 --> 00:03:27.639 what the authors call a path of destruction for code maintenance. 74 00:03:27.879 --> 00:03:30.560 A path of destruction sounds dramatic. What do they mean 75 00:03:30.599 --> 00:03:30.919 by that? 76 00:03:31.120 --> 00:03:34.319 Well, classic web applications were fundamentally not designed for client 77 00:03:34.400 --> 00:03:37.960 side rendering. The moment developers started updating parts of the 78 00:03:38.000 --> 00:03:42.000 screen dynamically, they found themselves duplicating their rendering logic. 79 00:03:42.159 --> 00:03:44.479 Ah, I see, So you'd have the server rendering the 80 00:03:44.520 --> 00:03:47.879 initial layout in say Java or PHP, and then a 81 00:03:47.919 --> 00:03:51.439 completely separate damascript file doing the exact same visual rendering 82 00:03:51.439 --> 00:03:53.439 in the browser for any subsequent updates. 83 00:03:53.479 --> 00:03:57.319 Exactly That duplication was the breaking point. Imagine a dynamic 84 00:03:57.400 --> 00:04:00.759 data table. The server renders the first fifty rose using 85 00:04:00.759 --> 00:04:04.000 a Ruby template. Okay, but then when a user clicks 86 00:04:04.080 --> 00:04:07.599 sword by date, the client uses AJX to fetch new 87 00:04:07.719 --> 00:04:10.879 raw Jason data. So now the developer had to maintain 88 00:04:10.919 --> 00:04:14.800 a second set of complex HTML rendering logic written entirely 89 00:04:14.840 --> 00:04:17.920 in JavaScript, just to rebuild it exact same table. 90 00:04:18.199 --> 00:04:21.279 Wow, so you had the exact same visual element governed 91 00:04:21.279 --> 00:04:24.279 by two completely different codebases, probably written by different teams. Right. 92 00:04:24.439 --> 00:04:27.480 Usually yeah, h a developer would fix a formatting bug 93 00:04:27.519 --> 00:04:29.920 on the server template, but completely forget to update the 94 00:04:29.959 --> 00:04:30.759 JavaScript file. 95 00:04:31.079 --> 00:04:34.199 Oh, which leads to a mismatched user interface depending on 96 00:04:34.240 --> 00:04:36.519 whether you refresh the page or click the button. That 97 00:04:36.600 --> 00:04:38.000 sounds like a nightmare, it was. 98 00:04:38.560 --> 00:04:42.399 That kind of technical debt is just unsustainable, which explains 99 00:04:42.399 --> 00:04:45.319 why the pendulum swung so violently in the opposite direction 100 00:04:45.439 --> 00:04:50.199 toward the single page application or SPA, the fat client approach. 101 00:04:50.759 --> 00:04:54.399 Right, developers essentially decided to stop splitting the baby. They 102 00:04:54.480 --> 00:04:57.439 move the entire application layer into the browser. 103 00:04:57.600 --> 00:05:00.560 Yeah. In an SPA, the server's job is reduced to 104 00:05:00.600 --> 00:05:04.560 sending a bare bones, almost entirely blank HTML page along 105 00:05:04.560 --> 00:05:06.759 with some raw data APIs. 106 00:05:06.439 --> 00:05:10.079 And then the browser downloads a massive JavaScript bundle and 107 00:05:10.199 --> 00:05:14.519 builds the entire user interface from scratch directly on your device. 108 00:05:14.399 --> 00:05:18.199 Which solves the duplicate code problem because everything is just JavaScript. Now. 109 00:05:18.360 --> 00:05:22.560 Wait, if spas fixed the duplicate code problem and gave 110 00:05:22.639 --> 00:05:26.959 us smooth app like transitions without reloading the page, didn't 111 00:05:27.000 --> 00:05:29.480 we just solve the Internet. Why is there a whole 112 00:05:29.480 --> 00:05:30.800 book about what comes next? 113 00:05:31.079 --> 00:05:34.560 Well, because SPA's created a beautiful, fluid experience for the 114 00:05:34.680 --> 00:05:39.160 user only after the application finally loaded. But they inadvertently 115 00:05:39.199 --> 00:05:43.040 shattered two fundamental pillars of the web, which are perceived 116 00:05:43.040 --> 00:05:47.399 speed and search engine visibility. This created an absolute crisis 117 00:05:47.399 --> 00:05:49.240 for e commerce and media businesses. 118 00:05:49.399 --> 00:05:52.240 Ah, so we're back to that dreaded blank larning screen 119 00:05:52.279 --> 00:05:53.000 I mentioned at the start. 120 00:05:53.040 --> 00:05:55.279 Now exactly, let's look at the hard data from the 121 00:05:55.319 --> 00:05:58.120 source material. According to a Radwar report cited in the book, 122 00:05:58.439 --> 00:06:01.160 back in nineteen ninety nine, use were conditioned to wait 123 00:06:01.199 --> 00:06:03.319 about eight seconds for a page to load. 124 00:06:03.480 --> 00:06:07.079 Eight seconds. That feels like an eternity now, right, But. 125 00:06:07.079 --> 00:06:10.600 By twenty ten, the landscape had completely shifted. Fifty seven 126 00:06:10.639 --> 00:06:13.560 percent of online shoppers said they would abandon the page 127 00:06:13.600 --> 00:06:15.639 if nothing showed up after just three seconds. 128 00:06:15.720 --> 00:06:18.319 Yeah, three seconds and you've lost more than half your customers. 129 00:06:18.600 --> 00:06:22.480 And it gets more granular. Both Amazon and Walmart published 130 00:06:22.480 --> 00:06:25.720 findings showing that a mere one hundred millisecond improvement in 131 00:06:25.759 --> 00:06:29.560 load time boosted their incremental revenue by up to one percent. 132 00:06:29.879 --> 00:06:33.040 One hundred milliseconds is barely a blank and it's tied 133 00:06:33.040 --> 00:06:37.040 to millions in revenue. That puts the SPA architecture in 134 00:06:37.079 --> 00:06:37.959 a really bad light. 135 00:06:38.199 --> 00:06:41.519 It excoses a massive flaw in the model. Because an 136 00:06:41.560 --> 00:06:45.120 SPA sends a blank HTML page. First, your browser has 137 00:06:45.160 --> 00:06:48.959 to download a massive JavaScript file, parse it, run it, 138 00:06:49.279 --> 00:06:52.199 fetch the initial data, and then finally render the screen. 139 00:06:52.319 --> 00:06:54.399 So you're just staring at a white screen or a 140 00:06:54.399 --> 00:06:55.399 little spinning wheel that. 141 00:06:55.360 --> 00:06:58.920 Whole time, exactly. And the authors explained that this architectural 142 00:06:59.000 --> 00:07:03.519 choice actively against the underlying protocols of the Internet, specifically 143 00:07:03.639 --> 00:07:06.519 a mechanism in TCP called slow start. 144 00:07:06.319 --> 00:07:10.360 TCP right, the foundational protocol handling how data travels across 145 00:07:10.360 --> 00:07:12.480 the network. Why does it start slow? 146 00:07:13.360 --> 00:07:16.680 It's basically a congestion avoidance mechanism. When a server starts 147 00:07:16.680 --> 00:07:18.759 sending data to a browser, it doesn't know how much 148 00:07:18.800 --> 00:07:20.839 bandwidth is actually available on the network path. 149 00:07:20.920 --> 00:07:22.680 Okay, so it has to test the waters first. 150 00:07:23.000 --> 00:07:25.000 Yeah, if it dumps a huge file all at once, 151 00:07:25.519 --> 00:07:30.639 it risks overwhelming routers and dropping packets entirely. So TCP 152 00:07:30.839 --> 00:07:33.560 starts by sending a very small amount of data the 153 00:07:33.639 --> 00:07:34.839 congestion window. 154 00:07:34.720 --> 00:07:36.560 Got it, And if that goes through smoothly. 155 00:07:36.639 --> 00:07:40.279 If that data is acknowledged successfully, the window doubles. But 156 00:07:40.319 --> 00:07:43.000 the book notes that reaching just sixty four kilobytes a 157 00:07:43.040 --> 00:07:46.240 throughput takes four full network round trips. 158 00:07:46.360 --> 00:07:48.879 Four round trips just for sixty four kilobytes. 159 00:07:48.920 --> 00:07:51.879 That's tiny, and in a mobile environment, those round trips 160 00:07:51.920 --> 00:07:54.120 add hundreds of milliseconds of latency. 161 00:07:54.360 --> 00:07:56.800 So the very architecture of the Internet prevents sending a 162 00:07:56.839 --> 00:08:00.920 giant JavaScript bundle quickly. If you're entire THEREUI is locked 163 00:08:00.920 --> 00:08:03.879 inside a two megabye JavaScript file, You're going to feel 164 00:08:03.920 --> 00:08:06.000 every single one of those network round trips before you 165 00:08:06.000 --> 00:08:07.959 see a single pixel exactly. 166 00:08:08.519 --> 00:08:10.839 The first few kilobytes of data sent to the user 167 00:08:10.920 --> 00:08:14.759 are essential for perceived responsiveness. Sending a blank page in 168 00:08:14.800 --> 00:08:19.199 those critical first milliseconds is honestly the worst possible strategy. 169 00:08:18.879 --> 00:08:22.800 And beyond the speed crisis, SPAS completely broke search engine optimization. 170 00:08:23.199 --> 00:08:26.800 They absolutely did. Search engines traditionally just scan the raw 171 00:08:26.959 --> 00:08:29.879 HTML coming from the server. If the server is sending 172 00:08:29.879 --> 00:08:32.879 a blank page, the crawler assumes the site is empty. 173 00:08:33.279 --> 00:08:35.320 I remember there was also a huge issue with how 174 00:08:35.440 --> 00:08:37.519 SPAS handled URLs, right. 175 00:08:37.360 --> 00:08:41.080 Yeah, routing in a single page application fundamentally conflicted with 176 00:08:41.120 --> 00:08:44.759 web standards. In a classic web app, the URL points 177 00:08:44.759 --> 00:08:47.759 to a real directory on a server, but an SPA 178 00:08:48.279 --> 00:08:51.200 uses hash fragments to manage navigation internally. 179 00:08:51.360 --> 00:08:54.559 Hash fragments, like when the URL looks like domain dot com, 180 00:08:54.559 --> 00:08:56.240 slash hashtag about. 181 00:08:56.080 --> 00:08:58.960 Exactly does it without triggering a server request? Yeah. The 182 00:08:59.039 --> 00:09:02.799 problem there is that web specifications dictate that anything after 183 00:09:02.840 --> 00:09:04.919 a hashtag is strictly meant for the browser. 184 00:09:05.120 --> 00:09:08.159 Oh so it is never sent in the HTTP request 185 00:09:08.200 --> 00:09:08.919 to the server. 186 00:09:08.720 --> 00:09:11.600 At all, right, and search engine crawlers obeyed that specification. 187 00:09:11.799 --> 00:09:15.399 They ignored the hash fragment entirely. To Google's bot, the homepage, 188 00:09:15.440 --> 00:09:18.360 the about page, and a specific product page all looked 189 00:09:18.399 --> 00:09:20.279 like the exact same blank root document. 190 00:09:20.600 --> 00:09:23.600 Oh man, So you end up with a beautiful, highly 191 00:09:23.639 --> 00:09:27.039 interactive application that nobody can find on Google and if 192 00:09:27.080 --> 00:09:29.919 they do happen to have a direct link, they bounce 193 00:09:30.000 --> 00:09:32.039 because the initial load takes four seconds. 194 00:09:32.080 --> 00:09:33.759 It's a disaster for discoverability. 195 00:09:33.799 --> 00:09:36.360 The Lanks companies went to just to hack their way 196 00:09:36.399 --> 00:09:39.879 around this are fascinating. The sources talk about Google trying 197 00:09:39.919 --> 00:09:42.799 to patch the bleeding by introducing the hashbang hack. 198 00:09:43.159 --> 00:09:46.799 Oh, the hashbang That was where developers literally put an 199 00:09:46.840 --> 00:09:50.600 exclamation point after the hashtag in the URL to signal 200 00:09:50.639 --> 00:09:53.080 to the crawler that there's client side content there. 201 00:09:53.159 --> 00:09:56.399 It just sounds so brittle a total workaround is a. 202 00:09:56.360 --> 00:10:00.399 Wildly complex workaround. When the crawlers saw that exclamation point, 203 00:10:00.399 --> 00:10:03.399 it would intercept the URL, transform it into a special 204 00:10:03.480 --> 00:10:06.960 query parameter, and ask the server to provide an HTML 205 00:10:06.960 --> 00:10:09.000 snapshot of what the JavaScript would have rendered. 206 00:10:09.039 --> 00:10:11.320 Wait, how does the server know what the JavaScript would 207 00:10:11.320 --> 00:10:13.559 have rendered if the server doesn't run JavaScript. 208 00:10:13.919 --> 00:10:17.679 That's the crazy part. To provide that snapshot, companies had 209 00:10:17.679 --> 00:10:20.080 to run headless browsers on their servers. 210 00:10:20.200 --> 00:10:22.039 Headless browsers, Yeah. 211 00:10:21.879 --> 00:10:25.600 They were basically spinning up instances of phantom js, which 212 00:10:25.679 --> 00:10:28.720 is an invisible web browser running in the server's memory, 213 00:10:28.799 --> 00:10:31.840 just to execute their own JavaScript, wait for the page 214 00:10:31.840 --> 00:10:35.440 to render, take the resulting HTML string, and hand it 215 00:10:35.480 --> 00:10:36.519 to the Google bot. 216 00:10:36.600 --> 00:10:39.200 That sounds like an infrastructure night were built entirely out 217 00:10:39.240 --> 00:10:39.879 of duct taate. 218 00:10:40.000 --> 00:10:42.879 Or they had to outsource that entire process to third 219 00:10:42.919 --> 00:10:47.120 party snapshot companies like brom Bone. The operational and performance 220 00:10:47.159 --> 00:10:49.000 costs were just staggering. 221 00:10:49.039 --> 00:10:52.200 Here's where it gets really interesting. Twitter provides the perfect 222 00:10:52.200 --> 00:10:53.159 case study for this right. 223 00:10:53.279 --> 00:10:57.120 Yes, In twenty ten, they launched a highly publicized architecture 224 00:10:57.120 --> 00:11:00.840 called New Twitter. It was groundbreaking for its time, shifting 225 00:11:00.879 --> 00:11:03.399 almost all the rendering logic and routing to the browser 226 00:11:03.679 --> 00:11:05.039 in an SPA model, but. 227 00:11:05.200 --> 00:11:07.039 The time to first tweet was abysmal. 228 00:11:07.240 --> 00:11:09.960 It was so slow to load that just two years later, 229 00:11:10.240 --> 00:11:13.679 Twitter's engineering team published a post mortem and released a 230 00:11:13.720 --> 00:11:16.759 re architected version that moved the initial rendering back to 231 00:11:16.799 --> 00:11:17.200 the server. 232 00:11:17.440 --> 00:11:18.960 And what happened to their load times? 233 00:11:19.279 --> 00:11:23.200 That single architectural rollback dropped their initial page load times 234 00:11:23.399 --> 00:11:26.639 to one fifth of what they were under the SPA model. 235 00:11:27.000 --> 00:11:31.240 Fifth, that is wild, and that historical context really sets 236 00:11:31.240 --> 00:11:34.279 the stage perfectly for the perfect union the authors are chasing. 237 00:11:34.440 --> 00:11:38.039 Exactly. The industry realized the pendulum had swung way too far. 238 00:11:38.679 --> 00:11:42.080 The classic web gave us SEO and instant initial loads, 239 00:11:42.320 --> 00:11:43.759 but clunky interactions. 240 00:11:43.879 --> 00:11:47.399 Well sbas gave us fluid interactions but destroyed initial load 241 00:11:47.440 --> 00:11:51.639 speeds and SEO. So the solution is isomorphic JavaScript. Yes. 242 00:11:51.960 --> 00:11:55.279 Isomorphic JavaScript is an architecture where a single codebase runs 243 00:11:55.279 --> 00:11:57.879 on both the server and the browser. It aims to 244 00:11:57.879 --> 00:12:00.799 deliver the benefits of both extremes with the drawbacks. 245 00:12:00.879 --> 00:12:04.559 Okay, writing code that runs anywhere sounds elegant in theory, 246 00:12:04.840 --> 00:12:07.519 but writing logic that has no idea where it's living 247 00:12:07.720 --> 00:12:10.759 sounds like a massive technical hurdle. How exactly does the 248 00:12:10.759 --> 00:12:12.759 handoff work between the server and the browser. 249 00:12:12.799 --> 00:12:15.200 The mechanism that makes this possible is called hydration. 250 00:12:15.399 --> 00:12:16.799 Hydration, okay, how does that work? 251 00:12:16.840 --> 00:12:19.320 When a user types in a URL, the server executes 252 00:12:19.360 --> 00:12:23.399 the JavaScript application logic, fetches the necessary data, and instantly 253 00:12:23.440 --> 00:12:27.080 generates a fully formed HTML. Strength it sends that concelet 254 00:12:27.200 --> 00:12:29.039 HTML document down the wire. 255 00:12:29.080 --> 00:12:32.320 So the search engine crawler gets a fully populated page instantly, 256 00:12:32.720 --> 00:12:36.480 and the user's browser immediately displays text and images without 257 00:12:36.519 --> 00:12:39.320 waiting for any massive JavaScript bundle to execute. 258 00:12:39.480 --> 00:12:42.720 Exactly The TCP slow start is an issue because those 259 00:12:42.759 --> 00:12:45.720 first few kilobytes actually contain content. 260 00:12:45.480 --> 00:12:47.039 But the page isn't interactive yet. 261 00:12:47.120 --> 00:12:50.919 Right right in the background, the browser downloads the JavaScript bundle. 262 00:12:51.440 --> 00:12:54.519 Once the bundle is ready, the JavaScript framework boots up. 263 00:12:54.759 --> 00:12:58.080 But instead of destroying the existing HTML and rebuilding the 264 00:12:58.120 --> 00:13:00.799 down from scratch, which would cause a massive visual flicker, 265 00:13:01.480 --> 00:13:03.120 it hydrates the page. 266 00:13:03.159 --> 00:13:06.200 It hydrates it so it analyzes the HTML that's already 267 00:13:06.200 --> 00:13:09.679 on the screen, maps its internal virtual representation to the 268 00:13:09.720 --> 00:13:13.159 existing elements, and silently on gotchaes the event listeners like 269 00:13:13.240 --> 00:13:15.440 the click handlers and form submissions. 270 00:13:15.559 --> 00:13:18.519 Yes, so the user experience is a lightning fast initial load, 271 00:13:18.919 --> 00:13:22.759 and the moment hydration is complete, the application seamlessly transitions 272 00:13:22.759 --> 00:13:24.759 into a single page application. 273 00:13:24.399 --> 00:13:27.240 For every click after that initial load, the browser handles 274 00:13:27.279 --> 00:13:30.480 the routing and data fetching asynchronously exactly. 275 00:13:30.600 --> 00:13:32.840 That handoff is what makes it so brilliant. 276 00:13:33.039 --> 00:13:35.240 But going back to my earlier point, how can the 277 00:13:35.279 --> 00:13:38.799 actual code be identical the server and the browser are 278 00:13:38.799 --> 00:13:40.399 completely different environments. 279 00:13:40.759 --> 00:13:44.240 Well, the book uses the term isomorphic, which implies a 280 00:13:44.320 --> 00:13:48.519 deep structural similarity. The authors actually borrow the term from 281 00:13:48.559 --> 00:13:49.799 mathematical graph theory. 282 00:13:50.000 --> 00:13:52.120 Okay, math, walk me through it. 283 00:13:52.159 --> 00:13:56.639 In mathematics, imagine two separate graphs. They might look entirely 284 00:13:56.679 --> 00:13:59.919 different visually, but if you can map every single node 285 00:14:00.080 --> 00:14:02.799 from the first graph to a corresponding node in the 286 00:14:02.840 --> 00:14:06.480 second graph and guarantee that all their relationships and connecting 287 00:14:06.480 --> 00:14:10.120 lines are preserved, those two graphs are mathematically isomorphic. 288 00:14:10.360 --> 00:14:12.840 So it's like a script for a play, whether it's 289 00:14:12.960 --> 00:14:16.720 performed in a massive grand Broadway theater that's our server environment, 290 00:14:17.200 --> 00:14:20.799 or a tiny, bare bones black box studio that's our browser. 291 00:14:20.960 --> 00:14:24.360 The characters, the dialogue, and the plot progression map perfectly 292 00:14:24.399 --> 00:14:24.960 to each other. 293 00:14:25.279 --> 00:14:28.320 That is exactly it. For JavaScript code to run successfully 294 00:14:28.360 --> 00:14:31.120 in both environments, there must be a mapping of the 295 00:14:31.159 --> 00:14:33.879 service capabilities to the client's capabilities. 296 00:14:33.919 --> 00:14:35.799 But it's not just an all or nothing switch, right. 297 00:14:35.919 --> 00:14:37.120 The authors say, it's a spectrum. 298 00:14:37.200 --> 00:14:39.360 Right, it exists on a spectrum. On one end, you 299 00:14:39.440 --> 00:14:44.279 have what they call environment agnostic code. This is pure computational. 300 00:14:43.559 --> 00:14:48.159 Logic, like mathematical calculations, data validation, or string formatting. The 301 00:14:48.159 --> 00:14:51.399 book mentions libraries like moment dot js, which is used 302 00:14:51.399 --> 00:14:52.600 for manipulating dates. 303 00:14:52.679 --> 00:14:55.679 Yeah, formatting a timestamp into a readable string doesn't require 304 00:14:55.720 --> 00:14:58.960 any knowledge of the network or the user interface. It's 305 00:14:59.000 --> 00:15:01.279 just an input in an out put. That code works 306 00:15:01.320 --> 00:15:02.200 perfectly everywhere. 307 00:15:02.240 --> 00:15:04.639 The only hurdle is moving it between environments. 308 00:15:04.679 --> 00:15:07.679 I guess, which is where build tools come in. You 309 00:15:07.759 --> 00:15:10.879 need a tool like webpack or Browserifi. Think a webpack 310 00:15:10.960 --> 00:15:14.159 is a highly organized factory line. It takes all your 311 00:15:14.200 --> 00:15:18.919 separate server side no dot JS modules, analyzes their dependencies, 312 00:15:19.240 --> 00:15:22.799 wraps them up and translates them into one single cohesive 313 00:15:22.840 --> 00:15:26.279 package that the browser's engine can actually digest and execute. 314 00:15:26.360 --> 00:15:28.120 But how does the code know where it is? For 315 00:15:28.200 --> 00:15:31.720 the environment specific stuff. The browser relies on a window 316 00:15:31.759 --> 00:15:35.519 object to manage URLs and screen sizes, but the server 317 00:15:35.639 --> 00:15:40.080 relies on raw HTTP requests. You can't just copypaste your 318 00:15:40.120 --> 00:15:40.840 routing logic. 319 00:15:41.240 --> 00:15:43.720 No, you can't. You need some sort of translator sitting 320 00:15:43.720 --> 00:15:47.639 in the middle. Those translators are called shims or polyphill jims. 321 00:15:47.720 --> 00:15:48.399 Okay, what do they do? 322 00:15:48.799 --> 00:15:51.639 A shim is an abstraction layer that intercepts a command 323 00:15:51.639 --> 00:15:55.080 from your application and translates it into the appropriate action 324 00:15:55.200 --> 00:15:59.000 for the underlying environment. Let's look at page routing, specifically 325 00:15:59.039 --> 00:16:00.360 redirecting a u US. 326 00:16:00.480 --> 00:16:04.000 Sure, in a browser, manipulating the URL is pretty straightforward. 327 00:16:04.080 --> 00:16:07.879 You just write window dot location dot eight ref equals 328 00:16:08.039 --> 00:16:09.480 new underscore earle. 329 00:16:09.919 --> 00:16:12.639 But if your isomorphic code runs that exact line on 330 00:16:12.679 --> 00:16:16.159 a server, the application crashes immediately with a window is 331 00:16:16.240 --> 00:16:20.240 not defined error. Servers don't have windows right On a server, 332 00:16:20.440 --> 00:16:24.960 A redirect requires modifying the HTTP response header, usually by 333 00:16:25.000 --> 00:16:27.960 executing a command like res dot right head alongside the 334 00:16:28.000 --> 00:16:28.720 new URL. 335 00:16:29.000 --> 00:16:31.519 So the shim acts as the middleman. You write a 336 00:16:31.559 --> 00:16:34.639 single routing function for your app. Inside that function, the 337 00:16:34.639 --> 00:16:37.720 SHIM performs a simple environmental check like does the window 338 00:16:37.759 --> 00:16:39.080 object exist exactly? 339 00:16:39.399 --> 00:16:41.519 If it does, we're clearly in the browser, so it 340 00:16:41.600 --> 00:16:45.039 fires the window dot location method. If it doesn't, we're 341 00:16:45.080 --> 00:16:47.279 on the server, so it executes res dot right head. 342 00:16:47.480 --> 00:16:50.639 The overarching application lojic never has to care where it lives. 343 00:16:50.919 --> 00:16:54.039 It just issues a generic redirect command and the SHIM 344 00:16:54.120 --> 00:16:59.039 handles the environmental translation perfectly. That is an incredibly robust 345 00:16:59.200 --> 00:17:02.200 architectural path. It really is Okay, you've sold me. But 346 00:17:02.320 --> 00:17:04.799 if this is the holy grail, if it resolves the 347 00:17:04.880 --> 00:17:09.839 SPA crisis, fixes SEO, delivers instant hydration, and eliminates duplicate 348 00:17:09.880 --> 00:17:14.480 code maintenance. Why isn't every single website on Earth rewritten 349 00:17:14.519 --> 00:17:16.160 in isomorphic JavaScript today? 350 00:17:16.359 --> 00:17:20.880 You're hitting on the core operational bottleneck. Every architectural choice 351 00:17:20.920 --> 00:17:26.039 carries a cost, and isomorphism introduces some undeniable operational realities. 352 00:17:25.599 --> 00:17:28.400 Meaning it's hard to implement if you aren't starting. 353 00:17:28.079 --> 00:17:31.359 From scratch, very hard. Think about a massive enterprise company 354 00:17:31.440 --> 00:17:34.240 like a bank or a major retailer that's spent two 355 00:17:34.279 --> 00:17:39.359 decades building their infrastructure, security protocols, and database connections in Java, Python, 356 00:17:39.440 --> 00:17:39.960 or PHB. 357 00:17:40.240 --> 00:17:43.799 To run isomorphic JavaScript natively, you need a JavaScript runtime 358 00:17:43.799 --> 00:17:47.079 on the server, which typically means deploying no dot Js. 359 00:17:47.240 --> 00:17:50.359 Yes, and integrating no dot Js into a legacy Java 360 00:17:50.400 --> 00:17:54.039 ecosystem is a massive undertaking. You generally have two choices, 361 00:17:54.359 --> 00:17:55.759 both with steep downsides. 362 00:17:55.920 --> 00:17:57.039 What's the first choice? 363 00:17:57.240 --> 00:18:00.400 First, you could run a standalone no dot Js server 364 00:18:00.559 --> 00:18:03.960 alongside your Java back end, acting entirely as a render service. 365 00:18:04.200 --> 00:18:06.400 But that means your Java server has to pull the 366 00:18:06.440 --> 00:18:09.319 data from the database, serialize all of it into a 367 00:18:09.400 --> 00:18:12.559 Jason format, send it over a local network socket to 368 00:18:12.599 --> 00:18:16.039 the Node server, wait for Node to generate the HTML string, 369 00:18:16.160 --> 00:18:19.240 and then route that HTML back out to the user exactly. 370 00:18:19.720 --> 00:18:25.119 The network latency and serialization overhead alone could completely negate 371 00:18:25.160 --> 00:18:27.000 the speed benefits you were trying to gain in the 372 00:18:27.000 --> 00:18:27.559 first place. 373 00:18:27.720 --> 00:18:29.200 Okay, so what's the alternative. 374 00:18:29.279 --> 00:18:33.440 The alternative is using an embedded JavaScript runtime directly inside 375 00:18:33.559 --> 00:18:37.519 the Java virtual machine. The book discusses Nashorn, which came 376 00:18:37.519 --> 00:18:40.880 packaged with Java eight. It allows you to execute javscript 377 00:18:40.880 --> 00:18:42.759 directly within your Java code. 378 00:18:42.519 --> 00:18:45.960 But running a scripting language inside a virtual machine built 379 00:18:45.960 --> 00:18:48.839 for a compiled language has to have performance limits, right. 380 00:18:48.920 --> 00:18:52.319 Oh, the impedance mismatch is severe. No dotchs is built 381 00:18:52.319 --> 00:18:55.279 on Google's v eight engine, which is highly optimized for 382 00:18:55.440 --> 00:18:58.759 javascripts single threaded asynchronous event loop. 383 00:18:58.640 --> 00:18:59.880 And Java doesn't work like that. 384 00:19:00.319 --> 00:19:04.720 No, the JVM handles threading entirely differently. Nayshorns simply didn't 385 00:19:04.759 --> 00:19:08.720 have the optimizations required to handle heavy, concurrent UI rendering 386 00:19:08.759 --> 00:19:10.200 at scale without choking. 387 00:19:10.319 --> 00:19:11.079 That makes sense. 388 00:19:11.440 --> 00:19:15.359 And beyond performance, there's the human element. Your operations team, 389 00:19:15.599 --> 00:19:18.839 who are experts at tuning JVM garbage collection and debugging 390 00:19:18.960 --> 00:19:23.000 Java memory leaks now have to learn entirely new troubleshooting 391 00:19:23.000 --> 00:19:26.599 paradigms for a production no dot JS environment. 392 00:19:26.799 --> 00:19:29.680 Yeah, if the site crashes at three am on Black Friday, 393 00:19:30.079 --> 00:19:33.200 your Java experts might be completely blind to what's causing 394 00:19:33.200 --> 00:19:36.319 the JavaScript render service to fail. That is a colossal 395 00:19:36.480 --> 00:19:37.119 business risk. 396 00:19:37.200 --> 00:19:38.839 It is It makes sense why it's not a blanket 397 00:19:38.880 --> 00:19:42.079 solution for everyone. If an application sits entirely behind a 398 00:19:42.160 --> 00:19:46.839 user loginscreen like an internal corporate dashboard, SEO is irrelevant. 399 00:19:46.880 --> 00:19:48.440 Google bot can't log in anyway. 400 00:19:48.599 --> 00:19:52.440 And if subsecond initial load times aren't mission critical Absorbing 401 00:19:52.440 --> 00:19:55.559