JavaScript for Line of Business Applications

Despite their name, template strings in ECMAScript 6 (ES6) are more like a different kind of function call than a mechanism for defining templates. This blog post explains how you can still use them for HTML templating. 

I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems.

I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.

If you want to know why I think all of this I’m afraid you’re going to have to read this long article in its entirety.

Some of the core ideas are:

• your entire view is a single complex vtree
• your entire view state is a single complex immutable object.
• your rendering function is pure, it takes just the view state (disclaimer: hooks & widgets are not pure).
• you declare all user input as channels up front in your view state.
• the view state supports cursors, you can nest components in components.

Mercury is unidirectional because:

• A DOM event triggers a value to be send to a channel
• The listener for the channel updates the view state
• An update to the view state triggers a re-render
• A new vtree is created
• diff() and patch() update the DOM.

mercury is similar to react, however it's larger in scope, it is better compared against om or quiescent

• mercury leverages virtual-dom which uses an immutable vdom structure
• mercury comes with observ-struct which uses immutable data for your state atom
• mercury is truly modular, you can trivially swap out subsets of it for other modules
• mercury source code itself is maintainable, the modules it uses are all small, well tested and well documented. you should not be afraid to use mercury in production as it's easy to maintain & fix.
• mercury encourages zero dom manipulation in your application code. As far as your application is concerned elements do not exist. This means you don't need to reference DOM elements when rendering or when handling events
• mercury is compact, it's 11kb min.gzip.js, that's smaller than backbone.
• mercury strongly encourages FRP techniques and discourages local mutable state.
• mercury is highly performant, it's faster then React / Om / ember+htmlbars in multiple benchmarks TodoMVC benchmark\ animation benchmarkTodoMVC benchmark source
• mercury comes with FP features like time-travel / easy undo out of the box.
• mercury is lean, it's an weekend's read at 2.5kloc. (virtual-dom is 1.1kloc, an evening's read.) compared to react which is almost 20kloc (a month's read)

There's a common design pattern in the Node.js community that has been bothering me for some time since it results in less readable code. The issue relates to designing modules that export a singlefactory function. Let's take a look at some example code using the popular express module:

In this post, I’ll demonstrate the usage of higher-order functions outside of a collection-processing context – with the ultimate goal of reducing boilerplate code in your real-world applications (as filter did above). We’ll start with partial function application (facilitated by Underscore’s _.partial) and move on to writing our own higher-order functions.

ECMAScript 6 sets have no methods for computing the union (e.g. addAll), intersection (e.g. retainAll) or difference (e.g. removeAll). This blog post explains how to work around that limitation.

How many photo carousels have you built? Date pickers? Dynamic tables and charts? Wouldn't it be great if there was a way to make these custom elements encapsulated and reusable? Welcome to Web Components!

React is awesome at handling what and when to show something to the user. In our example, what we're showing are related input fields (simple markup), and when those fields are shown is determined by the current step (the state of our Registration component). One way of thinking of this relationship is state determines shape. Depending on the state of our application, we're able to simply and predictably render something different, whether it's as small as a single character change or showing a completely different component altogether.

I'll start with a bare model and then I'll add feature after feature trying to explain the design decisions, pointing when possible to the corresponding implementations in React, Mitrhil and Mercury.

What follows is my own interpretation of React, feel free to criticize and contribute.

As I hoped, being the VDOM implementations so similar, it's straightforward to translate one view system into another. This fact opens a new world of possibilities: this is a demo where a UVDOM-view system is converted into React, Mithril and mercury with two different styles applied (Bootstrap and Pure), check it out.

In this article we continue our discussion of how to use Spring Security with Angular JS in a “single page application”. Here we show how to use Angular JS to authenticate a user via a form and fetch a secure resource to render in the UI. This is the second in a series of articles, and you can catch up on the basic building blocks of the application or build it from scratch by reading the first article, or you can just go straight to the source code in Github. In the first article we built a simple application that used HTTP Basic authentication to protect the backend resources. In this one we add a login form, give the user some control over whether to authenticate or not, and fix the issues with the first iteration (principally lack of CSRF protection).