These are chat archives for jdubray/sam

21st
Apr 2016
Jean-Jacques Dubray
@jdubray
Apr 21 2016 05:55
@devghost I looked at your code, that's a great way to write tests. I was wondering how to use chai and mocha. I'll add your sample to Sam.Js.org if it's OK with you.
Robert Blixt
@devghost
Apr 21 2016 05:56
@jdubray thanks for reviewing it and I'd be happy if you added it :smile:
Jean-Jacques Dubray
@jdubray
Apr 21 2016 11:29
@brusand you are welcome, I think it's important to keep the View components as decoupled from the application as possible (no knowledge of the model structure and action wiring).
Jon
@jiyinyiyong
Apr 21 2016 15:14
I'm reading that post on InfoQ and I don't agree with the part about React. SAM is good doesn't mean React is bad. And that example of rendering page in string is like someone who hasn't write a single page app(something like Gmail, no full page refresh or even part of page, only update the changed elements). So it's totally talking about not React. Still reading the rest part...
Fred Daoud
@foxdonut
Apr 21 2016 15:21
@jiyinyiyong I think you have misunderstood. My feeling is that @jdubray is not against React at all, perhaps more about some of the other libraries and patterns around it.
@jiyinyiyong as for rendering the page with strings, I agree with you that this may not be a good implementation for larger single-page applications. However that is not the point of SAM. You could still use React to render the view.
@jiyinyiyong to be clear, I initially had the same reactions as you, so I understand where you are coming from :) It is from talking with @jdubray (who has great patience and is kind enough to explain things) and looking at more examples that I started to get a better idea of what SAM is, and what it is not. I would summarize it as, when looking at the code examples, focusing more on how they demonstrate the SAM principles and patterns, and less on some of the implementation details.
Jon
@jiyinyiyong
Apr 21 2016 15:26
I can see from the rest of paragraphs it was talking about SAM. Personally I'm working on React for long and that example is quite unfair to us. And the title is more like(Why I No Longer Use MVC Frameworks) saying existing MVC frameworks is wrong. I agree the part on Redux that it grabbed some right ... sorry I not fast typing in English..
Redux grabbed some right concepts, but because it's mostly running inside a browser and there are lot's of limitations. And it's not definitely a good solution for web servers. So I think comparing SAM to React and Redux is wrong, to me it's like comparing Node.js to Angular.js .
Jean-Jacques Dubray
@jdubray
Apr 21 2016 17:05
@foxdonut @jiyinyiyong React was actually the starting point of SAM (V = f(M)) and I highly respect that contribution. I am actually writing a React implementation of SAM that I will share soon.
That being said, as you both mentioned, the full programming model behind React, including Redux/Flux or even GraphQL is sold as being fully baked and ready to be adopted by the industry at large. I would challenge thoroughly that believe.
Jean-Jacques Dubray
@jdubray
Apr 21 2016 17:10
I would not be surprised if within a few months lots of people step away from React altogether, precisely because the other side of React (everything that's not V = f(M)) will lead to many architecture issues when trying to connect the front-end with the back-end. At some point something has to run on the server and React is really not good at that
I understand that when you have 2 B users the last thing you want is to run something on the server, but that's not the case of many many organizations. There is probably a few dozens companies in the world where React could make sense, after that you need a much better front-end/back-end architecture. That's the issue I have with React.
The fact that Redux for instance is able to break it's principle #1 (a single state tree) with Sagas is not encouraging. It shows to me that React's architecture is pretty much out of control and people like Dan are ready to trade architecture for traction.
This is the last thing our industry need, including the React ecosystem.
Fred Daoud
@foxdonut
Apr 21 2016 19:02
well said @jdubray
Stardrive ENGG
@HighOnDrive
Apr 21 2016 19:32

"State modification, side effect?!" The big question at the CycleConf this weekend. Hoping for a rational outcome, check it out here:

https://twitter.com/cycleconf
https://www.youtube.com/watch?v=sCMnBED5ZBE

Jean-Jacques Dubray
@jdubray
Apr 21 2016 21:33

Wow, the cycle.js conference is a "stream"!! Groovy!

With Frameworks, the Front-End/Back-End architecture seems to always be an afterthought. Either you get nothing like React and Cycle.js or you get some form of Data Binding which is worse than nothing.

When you don't need to persist your application state or it is as simple as persisting/fetching posts, you are probably ok. But that's not the kind of application I am working on. I help people architect OmniChannel applications and in that context the Front-End/Back-End articulation is essential. You cannot afford to coule your Front-End to your Back-End.

I have worked as far back as 2009 on this kind of problems and one of my client's biggest program had come to a halt because they could no longer produce the back-end APIs support their Front-End. That was a $1B program that had been very successful business wise, or even technically, one would have been considered to be state-of-the-art architecture, yet by applying the "vertical slice" pattern they had reached a point where everything change in the solution was extremely costly.

Stardrive ENGG
@HighOnDrive
Apr 21 2016 22:39
Yep, what you describe makes good sense. Really liking Horizon from RethinkDB as a robust backend: https://discuss.horizon.io/t/the-road-to-1-0/28
Jean-Jacques Dubray
@jdubray
Apr 21 2016 22:50

The "back-end" is rarely just a Database, if that was the case, life would be easy. There is business logic both application level and enterprise level that need to be factored properly to be reusable and maintainable. Patterns like BFF / Vertical Slice force you to reuse nothing, each time you have a new "screen" you create a new set of APIs. Worse ... sometimes you feel that is not quite right and you start reusing APIs that were built for another screen that's when you are dead. The absolute last thing you want to do is let the View decide which API it needs to call.

Redux had got it nearly right with "actions" and "reducer" but again, Redux actions are anemic (no chance to call an API) and the Reducer is a pure function (no chance to call a CRUD API). React was nearly there, but again, it's not in their DNA to think about this back-end / front-end articulation, then they came with GraphQL/Relay, which again makes sense for them, but GraphQL is again about the View calling an API... really? some days you just want to cry.

Stardrive ENGG
@HighOnDrive
Apr 21 2016 23:40

I'm making good progress working through my own application of state management and backend integration here. Learnt enough about MVI and SAM and have identified enough of my own reactive stages to put together a nicely abstracted solution. Just continuing to work/debug it by considering all aspects of my feature rich app.

For external APIs I am investigating Horizon and Partial Lenses. Utilizing these APIs is made much more possible by having done good engineering in the first place :smile: