Immutable Javascript

There are very good reasons to use immutable objects in certain languages. In Javascript however I’m still kinda meh. What are immutable objects? Basically it means that you are always creating new objects or entire data structures instead of making individual changes to objects in the same data structure.

The biggest reason for immutable objects is that they’re thread safe. This may make sense in some languages but since javascript is single threaded this doesn’t really apply. And when you use web workers to take advantage of multi-threading you’re using a messaging interface that helps to keep you out of trouble with the state of your objects.

Other arguments for immutable objects are to avoid temporal coupling and defensive copying.  Temporal coupling is an anti-pattern in which two actions are bundled together into the same just because they happen to occur at the same time. However, you can just as easily avoid it with either mutable or immutable objects. I don’t get the ‘no defensive copying’ argument because with immutable objects you ARE creating a complete copy.

Facebook’s React is a popular view framework that’s the V in MV*. They also have a library for models called immutable.js.  For React it makes some sense to use immutable.js.  React uses the observer pattern to update the view on a change to it’s model. Whether you like React or not there is some simplicity in not having to write specific binds between the model and view.  And the expensive process of observing all objects isn’t impacted by replacing the entire model through immutable.js.  There can also be some marginal performance improvements with this particular stack. With other MV* libraries however, you already have a model with its own methods and way of binding the view to the model. I think immutable javascript makes some sense for React apps but only depending on the application. Sometimes native objects make more sense for React apps, not just for performance, but because you can use native arrays with a much more extensive list manipulation library like lodash.js

In conclusion I’m really not sold on immutable objects in javascript, except in certain React apps.

 

 

 

Cleaning up boilerplate backbone views

And you think you’re so clever and classless and free

— John Lennon

One common complaint developers have with Backbone is the proliferation of repetitive boilerplate code. How many Backbone apps have a view like this declared over and over?

var MyView = Backbone.View.extend({
el: ‘#someId’,

template: _.template($(“#myTemplate”).html()),

model: myModel,

render: function() {
this.$el.html( this.template( this.model.toJSON() ) );
this.stickit();
return this;
}
});
This isn’t a problem inherent with Backbone, but a problem with developers writing repetitive boilerplate code. One possible solution is to use one of the opinionated frameworks that extend Backbone like Marionette, Chaplin, or Thorax. These are perfectly acceptable solutions if you like how they do it. They aren’t always necessary though. Instead of extending all views from Backbone.View, do it once for a given model and extend all other views for that model from these view constructors.

var MySubView = MyView.extend({
el: ‘#someOtherId’,
template: _.template($(“#anotherTemplate”).html());
});

This way I only change the methods that need to be changed. Also note that I’m using backbone.stickit in my render. This will be in all my views for this but if I don’t have a binding method, it will be a noop. This is the kind of flexibility I get without having to rewrite a big ugly render method, unless of course I need to write a different render method.

var MySubView = MyView.extend({
el: ‘#someOtherId2’,
template: _.template($(“#anotherTemplate2”).html()),
render: function() {
this.$el.html( this.template( this.model.toJSON() ) );

var anotherView = new AnotherView().render();
var anotherView2 = new AnotherView2({
model: someOtherModel;
}).render();

return this;
}
});

This is how I would create a hierarchy of views, but for any of the terminal views like AnotherView(), I would extend this from MyView. This is the beauty of javascript’s prototypal inheritance. Objects inherit from other objects. Just like in classical inheritance I can add methods, but I can just as easily change them.

 

 

Compressing Angular Modules with Gulp

Modules are very important for large applications.  For these I typically use require.js and compress it with r.js. However, since Angular has it’s own module system I prefer to use it, and for the compression part I use gulp tasks.

<script src="../vendor/angular/angular.js"></script>
<script src="../vendor/angular/angular-ui-router.js"></script>


<!-- build:all -->

<script src="../app/app.js"></script>
<script src="../app/controllers/childState1.js"></script>
<script src="../app/controllers/childState2.js"></script>
<script src="../app/controllers/form.js"></script>

<!-- endbuild -->

 

var concat = require('gulp-concat');
var gulp = require('gulp');
var htmlreplace = require('gulp-html-replace');
var ngAnnotate = require('gulp-ng-annotate');
var rename = require('gulp-rename');
var runSequence = require('run-sequence');
var uglify = require('gulp-uglify');



gulp.task('compress-js', function() {
 gulp.src('./dist/debug/public/app/**/*.js')
 .pipe(ngAnnotate())
 .pipe(concat('modules.min.js'))
 .pipe(uglify())
 .pipe(gulp.dest('./dist/minified/public/app'));
});
 

gulp.task('replace-script-tags', function() {
 gulp.src('./dist/debug/public/app/application.html')
 .pipe(htmlreplace({
 'all': '../app/modules.min.js'
 }))
 .pipe(gulp.dest('./dist/minified/public/app'));
});

Mobile Web Development Strategies

Mobile devices have come a long way in the last few years. As powerful as their desktop counterparts, mobile devices are profoundly different with touch screens, GPS, accelerometers, cameras, and other sensors, not to mention smaller screens. So many differences demand an entirely different experience. We then have the challenge of bringing those designs to life in a sustainable, maintainable, and effective way. We use several key strategies including device detection, progressive enhancement, and responsive design.

Device Detection allows the web server to know which particular device is being used, and to serve up an entirely different web page for that device. Going to the same web site could give you something completely different whether you are on your laptop, iPad, your brand new Android phone, or that old phone from several years ago that allegedly has Internet access. You could build one website for all, but chances are it would only look good on one of these devices. Device detection lets you target each one separately, for its own unique experience. Not only can you target all mobile devices globally, but you can actually target each specific type and version, from iPhone 3 to Blackberry 6.

Device detection by itself has a major drawback. There are hundreds of possible devices out there, making it costly to build corresponding websites that would be difficult to maintain. Responsive Design is an alternative to this. One website is created that morphs according to the device’s screen width. For instance, a desktop may show a three-column-wide layout, whereas these columns would be stacked one on top of each other for mobile. Responsive design works great for static content. It starts to show some limitations with rich web applications.

Among the many mobile devices out there, screen resolution is only one of the differences. Rich web applications require the use of javascript. Progressive Enhancement checks for javascript support, and if found, adds extra style and functionality that only javascript can give. Older phones will get a basic experience while newer smartphones can utilize modern technology.

So which of these strategies is the best one? Well, that entirely depends on what you’re trying to build, and you don’t have to pick just one strategy. You could use device detection to send the user to a mobile version that uses progressive enhancement, but this is just one possibility.

http://coding.smashingmagazine.com/2009/04/22/progressive-enhancement-what-it-is-and-how-to-use-it/

http://www.alistapart.com/articles/responsive-web-design/

Responsive Content with jQuery Mobile

jQuery mobile has a liquid layout out of the box. It uses mostly CSS3 and very few images. This makes it very fluid with any screen dimensions. What you may want to consider is responsive content as well. Look at this page. Change the size of your browser and you’ll notice that the menu is on the left on a desktop or tablet, but disappears when you get down to mobile size. You can achieve this kind of stuff with media queries. Look towards the end of their CSS file. The .content-secondary class defaults to display:none but the @media queries make it visible at a certain screen width. They also added a button to make it visible if you wanted


$(function(){
  $('body').delegate('.content-secondary .ui-collapsible-content', 'click', function(){
    $(this).trigger("collapse");
  });
});

The gist is that you could start with jQuery mobile and use media queries to add responsive content.