5 ms·

> Almost all of my React code is "called by React" with the one exception being `ReactDOM.Render()` It only feels this way because your calls to React are hidd

by Drew_ 5y ago

> Almost all of my React code is "called by React" with the one exception being `ReactDOM.Render()` It only feels this way because your calls to React are hidden away behind JSX. I believe this is also why you can't write any JSX without importing the React module first. If you've ever had the "pleasure" of writing React with plain React.createElement() calls (what your JSX ultimately gets transpiled to) then I think you would more likely agree with the notion that React is "just a library". Create-react-app is much more akin to a framework in that it bootstraps an environment for you where you don't have to do any of the things that make React feel like simply a fancy library for rendering HTML.

lugged 5y ago
React is a library that should have been a framework. Literally everyone has to cobble some n-factor framework together and given the amount of inexperience out there, what results is a damn nightmare. React solving the state problem natively would have made it an industry game changer. What we have is an industry mess.
- dragonwriter 5y ago
  > React is a library that should have been a framework. React is a library that powers several different frameworks, as well as lets people use it without those frameworks. If one size fits all, answer-for-everything frameworks were the optimal solution for all problems, Angular would own the world and we wouldn't need React.
  - lugged 5y ago
    Google rug pulled angular, I know at least one very large company that pulled all Google tech from their stack over angular 1 -> 2. React really isn't the thing people have decided is the optimal solution, jsx and keeping presentation tightly coupled to business logic is. What is see with react is constant attempts to work against that ideal.
    - dragonwriter 5y ago
      > React really isn't the thing people have decided is the optimal solution My point is there is no one thing people have decided is the optimal solution. React is an element of snow me of (several different) things people have found is optimal for some problems, and not part of others. > jsx and keeping presentation tightly coupled to business logic is. JSX is more generally than React is, which is why many not-React solutions use React, too, though even that is far from universal. Tight coupling between business logic and presentation is, OTOH, far less generally what people have decided is optimal.
      - imbnwa 5y ago
        I've seen entire apps written as React components/hooks, the whole thing, no redux/mobx/etc managing state above the level of necessary local UI state. React markets itself as just a library but the truth is people tend to go all in precisely because there's too much pressure to research a whole stack for yourself.
        lugged 5y ago
        Those are likely some really solid applications as a result. In my experience redux just enables developers to sprinkle global state everywhere which makes tests a pain to write and code hard to debug.
- archeroed 5y ago
  Angular Vue and Svelte fit your description and none of them are more popular than React, I guess people have made their choice.
  - danjac 5y ago
    It's an open question whether React succeeded because of technical advantages or because of Facebook's initial support and the job market creating its own dynamic (people go where the jobs are).
kkirsche 5y ago
Great resource for anyone interested in this. It’s really enlightening: https://pomb.us/build-your-own-react/ https://pomb.us/build-your-own-react/
imbnwa 5y ago
> If you've ever had the "pleasure" of writing React with plain React.createElement() calls (what your JSX ultimately gets transpiled to) then I think you would more likely agree with the notion that React is "just a library". I'm not sure why someone would unless you're strictly writing static JSX with no components whatsoever as some sort of weird replacement for just writing the equivalent static HTML. The minute you write a `render` or lifecycle method, React is now calling you. Not to mention stuff like Suspense asking you to throw a Promise to render from latest render cache. I think something like Crank.js[0] is more a view library since it puts all the nuts and bolts into userland. [0]https://crank.js.org/ https://crank.js.org/
- Drew_ 5y ago
  You use React APIs to do everything you would normally do with React. You use the API directly if you don't have a build step for your web app and you cant or don't want to add one. Since React is indeed simply a library with an API, you can progressively integrate React into an existing web app in this way (a big selling point in the early days that people have sensibly forgotten by now). You couldn't progressively integrate a traditional framework like Django for example. Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added.
  - imbnwa 5y ago
    > You couldn't progressively integrate a traditional framework like Django for example. I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here? > Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added. But I don't write the code that says when they're called. Backbone is more of a library, for example, since it lets me do all that and it can be progressively integrated into an app too (I can just use models, I can just the views, etc). I mean thats part of why people ran to Ember and Angular when they appeared, they didn't feel like doing all that. Also see Crank.js: you can emulate React's Component API in Crank, but the reverse is not true. If I'm not writing the code that "turns the gears" per se, then to me I'm using a framework. That framework might have a small API surface, it might have a large API surface. That's how I see it at least. A framework to me is defined by a certain threshold of abstraction. This is an async task library because I can opt-in and out of, as well as control, or simply replace, the scheduler[0] [0]https://github.com/mitranim/posterus https://github.com/mitranim/posterus
bryanrasmussen 5y ago
yes, well if I didn't use most of the built in functionality of a framework I suppose it would be a lot more like using a library.
- Drew_ 5y ago
  Support for JSX is not built into React. React is simply a JS library and JSX is not valid JS. So if you add React to a web page, and attempt to write logic with JSX, you will get syntax errors.
- jameshart 5y ago
  No, it's literally the case that JSX compiles into (indirect) calls to your own functions. It's not a magic 'framework' that calls your code when you use JSX, it's... your code. When you write return <MyFunction foo={bar}/> that gets turned into return React.createElement(MyFunction, { foo: bar }, []) Which returns a refreshable wrapper round the result of calling your function. It's really a reactive-functional type system, rather than a framework - with a syntactic sugar that makes it easy to generate a reactive wrapper round a function. Then you take the result of passing all your functions into that syntactic wrapper and hand it to ReactDOM to have it synchronize it with the DOM. React transcends the framework/library discussion because it really isn't either. It's a higher-ordered type factory.

by Drew_ 5y ago

lugged 5y ago

React is a library that should have been a framework. Literally everyone has to cobble some n-factor framework together and given the amount of inexperience out there, what results is a damn nightmare. React solving the state problem natively would have made it an industry game changer. What we have is an industry mess.

dragonwriter 5y ago
> React is a library that should have been a framework. React is a library that powers several different frameworks, as well as lets people use it without those frameworks. If one size fits all, answer-for-everything frameworks were the optimal solution for all problems, Angular would own the world and we wouldn't need React.
- lugged 5y ago
  Google rug pulled angular, I know at least one very large company that pulled all Google tech from their stack over angular 1 -> 2. React really isn't the thing people have decided is the optimal solution, jsx and keeping presentation tightly coupled to business logic is. What is see with react is constant attempts to work against that ideal.
  - dragonwriter 5y ago
    > React really isn't the thing people have decided is the optimal solution My point is there is no one thing people have decided is the optimal solution. React is an element of snow me of (several different) things people have found is optimal for some problems, and not part of others. > jsx and keeping presentation tightly coupled to business logic is. JSX is more generally than React is, which is why many not-React solutions use React, too, though even that is far from universal. Tight coupling between business logic and presentation is, OTOH, far less generally what people have decided is optimal.
    - imbnwa 5y ago
      I've seen entire apps written as React components/hooks, the whole thing, no redux/mobx/etc managing state above the level of necessary local UI state. React markets itself as just a library but the truth is people tend to go all in precisely because there's too much pressure to research a whole stack for yourself.
      - lugged 5y ago
        Those are likely some really solid applications as a result. In my experience redux just enables developers to sprinkle global state everywhere which makes tests a pain to write and code hard to debug.
archeroed 5y ago
Angular Vue and Svelte fit your description and none of them are more popular than React, I guess people have made their choice.
- danjac 5y ago
  It's an open question whether React succeeded because of technical advantages or because of Facebook's initial support and the job market creating its own dynamic (people go where the jobs are).

kkirsche 5y ago

Great resource for anyone interested in this. It’s really enlightening: https://pomb.us/build-your-own-react/ https://pomb.us/build-your-own-react/

imbnwa 5y ago

> If you've ever had the "pleasure" of writing React with plain React.createElement() calls (what your JSX ultimately gets transpiled to) then I think you would more likely agree with the notion that React is "just a library". I'm not sure why someone would unless you're strictly writing static JSX with no components whatsoever as some sort of weird replacement for just writing the equivalent static HTML. The minute you write a `render` or lifecycle method, React is now calling you. Not to mention stuff like Suspense asking you to throw a Promise to render from latest render cache. I think something like Crank.js[0] is more a view library since it puts all the nuts and bolts into userland. [0]https://crank.js.org/ https://crank.js.org/

Drew_ 5y ago
You use React APIs to do everything you would normally do with React. You use the API directly if you don't have a build step for your web app and you cant or don't want to add one. Since React is indeed simply a library with an API, you can progressively integrate React into an existing web app in this way (a big selling point in the early days that people have sensibly forgotten by now). You couldn't progressively integrate a traditional framework like Django for example. Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added.
- imbnwa 5y ago
  > You couldn't progressively integrate a traditional framework like Django for example. I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here? > Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added. But I don't write the code that says when they're called. Backbone is more of a library, for example, since it lets me do all that and it can be progressively integrated into an app too (I can just use models, I can just the views, etc). I mean thats part of why people ran to Ember and Angular when they appeared, they didn't feel like doing all that. Also see Crank.js: you can emulate React's Component API in Crank, but the reverse is not true. If I'm not writing the code that "turns the gears" per se, then to me I'm using a framework. That framework might have a small API surface, it might have a large API surface. That's how I see it at least. A framework to me is defined by a certain threshold of abstraction. This is an async task library because I can opt-in and out of, as well as control, or simply replace, the scheduler[0] [0]https://github.com/mitranim/posterus https://github.com/mitranim/posterus

bryanrasmussen 5y ago

yes, well if I didn't use most of the built in functionality of a framework I suppose it would be a lot more like using a library.

Drew_ 5y ago
Support for JSX is not built into React. React is simply a JS library and JSX is not valid JS. So if you add React to a web page, and attempt to write logic with JSX, you will get syntax errors.
jameshart 5y ago
No, it's literally the case that JSX compiles into (indirect) calls to your own functions. It's not a magic 'framework' that calls your code when you use JSX, it's... your code. When you write return <MyFunction foo={bar}/> that gets turned into return React.createElement(MyFunction, { foo: bar }, []) Which returns a refreshable wrapper round the result of calling your function. It's really a reactive-functional type system, rather than a framework - with a syntactic sugar that makes it easy to generate a reactive wrapper round a function. Then you take the result of passing all your functions into that syntactic wrapper and hand it to ReactDOM to have it synchronize it with the DOM. React transcends the framework/library discussion because it really isn't either. It's a higher-ordered type factory.