WEBVTT 1 00:00:00.120 --> 00:00:03.600 Picture this, right, You are at a flea market in 2 00:00:03.600 --> 00:00:06.120 New York City, just sort of wandering through the stalls, 3 00:00:06.160 --> 00:00:10.039 and you spot this incredible piece of art. 4 00:00:10.320 --> 00:00:13.080 Oh, I love a good flea market find. 5 00:00:12.919 --> 00:00:15.880 Right, So it's this eighteen oh two illustration of a 6 00:00:15.919 --> 00:00:19.280 woman from the Ottoman Empire, and you just you have 7 00:00:19.359 --> 00:00:21.399 to have it. But there's a catch. 8 00:00:21.480 --> 00:00:22.399 There's always a catch. 9 00:00:22.480 --> 00:00:25.480 Always. The seller's packing up, they're actually flying back to 10 00:00:25.519 --> 00:00:28.160 anchor of that very night. You don't have enough cash 11 00:00:28.199 --> 00:00:29.839 on you, and of course they can't take a card. 12 00:00:30.679 --> 00:00:31.440 So what do you do? 13 00:00:31.559 --> 00:00:33.439 I mean normally you just walk away. 14 00:00:33.359 --> 00:00:36.039 Right exactly, but not this time. You actually make a 15 00:00:36.119 --> 00:00:38.759 verbal agreement, seal it with a handshake, walk away with 16 00:00:38.799 --> 00:00:41.479 this priceless art under your arm, and you wire the 17 00:00:41.520 --> 00:00:43.280 money internationally the very next day. 18 00:00:43.799 --> 00:00:46.600 Wow. That is I mean, that is a massive leap 19 00:00:46.640 --> 00:00:47.039 of faith. 20 00:00:47.200 --> 00:00:51.159 It's totally wild, right, But that collision of old school 21 00:00:51.359 --> 00:00:55.119 analog trust and modern execution is exactly what we are 22 00:00:55.159 --> 00:00:56.880 unpacking today when it comes to software. 23 00:00:57.280 --> 00:01:00.320 Yeah, and that specific anecdote, funnily enough, is actually how 24 00:01:00.320 --> 00:01:03.240 the publisher acquired the physical cover art for the source 25 00:01:03.280 --> 00:01:05.319 material we're pulling from today, Yes. 26 00:01:06.040 --> 00:01:10.159 Which is this incredibly comprehensive engineering guide called Electron in 27 00:01:10.239 --> 00:01:13.719 Action by Steve Kenney. It was published by Manning. 28 00:01:13.799 --> 00:01:16.599 It's such a great book because we're basically looking at 29 00:01:16.640 --> 00:01:20.959 a technology that takes something incredibly established, you know, traditional 30 00:01:21.400 --> 00:01:23.680 native desktop applications. 31 00:01:23.159 --> 00:01:24.560 Old school stuff, right. 32 00:01:24.439 --> 00:01:28.400 And it completely rewires them using modern web technologies. And 33 00:01:28.640 --> 00:01:30.319 I mean, if you are listening to this deep dive 34 00:01:30.400 --> 00:01:33.519 right now, the odds are almost one hundred percent that 35 00:01:33.599 --> 00:01:35.879 you are already relying on this architect Oh. 36 00:01:35.879 --> 00:01:38.599 Absolutely, it's it's everywhere. Like if you use SLAG for 37 00:01:38.719 --> 00:01:41.959 work messaging, or maybe visual Studio code for programming, or 38 00:01:42.000 --> 00:01:44.920 even just the Brave browser for surfing the web, you 39 00:01:44.959 --> 00:01:45.959 are using Electron. 40 00:01:46.200 --> 00:01:48.959 Yeah. It is entirely hiding in planesight, it really is. 41 00:01:49.040 --> 00:01:52.319 And it represents this this fundamental shift in how we 42 00:01:52.400 --> 00:01:55.480 build for the desktop because for decades, you know, if 43 00:01:55.519 --> 00:01:58.000 you wanted to build a native desktop application, you were 44 00:01:58.040 --> 00:02:02.560 staring down this mass have totally fragmented engineering undertaking. 45 00:02:02.719 --> 00:02:05.280 Oh it was a nightmare. You couldn't just write one app. 46 00:02:05.359 --> 00:02:09.759 You had to learn entirely different programming languages and frameworks 47 00:02:09.840 --> 00:02:11.879 for every single operating system. 48 00:02:12.120 --> 00:02:14.680 Right, You'd need like C plus plus or maybe C 49 00:02:14.840 --> 00:02:18.400 sharp to target Windows machines, and then you'd have to 50 00:02:18.520 --> 00:02:21.439 completely pivot to objective C or Swift if you wanted 51 00:02:21.479 --> 00:02:22.800 to be on macOS, and. 52 00:02:22.800 --> 00:02:25.800 Then you might need a completely different toolkit like QT 53 00:02:26.039 --> 00:02:26.599 for Linux. 54 00:02:26.759 --> 00:02:30.360 Exactly, you're essentially funding and building the exact same application 55 00:02:30.479 --> 00:02:33.280 three separate times, which is I mean, it's an absolute 56 00:02:33.360 --> 00:02:36.280 nightmare for a solo developer or a startup. 57 00:02:35.919 --> 00:02:41.120 It's cost prohibitive. But Electron it bypasses that fragmentation entirely. 58 00:02:41.199 --> 00:02:43.439 It takes the holy trinity of web development. Right, So, 59 00:02:43.599 --> 00:02:45.960 HTMLCSS and JavaScript. 60 00:02:45.360 --> 00:02:47.680 This stuff everyone already knows exactly. 61 00:02:47.400 --> 00:02:50.240 And it allows engineers to use those exact same tools 62 00:02:50.280 --> 00:02:54.919 to build cross platform desktop applications from a single unified codebase. 63 00:02:55.280 --> 00:02:57.800 You write it once and it compiles to a native 64 00:02:57.800 --> 00:03:00.360 application for Mac Windows and Linux. 65 00:03:00.400 --> 00:03:04.159 Which is basically magic. And the sources outline this really 66 00:03:04.240 --> 00:03:08.280 helpful way to conceptualize this architectural shift. I kind of 67 00:03:08.280 --> 00:03:09.759 want to try tweaking an analogy here. 68 00:03:09.840 --> 00:03:11.039 If that's cool, Yeah, go for it. 69 00:03:11.360 --> 00:03:14.520 So, if you think about traditional web development, it relies 70 00:03:14.719 --> 00:03:18.759 entirely on a client server model, right. The user's browser 71 00:03:18.879 --> 00:03:21.599 is really just a lightweight storefront all the heavy lifting, 72 00:03:21.960 --> 00:03:25.199 the database, the file processing, all that business logic. It 73 00:03:25.240 --> 00:03:26.840 happens on a distant server, right. 74 00:03:26.719 --> 00:03:29.280 So the server is basically the kitchen, and the browser 75 00:03:29.360 --> 00:03:30.560 is just the dining room exactly. 76 00:03:30.599 --> 00:03:33.520 The browser is just where you eat. But if you 77 00:03:33.639 --> 00:03:36.360 lose your Internet connection, the road from the dining room 78 00:03:36.360 --> 00:03:39.280 to the kitchen is severed and the whole application just 79 00:03:39.479 --> 00:03:42.879 it breaks. You get the dinosaur game, right, But an 80 00:03:42.919 --> 00:03:48.039 Electron app fundamentally changes that architecture. Yeah, it is. It's 81 00:03:48.120 --> 00:03:50.439 more like a high end food truck pulling right up 82 00:03:50.479 --> 00:03:51.520 in your computer's driveway. 83 00:03:51.560 --> 00:03:52.199 Oh I like that. 84 00:03:52.400 --> 00:03:55.120 Yeah. It bundles the entire kitchen, like the whole back 85 00:03:55.199 --> 00:03:58.400 end processing run time, and installs it directly on your 86 00:03:58.439 --> 00:04:01.879 local hard drive right alongside the user interface. Everything required 87 00:04:01.879 --> 00:04:04.560 to run the application is just totally self contained. 88 00:04:04.840 --> 00:04:08.360 And you know, bundling that back end infrastructure locally that 89 00:04:08.520 --> 00:04:12.960 alters the entire security paradigm, which is honestly why Electron 90 00:04:13.039 --> 00:04:16.000 is so powerful. So well, think about when you visit 91 00:04:16.040 --> 00:04:21.160 a website in a traditional browser. That browser actively sandboxes 92 00:04:21.199 --> 00:04:25.680 the web application. It acts as this strict security perimeter. 93 00:04:25.399 --> 00:04:26.959 Right because it doesn't trust the code. 94 00:04:26.920 --> 00:04:29.480 Exactly, It assumes the code it just downloaded from a 95 00:04:29.560 --> 00:04:33.959 random server is potentially hostile, so that browser explicitly blocks 96 00:04:34.000 --> 00:04:37.199 the web app from reading your local file system, or 97 00:04:37.240 --> 00:04:40.519 modifying your operating system menus, or running background processes. 98 00:04:40.560 --> 00:04:43.839 But because an electron app is downloaded and explicitly installed 99 00:04:43.839 --> 00:04:48.040 by the user, it completely bypasses that web sandbo That is. 100 00:04:47.959 --> 00:04:50.839 The key mechanism. Yeah, by running an installer, the user 101 00:04:50.879 --> 00:04:55.199 actively grants the application elevated native privileges. Yeah, the operating 102 00:04:55.240 --> 00:04:57.639 system basically treats the exact same way it treats a 103 00:04:57.720 --> 00:05:01.839 native C plus plus application. So the web code inside 104 00:05:01.839 --> 00:05:04.439 the electron shell is suddenly allowed to read and write 105 00:05:04.439 --> 00:05:09.480 local files, interact with USB devices, and function perfectly without 106 00:05:09.480 --> 00:05:10.360 a network connection. 107 00:05:10.600 --> 00:05:14.120 That is wild, and the text highlights some really crazy 108 00:05:14.680 --> 00:05:19.240 real world examples of teams leveraging this, like Facebook built 109 00:05:19.240 --> 00:05:22.879 an entire development environment called new clide with it, and 110 00:05:22.959 --> 00:05:26.560 a company called Nihilis built this really heavy duty email client. 111 00:05:26.959 --> 00:05:29.879 But the most striking example of that offline capability comes 112 00:05:29.920 --> 00:05:31.480 from an agency called Wiredcraft. 113 00:05:31.639 --> 00:05:33.279 Oh, the Me and Mar project. 114 00:05:33.560 --> 00:05:36.040 Yeah, they needed to build an application to collect voter 115 00:05:36.120 --> 00:05:38.319 registration data all across me and Mar. 116 00:05:38.199 --> 00:05:42.279 Which is a region where relying on continuous Internet connectivity, 117 00:05:42.319 --> 00:05:43.800 which is entirely unfeasible. 118 00:05:43.959 --> 00:05:47.079 Yes, a traditional web app would be completely useless the 119 00:05:47.079 --> 00:05:50.920 moment the connection dropped. But by using Electron, Wiredcraft was 120 00:05:50.959 --> 00:05:53.279 able to use standard web developers to build a robust 121 00:05:53.319 --> 00:05:54.759 Windows application. 122 00:05:54.560 --> 00:05:57.160 And it stored all that data locally right exactly. 123 00:05:57.319 --> 00:05:59.759 Its stored all the voter data locally on the machine's 124 00:05:59.759 --> 00:06:02.680 hard and then it would automatically sync with the central 125 00:06:02.720 --> 00:06:05.639 server whenever a network connection finally became available. 126 00:06:05.720 --> 00:06:06.519 That's brilliant. 127 00:06:06.639 --> 00:06:10.000 They achieved native offline stability and they didn't even need 128 00:06:10.040 --> 00:06:13.639 to hire a specialized team of plus Windows engineers to 129 00:06:13.680 --> 00:06:13.959 do it. 130 00:06:14.600 --> 00:06:17.959 Now, it is definitely worth mentioning that Electron wasn't actually 131 00:06:18.000 --> 00:06:20.759 the first framework to attempt this hybrid approach. 132 00:06:20.879 --> 00:06:22.319 Oh right, there was an older one. 133 00:06:22.439 --> 00:06:26.399 Yeah, it had a predecessor called NWJS, which some older 134 00:06:26.439 --> 00:06:30.839 developers might remember as Node WebKit, but Electron eventually overtook 135 00:06:30.839 --> 00:06:34.000 it as the absolute industry standard, mostly due to a 136 00:06:34.000 --> 00:06:36.040 few critical architectural choices. 137 00:06:36.680 --> 00:06:40.920 So what specifically made the industry pivot to Electron over 138 00:06:41.040 --> 00:06:44.399 NWJS Again? Why did NWJS lose out? 139 00:06:44.600 --> 00:06:47.319 The primary difference really lies in how they handled the 140 00:06:47.399 --> 00:06:51.920 underlying browser engine. NWJS used a heavily customized, forked version 141 00:06:51.959 --> 00:06:52.920 of the Chromium engine. 142 00:06:53.000 --> 00:06:55.600 Okay, and four king is generally a headache, Yeah. 143 00:06:55.360 --> 00:06:59.399 A massive headache. It meant every single time Google released 144 00:06:59.399 --> 00:07:02.720 a new version of Chromium, the NWGS team had to 145 00:07:02.800 --> 00:07:05.839 manually port all of their custom modifications over to the 146 00:07:05.879 --> 00:07:08.560 new version. It just caused massive. 147 00:07:08.160 --> 00:07:10.240 Delays, so they were always lagging behind. 148 00:07:10.319 --> 00:07:16.600 Always. Electron conversely, relies on an completely unmodified standard release 149 00:07:16.639 --> 00:07:20.199 of Chromium. Because they don't fork the engine, Electron can 150 00:07:20.360 --> 00:07:24.279 rapidly update to the latest browser standards, sometimes within days 151 00:07:24.279 --> 00:07:25.399 of a new release. 152 00:07:25.240 --> 00:07:28.399 So developers always have access to the absolute bleeding edge 153 00:07:28.480 --> 00:07:29.399 JavaScript futures. 154 00:07:29.439 --> 00:07:33.000 Precisely, and beyond that, NWGS shared a single back end 155 00:07:33.040 --> 00:07:35.959 process across every single window of the application, so if 156 00:07:36.000 --> 00:07:38.439 one window crash, the whole thing goes down, the entire 157 00:07:38.480 --> 00:07:42.480 application came down. But Electron enforces a strict separation of processes, 158 00:07:42.519 --> 00:07:46.240 which creates a much more stable, resilient architecture. You add 159 00:07:46.240 --> 00:07:49.279 in built in crash reporting and automated background updating, and 160 00:07:49.519 --> 00:07:53.360 well it becomes pretty obvious why enterprise teams adopted it 161 00:07:53.399 --> 00:07:53.920 so quickly. 162 00:07:54.079 --> 00:07:56.560 Okay, so you just mentioned Chromium, which perfectly sets up 163 00:07:56.560 --> 00:07:59.680 our next step here. To really understand how this local 164 00:07:59.720 --> 00:08:02.040 food truck operates, we need to lift the hood. 165 00:08:02.199 --> 00:08:02.720 Let's do it. 166 00:08:02.879 --> 00:08:07.720 Electron achieves this by taking two massive, fundamentally different engineering 167 00:08:07.720 --> 00:08:11.759 engines and just sort of bridging them together, the Chromium 168 00:08:11.839 --> 00:08:14.680 content module and no JS. 169 00:08:15.199 --> 00:08:18.920 It is an incredibly ambitious fusion. The Chromium content module 170 00:08:19.000 --> 00:08:22.680 is responsible for parsing your HTML and CSS and actually 171 00:08:22.720 --> 00:08:24.519 rendering it into a visual interface. 172 00:08:24.720 --> 00:08:26.600 Right, and my understanding for the text is that the 173 00:08:26.680 --> 00:08:30.439 content modules essentially the core rendering engine of Google Chrome, right, 174 00:08:30.839 --> 00:08:34.120 like the blank rendering pipeline and the v eight JavaScript engine, 175 00:08:34.519 --> 00:08:37.159 but without any of the actual Chrome browser wrapped around it. 176 00:08:37.279 --> 00:08:39.799 That is a crucial distinction. It's basically the engine of 177 00:08:39.840 --> 00:08:42.879 the car minus the leather seats in the stereo. You 178 00:08:42.919 --> 00:08:46.799 get the world class rendering capabilities. But Electron completely strips 179 00:08:46.840 --> 00:08:49.240 out all the consumer blow So no extensions, right. There 180 00:08:49.240 --> 00:08:53.440 are no chromostensions, no bookmark syncting, no built in password managers, 181 00:08:53.919 --> 00:08:57.279 and no PDF fewers. It is just the raw engine 182 00:08:57.320 --> 00:08:59.440 required to turn code into pixels. 183 00:08:59.759 --> 00:09:02.559 But I do have a question about that, because even 184 00:09:02.559 --> 00:09:06.600 stripped down bundling an entire Chromium rendering engine inside every 185 00:09:06.600 --> 00:09:10.240 single desktop app. That seems like a massive resource overhead. 186 00:09:10.320 --> 00:09:11.120 It's definitely heavy. 187 00:09:11.200 --> 00:09:15.320 Yeah, So why wouldn't Electron just use whatever default browser 188 00:09:15.519 --> 00:09:18.399 the user already has installed on their machine to render 189 00:09:18.399 --> 00:09:21.879 the interface? Like, why not just use their local Safari 190 00:09:21.919 --> 00:09:22.600 your edge. 191 00:09:22.879 --> 00:09:24.879 That's a great question, and it really comes down to 192 00:09:24.919 --> 00:09:26.360 the concept of determinism. 193 00:09:26.519 --> 00:09:28.120 Okay, determinist Right in. 194 00:09:28.080 --> 00:09:30.399 Traditional web development, you build a site and you kind 195 00:09:30.399 --> 00:09:32.879 of just cross your fingers hoping it looks the same 196 00:09:33.120 --> 00:09:36.320 on a user's totally outdated version of Safari as it 197 00:09:36.480 --> 00:09:39.480 does on like a brand new version of Firefox. 198 00:09:39.519 --> 00:09:41.879 Oh, the cross browser compatibility nightmare. 199 00:09:41.679 --> 00:09:45.360 Exactly, it's awful. But by bundling a specific, hard coded 200 00:09:45.440 --> 00:09:49.639 version of Chromium directly inside the application, the developer guarantees 201 00:09:49.679 --> 00:09:54.279 a perfectly deterministic environment. They know exactly which CSS features 202 00:09:54.320 --> 00:09:57.639 are supported, they know exactly how the rendering pipeline behaves. 203 00:09:58.039 --> 00:10:02.120 It completely eliminates the nightmare of cross browser compatibility testing. 204 00:10:02.399 --> 00:10:04.000 Oh, that makes a lot of sense. You just bypass 205 00:10:04.039 --> 00:10:07.759 the guesswork entirely. So you pair that highly predictable visual 206 00:10:07.759 --> 00:10:10.600 engine with no JS, which is traditionally a server side 207 00:10:10.639 --> 00:10:13.399 JavaScript run time. Yes, and Node is the piece that 208 00:10:13.440 --> 00:10:16.759 provides the low level system access. So you have the 209 00:10:16.759 --> 00:10:20.720 beautiful UI of Chromium essentially holding hands with the raw 210 00:10:20.720 --> 00:10:22.080 filesystem power of Node. 211 00:10:22.159 --> 00:10:24.279 And to keep those two engines from just stepping all 212 00:10:24.320 --> 00:10:28.879 over each other's toes, Electron mandates a very strict process architecture. 213 00:10:29.799 --> 00:10:33.559 In every Electron application, there is exactly one main process, 214 00:10:33.720 --> 00:10:37.279 just one, just one, and this process runs purely in 215 00:10:37.320 --> 00:10:40.799 no JS. It remains entirely invisible to the user. Its 216 00:10:40.879 --> 00:10:43.720 sole job is to manage the application life cycle, handle 217 00:10:43.759 --> 00:10:46.840 operating system integration, and sort of orchestrate things like native 218 00:10:46.840 --> 00:10:48.879 application menus and system tree icons. 219 00:10:49.039 --> 00:10:51.360 So the main process is basically the puppet. 220 00:10:50.960 --> 00:10:54.200 Master, yes, exactly, and that single main process can then 221 00:10:54.240 --> 00:10:57.919 spawn zero or more render processes. These are created using 222 00:10:57.919 --> 00:11:01.360 an Electron module called browser window. Okay, and each renderer 223 00:11:01.399 --> 00:11:04.440 process is an isolated instance of Chromium that displays an 224 00:11:04.440 --> 00:11:06.200 actual window on the user's screen. 225 00:11:06.440 --> 00:11:08.360 Okay, let's unpack this for a second, because I want 226 00:11:08.360 --> 00:11:10.799 to push back on something that sources detail about these 227 00:11:10.879 --> 00:11:12.000 renderer processes. 228 00:11:12.080 --> 00:11:12.399 Sure. 229 00:11:12.600 --> 00:11:17.000 The text notes that inside these UI windows, developers can 230 00:11:17.080 --> 00:11:21.600 use the modern fetch API to ping third party servers directly, right, 231 00:11:22.200 --> 00:11:25.240 they can scrape data from remote websites without routing the 232 00:11:25.279 --> 00:11:27.200 requests through their own proxy server. 233 00:11:27.279 --> 00:11:28.279 They absolutely can. 234 00:11:28.399 --> 00:11:32.720 Well wait, doesn't that fundamentally bypass cross origin resource sharing 235 00:11:32.840 --> 00:11:37.679 or cores, I mean, preventing a webscript from silently pinging 236 00:11:37.840 --> 00:11:42.399 unverified external servers is like the foundational security policy of 237 00:11:42.399 --> 00:11:45.360 the modern web. If Electron just turns off cores and 238 00:11:45.440 --> 00:11:48.000 lets client side JavaScript do whatever it wants, isn't that 239 00:11:48.039 --> 00:11:49.600 a massive vulnerability? 240 00:11:49.679 --> 00:11:52.159 What's fascinating here is that it sounds alarming if you 241 00:11:52.240 --> 00:11:53.919 view it through the lens of a web browser, but 242 00:11:53.960 --> 00:11:56.399 you really have to shift your context to the desktop. 243 00:11:56.759 --> 00:11:58.440 This goes entirely back to user. 244 00:11:58.200 --> 00:11:59.600 Agency user agency. Right. 245 00:12:00.039 --> 00:12:02.200 Visiting a URL is a passive action. You click a 246 00:12:02.279 --> 00:12:04.679 link on a random forum and code starts executing on 247 00:12:04.720 --> 00:12:07.480 your machine instantly. The web browser has to assume that 248 00:12:07.519 --> 00:12:10.759 code is hostile, so it enforces cores to prevent data. 249 00:12:10.559 --> 00:12:12.879 Theft because you didn't ask it to do anything other 250 00:12:12.919 --> 00:12:13.519 than load. 251 00:12:13.360 --> 00:12:17.679 A page exactly. But installing a desktop application is an active, 252 00:12:18.080 --> 00:12:19.200 deliberate choice. 253 00:12:19.440 --> 00:12:22.720 Ah, So by installing it, you are basically signing a 254 00:12:22.759 --> 00:12:23.679 contract of trust. 255 00:12:23.840 --> 00:12:28.120 Precisely, you are granting that software native authority. If a 256 00:12:28.159 --> 00:12:33.159 developer writes a malicious native C plus plus application designed 257 00:12:33.159 --> 00:12:36.960 to secretly ping a remote server, the operating system allows it. 258 00:12:37.519 --> 00:12:41.559 Electron simply gives web developers that identical native capability. 259 00:12:41.639 --> 00:12:43.320 So it's not a bug, it's a feature. 260 00:12:43.519 --> 00:12:46.159 Right. The application is no longer operating in the public 261 00:12:46.200 --> 00:12:49.480 sandbox of the Internet. It is an installed piece of software. 262 00:12:49.840 --> 00:12:52.600 It basically removes the training wheels and hands the developer 263 00:12:52.679 --> 00:12:53.919 the keys to the engine. 264 00:12:54.080 --> 00:12:57.399 Okay, we are officially out of the sandbox, so let's 265 00:12:57.399 --> 00:13:01.320 look at how this architectural shift radically simplifies building an 266 00:13:01.320 --> 00:13:05.639 actual application. The text walks through constructing this starter project 267 00:13:05.639 --> 00:13:06.559 called Bookmarker. 268 00:13:06.639 --> 00:13:08.759 Oh, the bookmarker app. Yeah, that's a great example. 269 00:13:08.879 --> 00:13:11.600 Yeah. The premise is pretty straightforward. The user pastes a 270 00:13:11.840 --> 00:13:14.759 URL into a text field, the application fetches the title 271 00:13:14.759 --> 00:13:17.039 of that remote web page, and it just says it 272 00:13:17.039 --> 00:13:17.559 to a list. 273 00:13:17.840 --> 00:13:21.279 And this project perfectly highlights the advantage of that deterministic 274 00:13:21.320 --> 00:13:24.960 Chromium engine we discussed earlier. Because the developer knows exactly 275 00:13:25.120 --> 00:13:27.519 which version of V eight is running, they don't need 276 00:13:27.559 --> 00:13:31.600 to write any legacy fallback code for Internet. 277 00:13:31.159 --> 00:13:33.720 Explorer eleven Oh, thank goodness. 278 00:13:33.799 --> 00:13:36.679 Right, they can rely heavily on modern JavaScript standards. 279 00:13:36.799 --> 00:13:39.960 Right. So the application takes the URL, uses the fetch 280 00:13:40.000 --> 00:13:43.279 API to ping the target server directly from the client side, 281 00:13:43.600 --> 00:13:48.240 and downloads the raw HTML string of the remote site. Now, normally, 282 00:13:48.279 --> 00:13:51.440 if you have a massive string of raw eachtmail, you 283 00:13:51.519 --> 00:13:53.799 need a pretty hefty third party library to parse through 284 00:13:53.840 --> 00:13:55.440 it and find the specific data you want. Right. 285 00:13:55.519 --> 00:13:57.840 You definitely would if you were operating purely in a 286 00:13:57.919 --> 00:14:00.960 node back end. But because this code is actually running 287 00:14:01.000 --> 00:14:04.559 inside a Chromium renderer process, the developer has access to 288 00:14:04.679 --> 00:14:08.120 native browser APIs, so they can simply hand that raw 289 00:14:08.279 --> 00:14:11.399 HTML string directly to the built in DOM parser object. 290 00:14:11.799 --> 00:14:15.240 It instantly converts the text into a fully traversible object tree, 291 00:14:15.600 --> 00:14:18.320 allowing them to extract the title tag with a single line, 292 00:14:18.360 --> 00:14:20.559 a standard DOM manipulation. 293 00:14:20.279 --> 00:14:23.960 That is incredibly elegant. And then to make sure the 294 00:14:24.039 --> 00:14:27.440 data actually survives when the user quits the application or 295 00:14:27.480 --> 00:14:31.480 reboots their computer, Bookmarker simply saves the list of links 296 00:14:32.159 --> 00:14:36.120 using the browser's standard local storage API. No complex SQL 297 00:14:36.159 --> 00:14:39.480 database required at all, None at all. But I love 298 00:14:39.519 --> 00:14:41.919 this part of the text points out a really funny 299 00:14:42.039 --> 00:14:45.000 practical trap that developers always fall into when they are 300 00:14:45.000 --> 00:14:46.519 building their first Electron app. 301 00:14:46.600 --> 00:14:50.399 Yes, the unintended navigation trap. It gets everyone, it's so funny. 302 00:14:50.519 --> 00:14:53.120 So what does this all mean? When the user actually 303 00:14:53.440 --> 00:14:56.720 clicks the saved link inside our app? Like the app 304 00:14:56.799 --> 00:14:59.159 is working perfectly, the user has a beautiful list of 305 00:14:59.200 --> 00:15:01.200 save links. What happens when they click one? 306 00:15:01.320 --> 00:15:04.840 Well, because the renderer process is fundamentally just a Chromium browser, 307 00:15:05.200 --> 00:15:08.200 it reacts exactly how a browser is programmed to react. 308 00:15:08.440 --> 00:15:11.720 When a hyperlink is clicked, it immediately navigates the current 309 00:15:11.759 --> 00:15:13.360 window to that new URL. 310 00:15:13.159 --> 00:15:16.279 Which sounds totally fine until you realize, Yeah, our custom 311 00:15:16.320 --> 00:15:18.879 Electron app doesn't have a back button, it doesn't have 312 00:15:18.919 --> 00:15:22.120 an address bar. So the user clicks their saved article, 313 00:15:22.399 --> 00:15:26.120 the UI just disappears, the web page loads, and they 314 00:15:26.120 --> 00:15:30.000 are completely trapped inside that site. The only way out 315 00:15:30.039 --> 00:15:33.919 is to actually force quit the entire application and relaunch it. 316 00:15:33.919 --> 00:15:37.039 It is a perfect example of the mindset shift required 317 00:15:37.080 --> 00:15:40.799 for Electron. You have to constantly remember you aren't building 318 00:15:40.799 --> 00:15:44.360 a website, You're building native software that just happens to 319 00:15:44.480 --> 00:15:46.799 use web rendering, So how do you fix it? To 320 00:15:46.879 --> 00:15:51.039 fix this, developers utilize an Electron module called shell, and. 321 00:15:51.039 --> 00:15:54.039 The logic here is brilliant. Instead of letting the click 322 00:15:54.159 --> 00:15:58.120 execute normally, the developer writes an event listener to intercept 323 00:15:58.120 --> 00:16:01.679 the click. They grab the URL, prevent the default navigation, 324 00:16:02.000 --> 00:16:04.480 and then pass the URL to a command called shell 325 00:16:04.559 --> 00:16:05.960 dot open external Yeah. 326 00:16:06.039 --> 00:16:08.919 That command takes the request and basically bridges the gap 327 00:16:08.919 --> 00:16:11.679 between the web app and the operating system. It asks 328 00:16:11.720 --> 00:16:15.480 thes hey, what is the user's globally preferred application for 329 00:16:15.519 --> 00:16:16.559 handling weblinks? 330 00:16:16.600 --> 00:16:19.480 So it's asking the computer, not the app exactly. 331 00:16:20.039 --> 00:16:22.840 The operating system then intercepts the intent and launches the 332 00:16:22.879 --> 00:16:26.200 link in the user's actual external browser, whether that is Safari, 333 00:16:26.399 --> 00:16:27.440 Edge or Firefox. 334 00:16:27.799 --> 00:16:32.519 It hands the URL back to the native ecosystem. That's 335 00:16:32.519 --> 00:16:36.600 so smart now. Bookmarker proves you can bypass network restrictions 336 00:16:36.639 --> 00:16:41.159 and handle data natively. But a floating box of text 337 00:16:41.679 --> 00:16:44.320 doesn't really feel like true desktop software. 338 00:16:44.440 --> 00:16:46.039 No, it still feels a bit like a widget. 339 00:16:46.279 --> 00:16:49.720 Right. To truly replace traditional applications, the UI needs to 340 00:16:49.759 --> 00:16:53.480 seamlessly mimic the host operating system, and that leads us 341 00:16:53.519 --> 00:16:56.840 to the next, much more sophisticated project in the source text, 342 00:16:56.879 --> 00:17:00.399 which is a markdown text editor called firesaleire Cell. 343 00:17:00.320 --> 00:17:02.879 Is an excellent case study in UI integration. It features 344 00:17:02.879 --> 00:17:06.319 this dual pain interface. The user type's raw markdown formatting 345 00:17:06.359 --> 00:17:09.400 on the left PAIN, and the application instantly renders it 346 00:17:09.440 --> 00:17:12.680 as formatted HTML on the right PAIN using a library 347 00:17:12.720 --> 00:17:13.359 called marked. 348 00:17:13.640 --> 00:17:16.720 Structurally balancing those two columns is pretty trivial because the 349 00:17:16.759 --> 00:17:20.559 developer can just use modern CSS flexbox without I'm constantly 350 00:17:20.599 --> 00:17:21.720 worrying about browser support. 351 00:17:21.839 --> 00:17:23.839 Yeah, the determinism strikes again exactly. 352 00:17:24.160 --> 00:17:26.720 But where the source material gets truly fascinating is the 353 00:17:26.759 --> 00:17:30.119 specific CSS techniques used to actively disguise the fact that 354 00:17:30.160 --> 00:17:31.640 the interface is built with HTML. 355 00:17:31.680 --> 00:17:34.880 Well, the typography integration is a total standout technique. 356 00:17:34.480 --> 00:17:36.799 It really is. Yeah, because if you just define a 357 00:17:36.839 --> 00:17:41.839 standard web font stack like Aerial or Helvetica, the application 358 00:17:41.920 --> 00:17:45.680 will always look slightly foreign on a modern operating system, 359 00:17:45.920 --> 00:17:49.039 it won't match the surrounding system menus. So instead the 360 00:17:49.079 --> 00:17:53.640 developer applies a specific CSS declaration dot font menu. 361 00:17:53.920 --> 00:17:56.559 And what makes that so powerful is that it isn't 362 00:17:56.640 --> 00:17:59.920 just a static fun assignment. It's actually a dynamic queer. 363 00:18:00.359 --> 00:18:00.640 Really. 364 00:18:00.799 --> 00:18:04.240 Yeah. When Chromium reads font dot menu, it reaches out 365 00:18:04.279 --> 00:18:07.240 to the underlying operating system's UI layer and asks what 366 00:18:07.440 --> 00:18:11.079 is the currently active system font? So on macOS, it 367 00:18:11.119 --> 00:18:15.440 instantly inherits Apple's San Francisco font. On Windows, it pulls 368 00:18:15.559 --> 00:18:16.400 Cego UI. 369 00:18:16.640 --> 00:18:17.680 That's amazing, it is. 370 00:18:17.759 --> 00:18:20.640 The text rendering completely bridges the gap between web CSS 371 00:18:20.680 --> 00:18:23.119 and the native C plus plus rendering of the OS. 372 00:18:23.400 --> 00:18:26.480 The developer also tackles focus outlines in this project, which 373 00:18:26.480 --> 00:18:29.039 is another huge tell. In a normal web browser, when 374 00:18:29.079 --> 00:18:31.640 you click into an input field, usually get this glowing 375 00:18:31.680 --> 00:18:34.000 blue ring around the box to show that it's active. 376 00:18:33.839 --> 00:18:37.839 Right, which is vital for web accessibility. But native desktop 377 00:18:37.880 --> 00:18:39.359 text editors don't really do that. 378 00:18:39.720 --> 00:18:43.359 No, they don't. So by explicitly overriding that default web 379 00:18:43.359 --> 00:18:46.920 behavior in the CSS, the application stops looking like a 380 00:18:46.920 --> 00:18:49.480 web form and really starts feeling like a standalone tool. 381 00:18:49.599 --> 00:18:52.920 But the most crucial polished technique discussed in the text 382 00:18:52.960 --> 00:18:57.720 addresses a deeply ingrained psychological cueue, which is the white flash. 383 00:18:57.880 --> 00:19:01.319 Oh yes, this solves something that has annoyed me for years. 384 00:19:01.920 --> 00:19:06.160 Whenever you launch a heavy web wrapped desktop application, you 385 00:19:06.279 --> 00:19:12.279 often get this jarring, blinding white screen for a fraction 386 00:19:12.359 --> 00:19:14.920 of a second before the dom actually loads and paints 387 00:19:14.960 --> 00:19:15.440 the interface. 388 00:19:15.559 --> 00:19:17.759 It completely shatters the illusion, right it really does. 389 00:19:17.799 --> 00:19:20.720 It screams, hey, I am a slow website trying to load. 390 00:19:20.839 --> 00:19:23.640 It is an absolute dead giveaway of the underlying technology, 391 00:19:23.720 --> 00:19:26.680 but the solution provided by electrons life cycle events is 392 00:19:26.680 --> 00:19:30.160 incredibly elegant. When the main process executes the node code 393 00:19:30.160 --> 00:19:33.240 to construct the browser window, the developer simply passes a 394 00:19:33.279 --> 00:19:36.000 configuration property dot show false, so. 395 00:19:35.960 --> 00:19:38.799 The chromium window is actually spawned in the system memory, 396 00:19:39.039 --> 00:19:41.079 but it remains completely invisible to the user. 397 00:19:41.400 --> 00:19:43.920 Correct the application is given the time it needs to 398 00:19:44.000 --> 00:19:48.079 parse the HTML, execute the CSS, and fully render the 399 00:19:48.160 --> 00:19:51.640 dawn tree entirely in the background. Meanwhile, the developer sets 400 00:19:51.720 --> 00:19:54.400 up a listener for a specific life cycle event called 401 00:19:54.480 --> 00:19:57.319