Marionette.js 5 years old

December 11, 2016 Marionette.js 5 years old. This project has gradually grown all these years. It was developed by hundreds of contributors, hundreds of commits and tens of hundreds of projects that use Marionette were created. We were innovative and outdated. We have seen new frameworks coming and some leaving. We may never be new and fashionable, but we will do our best to constantly move forward.

Why Marionette.js?

At the beginning of 2013, I was tasked with finding a solution to the ever-growing difficulties in a RoundingWell application that used PHP and jQuery. The design constantly demanded more and more user interactions with the application. Maintaining such a state led to the creation of fragile and difficult to understand code. I looked at the frontend of the library to find a solution, and after researching many resources I felt more comfortable with Marionette. At that time, he had an active community, the library itself looked small enough and flexible to interact with the server. Frankly, the RoundingWell team learned on the fly. We needed a small API that we could quickly understand, and the ability to quickly read and understand the source code was awesome.

The motivations by which people choose Marionette today are very similar. For developers who are just familiar with javascript frameworks, this provides a feeling of comfort. Marionette has a small and flexible API, and the code base is simple and easy to understand.

Interactive and complementary

New developers, after a year of learning, feel terrible about the ever-growing list of new technologies that they may need to know. They are trying to keep up with new technologies that are popular in the community, throwing what they already know. Stability is perceived as stagnation and when new best decisions are theorized, current best decisions are demonized.

If you are developing a fairly mature javascript framework with a practically stable API, what should you do when someone presents improvements to you in the form of solutions implemented in another framework? You can drop your current project and start rewriting everything using a new solution, and as a result, it will definitely affect everyone around - they will be forced to do the same. But frankly, this is unrealistic. It will be more pragmatic and of course less exciting to discover what is working now and apply interactive and progressive changes that will bring a better solution. This is important when users and contributors move in step.

Marionette hopes to improve in this way. This may mean that Marionette will never be more advanced, but also that Marionette is improving and your application will not need full refactoring for a long time.

Looking back

Our trip was not perfect. I believe that the Marionette v3 release was ambitious and changed a lot of things. The changes made were good and very necessary, but the release preparation took a lot of time. Of course, we need the help of everyone to improve the documentation and create examples that are built on the third version. It is very difficult to find something fresh about the third version, since we did not take enough time to create new information and articles, and there is a lot of material about the second one. This affects searches. In addition, I want to say, if you have not tried the new version - please do it! If you need help, our community is always with you.

Looking forward

Watching in 2017, the Marionette team will be holding small releases. Releases of new versions will ideally contain small and simple updates, while new and exciting "features" will be released in minor versions. Changes that can break the logic of your applications will be presented in the form of flags or in parallel with the existing logic. Developers will be easy to predict the innovations of future releases.

Our main goal has not changed. Marionette aims to be accessible , with a small and clear API. We want our code to be easy to read with a clear structure. We want Marionette to be interactive both in the approach to source code changes and in applying it on real projects. Marionette will remain flexible . We will offer best practices, but most of the architectural solutions that are applicable to a particular project are on the shoulders of the developers themselves. Most likely the most important goal is the support of our community. In our community, there has always been excellent mutual support and support in creating content that improves the framework environment.

Thank. Over the next 5 years!

» Author
» Original on the blog
» Original on medium

» Repository
» Website