Hey Scott, Actually, there _is_ another github project called flow-js ( https://github.com/willconant/flow-js ), which shares the goal of ordered execution. I took a gamble using such a generic term - but otherwise abhor trendy names. Hopefully, my work will be good enough, so folks eying the title won't be too miffed!
I understand the broad "Why" questions. (Why did you make it? Why should I use it?, etc.) I also appreciate your willingness to read my answer. While passion has taken me so far, clarity has proven my biggest obstacle. It is a simple question, and I hope to improve this answer over time... I created Flow out of frustration with a complicated web project. I started with clean reusable objects, simple custom-events, and high- level controller functions. Soon, with a looming deadline and many business-rule changes/revelations, I simply needed to "get it done", and wound up inserting logic where ever necessary. The code works today, but I wouldn't wish it upon anyone in the future... including myself. My experience is typical in the web industry - let alone, software industry. In fact, every web project I've worked on (and observed) has exceeded it's scope and/or resources. There are many reasons for this, but I'll focus on one: we expect requirements to be static, even though they often change. Once we've translated requirements into functionality (e.g., objects and methods), it becomes impractical to update them for every changing requirement - especially when we're far along in the development process. My nightmare project epitomizes how change kills code, and that's because we never code for change. [ I'm not talking about parameters and configurations, but process and logic. ] I vowed to find an approach to coding that reduced my translation efforts and optimized my implementation (of requirements). Most libraries focus on *solving* the problem, or are action-based. I wanted to focus on *defining* the problem, so I might identify how these actions related to the larger problem. I needed a context-based framework, and that's how I started Flow. Flow lets you describe a problem using incrementing contexts, called states. Then, according to the logic of your own terms and structure, you code to satisfy individual states instead of the entire problem. This is easier since requisite (parent) states will be satisfied by the time your code executes. Finally, as the problem (requirements) change, you can update your interpretation without destroying your surrounding logic. I hope this helps explain how Flow came about, why it exists, and what gaps it fills. Things are still fuzzy, but it's also my first attempt at explaining things publicly. I fully appreciate (all) your questions! On that note, to best _demonstrate_ why you should use Flow, I'm writing a walk-thru for the wiki. I'll notify this board when I'm done (tomorrow, hopefully). Many thanks for your attention and patience! - best, bemson On Apr 26, 6:18 am, Scott Sauyet <[email protected]> wrote: > I wrote: > > Do you have some simple examples? > > Never mind. I missed the examples page Stefan pointed out. > > I'll look at it soon. > > -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
