JavaScript for Line of Business Applications

Dozer is a system for rapidly developing services to support front-end applications.

It's not a framework, not a toolkit, rather Dozer aims to be a malleable and unopinionated foundation for developing RESTful API's and web services to support front-end development.

Dozer creates a core server environment using NodeJS and the Express framework then allows you to build api endpoints, database models, components and adapters which all work together to provide the services required on the front-end.

This project has been inspired by another great concept ngBoilerplate, allowing to create modern web applications in AngularJS. It follows all the best practices introduced in ngBoilerplate such as component/feature-oriented directory structure, intelligent build system, etc. However, I decided to improve it a little bit and create my own boilerplate from scratch since I missed some basic features like:

• watch for any file changes and apply them to the project in real-time,
• image optimization,
• remove redundant code on compiling output HTML,
• plus ngBoilerplate hasn't been updated for months.

Now this all has been made possible. Please welcome ng-devstack!

All set? Good, let’s dig in. If you’ve looked at the W3C web components specs, you’ve seen that it’s actually a meta-specification, meaning it’s comprised of several other specifications. Each of these subspecs are fascinating and worth digging into, but I’m going to present the smallest example I could come up with to build something interesting, and show how all of these specs fit together. Then I’ll drill into to each spec and talk about where it fits into the puzzle.

Also, I’ll be using the excellent vanilla.js framework to help me build this example. It’s highly functional and extremely light weight. You should check it out if you haven’t yet!

Ok, so by now you’ve gotten the Vanilla.js joke. In all seriousness, not to knock excellent libraries like jQuery, etc, but for this article I thought it would be illuminating to see how how we can build rich web components with just the built-in APIs that will be coming to the browser.

A few months ago I started building things in my free time using AngularJS and it has been an incredibly rewarding and productive journey. In my day job, I spend most of my time building single page applications using either Dojo or jQuery. This article is my attempt to make an objective argument that AngularJS is ready for use in building enterprise software. To accomplish this, I am first going to give a brief history of Angular, then dive into what is important to enterprises by talking about:

* Who is Behind AngularJS?
* How can I Hire and Educate Developers?
* What Kind of Browser Support does AngularJS have?
* How does Google protect AngularJS' Intellectual Property?
* What GUI Toolkits work with AngularJS?
* How can I handle internationalization and accessibility in Angular?
* How can I test my AngularJS applications?

As I’ve mentioned countless times before Ember.js is really hard to understand and to get it’s concepts right. Without some deeper knowledge knowing how to do trivial things can get pretty tricky. Uploading files with Ember.js using drag and drop is no exception here. Common task to solve which using vanilla stack will only require to include any available JavaScript library for drag and drop file upload may look impossible to solve for some using Ember.js.

Ember.js provides us with View Objects which we will use to solve this particular problem. First thing you need to know is that View Object has it’s own template which can be defined in two different ways.

But rich client-side JavaScript frameworks aren’t a good fit for every site, especially content sites like Sourcegraph, as we soon learned. Here are some of the unexpectedly painful things we experienced along the way. We hope this is helpful to other developers who are facing a similar decision.

We knew about many of these pain points in advance, but we didn’t know how painful they would be.

1. Bad search ranking and Twitter/Facebook previews
2. Flaky stats and monitoring
3. Slow, complex build tools
4. Slow, flaky tests
5. Slowness is swept under the rug, not addressed

localForage includes a localStorage-backed fallback store for browsers with no IndexedDB or WebSQL support. This means that asynchronous storage is available in Chrome, Firefox, and Safari (including Safari Mobile).

localForage includes a Backbone.js storage library that you can use to store your Backbone collections offline with only a few lines of really simple code.

Of course, Backbone.js is entirely optional and you can use localForage without it!

I find it extremely helpful to have an idea of what is important to me and my team in structuring my app instead of focusing on the actual structure.

You have to find your own path that is comfortable for you and your team. Instead of just picking a structure, it’s helpful to think about the “why”, so I’ll walk you through the guidelines I follow and my thought process on why I choose how I do.

These are my guidelines. I’m sharing them as one possible path you can take but the main point of this post is to share how I think about structuring my Angular apps. There is a reason for the madness and if you take anything from this post it’s to be sure to have a set of guidelines and conventions of your own.

The structure should follow these 4 basic guidelines. When I find my structure is not feeling comfortable, I go back and revisit these LIFT guidelines

1. Locating our code is easy
2. Identify code at a glance
3. Flat structure as long as we can
4. Try to stay DRY (Don’t Repeat Yourself) or T-DRY

Bart recently experimented with combining OpenLayers 3 and Ember.js to create a LayerSwitcher that supports grouping and overlays as well as base layers.

Some of my takeaways from this exercise were:

* Ember seems powerful, and easy to learn. However, it’s sometimes hard to scrape together all the resources needed to learn and extend the framework.
* Components are pretty new to Ember and I couldn’t figure out how to properly define a component in a different namespace and use it in the application template (this is why I needed to use a workaround).
* OpenLayers 3 also has observable properties, which makes it easier to integrate the two.

When I wrote my first Angular application 2 years ago I was blown away at it's awesome testing story. Although their implementation of dependency injection was a little odd and the size of function signatures were ridiculous, it proved to be one of the frameworks largest selling points. When I started play around with Ember ( v0.9.6 days ), the project didn't really have a strong testing story, but I would argue that Ember now has a better testing story than Angular. Not only does Ember have dependency injection through the container, it also comes along with Ember Testing, which is a suite of tools for integration testing.

First, we agree that there is nothing technically wrong with this code; second, we agree that there is a lot of unnecessary ceremonial boilerplate which we no longer need thanks to syntactic simplifications being introduced in ECMAScript, 6th Edition. The words “function” and “return” both appear six times each, in pairs for every function in the entire program—of which there are six. There are thirty parenthesis: fifteen opening and fifteen closing. There are twelve curly braces: six opening and six closing. Most of that has very little to do with expressing the actual functionality, so let’s get rid of it! The following program is observably the same as the previous program, utilizing new syntactic forms of ES6, bringing the code closer to the expressiveness of Scheme—and yet more concise.