The title of this post mentions three area that have been interesting me over the last few months. They are three very different technologies but all have a similar goal. I believe that they are all aiming to increase the expressiveness of the code you write by making it say more about what you are doing and less about implementation. In essence they all tackle this in different domains. It may be argued that to some level many patterns and trends in programming exist to increase expressiveness.
So this post could grow to an epic if I tried to discuss all three in detail. So I will just give a quick overview. No opinions but needless to say I am excited by all of them.
Web Components
This is a conglomeration of emergent specifications that will allow pages to be divided more along the lines of widgets/sections. This is instead of separation into just three functional pieces namely content(HTML), style(CSS) and behaviour(JavaScript). The four new web standards for web components are
- Custom Elements
- HTML Imports
- Templates
- Shadow DOM
Browser support is variable and progress can be checked here. They can be experimented with now using a polyfill library called polymer. A decent introduction can be found here.
Functional Reactive Programming (FRP)
I first came across this in the excellent JavaScript library bacon.js. There are other implementations such as rx.js. FRP is a structure to handle events and data manipulation. It aims to provide a consistent language for manipulating event stream that have much in common with collection operations such as map, reduce and filer. The analogue being that a stream of clicks can be considered an array in time of click. How helpful that visualisation is I am unsure off but the code is definitely a wonderful step up the abstraction ladder. To have an overview I would definitely recommend this walk through of implementing snake
Microservices
Fundamentally this is about breaking up a well organised large application into several smaller applications that run in concert to create on application agglomeration to a user. There are several benefits to this approach, each can be written in the language most suitable to its task, they can easily be rewritten when the business environment changes. The downsides are mostly the added complexity with deploying many services but this can be mitigated with automation and making use of services such as heroku. An excellent introduction is here.
Single Responsibility
The Single Responsibility Principle (SRP) is a cornerstone of good code design but there is more to it that the simplicity of its statement gives away. It took me a while to discover what I see as a key feature of single responsibility and that is a concept of scale.
In a restaurant the chef has the single responsibility to prepare food while the waiter has the single responsibility to deliver food. However into this mix we can add a tin opener that has the single responsibility to open tins. These are however not three equal partners. It is evident that the chef can use the tin opener without having two responsibilities, namely preparing food and operating a tin opener. Operating a tin opener is part of the preparing food responsibility.
In conclusion I see these three things providing new ways to organise code. In the Model View Controller world the application is broken up by functionality. As an application grows you can find yourself with a large application that is still only broken into three clean pieces, the model layer the view layer and a controller layer. Instead we can move to separating code around features. As an application grows it gets more features and the number of distinct pieces grows. This is good because each can be understood in isolation.