JavaScript for Line of Business Applications

A talk on the SOLID software development principles, tarted at JavaScript, presented at CodeMash 2014.

Note that the slides are less useful without the video of all the things I said. You can find that here:http://www.youtube.com/watch?v=TAVn7s-kO9o

The code and raw keynote slide deck is available here: https://github.com/derickbailey/solid-javascript

First of all I think it’s important to evaluate technologies on objective rather than subjective features. “It feels nicer” or “it’s cleaner” aren’t valid reasons: performance, modularity, community size and ease of testing / integration with other tools are.

I’ve done a lot of work benchmarking, building apps, and reading the code of Angular to try to come up with a reasonable comparison between their ways of doing things.

* Community / project maturity
* Performance
* Mechanisms for code reuse
* Server rendering
* Tooling integration
* Simplicity
* My conclusion

The main idea was to provide a simple and tiny CRUD API (<2Kb once gzipped). Basically, you instantiate a database, inserts objects (documents if you're a fan of MongoDB) and store them wherever you want. Then you can retrieve, update and delete documents. Pretty easy.

At first I hard-coded the usage of localStorage, then with the help of Fabrice Weinberg and Valérian Galliat, I managed to externalize the driver (what does the storage) so that you can plug the CRUD class to whatever suits your needs.

The driver is what actually stores your data. It is the interface that deals with persistence. To put it simple, the Database class manipulate your data while the driver stores them.

You can code your own driver or use the one I made which relies on DOM Storage (eitherlocalStorage or sessionStorage, depending on how your initialize it). The driver can rely on any storage system that supports key/value pairs (DOM Storage, Redis...). Also, it has to implement the 3 methods: getItem, setItem and removeItem.

Today, I rewrote a prototyped Rails API into SailsJS, to take advantage of the dramatic speed boost of server-side Javascript. Waterline, the ORM used by Sails, currently does not support joins or associations (although they are coming soon), so manual solutions are required for the time being. This gave me a few headaches, but wasn't too difficult or complicated once I figured it out.

One issue that I ran into quite early deals with the way Javascript (and, by extension, Sails) handles function calls. Unlike most other languages, the majority of Javascript calls are non-blocking; that is, the following code...

In this blog post about EmberJS and Ember-Data, we’ll use the example from the last blog post series (you can find it in this git repo on the branch master) and we’ll plug in the RESTAdapter in order to get data from an Express server instead of using fixtures. Clone the git repo, and follow me !

The Ember App Kit has a very useful little feature called ‘API-stub’, it let you create routes on Express and respond with data. We will use this API-stub to create our JSON that we want to send to our Ember app through Ember-Data, so let’s configure our ApplicationAdapter.

A boilerplate project for a complete web application written using Backbone.js & Marionette, node.js & ExpressJS, MongoDB & Mongoose, Handlebars, Grunt.js, Bower, and Browserify!

I created a super basic single page application (SPA) that is a simple Contacts manager. While this app is pretty simple, there’s actually a lot that’s involved. My goal with this article is to cover the entire stack of the application including; back-end, data, front-end, tools and testing. The stack consists of the following core technologies:

* Back-end: node.js and ExpressJS
* Data Layer: MongoDB and Mongoose
* Tools: Grunt, Bower and Browserify
* Testing: Jasmine, Karma, and PhantomJS
* Front-end: Backbone.js and Marionette.js

I’ll go into detail on each of the above components comprising the “full” stack. Again, because its such a simple app, not a whole lot of time will be spent covering the bells and whistles of the user interface or how the app works because that’s fairly obvious (nor did I spend a whole lot of time on the actual implementation, as I didn’t want it to distract from the core of the app). Instead, I’ll go into detail covering every aspect of how the app was built and the workflow process using the various tools.

The end goal is to have a code base to act as a boilerplate starter for any new projects down the road. The code should be fully functional and complete, yet easily digestible. Ultimately, after you read this article and have a solid understand of everything under the hood, you should be able to simply clone the repo and start building your app!

I recently introduced you to JavaScript generators which I think are a really interesting feature that we should look at for the future of JavaScript. In that blog post I was talking about LINQ in JavaScript and kind of glanced over an important part of generators, and that's how you use them if you're not using a for-of loop. While generators make a lot of sense in the scope of managing datasets that isn't their only usage, in reality generators are quite useful if you want to lazily execute any function.

Developing web applications today is quite easy, you will find always a framework/library that does most of the work for you. 

Some month ago, I heard about Apigility and lately I have been playing a little with it. So what’s Apigility?: Apigility is an API Builder, designed to simplify creating and maintaining useful, easy to consume, and well structured APIs. 

For this tutorial I’m going to show you how to create a Todo-Api, using Apigility on the backend and Ember.js on the front end. 

In this article, Maksim Chemerisuk introduces live extensions and better-dom - a new Javascript library for working with the DOM.The objective was to review existing APIs and solutions and to build a clearer, testable and lightweight Javascript...

Lately, I have started to see more and more problems with jQuery, at least my use of it. Most of the problems are with jQuery’s core and can’t be fixed without breaking backwards compatibility — which is very important. I, like many others, continued using the library for a while, navigating all of the pesky quirks every day.