Towards a deeper integration: A Web language

When I wrote the article "How to solve the integration problem", in which I assimilate web development to a general integration problem, I was not fully conscious of how true it was. Web development is becoming increasingly a problem of integration of different technologies, languages paradigms and applications. Consciously or unconsciously web developers view web applications as a problem of integration. as essentially the development and integration of two or three independent applications: one in the browser, other in the server and maybe another in the database, with a dozen configurations that glue these things together.

That implicitly precludes the effort in the search for a higher paradigm that can be found by a deeper integration. That leaves essentially unresolved the problem of creating a true Web framework: A Web language. A framework in which the fundamental building block has data navigation presentation and storage and whatever other thing necessary inside itself. This building block that has all the components integrated, may be composed to build true web applications.

The situation is similar to the time when there were only batch systems.  There was no unification of input, processing and output. the programmer created a job  in a set of punched cards. The output of he job was sent to a printer. There were no interactive input-output. there were a input program, a processing program and a printing program. The applications ran essentially in the same way as a stateless web service  work.

Then, interaction was added. both input and output streams were intermixed. state was added. Each programming component may alternate repeated input and output interactions. When there were previously only batch processes, then there were development environments, shells, games etc. 

The building block for console applications had a higher level than the one of previous batch developments. The programmer managed abstractions in terms of the problem not in terms of the phase in the process in which the batch was executing for the hardware needs. That was because a new composable piece was found: the IO procedure, that combined input and output. The IO calls were a product on this revolution. that was a true revolution since it was an inversion of control where the program was in control of the flow. And a new kind of application was born: the interactive console application.

But essentially the IO procedure was the combination of small batch programs: the OS and library calls.  We don´t think on these small pieces as programs. we are so accustomed to work with pieces at a higher level that we do not even consider that. 

Can we do the same for the Web?. One may say that this new de-inversion of control will produce problems of scalability, state handling etc. All this is true. But they are the very same problem that the Operating systems had when switched from batch to interactive applications:  the batch systems did not leave state behind. They were fine and reliable. But people though that batch systems were not enough.

Can we do the same for the Web?. Unlike console applications. In Web applications the user must be in control, not the program. But the programmer must feel that he is in control of the flow.

That is not only possible, but highly desirable. If the fused building block is composable, we would have the Rosetta Stone of integration, a new unified language upon which to talk at a higher level with the machines for building web applications and since web applications are a particular kind of application integration, we can extend it to any kind of integration problem, as I mentioned in the article above.

Furthermore, if the building block and the composition make use of well known ideas then the task of making that language understandable becomes far more easy.

And now the marketing part. Excuse the bombastic tone, required in any marketing activity:

In the article mentioned above, I claim that MFlow do it. It is a Web language.  The MFlow building blocks are the widgets and the flow elements, (flowlets). A widget is an applicative or monadic piece of code with  a parser of request parameters and a writer of HTML code. It combines the creation of rendering, request parsing, processing and session management among other in a single atomic composable element. In the other side, a flowlet manage reusable and composable flows of pages, with state management.

People that know how to program monadic parsers will find natural how the MFlow monadic widgets works. People that know how to use formlets will find natural how applicative widgets behave.  If an user know how to create imperative code, he can create page navigations.

And the deep fusion of elements will give the opportunity to create easier solutions to known problems.

Soon I will add composable caching directives to MFlow, where a widget can express its own HTTP caching needs to the page, and I will show an example that uses this for caching javascript programs generated in the server by the haskell code to navigate a dataset without repeated accesses to the server.

Stay tuned.