TodoMVC is a place where a large number of people have turned in examples of building the exact same Todo web application while using different MV frameworks (and even some non-MV frameworks). Why? So that developers can come explore the code and decide for themselves which libraries and frameworks look best to them. For those wishing to explore the MV* landscape, this is can be a huge help for getting a quick look each framework.
It may not be ready for production, but the release candidate for version 3 of Twitter Bootstrap is a huge change from 2.3 and has me very excited about its future. Sadly, they have done very little related to JavaScript, but that doesn’t mean I can’t enjoy it. Let’s take a quick look at some of the major changes appearing in Twitter Bootstrap 3, CSS and JavaScript alike.
For a while, I’ve been thinking about how best to handle showing modal dialog boxes for my applications while utilizing Backbone views. A lot of interesting ideas passed through my head, but none of them seemed exactly right. Then I saw a post by Derick Bailey where he described how he uses Marionette’s Regions to handle the work. His post is a bit on the old side and Regions have changed a bit since, so I decided to look into how to do it myself.
Hey everyone. I’m sorry that I’ve been neglecting you all so much. I can’t believe it’s been two months since I last posted something on here. In short, I’ve been very busy. I’ve written several articles for other blogs, and that’s actually what this post is all about. If you’re not following some of these blogs, you may have been missing out on some of my work. So here’s what I wrote in my absence from this website.
Hey everyone! Backbone 1.0 has been released! I just happened to pop by their site and see that 1.0 is official, so I have no idea how long it has been out. Why didn’t anyone tell me?!?!? Anyway, there may be some of you out there wondering what this new version brings and how they can update their apps to bring in all the new awesomeness. Well, let’s take a gander at this new stuff.
RaptorJS is a toolkit that provides support for building JavaScript modules and UI components that function on the server and in the browser. RaptorJS promotes modularity which is crucial to building reasonably complex HTML web applications that are maintainable, easily testable and optimized. Keep reading below to learn more about this helpful toolkit.
As sites are filled with more and more JavaScript, images, and other external assets, web pages have become more and more bloated and performance has started to become an issue. We’ve started to reduce the number of requests by concatenating our JavaScript and CSS files and using image sprites. We’ve shrunk file sizes by minifying and obfuscating our code and optimizing our images. All these measures are good, but they may not be enough. If you have a large JavaScript application, you could have a ton of JavaScript being loaded in that single concatenated file, and a lot of the code may be going to waste because it isn’t used. Let’s try to “lazy load” some of that code using RequireJS.
I can’t go a single week without reading another article talking about promises. I’m not talking about when you promise your child that you’ll be there for his baseball game. I’m talking about a JavaScript concept that makes it simple to react to the completion of asynchronous actions without indenting ten levels when you need to perform one asynchronous action after another. While working on a Backbone application, I tried to use promises in my main asynchronous processes, and I’m not sure it measures up to my previous event hub architecture. Let’s compare!
It wasn’t long ago that I ran into a strange issue with Chrome. My Jasmine tests were failing because the timeout on the asynchronous actions was too short for Chrome, even though they worked perfectly fine for Firefox. This led to me writing some tests to see if Chrome’s WebSocket implementation was slow which gave some pretty interesting results. I’ve also heard some interesting results from my readers, so I decided to investigate some more.
In my last article where I talked about unit testing Socket.IO with Jasmine, there was a point where I mentioned that I needed to use timeouts that were a second and a half when doing the asynchronous connecting and disconnecting from the Socket.IO server. It was working just fine with 750 millisecond timeouts on Firefox, but when I tested it in Chrome, timeouts were being reached and the specs were failing. Let’s see if we can get to the bottom of this and figure out why Chrome failed so hard here.