Echo JS 0.11.0


tracker1 comments

tracker1 26 days ago. link 1 point
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.
tracker1 26 days ago. link 2 points
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',

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

    const loadTodos = () => async (dispatch, getState) => {
      try {
        dispatch(loadTodosSuccess(await fetch('/todos')));
      } catch(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
tracker1 27 days ago. link 2 points
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.
tracker1 30 days ago. link 1 point
Nice, however, I usually reach for a streaming library, if I need anything large.
tracker1 30 days ago. link 1 point
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 ..."
tracker1 30 days ago. link 4 points
* 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.
tracker1 31 days ago. link 2 points
For me the most common use cases for cloning are for logging, or a sanity check before crossing a wire (often for API responses and/or errors).  So true clones aren't needed, same for prototype chains.  What you do want to avoid is to have circular references plucked, and/or pull up error message/stack properties out of the prototype instance.

I created an npm module (safe-clone-deep), and helped with another (fclone).  I mostly just use fclone these days.
tracker1 31 days ago. link 13 points
Happy to help.  This site has become a part of my daily routine for a few years now.  Thanks for all your hard work on this.  I totally understood why you had taken it down, and even more happy you've decided to bring it back up.
tracker1 32 days ago. link 2 points
Really hope this gets flushed out and injected into an electron app.