6 ms·

React has this intended/unintended side effect of teaching functional programming concepts without making it obvious. For me, after finding out the core concep

React has this intended/unintended side effect of teaching functional programming concepts without making it obvious. For me, after finding out the core concepts of React (views are pure functions, functional composition etc.) are actually functional programming applied tastefully to rendering, I finally realized the elegance of functional programming, and since than I've been merging these concepts into my programming methodologies.

michaelchisari 10y ago
You should give Elm a look, then.
- pka 10y ago
  And after that, PureScript :)
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- hakanderyal 10y ago
  I'm really interested in Elm, it's on my 'things to explore' list. But I've already built a big 'component' library for my designs and style in React, and it's hard to justify a switch to anything else for a long time. And sadly that's the biggest problem the upcoming languages/frameworks face.
  - noir_lord 10y ago
    Yup, I still use knockout because I have components for nearly everything I do.
    - disease 10y ago
      Do you mix React and Knockout components by any chance? We are looking at moving from Knockout to React and I was wondering how painful this would be. My guess would be that if you are doing all or most of your KO stuff with components, then the switch shouldn't be too bad.
      - taude 10y ago
        I've done some mixing of Knockout and React. We had a custom datagrid that was taking a long time to bind up all the data with templates. I think it was made almost 8x faster for rendering moving it to a React component. This was a POC project done probably 18 months ago.
  - michaelchisari 10y ago
    Nothing wrong with that. I'm on a greenfield project with no particular deadline, so I chose Rust + Elm, but if I had to build rapidly, or had already committed a bunch of code in another framework, I'd definitely stick with that.
true_religion 10y ago
I think that's a big win. With React, you can see the use for functional concepts without having to switch to a functional programming language, or completely divest your codebase of 'friendly' object oriented techniques like class structure and subclassing. Similarly, I'd give a shout to MobX for showing me how observables can be used in practice. For the longest time I'd wanted to learn it, but I'd choke on the syntax and the generality of common libraries. Showing how MobX worked to simplify React code, gave an instant sense of success and things clicked afterwards.
- jiyinyiyong 10y ago
  MobX makes React simple because it's JavaScript. If you've write React with ClojureScript, you will find out that ClojureScript simplified React too. And people may also say ClojureScript is the magic piece that make React great.
  - true_religion 10y ago
    How would ClojureScript help here?
    - jiyinyiyong 10y ago
      I'm saying MobX is not the final answer for React. Behind React is the theory of uni-directional data flow. Observable in MobX looks nice and it fixes uni-directional data flow in JavaScript syntax of assignments. Seeing from ClojureScript and other languages that implemented persistent data structure by default, MobX is just a tricky solution designed for JavaScript. And ClojureScript handle uni-directional data flow well too with persistent data and atom type.
      - true_religion 10y ago
        Ah I see. I wasn't saying it is the final answer. It's just a 'good thing' because without it I wouldn't have learned observables to the depth that I did. It's a start... because it brings the concept to Javascript, a language that I'm already familiar with and have a build chain for. If one is going to switch languages, then you can consider the whole sweep of compile-to-JS languages. Elm is pretty nice in that scenario, and pairs well with my use of Elixir on the backend.

michaelchisari 10y ago

You should give Elm a look, then.

pka 10y ago
And after that, PureScript :)
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
hakanderyal 10y ago
I'm really interested in Elm, it's on my 'things to explore' list. But I've already built a big 'component' library for my designs and style in React, and it's hard to justify a switch to anything else for a long time. And sadly that's the biggest problem the upcoming languages/frameworks face.
- noir_lord 10y ago
  Yup, I still use knockout because I have components for nearly everything I do.
  - disease 10y ago
    Do you mix React and Knockout components by any chance? We are looking at moving from Knockout to React and I was wondering how painful this would be. My guess would be that if you are doing all or most of your KO stuff with components, then the switch shouldn't be too bad.
    - taude 10y ago
      I've done some mixing of Knockout and React. We had a custom datagrid that was taking a long time to bind up all the data with templates. I think it was made almost 8x faster for rendering moving it to a React component. This was a POC project done probably 18 months ago.
- michaelchisari 10y ago
  Nothing wrong with that. I'm on a greenfield project with no particular deadline, so I chose Rust + Elm, but if I had to build rapidly, or had already committed a bunch of code in another framework, I'd definitely stick with that.

true_religion 10y ago

I think that's a big win. With React, you can see the use for functional concepts without having to switch to a functional programming language, or completely divest your codebase of 'friendly' object oriented techniques like class structure and subclassing. Similarly, I'd give a shout to MobX for showing me how observables can be used in practice. For the longest time I'd wanted to learn it, but I'd choke on the syntax and the generality of common libraries. Showing how MobX worked to simplify React code, gave an instant sense of success and things clicked afterwards.

jiyinyiyong 10y ago
MobX makes React simple because it's JavaScript. If you've write React with ClojureScript, you will find out that ClojureScript simplified React too. And people may also say ClojureScript is the magic piece that make React great.
- true_religion 10y ago
  How would ClojureScript help here?
  - jiyinyiyong 10y ago
    I'm saying MobX is not the final answer for React. Behind React is the theory of uni-directional data flow. Observable in MobX looks nice and it fixes uni-directional data flow in JavaScript syntax of assignments. Seeing from ClojureScript and other languages that implemented persistent data structure by default, MobX is just a tricky solution designed for JavaScript. And ClojureScript handle uni-directional data flow well too with persistent data and atom type.
    - true_religion 10y ago
      Ah I see. I wasn't saying it is the final answer. It's just a 'good thing' because without it I wouldn't have learned observables to the depth that I did. It's a start... because it brings the concept to Javascript, a language that I'm already familiar with and have a build chain for. If one is going to switch languages, then you can consider the whole sweep of compile-to-JS languages. Elm is pretty nice in that scenario, and pairs well with my use of Elixir on the backend.