Author Archives: Patrick Steele-Idem

About Patrick Steele-Idem

Patrick Steele-Idem is a member of eBay’s platform team who enjoys writing open-source software and improving how web applications are built. He is the author of RaptorJS, a suite of open-source front-end power tools that are being used within and outside eBay.

The Future of Marko

At eBay, we’ve completely transformed how we build web applications, starting with the transition from a Java-based stack to a Node.js-based stack. Node.js has enabled teams to move faster, and it offers an abundant ecosystem of tools and libraries that are essential to modern web application development.

We built Marko, a library for building UI components with minimal boilerplate, five years ago and it has evolved based on feedback from our vibrant and growing community. Marko is completely open source and to ensure that it remains a healthy open source project, we are thrilled to announce that eBay will be contributing Marko to the JS Foundation.

Marko will continue to be a key component of eBay’s web application development stack. It takes care of automatically and efficiently updating the DOM in response to data changes. On the server, Marko takes advantage of the asynchronous and streaming primitives provided by Node.js to greatly accelerate the performance of eBay’s pages, ensuring shoppers are getting the fastest experience available when browsing on eBay.

Joining the JS Foundation

At eBay, we were founded with the core belief that we should use technology to empower and connect people globally. In the technology world, we’re a core contributor to and believer in open source technology. Not only does a company culture of open source help us empower our developers, but it also enables our technologists to collaborate across the organization and with peers across the industry. eBay is a member of the Linux Foundation (including the Cloud Native Computing Foundation and the Open API Initiative) and will continue to actively participate in the open source software community.

So what does it mean for Marko to join the JS Foundation? First off, with nearly 20,000 UI components within eBay, we are committed to evolving Marko and expanding the surrounding ecosystem. The Marko core team members that are employed by eBay will continue to maintain and lead the project.

As part of the JS Foundation, Marko will reside alongside other notable projects such as webpack and Mocha. By moving Marko to the JS Foundation, we feel that we will be able to more closely align with other projects in the JavaScript ecosystem. In addition, we want to make it clear that Marko has and always will be open to outside contributions and outside maintainers. While we have seen great growth in the Marko community, we believe there is still a lot of potential yet to be unlocked. Through neutral governance and close ties with other prominent projects, we believe the JS Foundation will allow the Marko community to grow and flourish.

Early history

Marko has a long history within eBay that dates back to 2012, when we started exploring using Node.js as our web application development stack. This was at a time when JavaScript HTML templating was starting to take off. At eBay, server-side rendering was very important, and we wanted support for UI components that provided encapsulation of rendering logic, client-side behavior and styling, and progressive and asynchronous HTML rendering (features that we had on our previous Java-based stack). Dust.js was used by a few teams because it offered streaming and asynchronous rendering, but it lacked support for UI components. Dust.js also provided very few hooks to optimize templates at compile-time, and it promoted what we considered the bad practice of global helpers. eBay open sourced a JavaScript toolkit named RaptorJS that included a very early version of Marko called Raptor Templates. RaptorJS is now defunct, but many of the modules that were part of RaptorJS now live on as independent projects (including Marko).

Marko has evolved a lot over the years. While Marko has always had very strong performance on the server and support for basic UI components, many other features came later and were inspired by other UI libraries/frameworks. For example, after React was announced and gained popularity due to virtual DOM (VDOM) rendering and diffing, we also introduced VDOM rendering and DOM diffing/patching into Marko to avoid manual DOM manipulation. However, unlike with React, the Marko VDOM was and will continue to be an implementation detail that could change at any time. Support for single file UI components was inspired by a similar feature found in Vue and Riot.js. Marko has always aimed to stay competitive with other UI libraries by innovating and closely following industry trends while also focusing on keeping the runtime fast and small.

Marko is now heavily used within eBay, and it is also starting to be used by outside companies, startups, government agencies and educational institutions. The Marko ecosystem has continued to grow and is now supported in many different IDEs and editors and on services like GitHub. The core Marko team has continued to grow, and it consists of a mix of eBay employees and outside developers.

Project roadmap

Asset pipeline integration

Delivering JS, CSS, images, and other front-end assets to the browser is a fundamental requirement of building any web application. As such, we believe Marko should offer first-level support for an “asset pipeline” to simplify the build chain that most developers are used to.

At eBay, we do not have a separate build step. Instead, at runtime we generate all of the JavaScript and CSS bundles required to make the page function. In addition, our tools automatically inject the required <script> tags into the page body and the required <link> tags into the page head. Furthermore, front-end assets such as images and fonts automatically get uploaded to the eBay Resource Server that backs our Content Distribution Network (CDN). We want to introduce this ease of use to all users of Marko.

Progressive Web App (PWA) samples

Progressive Web Apps offer a compelling user experience that is reliable, fast, and engaging. We want to help more developers build PWAs and will be rolling out more sample PWAs built on Marko to help guide developers.

Language Server support

Integrations with editors and IDEs is a challenge for any new language or framework. We have implemented advanced support for the Atom editor, including autocomplete of both core and user-defined tags, hyperclick to jump to tag definitions, and more. But for other editors, we only provide basic syntax highlighting.

Microsoft’s Language Server Protocol gives us the opportunity to write this advanced functionality in a way that can be shared across a growing number of editors.

Improved error messages in development

Compiler checks have been used to improve the developer experience: things like misspelled tag names or using deprecated features.  And while these checks are pretty comprehensive, there are certain checks that can only be done at runtime.

In the past, we have kept runtime code size small and fast by limiting error messages and runtime error checking. We recently updated Marko to support both a development mode and a production mode, and now we want to take the logical next step to add additional code to our runtime that will provide much friendlier error messages and catch problems earlier.

UI component marketplace

Starting a new web application can be daunting, but having an arsenal of UI components to choose from can be a huge time saver. While it can be challenging to create a UI component that works well for every application, we believe it is extremely helpful for developers to showcase their UI components, even if they are to be forked and adapted for slightly different use cases.

With nearly 20k components at eBay, we want to make it easy for our own developers to find the right component for the job, and we’d like to extend this marketplace to the open source community to make it easy to find quality components for use in your app.

We are excited about the future of Marko and look forward to building it with the support of the JS Foundation. If you are interested in learning more about Marko, you can get additional information on the Marko website. Join the conversation and contribute on GitHub.

– the Marko team at eBay


Patrick Steele-Idem

Patrick Steele-Idem is a Principal Engineer on the eBay Platform team and is co-leading eBay’s open source program. He is actively engaged in many open source projects (including Marko, Lasso, and morphdom). Patrick is the original author of Marko and is now leading the Marko core team and the Lasso core team.

 


Michael Rawlings

Michael Rawlings is a Senior Software Engineer on the eBay Platform team where he works closely with product teams to improve the way front-end applications are built. He enjoys building tools that improve the developer experience and make it simpler to build scalable and performant apps.  

 


Austin Kelleher

Austin is a Software Engineer on the eBay Platform team. He graduated from Penn State University in 2016 with a degree in Computer Science. Previous to joining eBay, Austin contributed to Marko and Lasso in his free time.

Announcing Marko v3: From HTML to HTML-JS

MarkoJS LogoMarko is one of the fastest, lightest, and most powerful HTML templating engines for Node.js and the browser, and we are very pleased to see a healthy and growing community. Marko has been downloaded over 100k times in the first few months of 2016, and the project has a very active Gitter chat room. We are excited to announce some huge improvements to the Marko templating engine as part of the v3 release.

Marko v3 introduces a new HTML-JS syntax and a new parser that makes Marko more intuitive. Marko’s clean, HTML-based syntax has been a strength, but over time it became clear that using a strict HTML parser was actually putting unnecessary constraints on the Marko language that negatively impacted code readability and usability. The new HTML-JS syntax that ships with Marko v3 breaks away from the limitations associated with the standard HTML syntax while still maintaining the look and feel of HTML.

Read more on the MarkoJS blog.

Async Fragments: Rediscovering Progressive HTML Rendering with Marko

At eBay, we take site speed very seriously and are always looking for ways to allow developers to create faster-loading web apps. This involves fully understanding and controlling how web pages are delivered to web browsers. Progressive HTML rendering is a relatively old technique that can be used to improve the performance of websites, but it has been lost in a whole new class of web applications. The idea is simple: give the web browser a head start in downloading and rendering the page by flushing out early and multiple times. Browsers have always had the helpful feature of parsing and responding to the HTML as it is being streamed down from the server (even before the response is ended). This feature allows the HTML and external resources to be downloaded earlier, and for parts of the page to be rendered earlier. As a result, both the actual load time and the perceived load time improve.

In this blog post, we will take an in-depth look at a technique we call “Async Fragments” that takes advantage of progressive HTML rendering to improve site speed in ways that do not drastically complicate how web applications are built. For concrete examples we will be using Node.js, Express.js and the Marko templating engine (a JavaScript templating engine that supports streaming, flushing, and asynchronous rendering). Even if you are not using these technologies, this post can give you insight into how your stack of choice could be further optimized.

To see the techniques discussed in this post in action, please take a look at the accompanying sample application.

Background

Progressive HTML rendering is discussed in the post The Lost Art of Progressive HTML Rendering by Jeff Atwood, which was published back in 2005. In addition, the “Flush the Buffer Early” rule is described by the Yahoo! Performance team in their Best Practices for Speeding Up Your Web Site guide. Stoyan Stefanov provides an in-depth look at progressive HTML rendering in his Progressive rendering via multiple flushes post. Facebook discussed how they use a technique they call “BigPipe” to improve page load times and perceived performance by dividing up a page into “pagelets.” Those articles and techniques inspired many of the ideas discussed in this post.

In the Node.js world, its most popular web framework, Express.js, unfortunately recommends a view rendering engine that does not allow streaming and thus prevents progressive HTML rendering. In a recent post, Bypassing Express View Rendering for Speed and Modularity, I described how streaming can be achieved with Express.js; this post is largely a follow-up to discuss how progressive HTML rendering can be achieved with Node.js (with or without Express.js).

Without progressive HTML rendering

A page that does not utilize progressive HTML rendering will have a slower load time because the bytes will not be flushed out until the complete HTML response is built. In addition, after the client finally receives the complete HTML it will then see that it needs to download additional external resources (such as CSS, JavaScript, fonts, and images), and downloading these external resources will require additional round trips. In addition, pages that do not utilize progressive HTML rendering will also have a slower perceived load time, since the screen will not update until the complete HTML is downloaded and the CSS and fonts referenced in the <head> section are downloaded. Without progressive HTML rendering, a server/client waterfall chart might be similar to the following:

Single Flush Waterfall Chart

The corresponding page controller might look something like this:

function controller(req, res) {
    async.parallel([
            function loadSearchResults(callback) {
                ...
            },
            function loadFilters(callback) {
                ...
            },
            function loadAds(callback) {
                ...
            }
        ],
        function() {
            ...
            var viewModel = { ... };
            res.render('search', viewModel);
        })
}

As you can see in the above code, the page HTML is not rendered until all of the data is asynchronously loaded.

Because the HTML is not flushed until all back-end services are completed, the user will be staring at a blank screen for a large portion of the time. This will result in a sub-par user experience (especially with a poor network connection or with slow back-end services). We can do much better if we flush part of the HTML earlier.

Flushing the head early

A simple trick to improve the responsiveness of a website is to flush the head section immediately. The head section will typically include the links to the external CSS resources (i.e. the <link> tags), as well as the page header and navigation. With this approach the external CSS will be downloaded sooner and the initial page will be painted much sooner as shown in the following waterfall chart:

Flush Head Waterfall Chart

As you can see in the chart above, flushing the head early reduces the time to render the initial page. This technique improves the responsiveness of the page, but it does not significantly reduce the total time it takes to make the page fully functional. With this approach, the server is still waiting for all back-end services to complete before flushing the final HTML. In addition, downloading of external JavaScript resources will be delayed since <script> tags are placed at the end of the page (assuming you are following best practices) and don’t get sent out until the second and final flush.

Multiple flushes

Instead of flushing only the head early, it is often beneficial to flush multiple times before ending the response. Typically, a page can be divided into multiple fragments where some of the fragments may depend on data asynchronously loaded from various back-end services while others may not depend on any asynchronously loaded data. The fragments that depend on asynchronously loaded data should be rendered asynchronously and flushed as soon as possible.

For now, we will assume that these fragments need to be flushed in the proper HTML order (versus the order that the data asynchronously loads), but we will also show how out-of-order flushing can be used to further improve both page load times and perceived performance. When using “in-order” flushing, fragments that complete out of order will need to be buffered until they are ready to be flushed in the proper order.

In-order flushing of async fragments

As an example, let’s assume we have divided a complex page into the following fragments:

Page diagram

Each fragment is assigned a number based on the order that it appears in the HTML document. In code, our output HTML for the page might look like the following:

<html>
<head>
    <title>Clothing Store</title>
    <!-- 1a) Head <link> tags -->
</head>
<body>
    <header>
       <!-- 1b) Header -->
    </header>
    <div class="body">
        <main>
            <!-- 2) Search Results -->
        </main>
        <section class="filters">
            <!-- 3) Search filters -->
        </section>
        <section class="ads">
            <!-- 4) Ads -->
        </section>
    </div>
    <footer>
        <!-- 5a) Footer -->
    </footer>
    <!-- 5b) Body <script> tags -->
</body>
</html>

The Marko templating engine provides a way to declaratively bind template fragments to asynchronous data provider functions (or Promises). An asynchronous fragment is rendered when the asynchronous data provider function invokes the provided callback with the data. If the asynchronous fragment is ready to be flushed, then it is immediately flushed to the output stream. Otherwise, if the asynchronous fragment completed out of order then the rendered HTML is buffered in memory until it is ready to be flushed. The Marko templating engine ensures that fragments are flushed in the proper order.

Continuing with the previous example, our HTML page template with asynchronous fragments defined will be similar to the following:

<html>
<head>
    <title>Clothing Store</title>
    <!-- Head <link> tags -->
</head>
<body>
    <header>
        <!-- Header -->
    </header>
    <div class="body">
        <main>
            <!-- Search Results -->
            <async-fragment data-provider="data.searchResultsProvider"
                var="searchResults">

                <!-- Do something with the search results data... -->
                <ul>
                    <li for="item in searchResults.items">
                        $item.title
                    </li>
                </ul>

            </async-fragment>
        </main>
        <section class="filters">

            <!-- Search filters -->
            <async-fragment data-provider="data.filtersProvider"
                var="filters">
                <!-- Do something with the filters data... -->
            </async-fragment>

        </section>
        <section class="ads">

            <!-- Ads -->
            <async-fragment data-provider="data.adsProvider"
                var="ads">
                <!-- Do something with the ads data... -->
            </async-fragment>

        </section>
    </div>
    <footer>
        <!-- Footer -->
    </footer>
    <!-- Body <script> tags -->
</body>
</html>

The data provider functions should be passed to the template as part of the view model as shown in the following code for a sample page controller:

function controller(req, res) {
    template.render({
            searchResultsProvider: function(callback) {
                performSearch(req.params.category, callback);
            },

            filtersProvider: function(callback) {
                ...
            },

            adsProvider: function(callback) {
                ...
            }
        },
        res /* Render directly to the output HTTP response stream */);
}

In this particular example, the “search results” async fragment appears first in the HTML template, and it happens to take the longest time to complete. As a result, all of the subsequent fragments will need to be buffered on the server. The resulting waterfall with in-order flushing of async fragments is shown below:

In-order Flush Waterfall Chart

While the performance of this approach might be fine, we can enable out-of-order flushing for further performance gains as described in the next section.

Out-of-order flushing of async fragments

Marko achieves out-of-order flushing of async fragments by doing the following:

Instead of waiting for an async fragment to finish, a placeholder HTML element with an assigned id is written to the output stream. Out-of-order async fragments are rendered before the ending <body> tag in the order that they complete. Each out-of-order async fragment is rendered into a hidden <div> element. Immediately after the out-of-order fragment, a <script> block is rendered to replace the placeholder DOM node with the DOM nodes of the corresponding out-of-order fragment. When all of the out-of-order async fragments complete, the remaining HTML (e.g. </body></html>) will be flushed and the response ended.

To clarify, here is what the output HTML might look like for a page with out-of-order flushing enabled:

<html>
<head>
    <title>Clothing Store</title>
    <!-- 1a) Head <link> tags -->
</head>
<body>
    <header>
        <!-- 1b) Header -->
    </header>
    <div class="body">
        <main>
            <!-- 2) Search Results -->
            <span id="asyncFragment0Placeholder"></span>
        </main>
        <section class="filters">
            <!-- 3) Search filters -->
            <span id="asyncFragment1Placeholder"></span>
        </section>
        <section class="ads">
            <!-- 4) Ads -->
            <span id="asyncFragment2Placeholder"></span>
        </section>
    </div>
    <footer>
        <!-- 5a) Footer -->
    </footer>

    <!-- 5b) Body <script> tags -->

    <script>
    window.$af=function(){
    // Small amount of code to support rearranging DOM nodes
    // Unminified:
    // https://github.com/raptorjs/marko-async/blob/master/client-reorder-runtime.js
    };
    </script>

    <div id="asyncFragment1" style="display:none">
        <!-- 4) Ads content -->
    </div>
    <script>$af(1)</script>

    <div id="asyncFragment2" style="display:none">
        <!-- 3) Search filters content -->
    </div>
    <script>$af(2)</script>

    <div id="asyncFragment0" style="display:none">
        <!-- 2) Search results content -->
    </div>
    <script>$af(0)</script>

</body>
</html>

One caveat with out-of-order flushing is that it requires JavaScript running on the client to move each out-of-order fragment into its proper place in the DOM. Thus, you would only want to enable out-of-order flushing if you know that the client’s web browser has JavaScript enabled. Also, moving DOM nodes may cause the page to be reflowed, which can be visually jarring to the user and result in more client-side CPU usage. If reflow is an issue then there are tricks that can be used to avoid a reflow (e.g., reserving space as part of the initial wireframe). Marko also allows alternative content to be shown while waiting for an out-of-order async fragment.

To enable out-of-order flushing with Marko, the client-reorder="true" attribute must be added to each <async-fragment> tag, and the <async-fragments> tag must be added to the end of the page to serve as the container for rendered out-of-order fragments. Here is the updated <async-fragment> tag for the search results fragment:

<async-fragment data-provider="data.searchResultsProvider"
    var="searchResults"
    client-reorder="true>
    ...
</async-fragment>

The updated HTML page template with the new <async-fragments> tag is shown below:

<html>
<head>
    <title>Clothing Store</title>
    <!-- Head <link> tags >
</head>
<body>
    ...

    <!-- Body <script> tags -->

    <async-fragments/>
</body>
</html>

In combination with out-of-order flushing, it may be beneficial to move <script> tags that link to external resources to the end of the first chunk (before all of the out-of-order chunks). While the server is busy preparing the rest of the page, the client can start downloading the external JavaScript required to make the page functional. As a result, the user will be able to start interacting with the page sooner.

Our final waterfall with out-of-order flushing will now be similar to the following:

Out-of-order Flush Waterfall Chart

The final waterfall shows that the strategy of out-of-order flushing of asynchronous fragments can significantly improve the load time and perceived load time of a page. The user will be met with a progressive loading of a page that is ready to be interacted with sooner.

Additional considerations

HTTP Transport and HTML compression

To allow HTML to be served in parts, chunked transfer encoding should be used for the HTTP response. Chunked transfer encoding uses delimiters to break up the response, and each flush results in a new chunk. If gzip compression is enabled (and it should be) then flushing the pending data to the gzip stream will result in a gzip data frame being written to the response as part of each chunk. Flushing too often will negatively impact the effectiveness of the compression algorithm, but without flushing periodically then progressive HTML rendering will not be available. By default, Marko will flush at the beginning of an <async-fragment> block (in order to send everything that has already completed), as well as when an async fragment completes. This default strategy results in efficient progressive loading of an HTML page as long as there are not too many async fragments.

Binding behavior

For improved usability and responsiveness, there should not be a long delay between rendered HTML being displayed to the user in the web browser and behavior being attached to the associated DOM. At eBay, we use the marko-widgets module to bind behavior to DOM nodes. Marko Widgets supports binding behavior to rendered widgets immediately after each independent async fragment, as illustrated in the accompanying sample app. For immediate binding to work, the required JavaScript code must be included earlier in the page. For more details, please see the marko-widgets module documentation.

Error handling

It is important to note that as soon as a byte is flushed for the HTTP body, then the response is committed; no additional HTTP headers can be sent (e.g., no server-side redirects or cookie-setting), and the HTML that has been sent cannot be “unsent”. Therefore, if an asynchronous data provider errors or times out, then the app must be prepared to show alternative content for that particular async fragment. Please see the documentation for the marko-async module for additional information on how to show alternative content in case of an error.

Summary

The Async Fragments technique allows web developers to maximize the benefits of progressive HTML rendering to produce web pages that have improved actual and perceived load times. Developers at eBay have found the concept of binding HTML template fragments to asynchronous data providers easy to grasp and utilize. In addition, the flexibility to support both in-order and out-of-order flushing of async fragments makes this technique applicable for all web browsers and user agents.

The Marko templating engine is being used as part of eBay’s latest Node.js stack to improve performance while also simplifying how pages are constructed on both the server and the client. Marko is one of a few templating engines for Node.js and web browsers that support streaming, flushing, and asynchronous rendering. Marko has a simple HTML-based syntax, and the Marko compiler produces small and efficient JavaScript modules as output. We encourage you to try Marko online and in your next Node.js project. Because Marko is a key component of eBay’s internal Node.js stack, and given that it is heavily documented and tested, you can be confident that it will be well supported.

Patrick Steele-Idem is a member of eBay’s platform team who enjoys writing open-source software and improving how web applications are built. He is the author of RaptorJS, a suite of open-source front-end power tools that are being used within and outside eBay. You can follow Patrick on Twitter at @psteeleidem.