Breaking Up with Backbone.js

[tlovett1]

Well everyone, I think it's finally time... to break up with Backbone.js. I'm opening up this thread as a discussion, not a mandate. I'd like 10up Engineering (and the community) to fully get behind the future of advanced JS applications in WordPress, whichever direction we choose.

Why?

Backbone.js is an integral part of WordPress. We decided on Backbone as the JavaScript "framework" for our clients in 2014 because it was the WordPress way. Backbone is still a major part of WordPress (i.e. media library). However, WordPress and the web have both made strides towards more modern "frameworks" and "stacks".

My main issues with Backbone.js are:

1. Large applications are always a tangled mess. 10up projects that utilize large Backbone applications are nearly impossible to understand by anyone who didn't write the original code. I've seen this time and time again. I'd argue the same applies to WordPress (i.e. media library again). Backbone views are absolutely terrible for organizing code.
2. Backbone.js is tied to jQuery. jQuery is great. However, Backbone leads engineers to overuse it.
3. Backbone has been pretty much feature complete since version 1.0 (years ago) [1].
4. The Backbone ecosystem is, compared to other large open source projects, somewhat inactive [1].

[1]

What Should We Use to Build JavaScript Applications Going Forward?

I'd like to nominate React.js and it's extremely powerful set of related tools. Here's why:

1. Large scale React based applications are extremely maintainable and relatively quick to create. Rendering views and keeping track of state are very easy (total opposite in Backbone.js).
2. React.js applications, built properly, are extremely performant due to the virtual DOM concept.
3. React.js has massive community backing and is a top contender for most popular JavaScript framework in 2016. Additionally, the tools and frameworks built around React.js are numerous and well maintained.
4. React.js is a powerful tool for building isomorphic applications as well as native phone applications.
5. The WordPress community is arguably making it's way to React.js. Automattic's Calypso platform is built entirely on React.js. While WordPress core may still be on Backbone.js, React is probably the preferred JavaScript framework for WordPress developers.

Next Steps

Let's decide if as a company we want to move to React.js. If so, new JavaScript application projects (when a JS framework is appropriate) will be built in React.js instead of Backbone.js. Old projects built in Backbone.js will stay as is.

I'd also like us to write a React.js section in our Best Practices. The tools and patterns surrounding React.js are constantly changing. Therefore we'll need to be very careful on requiring any specific design pattern or tool. I think this section can be mostly "high level".

Thoughts?

[nicoladj77]

I think that Backbone and React solve different problems. React and React DOM taken alone are not a framework, but just a tool: you don't have a router, you don't have a wrapper for AJAX calls, no models, you just have functionality to build a UI. Backbone is still useful because the Rest API client is built in Backbone. In my current project, I did the UI in React, but the AJAX call still leverage Backbone as the client is really good. I'm totally ok to use React going forward for UI, even for more complex SPA applications ( where you at least need the React Router and probably Redux ), but Backbone still has a place in some projects I think, simply because it's a different thing ( mostly for the rest client 😄 ). Also, I noticed on a project I'm working on, that, when you use react, you don't need any jQuery, because you are not manipulating the DOM, but only the state. And events are handled differently, in a declarative way, which is what I REALLY like about React. Regarding React Performance...don't take it too much for granted! 😄

[timwright12]

Agreed about all points Backbone related here -- but I wouldn't say "dump it all together" -- there may be situations where it's still the answer to a problem. I would, however, like to see us identify a suite of frameworks to use in certain situations instead of attaching to a single one. This will allow us to choose the best tool for the job instead of the most popular one, while keeping pace with learning, professional development, and client request.

React, in it's proper application is great, but we're already seeing it lose ground to VueJS. Any single framework we choose moving forward will be great when it's used correctly, but I fear that saying something is correct 100% of the time might lead us down a similar path to where we ended up with Backbone where we're driving in screws with a hammer.

It might be worthwhile to move forward with React, but also evaluate a few other libraries or frameworks that serve certain situations better.

Echoing @nicoladj77's statement about performance -- the virtual DOM has shown to be faster, true - and VueJS adopted it as well, but the most performant thing you can do is always going to be not loading a library in the first place. This is where I think choosing the right tool for the job is going to be critical and serve us in the long run.

[jonbellah]

Totally on board to break up with Backbone as a general recommendation, for all of the reasons you outlined, but I agree with Nicola and Tim that it still has its applications in practice.

In that same vein, I'm not sure how prescriptive we should be about frameworks and libraries. The javascript landscape is changing and innovating at such a rapid pace, and frameworks and libraries can solve such different problems, that I think we should be open to alternatives (like VueJS) where they fit best.

I would prefer that we continue to focus the Best Practices on how to write good javascript (secure, performant, etc) and leave the selection of frameworks/libraries to the individual needs of the project.

[adamsilverstein]

Thanks for raising a great topic!

I agree with @nicoladj77 - Backbone and React solve different problems, I find them both useful and I am not sure we need to make a choice between them. I do agree with the overall point - we should standardize on building (especially medium-large non wp-admin) JS apps in React.

My experience using React so far has been fun and rewarding. It is fast, has a rich ecosystem, and the one way data flow/pure function Redux approach makes state reasonable for larger applications.

Backbone is also great, especially when building low/medium-complexity wp-admin or even front end features, for example post pickers, complex meta box interface or handling tabular data. Also, Backbone is critical when interacting with wp core implementations for media (or themes, revisions, or menus or widgets in the customizer).

In regards to "2. Backbone has been pretty much feature complete since version 1.0 (years ago) " I see this as an asset - Backbone does few things and it does them well, improving reliability and reducing code churn.

[thaicloud]

Also in agreement. I would opt to update our Best Practices to clarify that Backbone should not be used for large applications, and instead recommend (rather than mandate) React.js as a very capable alternative.

That said, I am 110% behind the addition of a React.js section. For all the reasons TL mentioned, it's clearly a front-runner & an extremely powerful tool. In my experience, however, the learning curve was pretty high- having clear best practices (even at a high level) could significantly reduce that hurdle for newcomers.

[chanceymathews]

I think the problem with Backbone is that it's seen as a "framework" when it's not. It gives you a collection type and an observable object wrapper and some AJAX goodies, but that's about it. You still need to make up the rest of the stuff that goes into most apps. That's why Backbone projects are all so different and confusing. The issue isn't Backbone, it's all that stuff that Backbone isn't. There are a million ways to build an app, and because Backbone doesn't provide those guidelines, everyone's going to come at it from a different angle.

Some frameworks have that training and consistency built in, but there's still going to be gaps.

[tlovett1]

Awesome discussion everyone!

Addressing a few points:

Backbone is still useful because the Rest API client is built in Backbone.

I would argue that using the wordpress-rest-api npm package is a better choice. It can be bundled to be used in browser. I totally support "choose the right tool for the job". However, I can't think of an instance where Backbone.js is the right tool.

React, in it's proper application is great, but we're already seeing it lose ground to VueJS. Any single framework we choose moving forward will be great when it's used correctly, but I fear that saying something is correct 100% of the time might lead us down a similar path to where we ended up with Backbone where we're driving in screws with a hammer.

Again, I'm on board with using the right tool for the job. I'm not advocating using React.js for everything JavaScript related forever. However, I do think we need to pick a framework of choice. Right now that framework is Backbone.js and it's causing issues on client projects. I think our Best Practices frame that as: "if you are building a larger JS application, we prefer React.js and the ecosystem around it. React.js might not always be the best fit but we believe it to be a good place to start the discussion around what to use." If we remove Backbone.js from our Best Practices and don't suggest something else, we will have engineers using everything under the sun (Angular, Ember, etc.) which is bad for everyone.

I would prefer that we continue to focus the Best Practices on how to write good javascript (secure, performant, etc) and leave the selection of frameworks/libraries to the individual needs of the project.

Writing good JS is 100% an important value at 10up. We should convey that in the Best Practices along with framework recommendations.

I think the problem with Backbone is that it's seen as a "framework" when it's not.

Fair point. I'd say the same about React.js. I don't want to debate about what constitutes a framework. Generally speaking, one can build a large JS application with React and the ecosystem of tools around it.

[tlovett1]

Would love to hear from more people. Maybe @kdo, @eugene-manuilov, @cmmarslender, @tylercherpak, @sudar ...

[adamsilverstein]

However, I can't think of an instance where Backbone.js is the right tool.

I can think of several instances where Backbone might be the best or sometimes only tool for the job, primarily in the wp-admin context:

• A repeatable custom meta selector backed by WordPress custom post types or taxonomies.
• A tabular view of a large WordPress backed dataset that needs to be asynchronously loaded and offer faceted filtering and search.
• Enhancements for the customizer menu builder or widget manager, for example adding per-menu options.
• A custom media modal tab that pulls in resources from a remote API.
• A custom customizer pane, for example a page curation tool.
• A custom view on the WordPress revisions screen that enables filtering revisions by user.

However, I do think we need to pick a framework of choice. Right now that framework is Backbone.js and it's causing issues on client projects.

What types of issues are we encountering, and how will shifting to React address these issues?

[tylercherpak]

I think one of the biggest issues I have faced with large backbone apps is the management of the state. I feel like the adoption of redux as a state container could go a long way as well. Redux in and of itself has no dependence on react and could be used with backbone with less effort than converting to react and redux all at once. Redux, when used correctly, can help everyone on a project know exactly when changes to the state happen.

I know it was already mentioned here before but it is worth reiterating that react is not a framework but just a ui library. There is room to explore the possibilities of using react with existing backbone apps. Possibly in a situation where the app just keeps getting bigger and bigger and we want to be able to slowly start to refactor to react and separating out the logic from the view to lower the complexity.

For anyone who hasn't watched Dan Abramov's (redux creator) videos on redux should check them out: https://egghead.io/courses/getting-started-with-redux

[nicoladj77]

I can think of several instances where Backbone might be the best or sometimes only tool for the job, primarily in the wp-admin context

I agree with you, but I think that we could use Backbone AND React in all those cases, Backbone for Collections and Models and React for the UI. React simply abstracts the UI better than Backbone, and handles state changes without the need to touch the DOM, so it's better than the View part of Backbone. I still think that they are two different things that can be complementary in some cases

In regards to "2. Backbone has been pretty much feature complete since version 1.0 (years ago) " I see this as an asset - Backbone does few things and it does them well, improving reliability and reducing code churn.

I wanted to write the same thing, the fact that Backbone is stable and proven should be a plus, it means that we don't have to worry about updates breaking our code, although this is more of an issue as Backbone version is dictated by WP

[tlovett1]

@adamsilverstein I agree there could be instances where Backbone.js is appropriate. I'd so all those instances are extending/mimicking existing WordPress functionality (customizer, media library, etc.). I think we can note that in the best practices.

As for React being a UI component. Yes, I agree. We'd use React in combination with something like Redux to create an application.

I don't see Backbone/React being compatible solutions (except maybe in extreme cases). If you are building an application in React, you want to use something like Redux where actions/reducers handle syncing data instead of Backbone.sync.

[eugene-manuilov]

"To be, or not to be - that is the question..." (c) Hamlet (1609)

I have been thinking about this discussion for a few days and want to say that it seems to me that we are losing original intent here. We are trying to find a golden mean by selecting most "popular" framework and trying to tell everyone to use it. Unfortunately, it's not gonna work, because there always be a case when other tool suits better for a project.

Instead of saying "good bye" to Backbone. Let's keep it along with other best practices for other tools. In this case we will have a knowledge base which is "most" comprehensive. We can say something like this: "If you use Backbone on your project, here are best practices for it", "If you use React, ..." ... Everyone will find something for themselves.

What tool to use is archetectual question/decision and usually requires deep understanding of requirements and ways to achieve targets, what seems to be out-of-scope for this knowledge base.

[sudar]

I can think of several instances where Backbone might be the best or sometimes only tool for the job, primarily in the wp-admin context:

I agree there could be instances where Backbone.js is appropriate. I'd so all those instances are extending/mimicking existing WordPress functionality (customizer, media library, etc.). I think we can note that in the best practices.

As someone who has worked on a couple of Backbone.js projects (especially with WordPress media modals) I totally agree with this. Even though Backbone.js code can get tangled a bit (especially with views) so far it is the only good solution for enhancing or extending WordPress functionality. No other framework/library can easily replace it for that use case (yet). I guess @adamsilverstein used Backbone.js in the recent media/image widget that he is working on for WordPress core.

But if we take the SPA type apps, then there are clear alternatives (React, vue.js etc) and Backbone.js falls flatly in front of them.

So we can word the recommendation such that if the project involves extending WordPress functionality (especially in media modals, customizer etc), then we can prefer Backbone.js. On the other hand if the project is more of a standalone one or SPA then we can prefer React.

After that we can also have tool specific recommendations/best practises. Some thing like this.

We can say something like this: "If you use Backbone on your project, here are best practices for it", "If you use React, ..." ..

This will help people who are just getting started with these tools/framework/libraries.

[ivankruchkoff]

On the Backbone side of things, the framework suffers from TIMTOWDI

The workaround for having 10 ways to solve a problem is to have a preferred organizational approach to Backbone, with deviations where the model doesn't make sense.

Things that can be mentioned, view (and subview) composition. What belongs in the view and what in the model. How much business logic can go into templates etc.

This problem is exactly why libraries like Marionette came out to handle these often encountered problems.

[tlovett1]

Ok, based on this thread, I think we need the following:

• JavaScript frameworks section added to Best Practices with Backbone.js and React.
• Both Backbone.js and React should mention situations where it's appropriate to use them along with some general best practices on using the framework.

Am I missing anything? Anyone interested in stepping up to write that section?

[kopepasah]

Although I am not an Engineer at 10up, I just wanted to throw in my two cents. 😋

tl;dr I completely support and advocate using Vue over React.

---

When writing React applications, things seem unnatural, hacky and lack a clear separation of code. You are always mixing HTML in JS and required to write using JSX (which sounds like JavaScript Extreme, but we all know it is not) - this tweet says it best.

While there are several ways to use Vue, one the most graceful is the implementation of single file components, which can be compiled using Webpack (one of many awesome features).

Think of Vue as the younger sibling of React which happened to learn from all the mistakes of the older sibling and decided go a different direction. 😝 Yes, Vue is young, but do not let that deter you from giving it a chance.

In addition, one of the arguments I hear advocating for React over other libraries is the basis that Facebook is behind React (glad to not have read that in this discussion). My goto counter to this argument is to imagine if people felt the same way about WordPress (with no corporate backer) in it's early years. 😱 (probably not an equal comparison, but it does make me think about it).

Nevertheless, I do agree to use the right tool for the job and Backbone is in a different category than Vue and React. However, given the choice between Vue or React, I would always choose Vue.

[tlovett1]

Thanks for the input, @kopepasah!

Still looking for a 10up'er to set up :)

[saltcod]

I've been thinking about this thread for a few days now, tallying up pros and cons.

I definitely think it's time to start down the road of having more institutional knowledge of a new framework, as we have had for years now with Backbone. I think this knowledge will be more useful in React-land than Backbone-land, as React seems to suffer less from the effects of TIMTOWDI than Backbone.

That said, my biggest concern is that React might just be too big, too complex and too frequently changing to allow us to effectively build that institutional knowledge and get to a point where we can build projects with React in an effective manner.

If we integrate more React into more projects and get further and further into the React ecosystem, I can definitely see getting to a place where we become very efficient with it.

However, if we end up building projects with React at the same frequency that we build projects with Backbone, I'm not sure we'll end up in a much better place. I'm thinking specifically here of the complexity of webpack and Redux and the fact that the React code you wrote just 1 year ago is significantly different than what you'd write today.

In short, React doesn't feel like a tool you can effectively pick up and use every few months. (Happy to be wrong here!)

On VueJS:

I've spent less time with Vue than React, but I've found it quite impressive. It feels "lighter" to use, easier to start with, easier to learn, easier to drop and pick up again as projects come and go. It feels to me like it would be easier to move a Vue project to a new pod than a React project. More experienced Vue users may rightly disagree with that as my time with Vue has been much more limited, but that's how it feels to me at this stage.

Personally, strictly as a front-ender, I would love to have something like Vue easily at my disposal all the time for doing easy DOM logic like this for making UI components, and for generally reducing spaghetti. A ton of the JS we write is creating simple bindings between two dom elements that listen for events.

All that said, it'd be hard to argue that React isn't "winning" handily in this space. With new tools like create-react-app, it feels like it should get easier to get up and running with React.

[tlovett1]

I definitely understand why some prefer VueJS over React. My hesitation with VueJS is it is the newest of the bunch, and React has already been embraced by the WordPress community.

No matter which direction we go, things will change over time. I'm sure in two years we will revisit the topic. However, we still need to move forward, and our current motto "Backbone all the things forever" since the JS landscape is fickle isn't working anymore.

A section on JS frameworks with some general guidelines of when to use what (i.e. Backbone.js with the customizer) is the next logical step.

I would absolutely love for an engineer at 10up to step up to help.

[tlovett1]

Good read on Core making the same move - https://wptavern.com/wordpress-to-select-new-javascript-framework-for-use-in-core

[tlovett1]

Haven't forgotten this thread :) I'd like us to address this after core makes a final decision.

[tylercherpak]

I would like to resurface this now that gutenberg is coming soon. Anyone have new perspective with regards to the new admin interface?

[dana-ross]

There is an issue #214 for updating the entire JavaScript Best Practices section. Adding this note here so there's a link between these issues.

[timwright12]

Updating this thread with the PR for JS framework best practices with addresses React and Vue: https://github.com/10up/Engineering-Best-Practices/pull/231

[timwright12]

Vue PR has moved to: https://github.com/10up/Engineering-Best-Practices/pull/233

[tlovett1]

Closing this thread as we've made good progress on React/Vue.