The State of JavaScript Frameworks

If there is something you want to build on the web, there is a JavaScript framework to do it. Want to emulate a RESTful Rails backend using Node instead? Sails is for you. Build mobile apps with React components? Get some Reapp in your life. Need an impossibly lightweight and fast client-side MVC? Mithril will be your one and only.

JavaScript will even fix your crappy 'scroll to top' button.

The current state of JavaScript framework development.

The problem with JavaScript ubiquity in web development is mistaking change for progress. Whenever a new framework is released, there tends to be a bit of of an “emperor’s new clothes” effect. While it's easy to bag on every newest flavor of the week. there are JavaScript frameworks that have proven useful for longer that the attention span of a teenager, and are being used to build some awesome stuff. Today we take a look at three: Angular, Meteor, and React.

The Stalwart: Angular

Out of the three listed, Angular is probably the most commonly used JavaScript framework. With backing from the Mountain View Monster themselves (Google), Angular is used by several high-traffic applications, such as MSNBC, Vevo, and Honest Company's e-commerce site. Angular plays nicely with open source back ends like Rails and Node, as well as proprietary solutions like .NET and ASP.NET.

Angular's biggest trick is adding dynamic functionality to otherwise static HTML markup. It accomplishes this feat with two-way data binding, which marries changes to either the view or the model to each other. When an Angular view is updated, the information is also changed, or "binded" to its model. When a model's data is changed, the view is updated automatically. This binding eliminates many of the errors that come from trying to write code to manipulate the DOM on data changes.

Being one of the most widely adopted frameworks also means that the resources for learning Angular are prevalent. CodeSchool has a fantastic video series that breaks down the components very well. Codecademy has also jumped into the fray with their own step by step exercises for tackling Angular.

The Challenger: Meteor

Meteor is unique on the this list as the only truly full stack framework. Unlike our other two contestants for Ruler of All JavaScript, Meteor is not maintained by a Bay-area behemoth, but rather the VC-backed collective of scrappy former MIT students known as Meteor Development Group. Meteor is starting to be adopted by several startups, most notably are Workpop, an Los Angeles-based jobs board for hourly workers, and Classcraft, a teaching gamifcation application.

Meteor’s biggest trick is reactive development. The modern web requires UI’s on the client to respond immediately to changes in data, without having to wait for server calls on every single action. Meteor accomplishes this feat by incorporating a TON of awesome tools that are unlike most other web development frameworks around. The combination of in-house developed tools like Blaze, Tracker, and DDP, combined with awesome existing technologies like Node, MongoDB, jQuery, and Handlebars makes for a comprehensive stack for building reactive web applications quickly.

For context, try to build a real-time chat application in Rails. Don’t worry, I’ll wait.

...

...

...

Back? Not a fun experience, huh? Exactly why Meteor is so awesome. If you need more proof, here’s the Internet’s take on Meteor and its place in modern web development:

Meteor has developed a robust community with great resources in a short time. Atmosphere a catalogue of Meteor packages, similar to Ruby gems. Crater is a Reddit/Hacker News-like community for Meteor news and happenings. There are several great podcasts as well, including The Meteor Podcast, MeteorClub, and Meteor Interviews.

The Phenom: React

Not to be outdone by Google, the Zuckerberg Gang have recently released React, a “JavaScript library for building user interfaces.” React is possibly the best solution yet to creating and using customized UI components. Justin Deal from Zapier Engineering explains it best:

With React, just like with a game engine, you simply specify how a given application state gets translated to a given view. If something changes, you don't change the view. Instead, you just render again and get a new view.

React adoption has been swift, and is currently utilized by two of the biggest web applications in the world: Facebook and Instagram. Some heavy duty credentials, indeed.

It's ironic that, while Angular puts the power of JavaScript directly into your HTML markup, React's new JSX syntax allows HTML to be customized and written directly in JavaScript. So, instead of writing a bunch of string soup to reference your HTML tags like this:

var Hello = React.createClass({displayName: 'Hello',  
    render: function() {
        return React.createElement("div", null, "Hello ", this.props.name);
    }
});

the JSX syntax allows a much more direct reference, like so:

var Hello = React.createClass({  
      render: function() {        
           return <div>Hello {this.props.name}</div>;      
  }    
});

As a web developer, I’ve always found the JavaScript/jQuery of doing HTML references a bit clunky and easy to screw up. The JSX syntax makes it easier to manipulate your views with all of the power of JavaScript in the browser. Add the highly reactive and realtime nature of React views, and you’ve got yourself an awesome new framework that promises to make web development easier.

The Winner: JavaScript Developers

So who is the winner of our JavaScript deathmatch? All three of these frameworks have pros and cons. I’ve always thought that part of our roles as developers is deciding which tool is right for the job. For comparison, here's a discussion among some React and Angular maintainers talking about various topics.

With multiple good tools available, our roles becomes both more involved and easier. Have a giant, constantly changing database that needs to be reflected in your front-end at scale? Angular is your best bet. Need to build an reactive prototype quickly and make your developers happy and more productive? Meteor fills your needs. Need modern view layers that are real-time an use fully customizable components? React is the one for you. You really can’t go wrong with any of these frameworks. In these three cases, the emperor’s new clothes are, in fact, as fancy as they appear to be.

Anatomy of a Rails Application, Part I: Views

Ruby on Rails is a framework for building web applications that allows developers to create back-end database systems quickly. My favorite part of Rails is that it integrates the visual presentation of back-end data easily. Learning how to control databases in general without any visuals can be tricky, so we'll start today by looking at Rails and setting up these visuals the Rails way. Theses visuals are called "views," and written mostly in HTML, with some special Ruby sauce mixed in. Rails gives us some tools using the Ruby language to beef up what we can do in our views. Let's take a look.

This post is the first of a multi-part series on building a Rails application.

alt Introducing PowerUp, a workout logging web application using Rails, MongoDB, and Bootstrap.

There are many resources available for setting up a Rails application from scratch, such as Daniel Kehoe's excellent book, Michael Hartl's tutorial, and the Rails video lesson series at CodeSchool. This series will jump into writing code on a live application.

PowerUp is an application that allows users to log their workouts. PowerUp's views have to provide a visual interface for the following tasks:

  • Create a new user through a signup form
  • Log in an existing user to the site
  • Edit the user's information
  • Create a new workout log
  • Edit the details of a particular workout log
  • Delete a workout from a user's list of workouts.

Rails knows that, in order for our views to display properly in a browser, the html code must be formatted a ceratin way. Rails takes care of part of this issue for us by providing a default page layout, in which other views of our app will show. This default piece is a file called application.html.erb:

<!DOCTYPE html>  
    <html>
        <head>
            <title>PowerUp</title>
            <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true %>
            <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
            <%= csrf_meta_tags %>
        </head>
        <body>
            <%= yield %>
        </body>    
    </html>

The application.html.erb file gives us all of the doctype, html, head, and body tags without any additional configuration. These nice built-in defaults are a theme of developing applications with Rails. On this page, the <%= yield %> tag is a sort of placeholder. Rails puts whichever view is needed in place of the yield tag, and the resulting page is still clean, seamless HTML. For example, if one of our views consisted of the following code:

<h1>This is an example page</h1>  
<p>I'll show up in place of the yield tag, just watch</p>  

The browser would render this:

<!DOCTYPE html>  
    <html>
        <head>
          <title>PowerUp</title>
          <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %>
          <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
          <%= csrf_meta_tags %>

        </head>
        <body>

            <h1>This is an example page</h1>
            <p>I show up in place of the yield tag, just watch</p>

        </body> 
    </html>

This example is the most basic way in which Rails keeps our code DRY (Don't Repeat Yourself). The yield tag inserts only code that is changing in the HTML, keeping us from having to write the other page tags over and over for each page that the application renders in the browser.

Another tool that helps developers write DRYer code in Rails is view partials. Partials are code chunks that can be called in as many places in your application as needed. In PowerUp, the form used to create a new workout log and edit existing logs is identical. So we'll write a form partial and save is as _form.html.erb within the views/workouts folder.

First, we'll access the form partial in the new workout view, with some Bootstrap styling, like so:

<div class="col-sm-4 col-sm-offset-4">  
    <h1>Edit</h1>
    <%= render "workouts/form" %>
</div>  

Notice how the render calls the 'form' partial from the 'workout' folder. Saving the partial with this specific file path is important. It is likely that there will be other forms in other parts of your Rails application, and the only way to distinguish them when using the render tag is by specifying which folder in which to access the partial. The render tag helps keep code DRY by allowing changes to a single file to be accessed throughout the application.

Having DRY code is awesome and all, but what if we want smart code as well? What if I want to provide PowerUp users links to their profile and log out, but only when they are logged in? Rails gives us a way to do change content based on certain conditions by allowing Ruby code in our views.

First is our navbar links when a user is not logged in:

alt No user logged in, static links.

Here's the code for static links:

<li><%= link_to "Log In", new_session_path %></li>  
<li><%= link_to "Sign Up", new_user_path %></li>  

Pretty straighforward, but these links will always stay the same. Not useful when a user is logged in. We want the user to have access to these links:

alt User logged in, dynamic links

Rails lets us write Ruby code into our views. Let's use an if statement to check if a user is logged in, and show the appropriate links based on this check:

<% if logged_in? %>  
        <li class="active"><%= link_to "Welcome, #{current_user.name}!", user_path(current_user) %> </li>
        <li><%= link_to "Profile", user_path(current_user) %> </li>
        <li><%= link_to 'Log Out', logout_path, method: :delete %></li>
    <% else %>
        <li><%= link_to "Log In", new_session_path %></li>
        <li><%= link_to "Sign Up", new_user_path %></li>
<% end %>  

Now our navbar links will change based on the user's needs. This dynamic content concept can be used in many different ways; error messages, vote/comment counters, and other permission-based content restrictions.

Rails gives developers a few methods for presenting data and information in a flexible way. Yield tags, partials, and even straigh Ruby code are all tools that developers can use to build attractive and useful views in their Rails applications. Try some of these techniques in your next app and see what you can build.