6 ms·

To me this is still why React feels like the first front end UI framework that got it "right." It stays close to vanilla Javascript. There's a tiny API surface

To me this is still why React feels like the first front end UI framework that got it "right." It stays close to vanilla Javascript. There's a tiny API surface area to learn, and the rest is vanilla Javascript classes and functions. Angular's API, and apparently Angular 2.0's API, is still large, and strays far from vanilla Javascript

aarpmcgee 10y ago
Ember shares this problem, imo.
nichochar 10y ago
"tiny" nope.
- mythz 10y ago
  The surface area you have to learn to be useful in React is tiny, much so compared with Angular2.
- brentvatne 10y ago
  import React from 'react'; import ReactDOM from 'react-dom'; function App(props) { return <div>Hello {props.name}</div>; } ReactDOM.render( <App name="nichochar" />, document.getElementById('root') ); Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render. That's pretty much all there is
  - alexbecker 10y ago
    I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.
    - barryhoodlum 10y ago
      It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.
  - grumblestumble 10y ago
    If that's pretty much all there is, you'd be better off saving ~150kb and just using ES6 template strings.
codelike 10y ago
That's one of the pros often mentioned about React. In practice, I haven't found it to be true so far. Once you start using React, you'll almost certainly have to use one the Flux implementations. So let's say you use Redux. Suddenly you also have Actions, Reducers and Stores that you have to learn. If you want to use Async Actions (which is very likely in a web application), you'll probably need Redux Thunk, so that's another concept to understand. Then there's routing, which is not present in the React core, so you'll need a routing library as well. Again your API surface increases. In the end, if you want to write a larger application with React, you'll often have a similar or even larger API surface than Angular. I can understand that some people prefer the conceptual model of React (with its focus on Components) over that of Angular. The claims about a smaller "API surface" have always felt wrong to me, though.
- Nemcue 10y ago
  The difference is that you're spending time learning about concepts that you are unfamiliar with, as opposed to learning Angulars many APIs. For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).
  - shriek 10y ago
    Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.
- barryhoodlum 10y ago
  You don't "almost certainly" need Flux at all. By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.869mssx85 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
- wccrawford 10y ago
  I've been using React for small projects in my personal time, and I haven't needed anything like Flux at all. Maybe you'll need it for complex apps, but React can be used for small ones without that added complication.
andrewstuart2 10y ago
I still firmly believe Angular 1 got the right pieces into the framework (directives and services), but that the community latched onto some of the extraneous pieces (controllers, controllerAs, etc), which don't offer enough cost/benefit and simply make things much harder to grok. You often end up babying references and being bitten by implementation details of JS and somewhat-confusing names for things (e.g. $scope does not behave like the variable scope of any ES version). Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.
peferron 10y ago
Is the comparison fair? I haven't tried Angular 2, but it seems much more full-featured than React. For example, I guess that Angular 2 includes a router, while React doesn't, and just a few days ago there was a vitriolic thread just here on HN about the state of react-router. If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so. [1] https://github.com/davezuko/react-redux-starter-kit https://github.com/davezuko/react-redux-starter-kit [2] https://github.com/davezuko/react-redux-starter-kit/blob/master/src/routes/Counter/index.js https://github.com/davezuko/react-redux-starter-kit/blob/mas...
- barryhoodlum 10y ago
  It's not a fair comparison. React is just a view layer. It's not trying to offer everything that you'd need to write a web application. React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.
stupidcar 10y ago
Tell me about it! Literally all you need is React. Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going! Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!
- specialp 10y ago
  I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.
  - stupidcar 10y ago
    While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework. For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours? Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it? With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code. With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.

aarpmcgee 10y ago

Ember shares this problem, imo.

nichochar 10y ago

"tiny" nope.

mythz 10y ago
The surface area you have to learn to be useful in React is tiny, much so compared with Angular2.
brentvatne 10y ago
import React from 'react'; import ReactDOM from 'react-dom'; function App(props) { return <div>Hello {props.name}</div>; } ReactDOM.render( <App name="nichochar" />, document.getElementById('root') ); Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render. That's pretty much all there is
- alexbecker 10y ago
  I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.
  - barryhoodlum 10y ago
    It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.
- grumblestumble 10y ago
  If that's pretty much all there is, you'd be better off saving ~150kb and just using ES6 template strings.

codelike 10y ago

That's one of the pros often mentioned about React. In practice, I haven't found it to be true so far. Once you start using React, you'll almost certainly have to use one the Flux implementations. So let's say you use Redux. Suddenly you also have Actions, Reducers and Stores that you have to learn. If you want to use Async Actions (which is very likely in a web application), you'll probably need Redux Thunk, so that's another concept to understand. Then there's routing, which is not present in the React core, so you'll need a routing library as well. Again your API surface increases. In the end, if you want to write a larger application with React, you'll often have a similar or even larger API surface than Angular. I can understand that some people prefer the conceptual model of React (with its focus on Components) over that of Angular. The claims about a smaller "API surface" have always felt wrong to me, though.

Nemcue 10y ago
The difference is that you're spending time learning about concepts that you are unfamiliar with, as opposed to learning Angulars many APIs. For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).
- shriek 10y ago
  Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.
barryhoodlum 10y ago
You don't "almost certainly" need Flux at all. By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.869mssx85 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
wccrawford 10y ago
I've been using React for small projects in my personal time, and I haven't needed anything like Flux at all. Maybe you'll need it for complex apps, but React can be used for small ones without that added complication.

andrewstuart2 10y ago

I still firmly believe Angular 1 got the right pieces into the framework (directives and services), but that the community latched onto some of the extraneous pieces (controllers, controllerAs, etc), which don't offer enough cost/benefit and simply make things much harder to grok. You often end up babying references and being bitten by implementation details of JS and somewhat-confusing names for things (e.g. $scope does not behave like the variable scope of any ES version). Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.

peferron 10y ago

Is the comparison fair? I haven't tried Angular 2, but it seems much more full-featured than React. For example, I guess that Angular 2 includes a router, while React doesn't, and just a few days ago there was a vitriolic thread just here on HN about the state of react-router. If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so. [1] https://github.com/davezuko/react-redux-starter-kit https://github.com/davezuko/react-redux-starter-kit [2] https://github.com/davezuko/react-redux-starter-kit/blob/master/src/routes/Counter/index.js https://github.com/davezuko/react-redux-starter-kit/blob/mas...

barryhoodlum 10y ago
It's not a fair comparison. React is just a view layer. It's not trying to offer everything that you'd need to write a web application. React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.

stupidcar 10y ago

Tell me about it! Literally all you need is React. Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going! Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!

specialp 10y ago
I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.
- stupidcar 10y ago
  While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework. For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours? Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it? With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code. With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.