JavaScript for Line of Business Applications

This will be a short post about two built in Ember.js route handlers – ApplicationRoute and IndexRoute.

I’ve been building a simple application which has an /entries route. Whenever someone visits my application via root path / I wanted them to be transitioned (think redirected) to the /entries route. To do this, we’ll be using the beforeModel hook in the Route object.

The Route handler is the perfect place for that because it’s responsible for an application state for a given url. Since I wanted to transition from / to /entries I quickly addedthis.transitionTo(“entries”) code inside of an ApplicationRoute’s beforeModel hook.

Monad is a design pattern used to describe computations as a series of steps. They are extensively used in pure functional programming languages to manage side effects but can also be used in multiparadigm languages to control complexity.

React router component allows you to define routes in your React application in a declarative manner, directly as a part of your component hierarchy.

Having routes defined as a part of your component hierarchy allows to dynamically reconfigure routing based on your application state. For example you can return a different set of allowed locations for anonymous and signed-in users.

React router component can dispatch based on location.pathname or location.hash if browser doesn't support History API.

Furthermore it provides advanced features like support for full page server side rendering, multiple routers on the same page and contextual routers.

Consuming OData with plain JavaScript is a bit painful, as we would require handling some of the low-level conversions. datajs is a JavaScript library that simplifies this task.

datajs converts data of any format that it receives from the server to an easily readable format. The batch request sent is a POST request to the path /odata/$batch, which is made available if batch update option is enabled in the OData route configuration.

As seen in the last post, a batch update request bundles of a number of create put and patch requests. These operations have to be specified in an object literal. Following snippet demonstrates it with a create, an update and a patch request...

Browserver is an exploration in simplifying application architecture, by looking at it upside-down, and turning web browsers into Internet-addressable web servers. It exposes a node.js-like API in the browser, tunnelling HTTP over WebSockets so that you don’t need to roll your own custom code to connect the various pieces of your web architecture to your end clients.

Instead, you can move the complexity of your application to the edges by making your end clients first-class HTTP servers, and then use your existing HTTP-related infrastructure to communicate with them.

If you know me, you know it’s easy to get me talking about Ember.js. A year ago, I was deeply skeptical of developing client-side applications. Now, after spending a year shipping production applications in Ember, I believe that client-side apps represent the same generational leap that database-backed apps with Rails offered circa 2006.

Despite the title of this article, I can’t actually predict the future, but I can bet on it. And Charles and I are betting The Frontside’s future on the fact that Ember provides a foundation for creating amazing, next-generation user experiences for the web.

Server-side MVC frameworks rely on the classic Apple philosophy of optimizing for the 80% use case. These frameworks excel at taking a database, exposing CRUD (Create, Read, Update, Destroy) actions via HTTP, and building form-based UIs to work with these records. CRUD-oriented frameworks make it easy to build applications like blogs and contact management software.

What server-side MVC frameworks are not particularly well-suited to are user-driven, stateful UIs like you’d see in desktop apps like Word, Excel, or iTunes.

Rails, as a mature framework, has evolved a set of standard solutions to these types of problems. Generally, they involve minimizing the amount of JavaScript needed and placing as much of the burden on the server as possible.

This post describes a prototype that uses Polymer webcomponents in D3.js.

Appending a single element, like a ‘rect’ to a D3 selection is straightforward. But when you want to append a more complex, nested structure to a selection, it would be nice if you could append a renderer or template. And I would find it even more comfortable if you could specify this in a structured language like xml/html. Furthermore, I would like to specify the behaviour of this renderer within the renderer itself.

I first encountered this desire when I tried to use D3 for visualizing Isotype charts. D3 maps data points to dom elements in a one-to-one relation, while Isotype maps data points to dom elements in a one-to-many relation. You can solve this by converting data points to arrays, but that feels a bit hackish.

I decided to use webcomponents.

This entry is a sort of "part 2" to my previous entry React Demystified. Now that I understand React better, I want to take a closer look at the blog post that motivated this quest to begin with, The Future of JavaScript MVC Frameworks. That entry advocates a vision for what MVC's of the future will look like in JavaScript, and is accompanied by some strong benchmark numbers.

The article's overall argument is that the design/architecture of most JavaScript MVC libraries today makes them slow. While they can be optimized to improve performance, a much better approach (according to the article) is to change the design of the MVC library to something that is inherently faster; a design where the optimizations fall out of the design "for free". A design that is fast by default. This is the claim that I want to take a deeper look at and evaluate in detail.

I want to go deeper because the form of the argument -- the idea that a fundamentally different design can render a lot of busy-work obsolete -- is one that resonates with me. But there are a lot of aspects of this that are all mashed together a bit in the article, so I want to break them apart and look at them one by one.

Two-way data binding greatly simplifies writing views in web applications. The code in this article uses Object.observe to implement a simple two-way data binding in about 100 lines of code.

Inspiration for combining React with D3 came from reading the following two blog posts where AngularJS was used as a part replacement for D3.

* Replacing (most of) d3.js with pure SVG + AngularJS
* Screw D3.js, Bar Charts in AngularJS

In these articles, AngularJS was used to manipulate the SVG elements, rather than D3.js. It had been relegated to providing the axis scales, calculating shape dimensions and path coordinates.

I was convinced that React could take Angular's place. Bringing with it the benefits of the web component style charting tags that the JSX syntax would allow me to create.

This would allow me to specify my chart component in the domain and terms of charting: Chart, Bar, Line and DataSeries. Rather than the actual implementation detail of SVG elements such as g, path, rect.

Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.
Giles Bowkett demonstrates a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gives ‘disposable robot assassin at large’ as his title, but it fit better with the code he is demonstrating.
Bowkett explores many options and iterations of his automation ideas...
It’s an amazing mix of capabilities that let you build your own robot (code) assassins.