The question of either to write code server side or browser side is more than a question, it is a problem. Either way, you will end up rewriting code from one side to the other because you suddenly will realize that to add something to that functionality in the server, you need something from the client and vice versa, after some changes you will realize that your functionality in the client would run better in the server or the other way around, so you will rewrite code back and forth from the server to the client and viceversa.
The underlying problem
The underlying problem is the lack of a high level language both for the Web and the cloud, that can run in the server and in the browser, so that no code rewrite is necessary for communication locally or remotely, so each piece of functionality can be migrated at installation time depending on the capabilities of each node. Or.. better, at runtime, depending on capabilities and load conditions, from the server to the client and back. It can be done. It is something that I have been after since I started coding Web applications. First I tried it to design such a system with javascript, but at that time nothing in the Web architecture were mature enough.
The Web
MFlow and hplayground are a server and a client haskell Web frameworks respectively. Both share the same syntax and semantics, that is, almost the same code for the creation of pages and for the creation of dynamic effects in them. MFlow can perform almost all the page dynamic effects with or without ajax and javascript, using full page refresh when AJAX is not available . Hplayground can perform richer reactive, dynamic effects since all the code has been compiled to javascript.
In my roadmap I plan to create a hplayground module for MFlow, with a single modifier, call it "client", that will compile the MFlow code to javascript using hplayground libraries and will run it in the browser. Otherwise it will behave as any other MFlow page procedure. Later that process of segregation will be automated; There will be no "client" modifier and any presentation code can be translated to javascript and can run in the browser, depending on the capabilities of the browser, load conditions, bandwidth etc.
Cloud:
MFlow has the FlowM monad, that can perform tracking, backtracking and long running transactions. See this article:
These effecta are very important for the creation of loosely coupled architectures where exceptional conditions are not only exceptional, they also may be a part of the flow. Conceptually a web application is a loosely coupled application with a server and a browser, where the client interrupt and send requests and responses in any order. To deal with that, the FlowM monad has these tracking, backtracking and state management effects. These are the very same effects necessary for dealing with communication failures, error conditions or transaction rollbacks from other MFlow nodes and/or databases without resorting to the spaghetti code of event handlers and a centralized updated state. Like in the case of web frameworks, spaghetization precludes the programming of cloud framework such is Cloud Haskell at a higher level.
In my roadmap is the creation of MFlow node communication for synchronization and inter-node data access, using the web first, and later cloud Haskell as communication means, so that clusters of MFlow nodes share the processing load and the data access load. At the end all the cloud distribution of resources will start in a single program in a single node. The distribution of data and procedures will be automatic. I will add a "remote" modifier to distribute MFlow procedures. Later this remote modifier will disappear and it will be automatic, just like in the case of the "client" modifier for the browser. But this time these application would not be focused in web applications but any kind of them.
This may sound too ambitious. In fact that was never my goal, but a goal of the developer community. I always found it desirable and realizable, but not by me alone. However I never imagined that I would realize it to the level that I've already done. I ever thought that this would be done by other people.
Who knows maybe I can see it realized. Maybe I find more people to join this vision. God will say.
UPDATE 03/09/2015 instead of cloud haskell, I developped my own distributed architecture, that is higher level; Transient:
http://github.com/agocorona/transient
Transient is based on the hplaygroud monad for handling events reactively. An event can be a mouse click, but also the arrival of data through a socket. The MFlow web server and and navigation can be implemented on top of that so the dream is closer to reality.
UPDATE 03/09/2015 instead of cloud haskell, I developped my own distributed architecture, that is higher level; Transient:
http://github.com/agocorona/transient
Transient is based on the hplaygroud monad for handling events reactively. An event can be a mouse click, but also the arrival of data through a socket. The MFlow web server and and navigation can be implemented on top of that so the dream is closer to reality.
