These are chat archives for jdubray/sam

7th
Feb 2016
Jean-Jacques Dubray
@jdubray
Feb 07 2016 00:04
Ok, adding a sample to sam-examples room
Stardrive ENGG
@HighOnDrive
Feb 07 2016 00:07
@jdubray Very interesting, an obvious nap to me is the way a Rx observable works, they all have onNext functions that operate with whatever predicate function you provide to them.
Jean-Jacques Dubray
@jdubray
Feb 07 2016 00:09
Yes, absolutely! but you are doing it in the dark without understanding which control state you are in.
nap gives you access to the "true" next-action based on the state of the system.
Jean-Jacques Dubray
@jdubray
Feb 07 2016 00:21
thank you for the discussion, really enjoyed it and all the hard work from Fred and Bruno, I have to step out for a few hours.
brucou
@brucou
Feb 07 2016 00:32
sure, it is good to take a break
Stardrive ENGG
@HighOnDrive
Feb 07 2016 01:05

To bring my story to the table I'll lay it out by saying that I've been creating a large app with many options. I've been through a number of technology stacks and at the end of the day I had a desperate feeling of having to save the higher purpose of my app from the straitjacket frameworks and languages that have been available.

So what did I end up with? Essentially a state-machine and execution flow pattern that is feature driven and where it no longer really matters much what damn framework I use or if I use one at all.

How did this come to be? Well first off the app I'm building involves multiple tools that need to be used together in a natural way and then there were the endless variations that my industry wants, so I needed to accommodate all this.

So how did it turn out? In the end my app was stratified into configuration based models, logic modules, UI surface widgetry and the core thin client, with almost all of it residing on a BaaS.

Configurations turned out to be a key, with two primary ones, a schema for the apps content and what I sometimes have called a manifest, a one atom type of model representing the apps constitution.

Lets focus on the app constitution, which is comprised of many states. Since it is a configuration that can be stored, activated and exchanged the JSON format turned out to be very handy. The JSON graph is then a map with states that can be transitioned between.

From here I discovered all the ways I can activate states and what all their possible params expressed as simple KV pairs could be. This arrangement afforded me a place to put everything from scalars to nap auto invoked ops plus the total environment a given app tool/mode/state needed to work with, in an open ended way.

So I had all this in the bag and arranged, then I encountered Cycle.js. The immediate thing I like about it is actually simple but a nice abstraction not seen in other frameworks, namely the Intent part of the MVI pattern that Cycle.js promotes.

In my design up to the time and had already been calling this abstraction the membrane. Because I wanted to separate myself as much as possible from the DOM event capture mechanizm and jump straight back into my logic module functions. I had really started hating frameworks by this time and did not want to be entangled in them more than necessary.

OK, that brings the story to now where I have the patterns I've discovered and then MVI and SAM on either side. I believe that there is a good synergy between all patterns.

However, I have found that the Cycle.js community is largely sold on the idea that Rx can be used to dynamically calculate all state and therefore Cycle.js has a very under developed and meager model. So, I'm glad you have put forward SAM because my overarching app pattern is a hybrid between MVI and SAM.

I'll end this here for now, I'm hoping to align the key entities from MVI and SAM and see what that gives. Also, I have some more ideas on how this works itself out in code flow.

@jdubray "nap gives you access to the "true" next-action based on the state of the system". These would also be defined as a KV on a given tool state. Some of the tool states are quite elaborate and represent a complete flow control strategy that can be tweaked by the user.
Rob Wormald
@robwormald
Feb 07 2016 02:23
hey there
read the article, very interesting discussion - i'm a core dev on angular2 and mostly working on our reactive stuff with RxJS (it was linked in our internal slack channel)
figured i'd join the party :D
Stardrive ENGG
@HighOnDrive
Feb 07 2016 02:27
@robwormald Cool and good to see you. SAM seems like it is relevant to most frameworks :+1:
brucou
@brucou
Feb 07 2016 02:27
@foxdonut > My attempt at improving the code example stalled at this: http://codepen.io/foxdonut/pen/GoYyPG?editors=1010
Ok sorry about that I am not very skilled with this tool
@foxdonut
you have a point that putting the listener directly in the html resulted in a not-so-clean and certainly not scalable style. When you have the time, have a look at my proposal, I think it is basically cycle.js but hand made, i.e. I wire the cycles manually (I have two of them, one for the side effect on the model, one for the DOM side effects). Ideally you would take the SAM_component properties and wire it somehow with cycle.js API.
brucou
@brucou
Feb 07 2016 02:33
Also, I am currently investigating whether it makes sense to regroup the actions executions (which can have side-effects too) in a driver too.
@robwormald welcome to the party. Have you read the part about the channel for examples?
Rob Wormald
@robwormald
Feb 07 2016 02:37
yep, thanks.
my (brief) 2c - after a fair number of years doing UI / front end / Cocoa / web dev, i'll say that redux (let's call it the pattern, lower case r, vs the React implementation) is far and away the clearest and most testable implementation of just about anything i've used previously. redux implemented with Observables (specifically, .scan() ) is that much better, in terms of how I think about how front end applications work
Rob Wormald
@robwormald
Feb 07 2016 02:44
angular2 and react, properly used, are nowadays just two different opinions on translating model state to DOM. and most of the complexity of perfomant web applications comes from that translation (which is, with all respect, often glossed over by non-front-end developers) - the DOM is a slow, strange beast
i'm a massive, massive fan of cycle, it informs a lot of the current design we're working on around reactive ng2. andre's talk (what if the user was a function) sort of changed how i think about front end dev in general
brucou
@brucou
Feb 07 2016 02:54
Interesting comments rob. Note that the theoretical framework that support this pattern comes from distributed computing systems. This is an environment where resilience (tolerance to failure) is key, and eventual consistency is hard to guarantee. Think how hard it is to reason about a program that is single-threaded, then about one that is multi-threaded, then about one that is distributed and some nodes might be there or disappear at any time without notifying etc.
This pattern is in the line of helping with problems encountered in those contexts. What I want to say is that it is not just a front-end thing, I believe it should bring more value in highly distributed systems where keeping track of states is a nightmare.
Not to say it is not useful for front-end, just that there might be other tool for simpler problem. A common problem in some context of state machines is that, under the standard formalism (an action as an arrow from a state to another one) you end up with HUGE state machines for doing simple things (recognizing a not-so-complex simple expression).
brucou
@brucou
Feb 07 2016 03:01
So while having the state machine guarantees a certain number of nice behaviours (correctness, ease-to-reason, etc.), you still have to write that machine, so it will be interesting to see if the reversal of the graph (Sk, A, Sk+1) where an action is an edge linking two states vs. the co-graph where a state is associated to all its edges (Sk, Ak,j) results in a more productive process.
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:05
@robwormald welcome! honored to speak to you. If you like Redux, well, SAM is the correct semantics that Redux should have had. It tried to speak to Dan about it, but he never replied to me. SAM's semantics are based on TLA+ so you can't find a more robust formalism.

@robwormald

translating model state to DOM

My take on it is that you don't need either React or Angular. I am certain you could show me an example or two where they add value, but for 98% of the cases I see, they simply don't (compared to the incidental complexity).

Rob Wormald
@robwormald
Feb 07 2016 03:08
i think that depends on what you define as "value"
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:08
Value is the time it takes to get something done correctly (time-to-production)
Rob Wormald
@robwormald
Feb 07 2016 03:08
your take often comes up, and i would say that in any sufficiently complex front end project, you end up rolling your own "framework" anyway
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:08

@brucou

you still have to write that machine

well, the problem is that you have to write that code anyways, it's not like writing the machine is optional, you may think it is, but in the end the code you write must be equivalent to the state machine, in simple cases, you can use approximations and get it right, but on average the state machine will be more correct and save time for more complex projects

Rob Wormald
@robwormald
Feb 07 2016 03:10
having worked in both the "trenches" of startup app development and now on development of actual frameworks, i've been down both roads and for most cases, i'd pick the framework in either case
as an app dev (vs a framework dev) one's job is "getting it done" - rolling your own psuedo-framework almost never works out on a team of more than say, 3 developers
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:11

@robwormald

you end up rolling your own "framework" anyway

I'd like to challenge that, with the proper factoring, I would argue that the need for a framework goes away.

brucou
@brucou
Feb 07 2016 03:12
I would argue that the framework is precisely that factoring.
Rob Wormald
@robwormald
Feb 07 2016 03:12
indeed
brucou
@brucou
Feb 07 2016 03:12
just the factoring of somebody else
Rob Wormald
@robwormald
Feb 07 2016 03:12
somebody else with a huge amount of pre-testing done against it
brucou
@brucou
Feb 07 2016 03:13
:-)
Rob Wormald
@robwormald
Feb 07 2016 03:13
here's an example i came across today -
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:13
That's why when it comes to factoring code, you might as well go to the source and start with TLA+, then move your way up as you identify classes of problems and provide more optimized factoring for these classes of problems
(if you don't know much about the browser's event loop, that's a great place to start)
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:14
For instance, Redux does not have a next-action-predicate. Then what do you do? actions start updating the model or the model starts calling actions.
Rob Wormald
@robwormald
Feb 07 2016 03:15
but you'll note that before you even start thinking about what's happening, you've got to contend with the fact that code doesn't even execute in the same order across the modern 4 browsers
brucou
@brucou
Feb 07 2016 03:15
@jdubray let rob develop his point please. It is hard to follow conversations in this chat format.
Rob Wormald
@robwormald
Feb 07 2016 03:15
literally the same 5 lines of code act completely differently across them.
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:15
ok
Rob Wormald
@robwormald
Feb 07 2016 03:16
and so that's where the value of frameworks come in. I as a framework developer have spent the last 48 hours of my life bashing my face against the keyboard across 4 browsers on 3 OS's, simply because code executes out of order
so you as a app developer don't have to
"everybody has a plan until they get punched in the face"
95% of front end developers couldn't explain to you what a microtask is - even competent ones (i didn't, properly, until recently)
brucou
@brucou
Feb 07 2016 03:18
rob, let us know when you have finished your line of argumentation
Rob Wormald
@robwormald
Feb 07 2016 03:18
none of this is to say that formal methodology has no value - of course it does - but it often feels a bit like high school kinematics, which are easy if we can ignore air resistance, you know?
but unless you've hit the bug where a Promise executes before a timeout in safari but not in chrome, its easy to say "you don't need a framework"
(nearly done)
so my point is i think that there's a huge amount of value in the sort of thing you're advocating, but the pragramatic side of me says "okay great, but i gotta ship"
/rant
(sorry, one more thing)
async is probably the hardest thing to deal with for JS devs, and fwiw, that's why i'm a massive fan of RxJS, because it smooths out a lot of the above hair pulling in favor of sequences)
/end rant
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:23
@robwormald Angular2 is close to 500 classes/semantics, do you really think that's what is required to build a Web app? The core package is 180 classes.
Things are that broken? perhaps you may want to fix things a bit closer to the source.
Rob Wormald
@robwormald
Feb 07 2016 03:25
its really more like, 10
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:25
It's like building a rocket that ignores gravity, and then adding a control system to fix it, maybe you can build the rocket in a slightly better way
Rob Wormald
@robwormald
Feb 07 2016 03:26
the thing is, we're at the mercy of the DOM. which is not implemented by us, nor consistently by those who do
(note i'm not saying ng2 is the bees knees any more than react or cycle or mithril)
but there is value in frameworks and virtual DOM and the like
your typical server side / distributed application runs in a reasonably guaranteed environment, would you agree?
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:27
yes
Rob Wormald
@robwormald
Feb 07 2016 03:28
i'd certainly grant that it comes with its own set of problems (fault tolerance and the like, as @brucou mentioned)
but state management (redux et al) are trivial, as compared to the enviroment in which a web application runs and its bugaboos)
and for what its worth, i love the fact that frameworks exist, because they solve the annoying issues and let me focus on building applications
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:31
To be honest, from the trenches, it is exactly the opposite, frameworks like React and Angular get in the way of building stuff, and stuff you can maintain.
Rob Wormald
@robwormald
Feb 07 2016 03:31
and while a server side developers "deliverables", shall we call them, are things like consistency and not-losing-all-the-damn-data-in-the-database
front end developers deliverables are more often than not "60 fps scrolling on crappy android 4.0 devices"
brucou
@brucou
Feb 07 2016 03:33
I am not sure the numberof classes, whichever you choose to count it is a factor positive or negative in the target improved productivity. I mean a turing-machine have very few instructions and is essentially equivalent to any programming language. Now try writing any program with a turing machine. So I believe the complexity argument is not relevant when choosing a framework. Each framework is a refactoring among a set of fault-lines that the refactoring seek to fix. Angular1, 2, x will make it easier to be do some things, and it will be harder to do others. So choosing a framework is about knowing which one will help you attain YOUR goals. Basically I don't think every program should be rewritten following TLA+ only those who are worth the pain. Some people want to write a decreasing counter, some want to write a word-of-the-day and some must program distributed databases. To each his own set of issues and set of tools to address it.
Rob Wormald
@robwormald
Feb 07 2016 03:33
"it should look roughly the same in 4 browsers across 11 versions because our-budget-doesn't-allow-us-to-use-anything-other-than-IE8-but-we'd-really-like-our-customers-to-use-it-on-their-iphones"
brucou
@brucou
Feb 07 2016 03:34
So what I am saying, is that blunt affirmation of the kind you are doing JJ is showing a lack of understanding of the variery of use cases.
Rob Wormald
@robwormald
Feb 07 2016 03:34
@brucou that's mostly what i'm saying, i agree
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:35
Possibly, such as the affirmation that the semantics of Angular1 or 2 drive IT organizations to write code that's cost-effective and maintainable.
Rob Wormald
@robwormald
Feb 07 2016 03:35
if i had a "design pattern" (lets not call this a framework, for clarity) you're describing, i'd still have to deal with all the browser idiosyncracies and i'd still struggle to make it performant at 60fps
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:36
The problem is that I may want to go native for iOS, hybrid for android and build some Web app in an old portal. Where does Angular or React help?
I don't doubt that there are some problems that look like the one you are describing
Rob Wormald
@robwormald
Feb 07 2016 03:37
"some problems" = 99% of the crap web developers deal with on a day to day basis
or i should say, 99% of the time-sink crap that nukes everybody's time estimates for delivery
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:37
but there are an equally or larger class of problems in IT where people are ready to accept tradeoffs in that area, as long as building their solution does not cost an arm and a leg
Rob Wormald
@robwormald
Feb 07 2016 03:38
(re: the iOS / hybrid / web app question, in ng2 or react you'd write the vast majority of your logic in JS decoupled from anything frameworky, and both allow you to use different rendering engines)
brucou
@brucou
Feb 07 2016 03:38
JJ your experience is predominantly back-end right?
Rob Wormald
@robwormald
Feb 07 2016 03:39
the brilliant thing about for example, Redux or RxJS is that its entirely framework agnostic, and works equally well (and is portable) between frameworks
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:39
Look in the end, SAM does not preclude using React or Angular, SAM is just a pattern, so I don't want to argue whether you need or don't need a framework, at least SAM offers a choice not to use React or Angular,
Yes, I come from the back-end
Rob Wormald
@robwormald
Feb 07 2016 03:40
well, if you're looking to push such an idea forward, imho, you'll have an easier time saying "this awesome pattern works with your framework of choice" vs "this awesome pattern means you don't need a framework"
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:41
The part that I don't like in this argument, is that you assume by definition that a framework will solve more problems than it creates, which I would tend to disagree with.
brucou
@brucou
Feb 07 2016 03:42
Then you have dealt with a very different set of issues than a front-end developer so I am not surprised you would hold different views.
Rob Wormald
@robwormald
Feb 07 2016 03:42
then, frankly, you haven't done enough front end development ;-)
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:42
Maybe...
Rob Wormald
@robwormald
Feb 07 2016 03:43
now - i will say that i've been in some shops where developers have no idea what they're doing, and they've entirely coupled all of their business logic to a framework
angular1 is particularly bad about the "angular way" - it has a lot of its own idioms that can tangle you into non-portable code
its a conscious decision in ng2 to be much less opinionated there, and leverage the JS ecosystem (think ES6 modules, which didn't exist when ng1 modules were invented)
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:45
The general problem is more around the relationship between APIs and Front-Ends, that's where frameworks kill you and push you to use stuff like BFF.
brucou
@brucou
Feb 07 2016 03:45
bye guys I am off. Thanks for the nice conversation
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:47
What you may gain in browser independence you sink it in the back-end. In the end, the only thing that counts is time-to-production. That's when I argue that the argument with/without a Framework is not that clear cut.
Rob Wormald
@robwormald
Feb 07 2016 03:47
that's where frameworks kill you and push you to use stuff like BFF. <- i'd disagree there. the problem is that most frameworks dont make a recommendation there
the fact that neither angular or react provide any tools for it means its the wild west out there for that problem
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:48
yes, but they do it indirectly, they offer some sugar called "databinding"
and the argument goes, you save 3 lines of code in the front-end and you end up writing 300 more in the back-end
Rob Wormald
@robwormald
Feb 07 2016 03:49
i don't quite see how those two are related
whether you call it a component or a view or a controller or a whatever, you have some slice of state to be rendered as a UI
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:50
well, perhaps that's the problem
the Front-End developers require that the model be shaped to fit the views
That's what I tried to solve with SAM, and I believe I did.
In SAM the view no longer calls anything. It triggers an action. At the other end of the reactive loop a new view is produced a la react.
that is, more or less, precisely what a react stateless component is
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:52
precisely my argument, that's why you don't need react
Rob Wormald
@robwormald
Feb 07 2016 03:52
except that your version falls apart for anything remotely resembling a modern web application
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:53
Creating a stateful UI component is an ignominy (stateful from the model perspective, not something like a wizard)
Rob Wormald
@robwormald
Feb 07 2016 03:53
i agree there. react and angular agree.
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:53
Please elaborate, because I certainly don't see it in practice where it falls apart
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:54
I am sure you can find some edge cases, but again for the typical IT digital solution...
Rob Wormald
@robwormald
Feb 07 2016 03:54
if you're simply wiping out the entire div and re-rendering, you haven't solved the problem
because it might work, but it won't be performant whatsoever
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:55
Again, nothing prevents you to use that kind of technology if you want, what I am arguing is that 98% of the time, this is overkill.
Rob Wormald
@robwormald
Feb 07 2016 03:55
i'm saying its the other way around. maybe 2% of the time you can do it with vanilla JS
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:55
I find actually react so performant that it degrades the UI, it just goes too fast
That's not what I see in IT
Rob Wormald
@robwormald
Feb 07 2016 03:56
define "IT" - internal b2b applications?
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:56
Say mobile banking
Rob Wormald
@robwormald
Feb 07 2016 03:57
like your average wells fargo app in the app store, lets say?
Jean-Jacques Dubray
@jdubray
Feb 07 2016 03:57
Yes, exactly. Let's keep check deposit out of scope
Just pure account maintenance (list of transactions, schedule some payments, ...)
98% of IT apps are these apps
SAM allows to write state representation in different technology running either on the server or the client
60 fps is not an issue, at least on my bank account
Rob Wormald
@robwormald
Feb 07 2016 04:00
perhaps i spend more money than you ;-) but my wells fargo app on my iPhone 6S is rubbish
Jean-Jacques Dubray
@jdubray
Feb 07 2016 04:01
I didn't write it ...
Rob Wormald
@robwormald
Feb 07 2016 04:01
of course not!
the problem (especially on mobile) is that what works on the modern browser doesn't necessarily apply on anything > 2 years old (think android 4.1, which is still ~20% of users, iirc)
Jean-Jacques Dubray
@jdubray
Feb 07 2016 04:04
Again, Rob, SAM allows me to create these stateless components by the dozen at very little cost with no skills. An HTML designer can write the file you pointed out, no need to pay an angular resource
Everything else plugs into these state representation functions.
Again, think in terms of time-to-production, not if this piece of code is easier to write or not
Again, happy to take on a challenge (comparing lines of code, since I don't code for a living and I cannot spend full time on in, so we can't really compare time)
Rob Wormald
@robwormald
Feb 07 2016 04:06
that's precisely my point though - time-to-production is the biggest thing affected by all the browser idiosyncracies we're talking about
Jean-Jacques Dubray
@jdubray
Feb 07 2016 04:06
that's not what I see,
I am certain that there are some inextricable problems in that area and frameworks can solve a lot of them, but it seems to me that:
1) not everyone encounter these problems (responsive design/bootstrap helps a lot)
2) they create a lot more problems that you don't see because they show up in the server
apologies rob, but I have to go, it's really interesting to have your point of view. Again happy to take on any challenge, as long as it is reasonably representative of IT apps
Rob Wormald
@robwormald
Feb 07 2016 04:10
indeed, good chatting. always nice to discuss. what i'd love to see would be a SAM representation of such a thing, runnable (perhaps on github / bitbucket) that's agnostic of view stuff
believe me, if there's a usable pattern for solving the hard problems of client-server state managment, that's agnostic from the view side, then i (and many others) are all ears.
Fred Daoud
@foxdonut
Feb 07 2016 04:28
@robwormald nice to see a core ng2 Developer. I would love to discuss some ng2/RxJs ideas with you soon if you are interested.
Rob Wormald
@robwormald
Feb 07 2016 04:31
shoot!
Fred Daoud
@foxdonut
Feb 07 2016 04:39
I don't have the code handy with me atm but what do you think about being able to render Observables directly in view templates?
Rob Wormald
@robwormald
Feb 07 2016 04:40
or in angular/angular for that matter
Fred Daoud
@foxdonut
Feb 07 2016 04:44
Will do, but I need code to which I don't have access to atm. I don't want to waste your time, so when I have my ducks in a row I will elaborate.
Rob Wormald
@robwormald
Feb 07 2016 04:45
short answer is yea, its awesome, it works already, and its how i do everything, and it has pretty massive perf benefits