Echo JS 0.11.0

const Foo = {
      async then (done) {
        done(await request('https://foo.com'))
      }
    }

What happens when request throws an error (or the promise rejects)? ... in this case, there's no value to it.

Very cool... hadn't even considered some of the effects of smaller widgets like in the example.  Could be why so many sites are painful in mobile even.

While interesting, several of the examples don't account for errors, and are bad advice all around.  You're better off using async functions or explicitly using/returning proper promises, or at least account for error conditions.

While I appreciate the angularisms and directives, it no longer feels like redux.  I found that [angular-redux](https://github.com/angular-redux/store) was more my speed.

JSX really isn't a view framework/lib though several use JSX/Hyperscript transpile for representing component rendering (React, hyperscript, inferno, preact, etc).

That said, it does feel more natural to me, to have the JSX and css-in-js inside the JS, than with components like vue, svelte and web components.

While I do understand this, and get that it can make testing easier considering the pure nature vs having a mutating function based on the response of fetch (for example), I still find using redux-thunk with async action creators to be easier to comprehend and lower complexity in terms of code.

    const loadTodosStart = () => {
      type: 'LOAD_TODO_START',
    };

    const loadTodosSuccess = payload => {
      type: 'LOAD_TODO_SUCCESS',
      payload,
    };

    const loadTodosError = payload => {
      type: 'LOAD_TODO_ERROR',
      payload,
    };

    const loadTodos = () => async (dispatch, getState) => {
      dispatch(loadTodosStart());
      try {
        dispatch(loadTodosSuccess(await fetch('/todos')));
      } catch(error) {
        dispatch(loadTodosError(error);
      }
    };

Though, I wouldn't mind something similar that I could use as follows...

    // library
    const handleActionType = (type, payload) => (
      typeof type === 'function'
      ? type(payload)
      : { type, payload }
    );
    export const createAction = 
      (beforeType, successType, errorType, fn) => (...args) => (dispatch) => {
        dispatch(handleActionType(beforeType, args))
        return Promise.resolve(fn(...args))
          .then(payload => dispatch(handleActionType(successType, payload)))
          .catch(payload => dispatch(handleActionType(errorType, payload)))
          
      };


    // actions.js
    export loadTodos = createAction(
      'LOAD_TODO_START',   // before
      'LOAD_TODO_SUCCESS', // then payload = result
      'LOAD_TODO_ERROR',   // catch payload = error
      async (/* exposed args here */) => fetch('/todos'),
    );

Where the final method is the signature createAction exposes, wraps in try/catch and exposes as a thunk/function wrapper to be used with redux-thunk

Better than most comparisons... I would state that with a compatibility shim, that the risk to preact or inferno are limited, and you can always reconfigure to react if needed.  Beyond this, React 16 had some performance increases which I see expanding.  I know a lot of people use React in dev and preact in uat/prod.  Why?  It's an easy drop in for a smaller library.

Personally I think the size/scope of Angular becomes very difficult, and that it's harder to replace pain points compared to React.  Beyond this, usually someone should have an architect role and be the deciding factor on some early decisions like what state management, css loader or ui framework to start with.  Entropy, and going with what you know counts for a lot.  That said, I don't think I would ever choose Angular over React, and could be convinced of Hyper or Vue, but not familiar with Sapper.

Nice, however, I usually reach for a streaming library, if I need anything large.

Okay, Auth0 tends to have at least interesting articles, but they all really seem like blogvertorials for auth0.  None of them ever seem to be technically minded on their own.

I mean, if they had a separate article on (Here's how you integrate Auth0 and .Net core) from "Web apps with .Net Core and 2.0" that starts with "This follows up on ..."

* Two-way data binding is emphatically *NOT* an advantage... Every Angular 1/2/whatever app I've ever touched as a user has weird state bugs somewhere.  You get *FAR* less of these kinds of issues with 1-way data flow.  Hell, even using 1-way data (I'm using angular-redux, and have used rxjs), a lot of interactive bits (frustrated with angular-sortablejs) really bork things up when they break and don't raise proper events.

Detailed documentation with Angular does not overcome the weird choices made in terms of overall function and design.  Also, "world-renowned and time-tested" apply as much to React as it does angular, and even more so, since it's been around longer than Angular 2+, and used twice as broadly as Angular.

Under "New useful features" it mentions the HttpClient, one area that I think is entirely useless considering fetchAPI is in all modern browsers and easily shimmed otherwise.

On the react disadvantages: "Possible problems with updates," react is very good at deprecation warnings and doesn't remove stuff until the next full version, usually you have a few versions to go through before a feature is actually removed.

As to React.JS isn’t a framework... react + redux + redux-thunks + fetch give you everything you need that angular has in the box.  If you need more, you can easily swap out.  That gets to be much harder with angular.

The conclusion is completely backwards as you do not get a boost in productivity... you lose any advantage dealing with bugs in weird Angular behaviors.  Using a state manager like redux?  Update your model during a UI event, and see the whole app crash.  Crap, what properties of @Component do I need again, vs creating a render function.