![[ERR!]](https://pbs.twimg.com/profile_images/828593972029317120/4UXq5Hmj_normal.jpg)
225 Views
This approach is commonplace today, and libraries like Backbone.js, Ember.js, and Angular.js have made it easier for developers to build these rich JavaScript apps. We have found, however, that these types of apps have some critical limitations. To explain why, let’s first take a quick detour through the history of web apps.
3 comments
J Hall
10/24/2014 4:47:41 PM
["Twitter spent a year and 40 engineers rebuilding their site to render on the server instead of the client, claiming a 5x improvement in perceived loading time."](https://blog.twitter.com/2012/improving-performance-on-twittercom)
Wow. Good to know
Bob Senoff
10/24/2014 6:02:34 PM
@averyj thought you'd like this
Drew Peterson
10/24/2014 7:12:07 PM
While I haven't jumped on the React bandwagon yet, that's a project that I see as helping bridge the gap here. If you can render html on the server, deliver it to the client, and easily manipulate the DOM afterwards without stepping back in time to the good ol' jQuery days, you've got a winner: the benefits of better perceived load time without janky or full-page updates. You could probably achieve the same effect with other libraries, but I don't know of any off the top of my head that will only re-render the minimal amount of DOM like React does. @spikebrehm, what are you guys using to manipulate the DOM after the rendered html has been delivered to the client?