BigPicture

[Inkdpixels]

Sooo... Do we agree on the need of a big picture beforehand?

For me, this organization definitely should aim at being a "framework", but not a typical framework where everything is bundled into one big monolith. We should prioritize that each package should be abstracted and could be used individually, and still harmonizes with the other packages(Duh! This could be hard, but it's possible - And why go the easy way if you can lay bricks in front of you!).

I told @grebaldi today that we definitely need Example Components, but also examples for applications like the typical ToDo-App or a Code-Editor or the like. These examples could be used to pinpoint our goals - small packages, which play nicely hand in hand and creating a solid foundation.

@akoenig @grebaldi

[akoenig]

I'm definitely in favor of the highly modularized approach. This should be a major goal. Each library must be highly decoupled so that is possible to use it in several, different contexts.

I guess that even when we provide each lib separately, it might be a good idea to build an abstraction layer on top of it. For people who are used to work with bundled frameworks which provide a clean easy-to-use API.

[grebaldi]

One of the most remarkable things about this is, that reduct maybe would be the first sophisticated MultiPage App targeted framework since the old days of the $-war. Still it is not limited to that, so there is literally no conversion between SPA and MPA - which is quite nice.

We should embrace the fact, that any client application is part of a bigger, multi-channel ecosystem, so reduct should aim to enable as much and restrict as little as possible. There is no need to impose our MV*Blech concept on people who don't need it. There is no need to speak a different language than JS itself. There is no need to put framework boilerplate around stuff that works out of the box.

Some buzzwords that are already there:

• npm ecosystem
• es6/es7
• declarative
• prefer immutable over mutable
• single point of entry
• modularity

Some things, we could/should reason about:

Do we need a Controller Layer?
Why the heck should we?

Do we need a Model Layer?
Nope. But we certainly need a well-defined interface for arbitrary data sources for our components.

Do we need a server communication library?
Nope. fetch all the things.

Do we need Routing/Application state handling?
Meh. Somehow... Maybe... Don't know. There's problably a non-intrusive solution already for this.

Do we need an Event System?
There we go -> We do! And as @akoenig stated, it needs to be some really cool stuff that solves events forever :D

What else do we need?
Everything that's not there yet and too genius to be ignored ;)

This my two-cents in form of a large buzzword-compilation. This is neither complete nor an actual proposal for how the framework should look like. But I feel, this sums up some general mood-driven things and maybe adds to the Big Picture :)

As a last statement, I'd like to add:
precompilation is our friend.