Server side state in http is a wonderful thing to abuse.<p>One adserving system I worked on had a very expensive correlation process where it joined auction stats with impression stats. Essentially a big Hadoop job, except run in a stream.<p>Another system I later worked on solved the problem by tying impression requests back to the same server that ran the auction. That server kept the auction data in memory until it either received the impression or until a set amount of time had passed.<p>Hearing how it worked made me feel a bit dirty, then I realized how much money it saved them to do it that way and I was impressed with the simplicity of it.
For applications that have extremely fast server response times, it seems simpler to just send the HTML, keep JavaScript to the minimum and use prefetching for likely next clicks to ensure the next response is cached.<p>This site is fast, without PRPL.
Here's me complaining again that the first few sentences/paragraphs/section don't provide any useful information for me as a new user and I skipped right over them. Who are those words for? They sounds like a project proposal.
It was quite ironic to see the Google IO 2016 presentations about patterns how to make web apps approximate native apps in regards to UI/UX, with the presenters throwing jabs at mobile development, while the Google Android teams were presenting all the goodies about Android development on other rooms, just by using the platform.
It's missing a "P" – it should be "PPRPL":<p><i>Prerender</i>, Push, Render, Pre-cache, Lazy-load<p>But of course Polymer doesn't do prerender, so it doesn't fit the Google's image.<p>It really bugs me that you'll have to load and parse a huge amount of code to get anything rendered on the screen with Polymer.
<i>For most real-world projects, it’s frankly too early to realize the PRPL vision in its purest, most complete form – but it’s definitely not too early to adopt the mindset, or to start chasing the vision from various angles.</i><p>This reminded me of the "worse is better" essay, because it sounds very much like the perfectionist "MIT approach".<p><a href="https://www.jwz.org/doc/worse-is-better.html" rel="nofollow">https://www.jwz.org/doc/worse-is-better.html</a><p>I personally prefer an emphasis on simplicity over perfection, especially when simplicity means you actually get working code. Is there any sample app around that obeys the PRPL pattern and is a good example to start from?
I feel that this isn't so much a 'new pattern' as just an elaboration on 'pre-load stuff you know you'll need', which again isn't so much a pattern as just being common sense.
Has some overlap with the architecture that FlipKart used for FlipKart Lite, at least from my understanding of the article:<p><a href="https://medium.com/@boopathi/flipkart-lite-the-how-f6eb311dc943" rel="nofollow">https://medium.com/@boopathi/flipkart-lite-the-how-f6eb311dc...</a><p><a href="http://tech-blog.flipkart.net/2015/11/progressive-web-app/" rel="nofollow">http://tech-blog.flipkart.net/2015/11/progressive-web-app/</a>
I <i>love</i> this pattern. I've been studying web performance for a while in the context of working on my project Gatsby [0] — a React.js static site generator. The next version of Gatsby is explicitly patterned after PRPL.<p>Gatsby at build time generates a static HTML version of each page. Which makes the initial load time of a Gatsby site super fast. The browser then loads the minimum Javascript necessary to make that page interactive. Then in a service worker, it starts prefetching Javascript and data necessary for other pages so that when you click on a link, it takes very little time to fetch the code/data and then make the page transition.<p>A couple sites running 1.0 code that you can check out are my blog <a href="https://www.bricolage.io/" rel="nofollow">https://www.bricolage.io/</a> and an example site cloned from Instagram <a href="https://gatsbygram.gatsbyjs.org/" rel="nofollow">https://gatsbygram.gatsbyjs.org/</a><p>I wrote up the performance plans for Gatsby in this issue [1].<p>One analogy I came up for that which I really like is to JIT or lean manufacturing.<p>Quoting myself:<p>"There's a close analogy to just-in-time manufacturing ideas. Companies found that the way to be the most responsive to customers is to actually avoid doing work ahead of time. When they did do work ahead of time this would paradoxically slow them down as the speculative work would get in the way of getting the work done that's actually necessary (resource contention).<p>For both manufacturing and web apps there's high inventory cost (unused code takes up memory) and a premium on responsiveness. The car customer wants their new car yesterday and the web app consumer wants their app running immediately. Any work you do ahead of time because "they might need it" gets in the way of the app being responsive to the user.<p>With both you want to wait until the user asks for something and then work overtime to get it to them as fast as possible."<p>[0] <a href="https://github.com/gatsbyjs/gatsby" rel="nofollow">https://github.com/gatsbyjs/gatsby</a>
[1] <a href="https://github.com/gatsbyjs/gatsby/issues/431" rel="nofollow">https://github.com/gatsbyjs/gatsby/issues/431</a>