Isomorphic JavaScript is Dead… Long Live Isomorphic JavaScript!

This video was me just 2 years ago at ng-conf talking about how Isomorphic JavaScript was going to take the world by fire. At that time, the idea of duplicating code in two places (i.e. once on the server for search engines and another on the client for rich user interfaces) made me sick. rules! DRY Well…a lot has happened since then. Specifically, a few specific things have drastically affected the way I view the concept of Isomorphic JavaScript: I had to grow and maintain a large codebase over time. In many cases the “tricks” I used to make my code “Isomorphic” ended up causing more problems than they solved. My team grew much larger and I began to realize that training someone to understand the subtleties of Isomorphic JavaScript development was nontrivial (and extremely prone to error). The pace of shipping product features within my team grew exponentially. I eventually realized that ultra-DRY code often created tight dependencies that actually prevent fast iteration cycles (i.e. you can’t change one piece of code quickly for fear of adversely affecting many other dependent pieces of code) Much better server rendering solutions came around (including one that I helped build as part of the team) Angular Universal Trying to optimize for BOTH initial load performance and content reading versus long lived usage and rich interfaces is…well, frankly, impossible. Sure, you can sort of do an OK job at both, but they are very much at odds for when you want to have the absolute best possible experience. I talk a little about all of this in one of my latest talks on code management at AngularConnect: For all of these reasons, I truly believe that Isomorphic JavaScript is dead. Well…at the very least the concept of Isomorphic JavaScript where you could just take an app build for the client and then just let it magically work on the server. I don’t buy into that at all anymore. The New “Isomorphic” Instead, I believe the future is all about your platform-specific code in one place (i.e. you can have your SEO code together with your rich client code in the same repo), but then having different parts of your app specialized for only one or the other. In other words: authoring — Only server rendered with little to no client side JavaScript. Focused on maximum initial load performance and content delivery. Landing Pages — Only client rendered with perhaps just an app shell on the server side. Focused on the best possible rich user experience. App Pages These two can live on the same domain with the same website (and in many cases should). For example, check out the page on GetHuman.com. It is only server rendered with no client side JavaScript. However, if you click on a link (for example, the “Skip Waiting on Hold Button”) you will start to interact with a series of pages that are client loaded and have some rich features. United Airlines Phone Number Final Word on AMP Oh, and one more thing…when you start to go down this path there is an added bonus. The server-only landing pages you create should be very close to . It shouldn’t take you too much work to “AMPify” you pages which should yield even more benefits for the user experience during initial load. I am going to be talking a lot more about this at with my talk, . the AMP specification ng-conf 2018 Super-Powered, Server-Rendered Progressive Native Apps