Recently, have been learning Vue and, as always, learning-by-doing, which means writing code for real-world applications. In this process, I have learned something that is not really mentioned in the majority of online Vue tutorials.

Basically, when you create a Vue instance in your browser, you bind that Vue instance to a root DOM element. This means that everything you do within a Vue instance stays in that same Vue instance. In other words, to move information between two or more Vue instances running in your browser, you need an interprocess communication (IPC) in your browser. Also, when you load another page, the Vue instances in your prior page are destroyed, so state is not maintained when a Vue process closes and a new Vue process is created.

This is perfectly fine, of course; and what I discovered was the same thing that others before me have discovered: We generally use cookies, localStorage, or sessionStorage in the browser as a kind of primitive IPC. I guess you could consider this a kind of file system IPC (but not really), where each process running in the browser has access to data stored on the disk by the browser.

I have not found any additional IPCs available for interprocess communications in the browser (if you have, please post in reply and tell me). All the web frameworks I have reviewed run in their own sandbox, so to speak; and all of these frameworks require browser-based cookies, localStorage or sessionStorage to share persistant information between browser processes, or to be accessible to the user when they close and then open their browser again.

This also means that reactive Javascript frameworks like Vue are really designed to shine in reactive web SPAs (single page applications). In these apps, when you bind a Vue instance to a DOM root element, you can manage state as long as the page is not closed or reloaded.

What does this mean?

Well for starters, a "progressive web app" using Vue is one where you take your legacy web app, like ours here at unix.com, and add Vue SPA features. However, because legacy sites like unix.com are mostly build on a synchronous web model which is not SPA and each new area of the site is a page which tends to be reloaded, this make retrofitting to a modern framework like Vue challenging, to say the least.

On thing is for sure, applications like vBulletin and other CMS which use a legacy (old fashioned) synchronous web design architecture are losing popularity while reactive SPA apps are on the rise. For web developers, is a bit like riding a dinosaur (if your site was built on a legacy CMS like vBulletin) while trying to complete with those now riding in a F1 race car.

What does this mean for the future of unix.com and the underlying dinosaur-ish CMS system that was very popular years ago but now in fast decline? Well, I'm not 100% sure.

We must move toward a reactive SPA framework like Vue while at the same time keeping the old legacy system working. It's really a lot of work for a small development team, which at the moment is most me with some occasionally brainstorming with Scott.

I'm still working through what this means for the future of unix.com.

If you have any ideas, please feel free to share them here.