Why Melody?

Why did we create Melody? What is its purpose and what do we value in a framework?

The following part contains opinions and provides comparisons with other frameworks whose development does not stop and which are therefore likely already outdated when you're reading this.

Melody aims to provide a good balance between performance, code size and developer experience - just like any other framework. In Melodys case, good performance and a small code size are more important and it is therefore a lot smaller than most other frameworks. It combines a very low memory footprint with fast rendering and delivers all of that in a rather small package.

Why did you create it?

At this time the primary team behind Melody is working at trivago and we're building the hotel search application - a meta search engine for hotels and other accommodations.

Unlike many modern web apps like Facebook, Netflix or many internal tools our users land on our page and want to interact with it as soon as possible. They don't spend hours going through their newsfeed. They spend minutes. And we have to make sure that they receive the maximum value for every minute they spend with us. We also don't have the benefit of hiding our application behind a login page, so lazy loading wouldn't help to improve performance and we can't rely on long term caching as our users might not come back too often - just ask yourself: how often are you looking for a hotel? Thus, time to interactive is a highly critical measurement for us and therefore Melody has to be small.

Unlike many internal tools, we also don't benefit from being able to say "all our users have a modern device," since trivago operates worldwide. We want to be able to deliver a good experience to all of our users, regardless of the quality of their device. To achieve that, Melody has to be fast but also mindful with respect to reduced memory usage.

However, just like any other company in the world, we also want to be able to focus on building an amazing product. Thus, Melody has to offer a great developer experience that should be as familiar as possible to every engineer.

We also wanted to be able to reuse as much of our existing code as possible and thus, Melody has to understand Twig templates. Enabling us to render the same views on the client and on the server using JavaScript in the frontend and PHP on the backend.

When we decided to start working on Melody in 2015 there was no framework out there that would've delivered what we needed: A small size to get our app interactive quickly, a low memory consumption to enable low-quality devices to work smoothly and a development experience that competes with the best-in-class frameworks. So we decided to build our own.

Would you do it again?

Short answer: Yes.

Slightly longer answer: We're keeping a very close eye on other frameworks and especially Svelte and Glimmer are highly interesting to us. They both offer a similar tradeoff with Glimmer being one of the most innovative projects out there. We also watch React closely for their innovation regarding the development experience and interesting new ideas for API design.

Melody has been designed from the ground up to be flexible, to allow us to replace many or even all parts of it. For example besides the usual runtime, the compiler is also perfectly capable of taking Melody templates and producing JSX out of it, ready to be used within a React application. And when we saw React Hooks, we immediately implemented a new component API which can be used instead of the original melody-component API.

In the same way we'll keep observing Svelte and Glimmer and eventually we'll also jump towards an even more efficient renderer system which will enable us to remove the template instructions from our JavaScript - just like Glimmer is doing.

Compared to Glimmer Melody currently is a lot smaller and more production ready. It integrates very nicely with Webpack and offers familiar APIs for engineers who have used React before.

Svelte is an amazing tool and which one you prefer is likely down to a question of choice. Svelte is very different from React while Melody feels rather familiar to most engineers.

Should we use it?

That is entirely up to you. trivago has been using Melody since 2015 and we've been incredibly successful with it. Our engineers enjoy using it and it has proven to be a useful tool. Our intention in Open Sourcing Melody is not to replace any of the other frameworks but rather to enable others to also use the tool we've come too enjoy so much.

Since that likely didn't help you, we've prepared a short questionnaire for you:

• Do your users need to login before they can interact with the page?

• Are your users consistently on a fast network?

• Are your users using only high end devices?

• Are you working in a small team on many different applications?

• Is productivity more important to you than a high quality product (i.e. are you working at a startup?)

If the answer to many of those questions is a "Yes" then your framework choice shouldn't be based on technical considerations but rather which framework you like the most. Generally speaking Melody hasn't been designed for your use case and you might find some of its tradeoffs to be worse for you than they are for others.

What does it look like?

Since you've managed to get this far, we would like to provide you with a small sneak peak at what a Melody component could look like.

src/counter/index.js

import { createComponent, attachEvent } from 'melody-streams';
import { scan, mapTo, startWith } from 'rxjs/operators';
import { merge } from 'rxjs';
import template from './index.twig';

// define the component function
const Counter = ({ props }) => {
    // define event streams
    const [incrementButton, incremented] = attachEvent('click');
    const [decrementButton, decremented] = attachEvent('click');

    // the current count is the result of merging those events together
    const count = merge(
        incremented.pipe(mapTo(1)),
        decremented.pipe(mapTo(-1))
    ).pipe(
        // provide a starting value of 0
        startWith(0),
        // do the math
        scan((acc, next) => acc + next, 0)
    );
    
    // return an object whose properties are streams
    return {
        count,
        incrementButton,
        decrementButton
    };
}

// combine the state hook with the template and get a component back
export default createComponent(Counter, template);

src/counter/index.twig

<div class="counter">
  <h3>Counter: {{ count }}</h3>
  <button onclick="{{ increaseCounter }}"> + </button>
  <button onclick="{{ decreaseCounter }}"> - </button>
</div>

If you've used Rx.js before then you'll find yourself right at home but you also don't need to worry if you haven't seen this before - we'll introduce you to it.