Verizon Wireless Backbone.js+RequireJS migration

RequireJS is simply excellent. Having tasted what can be done with RequireJS I'd be reluctant to consider doing a backbone.js project without it. Backbone and Require provide an exciting way to work with JS which to me is somewhat reminiscent of the Robotlegs micro architecture for ActionScript3/Flex. You get clean separation of modules, an event bus that helps you decouple components, fast view generation with underscore templates.

I haven't compared the speed of view generation with React yet, although I've read conflicting information about the benefits. When time permits, I should run my own speed comparison. I suspect it only becomes an issue for largish, datagrid-like views with a lot of insertions and deletions. I'd be interested to see how well React Native handles the performance tests in the article below.

• Web Reflections - Is Anyone Testing On Mobile?

Using the text plugin for RequireJS allows us to load plain HTML templates. Plain HTML means existing editing tools can be reused, so we don't need to train developers on new formats or tooling.

SEO

Just as with any other web site, we do our best to ensure the search engines can work easily with our pages. E.g.: Only one H1 per page, content cannot be hidden to the search bots through JavaScript indirection. The challenge then is to provide a version of the page to the search engines crawlers.

Performance

Our front end strategy allows us to render pages faster, primarily by reducing the number of bytes sent, there are many factors affecting page load. Performance deserves an article of its own.

Flexibility

My favorite benefit about decoupling from the back end is leaving JSP/JSTL behind. With JS we have the opportunity to create massively flexible logic which is simpler to read than similar logic written JSP/JSTL.

Consider these two roughly equivalent code blocks:

JSP with Oracle ATG ForEach loop over a data set. This example taken from Oracle documentation

    <dsp:droplet name="/atg/dynamo/droplet/ForEach">
      <dsp:param name="array" bean="ClassroomService.enrolledStudents" />

      <dsp:setvalue param="CurrentStudent" paramvalue="element"/>

      <dsp:oparam name="empty">
        There are no students in this class.<br/>
      </dsp:oparam>

      <dsp:oparam name="outputStart">
        Here is the list of students in this class: <br/>
      </dsp:oparam>
      
      <dsp:oparam name="output">
        Student # <dsp:valueof param="count"/> :
          <dsp:valueof param="CurrentStudent.fullName"/> at address:
          <dsp:valueof param="CurrentStudent.address.city"/>
          <dsp:valueof param="CurrentStudent.address.State"/><br/>
        has the following grades:
        <dsp:include page="displayStudentGrades.jsp">
          <dsp:param name="studentInputParam" param="CurrentStudent"/>
        </dsp:include>
      </dsp:oparam>

      <dsp:oparam name="outputEnd">
        Total number of students: <dsp:valueof param="size"/> <br/>
        End of Student list.
      </dsp:oparam>

    </dsp:droplet>

JavaScript using Backbone Collection and underscore template. The are quite a few ways to achieve the same thing with Backbone. Here's one which is equivalent to the previous JSP snippet.

    <% if (studentsCollection.length === 0) { %>
        There are no students in this class.<br>
    <% else %>

        Here is the list of students in this class: <br>

        <% _.each(studentsCollection, function(student, index) { %>

            Student # <% index %> at address:
            <% student.address.city %>
            <% student.address.state %>
            has the following grades:
            <div class="gradesView"></div>

        <% }) %>

        Total number of students: <% studentsCollection.length %> <br>
        End of Student list.
    <% } %>

We have already significantly reduced the verbosity of the output loop. In addition, we're using regular js / underscore each syntax, albeit wrapped in underscore template markers. JS templating allows for fast preview in the client without tangling with the server. This typically results in a development loop of seconds rather than minutes. Prototyping things becomes a breeze and customers benefit because developers have time to refine the solution and iterate with UX teams.

2015 Page style

2013 Page style