4 ms·

This reminds me Cycle.js. I would definitely think stream paradigm is very useful to front-end. The essential difference in front-end, is the programmer is dea

This reminds me Cycle.js. I would definitely think stream paradigm is very useful to front-end. The essential difference in front-end, is the programmer is dealing with continous, realtime signals, and transform it into the graphical interface. This is very different from most request/response style back-end. And the stream is obviously a proper abstraction for modeling this. However, I found it's tedious to work with RxJS or other stream libraries, not because the design itself, it's just JavaScript lack of flexible DSL machanism like macro. If you invent a DSL for a stream flow diagram, you can get a lot of very neat equations between source and sink, but for JavaScript it's very hard to abstract away the stream context syntactically.

lorean_victor 7y ago
> I would definitely think stream paradigm is very useful to front-end. I think it is theoretically possible to mostly deprecate VDOM with this paradigm, leading to better overall performance and control. > The essential difference in front-end, is the programmer is dealing with continous, realtime signals, and transform it into the graphical interface. This is very different from most request/response style back-end. And the stream is obviously a proper abstraction for modeling this. Even for the backend though, specifically for concepts like message brokers (or any similar construct based on application) I would think the paradigm is quite useful. > If you invent a DSL for a stream flow diagram, you can get a lot of very neat equations between source and sink, but for JavaScript it's very hard to abstract away the stream context syntactically. I personally tend to believe that the ideal DSL (representation) for flow diagrams is a graph (as it encapsulates both the logical and the execution flow), which means in the end of the day any textual representation would be sub-optimal (as any textual representation of any directed graph is sub-optimal and less intuitive compared to drawing the graph itself).

lorean_victor 7y ago

> I would definitely think stream paradigm is very useful to front-end. I think it is theoretically possible to mostly deprecate VDOM with this paradigm, leading to better overall performance and control. > The essential difference in front-end, is the programmer is dealing with continous, realtime signals, and transform it into the graphical interface. This is very different from most request/response style back-end. And the stream is obviously a proper abstraction for modeling this. Even for the backend though, specifically for concepts like message brokers (or any similar construct based on application) I would think the paradigm is quite useful. > If you invent a DSL for a stream flow diagram, you can get a lot of very neat equations between source and sink, but for JavaScript it's very hard to abstract away the stream context syntactically. I personally tend to believe that the ideal DSL (representation) for flow diagrams is a graph (as it encapsulates both the logical and the execution flow), which means in the end of the day any textual representation would be sub-optimal (as any textual representation of any directed graph is sub-optimal and less intuitive compared to drawing the graph itself).