Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes.

Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your controller to a view component like a "Save" button. Then in your onSaveButtonClicked event handler in your controller, you typically you write something like:

    myView.setLoading(true) // to mask the view
    myModel.save() // to execute an Ajax req,
        on success,
           myView.setLoading(false)

In React+Flux, clicking the Save button calls an action creator. The action creator first fires an event "loading: true" before it does anything. A store which is bound to that load action then calls a method which dispatches another event. The view which is listening on the store is notified that "something changed" and redraws itself (to show the loading mask/spinner). All this and we haven't even begun loading any data yet. Repeat all steps once the data is loaded or if an error occurs.

I'm not against React at all - just for our purposes ExtJS seems like a better fit. To be fair, I did spent some time building a custom URL router which really simplifies everything. All of our controllers are consistent with start() and stop() methods, they can define data dependencies (i.e. this data needs to be loaded before start is called), etc.

It's not the over-theming (although that is part of what creates that easily-recognizable Ext-ness), it's the strictness with which they expect you to use their components. If you want a dropdown that functions exactly the way Ext made a dropdown it is the easiest thing in the world, but if you want a slightly different behavior then it's a whole rigamarole of events and overrides and stuff. It's not just how it looks but actual functionality that is hard to improve. You'd be frightened if you saw our "ExtOverride.js" file. :)

I should have also caveat-ed that we are on ExtJS 3, so ymmv with 4.

The way you've concisely written the Ext code and long-form written out the React code does show some form of bias, as what you're really doing with React is pretty much the same as how you've written the Ext code, but if you write out the full path of any kind of UI update it will seem more complex. I mean, adding "the store is notified that something changed and redraws itself to show the loading mask/spinner" is what, 2 lines of code? But a long-form explanation makes it seem like a bigger deal.

Your Ext code is missing all the logic to actually set up the Ajax stuff, all the event handling that you call out in React, error handling, etc... If you came into a React system with all the same things set up that you're assuming in your Ext system (data bindings, event handling, visual components) then the code to accomplish the same thing looks almost identical.

As I said, Ext is great if you want to do what Ext wants you to do. It magics away a lot of stuff that you have to call out explicitly with React+Flux. But the second something goes wrong or you want to try something else that magic bites you in the ass.

All I can say is that my experience switching from Ext to React has been one of massive amounts of time wasted figuring out the quirk of event flows and component layout hierarchies to front-end code that just makes sense and does what you'd expect and is ridiculously simple to debug.

To be fair, I think that ExtJs 4 offered a number of improvements over 3--but also introduced a lot of backwards incompatibility...

@mejari - the reason why I wrote out the React code long-form is because I couldn't figure out how to write it concisely :) Not because I'm biased hehe.

I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores:

    MyStore.listen(this._onMyStoreChange.bind(this));

The views manually call action creators:

    MyActions.saveData();

Action creators dispatch separate events for beforeRequest, onRequest, onError events:

    this.actions.onBeforeSaveSomething();

    // do the save
    this.dispatch({ type: 'SUCCESS', data: myData });

Stores need to listen for action creator events:

    this.bindAction(actions.onBeforeSaveSomething, this.onBeforeSaveSomething);
    this.bindAction(actions.onSave, this.onSave);
    this.bindAction(actions.onError, this.onError);
    

In the Flux flavor I'm using (alt), stores automatically dispatch events when their state is changed, but I found managing the store state is annoying because of the loading, error flags[1].

So the store.onSave might look like this:

    this.loading = false;
    this.error = null;
    this.data = data;

Finally, the view updates it's state in response to a store change which automatically calls render.

Then in the view render, you can show your loading/saving mask.

[1] https://news.ycombinator.com/item?id=9315503

I guess it just comes down to comparing two different things. Yes, you have to do more setup with React because React isn't what Ext is. But if you set up your React to the point that Ext is at, with data binding and error handling and event listening that Ext magics away you get code that is very similar. Almost all of your code is doing what Ext magically does, but in a React application of any size these things are handled via components and mixins and such and you don't have to deal with them in the clunky way you're describing.

Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :)

There's no Ext magic in the code I posted. Flux and MVC are different patterns. In MVC, the controller typically has direct access to the view and model which is why the code is simple:

    myView.setLoading(true);
    myModel.save(...)

That would look the same in Java Swing for example. Flux is a fundamentally different pattern and one that I really haven't seen the need for in the products we're building to justify it's disadvantages. But for some applications, it's probably the right solution.

And the reason you couldn't setup your stores in a similar fashion?

    myStore.setLoading(true);
    myStore.save(...);

Where the handling is in your action handler for whatever event was raised... This assumes you do your backend data access in the store itself... there are other options.

Sorry for the confusion: setLoading (poorly named) is a method on a view component in ExtJS 4 which displays a modal message mask.

No confusion.. you can have a property on your store that does the same to state, and triggers an event to draw a mask/modal in a similar way... there's nothing preventing you from doing that... it isn't so much in the box, but you can do it pretty easily.

You also aren't stuck building class based object constructors in JS as extjs projects tend to do.. or trying to shim out areas of extjs in order to extend a base rendering.

I also had issue with the amount of setup with React, which is part of what drove me to Mithril, which has almost zero boilerplate. Nearly every line of code you write is either relevant application logic or declarative view code.

I've also been thinking about migrating away from Ext--on the one hand there are theming issues--on the plus side, I rather like their grid widget. But, their licensing model just seems to keep changing and that worries me enough to want to move away. For example, now it's just not possible to buy a single developer seat.