Here’s to the Next 5 Years of MarionetteJs

Paul Falgout
Marionette.js blog
4 min readDec 11, 2016

--

On December 11th, 2016, Marionette will turn 5 years old. This project has consistently grown over these years. We’ve seen hundreds of contributors, thousands of commits, and tens of thousands of projects using Marionette. We have been cutting-edge and we have been old-hat. We have seen many frameworks come and some go. We may never again be shiny and new, but we strive to move ever forward.

Why Marionette?

In early 2013, I was tasked with finding a solution to the ever growing complexities of the RoundingWell PHP & jQuery webapp. Design was asking for more and more interaction, and maintaining the state was producing brittle, hard to understand code. I turned to frontend libraries for a solution, and after researching various options, I felt the most comfortable with Marionette. It had an active community and the library seemed small enough and unopinionated enough that it could be shoehorned into awkward periods of refactoring the large server-side application. To add to that, the RoundingWell team was learning while doing. We needed a small API we could grok quickly, and the ability to easily read and understand the source was invaluable.

I find the reasons people are choosing Marionette today are similar. For developers new to javascript frameworks, it feels comfortable. It has a small and flexible API. And the code base is easy to read and understand.

Iterative and Incremental

In the year of javascript fatigue, developers are feeling overwhelmed by the ever expanding list of things they may need to know. They are plagued with option anxiety and a constant push to drop what they know and move to the new thing to follow the “community”. Stability is construed as stagnation, and when new best practices are theorized, current best practices are demonized.

So if you’re developing a maturing javascript framework with a mostly stable API, what should you do when someone introduces an improvement through another framework? You could abandon your project and refactor everything to use the newer solution and thus require everyone else do the same. But clearly that isn’t realistic. A more pragmatic approach, but certainly a less exciting one, is to observe what works and make iterative and incremental changes towards a better solution. It is important to move at a pace that the user base and contributors can keep up with.

Marionette hopes to improve in this manner. This might mean that Marionette will never be cutting-edge, but what it does mean is that Marionette is improving and your app won’t need a ground-up refactor for the long term.

Looking back

The journey hasn’t been perfect. I believe the v3 release of Marionette was overly ambitious and changed too many things. The changes that were made were absolutely necessary and good, but the release took too long to go public and was too much of a transition. We certainly need everyone’s help to improve documentation and to build and add examples that go along with v3. While we haven’t lost much momentum in content creation, there is a wealth of v2 content that makes the v3 content harder to find in the wild. Additionally if you haven’t made the jump to v3, please do! If you need assistance our community is invaluable.

Looking forward

As we look to 2017, the Marionette core team is committing to smaller releases. Major and breaking releases will ideally be small and trivial updates, while we hope to release our more exciting features in minor versions. Breaking changes may be introduced behind feature flags or in parallel to current features so developers can preview the next major version behavior.

Our overall goals haven’t changed. Marionette aims to be approachable with a small, easy to understand API. We want our source code to be easily readable with clear organization. We want Marionette to be iterative both in how we approach changes to the library as well as how it can be implemented into an existing project. Marionette will remain flexible. While we will offer suggested best practices, most architectural decisions are up for the developer to decide as to what works best for their project. Perhaps the most important goal is that we plan to support our community as best as we can. The Marionette community has been excellent at supporting each other and building content to improve the ecosystem. Come chat with us!

Thanks. Here’s to the next 5 years.

-
@paulfalgout

--

--