<i>React has, ironically, allowed us to once again think about writing web applications as a series of pages rather than a monolithic blob of JavaScript code. It&#x27;s no wonder that developers have become so engaged with React and React Router: it&#x27;s the same mental model as traditional server-only applications. A page is rendered, some changes are requested, then a page is rendered with those changes. The only difference is that this can all happen client-side.</i><p>Our framework does this, without virtual DOM. You build apps by placing reusable components on pages. The pages honor existing web conventions -- so everything works like on the web. But then the framework manages HTML5 history for you, and even swaps javascript&#x2F;stylesheets in and out as you load pages. It loads the code for pages and components on demand, as you navigate the app, and doesn&#x27;t need a monolithic js and css file (although you could have one). Part of sticking to web standards is you can do things like caching on CDN, or even support caching files inside a PhoneGap bundle, so they load instantly on a &quot;native app&quot;, which you can make.<p><a href="http:&#x2F;&#x2F;qbix.com&#x2F;platform&#x2F;guide&#x2F;pages" rel="nofollow">http:&#x2F;&#x2F;qbix.com&#x2F;platform&#x2F;guide&#x2F;pages</a><p>All this does not require a virtual DOM. React and Mithril are great for virtual DOM but you don&#x27;t NEED it. In fact, the fastest approach to components re-rendering themselves is:<p>1) Have the constructor insert the HTML elements, eg by rendering a template, and <i>store references</i> inside the component to the elements it might want to update.<p>2) When some of the component&#x27;s state changes, simply requestAnimationFrame and make a batched update, using the same convention as react&#x27;s &quot;render&quot; method. Only the components whose state changed will update. That&#x27;s what Angular does: dirty checks the state instead of the DOM.<p>3) Traversing parents and children should be done via the component object tree, not the DOM.<p>And voila. You have the speed you need, where you need it. The main challenges are other things, like registering&#x2F;unregistering events, activating&#x2F;removing components while navigating pages, caching, retaining data until you don&#x27;t need it anymore etc. And for that you need a framework.