Health to the Web

Some technologies will work better for some situations than others. Client side mvc is more suitable for some use cases than others.  So it depends on many factors. e.g. If a "desktop-like" ui experience is critical, then think client side mvc. If your team has little javascript experience or mvc experience or you have significant SEO requirements then client side mvc may not be a good fit.  The following are my opinions and are not conclusive. Recommend you also research the web. Client side mvc Pro: User experience: traditional web apps typically submit a request and get back a full page each time; client side mvc apps handle more processing on the client and also typically make data requests to the client which should be faster to turnaround. Use gmail? Then you're using a single page app. gmail and others such apps provide a desktop-like experience in the browser. No page refreshes. We'll see more and more of these kinds of apps. Pro: Code...

Bootstrapping data onto the html page which is returned is a clever way to save one or more round trips to the server and show the user the complete page sooner. Bootstrap recommends this approach, see their FAQ . Twitter have a neat way to bootstrap json data into an html file. Uses 2 scripts as follows. Avoids creating any global variables. Notice the json data is within the script tag and is accessed using getElementById().innerHTML. Clean. I like it. I made a minor change to invoke as an immediate function: <script type="text/plain" id="init_data" class="json-data">{name: "denis"}</script> <script>     (function() {           var jsonText = document.getElementById('init_data').innerHTML,               initData = JSON.parse(jsonText);                 ...

Very interesting article from Twitter here about how they changed their client side architecture from  a single page app running client side javascript back to something more traditional. "When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’ browsers and consumed the Twitter REST API directly, in a similar way to our mobile clients." But there were Issues: - initial page-load performance - ensure that only JavaScript required is loaded and the application is interactive as soon as possible - urls are urls (no hashbangs) (important to Dan Webb) The defence The riposte By accounts #newtwitter did not do a good job of implementing hashbang and there were performance issues...the ripostes had it and.. ..so twitter rearchitected to: 1. "render our page content on the server and deferring all JavaScript execution until well after that...

Steve Souders 14 rules Google speed Max number of browser connections  See tab Connections per Hostname

I continue working on my little node js - mongodb - backbone js app which runs locally and on nodejitsu here. You can read more on my first post here . So I hooked in some basic mongodb Nodejitsu supports mongodb, couch and redis. I created a mongodb db following the instructions here in the nodejistu manual Nodejitsu provides you keys and access code to access the db. Through r&d and trial and error I got some functions to seed, list and remove data. I modified the code to read the bookReviews collection when users hit the landing page and return the landing page with that json data bootstrapped. I deployed using "jitsu deploy" and got an error related to mongo db. I kinda figured I needed to add it to dependencies so I updated the package.json as follows. I tried various versions for mongodb but hit on the >=0 solution looking at the rest of the package.json. This fixed it and the latest code is deployed.   "dependencies": {     "mongodb"...