Comment by Dashron | Hacker News Reader

Comment by Dashron | Hacker News Reader

I might be reading the blog wrong, but it seems he is using the MVC view (templates separated from the logic and sent to the user) and the user interface interchangeably. These are two very different things.

The interface the client uses is always going to be some sort of state transfer system, moving between different pieces of content and displaying elements to transfer between content.

Handling these views on the back end is an entirely different issue.

State machines are useful on the back end, but it can not be used between requests without causing headaches.

I have been experimenting with state machines in a node.js framework to handle asynchronous sub-views (https://github.com/Dashron/roads). It makes development incredibly simple, and breaks up the code so that you can have traditional, or single page apps with the same codebase.

I don't think a state machine would be useful at a higher level than this (in the backend) but I will put more thought into it.

I agree with your point just wanted to point to Nodejitsu node.js work that's highly relevant to it:

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

"Javascript is now an isomorphic language. By isomorphic we mean that any given line of code (with notable exceptions) can execute both on the client and the server. On the surface this seemingly innocuous property creates a number of challenges that are not solved by current MVC-based patterns. (...) In conclusion, we will explore a new pattern: Resource-View-Presenter."

Wow, Resource-View-Presenter is exactly my framework.

Except I call my presenter layer "resources" and my resources "models".

The state machine in my framework is a system within the view layer so you can asynchronously re-route through the "presenter" and re-use code.

I use state machine of sort (jbpm) in the backed to drive business processes. We have thin client connecting to database, nodes in state machine are actions on databes, or screens we show to user (with inputs possibly). Edges are transitions between screens. Edges can have conditions on them. It's all saved in database between requests, and request/response moves state throught transitions to the next interaction node (possible going throught a few action nodes doing sth on the databsae).

Any exception on the way rollbacks the whole state, and we commit only when we reach next interaction node.

It works great.

Reply on news.ycombinator.com