>...turn ugly when you start breaking down components into smaller and smaller components.

Care to elaborate?

This seems opposite to how components ought to work.

Take a table that is broken into rows then cells, within the cell you have a media object within that you have a list with items.

Each of those become separate components. Can you reuse them, yes but it would be more helpful to keep them in one component.

Then don't split them. If you use powerful methodologies to keep track of complex state in one component, not splitting is generally easier too, although you will lose slightly on performance. No one forces you split a component into multiple ones. I've implemented entire games in just one component with logic cleanly described by a finite state machine.

Reading this makes me feel better I make large monolothic components. Most examples would have you believe doing so is a big no no.

You can keep them in one component. Nobody is making you split every single object into discrete components.

So keep them in one component.

Just because a framework/language gives you a tool, doesn't mean you need to use it. Instead of emit, you can easily track state in a Vuex store and then have that change propagate to the required components.

You can also inject sideways data dependencies in React by using an event emitter. Shitty POC:

  // global-store.js
  const remove = (arr, el) => {
    const i = arr.indexOf(el);
    if (i < 0) return false;
    return !!arr.splice(i, 1);
  }

  class GlobalStore {
    constructor(data){
      this.data = data;
      this.subs = [];
    }
    sub(cb){this.subs.push(cb)}
    unsub(cb){remove(this.subs, cb)}
    notify(newArr){
      for (let s of this.subs) 
        s(newArr);
    }
    addData(item){
      notify(this.data = [...data, item])
    }
    removeData(item){
      if (remove(this.data, item))
        notify(this.data = [...this.data])
    }
  }

  // my-component.js
  import myStore from "./stores"
  class MyComp extends Component {
    ...
    componentDidMount(){
      myStore.sub(this._cb = data => {
        this.setState({data})
      })
    }
    componentWillUnmount(){
      myStore.unsub(this._cb)
    }
  }

Obviously, not super optimized, but it's just a POC.

A store could be used and things get cleaner but the overhead increases too much.

If ($)emit is not something you use for very ephemeral events, that otherwise cannot be expressed as state changes in natural way, or in a custom, reusable component (i.e something you could publish separately from your application), you're using it wrong. I rarely ever use emit and when I do it's either a very active reusable component or a solution for an otherwise very difficult problem. And I don't see what a meaningfully prettier/better API would be.

> Vue seems quickier but things like emit feel gross

FYI: You can pass a function as a prop in Vue.js too, just like React.

I agree with you.

What are your thoughts on https://github.com/hyperapp/hyperapp ?

V2 is coming relatively soon, and will have breaking changes.

Thoughts on Mithril?

I rewrote a ~30k line React app in Mithril and since then it's been my go-to view library. It's not mentioned here often, which is surprising given how nice it is to work with. The biggest improvements for my workflow have been closure components and the css selector syntax.

Closure components let you use closures to hold state, which ends up being a very elegant pattern. In react:

  class Square extends React.Component {
    constructor(props) {
      super(props);
      this.state = {
        value: null,
      };
    }
    render() {
      return (
        <button
          className="square"
          onClick={() => this.setState({value: 'X'})}
        >
          {this.state.value}
        </button>
      );
    }
  }

Is roughly equivalent to the following mithril code:

  function Square() {
    const state = { value: null };
    return {
      view() {
        return (
          m('button.square', {
            onclick() { state.value = 'X'; }
          }, state.value);
        );
      }
    }
  }

Notice that the closure gives us access to the state without needing to know what `this` refers to. You can also see the selector syntax in the mithril hyperscript above (`'button.square'`). That becomes especially nice if you're using an approach like tachyons for css, where simple classes are layered to create a style. I use this all the time for layout, which in react I would have created a bunch of stateless components for. Also worth noting: we happen to be directly mutating state in this example, but since mithril isn't opinionated about that you could really store and update your state however you please. Also, for quick projects that don't justify all the cruft that you get with `create-react-app`, it's nice to be able to just use a framework with no build steps whatsoever.

Mithril felt really slow to load for me, using it on a little hobby site and was not impressed with it's page-load performance.

I've been working with Mithril for 2 years and never heard anybody say that before. What's the site?

> I think there is still space for one more framework to rule them all.

People should learn to write apps with the DOM, that's the framework to rule them all and it's already in the browser. There no need for a framework to write apps that follow the unidirectional dataflow principle. That principle just need to be taught, like MVC or SOLID.

Oh my goodness, please no.

I already lived through the home-rolled, pure-js, custom frontend "frameworks" made by each team's resident "smart guy" once. I shudder just thinking about those days.

React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development.

> Oh my goodness, please no.

You don't educate developers to good practices just by abstracting the hard things. You don't need to use React/Angular/Whatever to manage state the right way in a front-end application. You don't need a framework to make code maintainable or testable, or you're just saying front-end developers are so incompetent and undisciplined they need a framework. No they don't, just like one doesn't need a framework like Rails or Spring or Django to write a server app.

> React/Angular/framework-whatever are glorious angels protecting us from the tyranny of half-baked, poorly thought out approaches to frontend development.

No they are not, they are making the developer ignorant of the underlying DOM architecture.

Uh oh, I think we found our 'resident smart guy.'

No, i'm not smart, I'm just not ignorant. Learning Django isn't going to make you learn HTTP spec for instance, you know what i'm saying? the same way, learning Angular OR Vue.js will not make you understand how event bubbling or event delegation works. plenty of "full stack" front-end developers out there who know nothing about the DOM.

There's Angular 2+, which largely follows the Shadow DOM + Web Components specs.

The creator of Redux disagrees: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Writing vue/react code w/o flux is like putting your entire application code into the view layer of an MVC app.

You can easily create a model that knows nothing about the view without Vuex/Redux.

>You can easily create a model that knows nothing about the view without Vuex/Redux.

Sure, but why not use the standard solution for the ecosystem.

As far as that linked Abramov post, it felt like a hedge to me. Basically he's saying you don't need redux to write a react app, which is a truism, then lists all the reasons why you should use redux.

Redux "code" is a simple library. But if you follow Abramov's architecture opinions that he only implies in the redux guide, you end up with a full highly scalable front-end framework architecture.

Plus vanilla react is non-deterministic with state. Redux solves this problem and that alone is worth the price of entry.