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.
- Custom Elements
- HTML Imports
- 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)
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.
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.