4 ms·

I am with you. React as originally designed made sense to me. You render the screen point-in-time and React takes care of updating the screen efficiently. This

I am with you. React as originally designed made sense to me. You render the screen point-in-time and React takes care of updating the screen efficiently. This is all I need from React. Everything else is bloat.

e12e 5y ago
Wasn't react first designed in standard ml, without classes? Then classes were bolted on in the js rewrite - and hooks are closer to the original design? https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke > So I continued to explore framework-izing these ideas, and I had implemented several iterations of what eventually became React, in a few languages - one of the first explorations began as a rough implementation of the reconciler and component model in Standard ML (CreateClass was a "module function"). This was really great because SML embraces immutability by default which is natural when building React style components. We naturally wanted to deploy UI to web browsers, and at the time, the compile-to-JS landscape was not as mature as it is now - I don't even think source maps existed yet. So it made sense to port that exploration to JavaScript (...) > One thing I noticed that when people were creating point to point bindings in their more traditional "MVC" app structure, it would almost always end up requiring "computable" bindings which invoke a function anytime a mutable cell had received a "change event". All these "computable bindings" ended up chaining together and small changes would end up causing large recomputation of the majority of the UI. I realized that functions already do transform inputs into outputs, and if we could just find a way to reinvoke those functions repeatedly, and quickly enough, that we could be much more expressive and concise, at not much more performance cost that the chain reaction that "computed bindings" would result in anyways.

e12e 5y ago

Wasn't react first designed in standard ml, without classes? Then classes were bolted on in the js rewrite - and hooks are closer to the original design? https://www.reactiflux.com/transcripts/jordan-walke https://www.reactiflux.com/transcripts/jordan-walke > So I continued to explore framework-izing these ideas, and I had implemented several iterations of what eventually became React, in a few languages - one of the first explorations began as a rough implementation of the reconciler and component model in Standard ML (CreateClass was a "module function"). This was really great because SML embraces immutability by default which is natural when building React style components. We naturally wanted to deploy UI to web browsers, and at the time, the compile-to-JS landscape was not as mature as it is now - I don't even think source maps existed yet. So it made sense to port that exploration to JavaScript (...) > One thing I noticed that when people were creating point to point bindings in their more traditional "MVC" app structure, it would almost always end up requiring "computable" bindings which invoke a function anytime a mutable cell had received a "change event". All these "computable bindings" ended up chaining together and small changes would end up causing large recomputation of the majority of the UI. I realized that functions already do transform inputs into outputs, and if we could just find a way to reinvoke those functions repeatedly, and quickly enough, that we could be much more expressive and concise, at not much more performance cost that the chain reaction that "computed bindings" would result in anyways.