3 ms·
Frontend: Elm Backend: Rails|Phoenix Database: PostgreSQL I don't understand why people still write javascript except legacy codebase maintenance although I
by Existenceblinks 9y ago
Frontend: Elm
Backend: Rails|Phoenix
Database: PostgreSQL
I don't understand why people still write javascript except legacy codebase maintenance although I respect everyone's freedom. Especially, sorry, React/Redux why? Yet, people are obsessed managing state on client (browser), that's the bad days of whatever framework including Elm. 90' Game developers would wonder too since they often prevent corrupt states from bad people was trying hard to mess (cheat) game states, thus source of truth and constraints must only live on server. States on front-end must be just something only for sake of displaying.
- devopsproject 9y agoYou are conflating two ideas. Game developers protect state to prevent cheating. For example, allowing a player to update his location could allow teleporting or spawning tons of bullets\projectiles If a web developer creates an IM webapp, why should they care if you modify your local copy of the message data? It only affects your session and the next time you get a copy of the message it will be the original. All other users are still seeing the original
- Existenceblinks 9y agoI don't see any of what you said is opposite to what I said (Local message is just for sake of displaying) I think we meant the same thing.
- nkristoffersen 9y ago"Global" state should live on server. Only local state lives on client. I'm not sure how you are against react, angular, etc, since they only manage "local" state.
- Existenceblinks 9y agoI know any framework or any single line of code on client is all about "local" state. But when people lost focus they _potentially_ couple business logics, local truth and constraints with "Global" state from servers, and trust wrong source of truth. And that might end up with next corrupted, e.g. POST, requests.
- sboselli 9y agoBut then you're essentially talking about BAD code. Bad code is bad; in any language or framework. Don't blame the knife (in this case React/Redux or w/e), blame the person wielding it.
- pvorb 9y agoIf the knife has a sharp handle, it is to blame. Many frameworks have common pitfalls. I've got no opinion where these are in React/Redux though.
- Existenceblinks 9y ago> If the knife has a sharp handle, it is to blame Agreed, this is a good example. I am trying to avoid blaming React/Redux specifically because it's going to end up with a blog post. Tree nodes communication, composition and state. Imagine you have a 5-height tree, each node is an object that can receive properties from its parent (hell yeah, lightly inheritance smell), that's not that bad until all objects' methods (components' callbacks) execution orders come together (hell yeah, lightly recursion smell in _imperative ways_ while a normal recursion can be done in declarative way of thinking). Next turn, Redux. Connect a store to any level of tree you want, ahh that sounds handy but I have no ideas who setState, when and where. Saga|Thunk hmm this is slightly better since it is a separate middleware but wait, it's not completely isolated, anything _available_ for you there; Dispatch, Store, setState etc. Finally, all these built on top javascript ahhhh I personally suck at orchestrating these things.