JavaScript for Line of Business Applications

Arch is a front-end functional style application framework using React as a UI layer. Arch applications are isomorphic out of the box, including form processing. This means you write your application as if it was client-side only and Arch will manage the server-side portion.

This also means you don’t get any control over the code running server-side, which is a design decision. The theory behind it is that any server-side code you need to run should sit in a separate server application which you talk to over an API.

Joel Burget, Developer at Khan Academy explains the design of his new react-haskell library.

It allows you to write a front-end app in Haskell which you compile to JavaScript via Haste and render using React JS.

The original Smalltalk MVC is an elegant way to structure an application. Unfortunately, the JavaScript community takes more inspiration from Dr. Frankenstein than from Smalltalk. The community appears to have done its best to saw off many good parts from MVC and bolt on unnecessary ugly bits to create framework monsters unsuitable for building real-world JavaScript applications.

I hope this article will remove the necessary historical digging to read and understand the implementation of Smalltalk MVC. Also, I hope it inspires better JavaScript frameworks and applications.

Scala.js opens a big world of frontend development to Scala fans. Most of the time Scala.js project ends up being an independent browser or Node.js application. But there are cases, where you would want to make a library for general frontend developers.

There’re some interesting gotchas in writing Scala.js library such way, that it will be natural to use for an average JS developer. In this article we will develop a simple Scala.js library (code) to work with Github API and will focus on the idiomaticity of it’s JS API.

This is a book on the functional paradigm in general. We'll use the world's most popular functional programming language: JavaScript. Some may feel this is a poor choice as it's against the grain of the current culture which, at the moment, feels predominately imperative. However, I believe it is the best way to learn FP for several reasons:

• You likely use it every day at work.

• We don't have to learn everything up front to start writing programs.

• The language is fully capable of writing top notch functional code.

That said, typed functional languages will, without a doubt, be the best place to code in the style presented by this book. JavaScript will be our means of learning a paradigm, where you apply it is up to you. Luckily, the interfaces are mathematical and, as such, ubiquitous. You'll find yourself at home with swiftz, scalaz, haskell, purescript, and other mathematically inclined environments.

Isomorphic apps are almost like “normal” apps when creating them with the FRP. Because the FRP encourages you to always pass the entire state object to the rendering function, nothing prevents you to do the same in the backend as well.

If you have read other tutorials you may already know that React has a “backend-compatible” function called renderToString. It behaves exactly like render but doesn’t call componentDidMount and returns the rendered HTML as a string instead of placing it into a DOM node. Component & model in → HTML out. Couldn’t be simpler?

Well… actually, it could be. There are two gotchas you should know before trying to use renderToString:

1. Your backend must understand JSX syntax
2. Your front-end modules must be CommonJS compatible

In this blog post I will talk about the changes coming in Angular 2 that will improve its support for functional programming.

Using a mutable domain model goes against our goal. Say we have a mutable domain model that backs up my component. And the component updates the model. Some other component, somewhere else, that happened to point it, will be updated.

Instead we should model our domain using dumb data structures, such as record-like objects and arrays, and transform them using map, filter, and reduce.

How to Stop Micromanaging Everything

Over the course of the next few years, the way we code is going to change in radical ways, pushing us in a fundamentally different direction than the one we’ve been sprinting for the past 30 years or so. These changes will lead to many important breakthroughs in programming techniques, processes, application scalability, and quality controls.