TSERS 2.x roadmap

[milankinen]

I'm creating this PR for TSERS 2.x release discussion and planning.

My proposed changes for 2.x are documented in roadmap.md document in this branch. Please feel free to comment and discuss about the proposed changes in this PR!

[milankinen]

See also issue #18

[codecov-io]

Current coverage is 97.98%

Merging #23 into master will not change coverage

@@             master        #23   diff @@
==========================================
  Files             1          1          
  Lines            99         99          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits             97         97          
  Misses            2          2          
  Partials          0          0          

Powered by Codecov. Last updated by b1b5d2b...1330375

[ghost]

I'm agree with your proposed changes. They look very nice!
I'm looking forward to TSERS 2!

TSERS = expressiveness + scalability = fun + productivity

[typeetfunc]

TSERS components would only return {DOM, Eff} pair

What about not-DOM application(server-side, console, native application)? Might be worth allow the user to define the main application Effect(DOM for web, HTTP for server-side etc.)?

[milankinen]

@typeetfunc Very good notice. Personally I wouldn't recommend TSERS or Cycle as a server-side architecture because request-response is point-to-point by nature, hence e.g. promise pattern works much better for it. But CLI...

How does for example {UI, Eff} sound? UI would then represent either DOM or CLI depending on the application type.

[typeetfunc]

@milankinen But why? Firstly Observables more general and more appropriate for implement architecture with first-class effects(cycle, tsers, ngeffects as examples). In second, modern web is very "real-time" - websokets, streaming, server push, subscribsions. Look at Appolo, feathers, horizon - all of them used observables for managing subscriptions.
I believe that you approach is very general and architecture with first-class effects/events is future of all "real-time" applications.