3 ms·
> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language" Well, it was prototy
by e12e 7y ago
> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language"
Well, it was prototyped in standard ml first[1], wasn't it? - then ported/re-implemented (shoehorned ;) into plain js.
So some things that sml has, and made sense in sml, had to become part of the library/language/framework that is react?
Later came reasonml (a ocaml dialect) which is a lot closer to sml than js - and I think the state handling reflects that, like the readme for reasonml variant of redux:
https://github.com/reasonml-community/reductive/blob/master/README.md https://github.com/reasonml-community/reductive/blob/master/...
"The code behind Reductive is incredibly simple. The first 40 lines include the entire re-implementation of redux. The next ~40 lines are a re-implementation of the react-redux library (without the higher-order component connect style implementation)."
In a sense, react has always been a design pattern - and a library to support/enable that pattern in Javascript.
[1]
https://www.reactiflux.com/transcripts/jordan-walke#come-idea-react-directly-inspired https://www.reactiflux.com/transcripts/jordan-walke#come-ide...
- lioeters 7y agoThank you for this latter link where the original author of React describes its beginning. After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is. The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data types, and foundation in lambda calculus and category theory. When you joked that it was "shoehorned" into JS, I got an insight into the reason why some design decisions in React feel awkward and strangely non-idiomatic. It explains, in part, the strong emotional reactions seen in this discussion thread, a number of justified opinions, its problems as well as benefits. I've been skeptical of the design of React Hooks, and still am, but now I'm interested in learning its influences, to understand the logic behind them. I wish that it had been implemented to be more "React-agnostic", like JSX, as generic extension to the JavaScript language.
- e12e 7y agoYou're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list. Ed: as an example, I found this (oldish) post on hooks in reasonreact: https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-building-a-pomodoro-timer-57h0 https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b... Compare as you will with a comparable one for reactjs: https://upmostly.com/tutorials/build-a-react-timer-component-using-hooks https://upmostly.com/tutorials/build-a-react-timer-component... Note - I would advice looking at the reasonreact documentation for up to date tutorials and guides... It's a quickly changing landscape. Eg: https://reasonml.github.io/reason-react/docs/en/usereducer-hook https://reasonml.github.io/reason-react/docs/en/usereducer-h... Finally I came across this - I thought maybe a sibling comment mentioned it - but a quick search didn't turn up anything - but imo it's a pretty strong argument for hooks (in js react) : https://tylermcginnis.com/why-react-hooks/ https://tylermcginnis.com/why-react-hooks/
- lioeters 7y agoNice resources! I've bookmarked them for later study. That last one I like, especially where the author recommends to "forget everything about lifecycle methods" and think of hooks in the context of synchronization. It makes sense, as a declarative way to describe state and state transitions. The aspect that's unsettling is that they're not idempotent pure functions, but rather deeply tied in with how React works internally. They can't be used outside of React, and require the programmer to understand the magic that makes them stateful. The common issues that beginner users of hooks encounter, like the "captured scope" of variables, or that hooks must be run in the same order every time, never conditionally - I suppose these are some reasons that make me (and other hook skeptics) react to them as "code smell". If someone had designed a library totally unrelated to React this way, I wouldn't want to use it. Looking at ReasonML, it's quite elegant and intuitive how React Hooks fit in. In fact, the code examples look very similar to how I structure my React projects, with state and actions (instead of a reducer or Redux, they use immer for immutable state changes). I'm staying open-minded about hooks, and I think the more I learn of its roots, the more I'll come around to accepting them as part of idiomatic React.