- 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.
- 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 Angular Universal team)
- 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:
The New “Isomorphic”
Instead, I believe the future is all about authoring 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:
- App Pages — Only client rendered with perhaps just an app shell on the server side. Focused on the best possible rich user experience.
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 the AMP specification. 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 ng-conf 2018 with my talk, Super-Powered, Server-Rendered Progressive Native Apps.