These are chat archives for jdubray/sam

4th
Sep 2017
Łukasz Lityński
@hex13
Sep 04 2017 14:34
I think Redux community entered the "cargo cult" stage (need for Redux itself, but also code artifacts like action constants, action creators or switch/case statements i.e. things that Redux does NOT require, but people put them in the code just because everyone else does that. It's tradition, not a pragmatism). So the biggest problem with Redux is not technical but psychological (i.e. most of programmers are believers rather than thinkers).
And there is a lot of Stockholm syndrome in Redux community - which stops innovation because people get used to Redux and don't want to try other approaches (even abstractions don't really abstract much. Most of Redux abstractions I see operate on the similar abstraction level (I.e. actions, reducers etc. They just move things around in other places they were originally. I think good Redux abstraction should abstract Redux concepts itself (even reducers, or immutability)
Łukasz Lityński
@hex13
Sep 04 2017 14:40
But honestly I don't see any future of Redux (BTW it's very good proof of concept! I'm glad Dan Abramov made this. It has good fundamentals and it allowed for inspiration for other libraries). Nevertheless I think using Redux in more complex apps than ToDo List is just cumbersome and I think this library will fade out of fashion in 2018 (and there will be huge amount of legacy code to maintain).
Jean-Jacques Dubray
@jdubray
Sep 04 2017 16:05
@antanas-arvasevicius if history can help, so far, not a single UI framework stood the test of time, not even close. I am sure it's easy to think, "but this time is different" or "we tried so many times, that one day we'll just get tired and we'll pick the last one standing"
For me that's why I prefer "raw" ES6/HTML5/CSS3. A language doesn't "break" easily. All the code that you have written generally continues to run, years after it was written, and if not, the adjustments are minor, when did someone rewrote an app after a language/SDK update?
Jean-Jacques Dubray
@jdubray
Sep 04 2017 16:11
@hex13 the biggest issue I have with React or React + Redux or Redux alone is the lack of consideration for API calls. I'd say the programming model goes in the right direction but they missed that turn and seem to not care about it. As I wrote in my "no MVC" paper, front-end developers call the shots when it comes to defining the shapes of APIs, but that's truly a curse. This is how products fall apart, one API at a time until the weight of the front-end can no longer be supported.

I mentioned it in a discussion a few days earlier:

so when you need to make an API call you need to do is outside the redux/render loop

That was true too in the early days of React where it was virtually impossible to weave API calls in React components. Then Flux came and tried to address that, then React came and drove the entire community back towards front-end with cool dev tools like "time travel"
It takes about 2-3 years to develop the symptoms of a poor API architecture, after that it is too late, in general you need to abandon your project/product because the cost of maintaining it is too high.
Facebook saw that problem coming, so they created GraphQL, but GraphQL can't work with for create/update/delete. The very problem of "Front-End" driven API design is that Front-End concerns are orthogonal to Systems of Record and Consistency.
Jean-Jacques Dubray
@jdubray
Sep 04 2017 16:16
Other than that, I truly think it's a shame because React had made a big leap forward and they took it all away.
On a completely different topic, I found this article really interesting in the context of STAR: "JOIN Elimination: An Essential Optimiser Feature for Advanced SQL Usage"
Ultimately, it's really key to clearly layout your programming model, regardless of the framework or language, otherwise, you are pretty much using snake oil, even if the people who are making/selling it don't even understand that's just snake oil.
Łukasz Lityński
@hex13
Sep 04 2017 16:40
thanks :)
Antanas A.
@antanas-arvasevicius
Sep 04 2017 17:26
Hi there
I've seen many project which uses raw js/html/css and they were unmaintainable, because every UI component was written from scrach and used inconsistently e.g. List grids copy pasted to different pages and changed, drop downs was also patched, e. g. Drop down with multi columns
Antanas A.
@antanas-arvasevicius
Sep 04 2017 17:31
With auto complete
And sorting
Antanas A.
@antanas-arvasevicius
Sep 04 2017 17:54
See no point to reinvent rich gui components
Jean-Jacques Dubray
@jdubray
Sep 04 2017 19:01
I beg to disagree, functional HTML changes everything, it's quite the opposite.
Jean-Jacques Dubray
@jdubray
Sep 04 2017 19:07
I agree that a traditional JQuery app would quickly become unmaintainable.
It's very natural to decompose a UI/tree in functions, I don't even need vdom as I explained earlier.
but I am not against usign that type of library. I am against using a framework that will trap your business logic, especially when it doesn't know how to deal with APIs.
Łukasz Lityński
@hex13
Sep 04 2017 23:34
and where APIs belong? I always wonder. The best I came up with is to isolate API calls in some sort of abstraction/wrapper or/and to put them in different layer.
and what is "API"? (to be sure we're on the same page). Do you talk about for example AJAX calls or interacting with some special third part library?
Łukasz Lityński
@hex13
Sep 04 2017 23:43
and what do you think about dependency injection for injecting API? i.e. creating services like in AngularJS and inject them to the functions. This approach could allow for mocking or virtualize APIs (to remove side effects).
Łukasz Lityński
@hex13
Sep 04 2017 23:49
I mean something like this https://jsfiddle.net/d4xktn8p/1/