AngularJS vs Marionette: What are the differences?
"Quick to develop" is the primary reason why developers consider AngularJS over the competitors, whereas "Uses Backbone" was stated as the key factor in picking Marionette.
AngularJS and Marionette are both open source tools. It seems that AngularJS with 59.6K GitHub stars and 28.9K forks on GitHub has more adoption than Marionette with 7.15K GitHub stars and 1.35K GitHub forks.
InVisionApp, Intel, and imgix are some of the popular companies that use AngularJS, whereas Marionette is used by Zinc, Sonarr, and Kayako. AngularJS has a broader approval, being mentioned in 2799 company stacks & 1860 developers stacks; compared to Marionette, which is listed in 35 company stacks and 9 developer stacks.
What is AngularJS?
What is Marionette?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Marionette?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.
Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.
We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.
But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.
With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.
When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.
The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.
We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.
We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.
When Redash was created 5 years ago we chose AngularJS as our frontend framework, but as AngularJS was replaced by Angular 2 we had to make a new choice. We decided that we won't migrate to Angular, but to either React or Vue.js. Eventually we decided to migrate to React for the following reasons:
- Many in our community are already using React internally and will be able to contribute.
- Using react2angular we can do the migration gradually over time instead of having to invest in a big rewrite while halting feature development.
So far the gradual strategy pays off and in the last 3 major releases we already shipped React code in the Angular.js application.
At Beamery we had a large, AngularJS app, built over several years. Our clients were happy, but we were not. We had several problems: Building new features was slow. AngularJS doesn’t scale nicely. Features clash with each other. Isolation doesn’t come as standard, you have to work hard to keep features separate. It takes time to get it right. #Hiring was hard, for all the reasons listed above. The app was slower than it needed to be because AngularJS was never built for speed. We wanted to render half a million contacts, and Angular was fighting us all the way.
As time went by it become harder to find developers who would willingly choose AngularJS over React Angular 2 , Vue.js , Aurelia or Polymer .
So we faced a choice. We could throw it all away and start again, we could upgrade to Angular 5, or the awesome option - we could use micro frontends. We chose the awesome option.
By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.
I use TypeScript because it's adoption by many developers, it's supported by many companies, and it's growth. AngularJS, React, @ASP.NET Core. I started using it in .NET Core, then for a job. Later I added more Angular experience and wrote more React software. It makes your code easier to understand and read... which means it makes other people's code easier to understand and read.
Back in 2015, my company had a back-office dashboard that was originally built in AngularJS 1. Since Angular 2 presented drastic changes we decided to rethink the options and we looked at React and Vue.js. Besides, at the time, Vue had basically only one developer, its structure (100% oriented to components) and also its backward compatibility focus (Angular 1 to 2 no more) we preferred it against React cause it seemed more straightforward, clean and with a small learning curve. Now 4-5 years later we are very happy with our choice.
AngularJS is a structural framework for dynamic web apps. With AngularJS, designers can use HTML as the template language and it allows for the extension of HTML's syntax to convey the application's components effortlessly. Angular makes much of the code you would otherwise have to write completely redundant. We can use Angular to build any kind of app, taking advantage of features like: Two-way binding, templating, RESTful api handling, modularization, AJAX handling, dependency injection, etc
All of our frontend code is on AngularJS. Directives, controllers, and services really help in organizing code in order to keep things maintainable, and two-way binding makes data input easy. The large ecosystem of modules for directives is fantastic, too.
When ever I need heavy user client side apps this is my tool of choice. There are a ton of JS frameworks out there, picked this one because of philosophy they are trying to put out there and great community. Two way data binding FTW!
The front end was built on an Angular template supplied by the client. We leveraged Angular's flexibility and speed to delivered complex matrices of data quickly and with great finesse.
We use Angular.js to build our front-end framework known as Frontkit, so our apps can get started faster with reliable, interactive components.