Loki Checkout versus Hyvä Checkout
The Hyvä Checkout was designed to be the checkout for Hyvä Themes. While other checkout extensions required Luma as a theme fallback, the Hyvä checkout did not. For years, the Hyvä Checkout was the only checkout to crank up performance properly. The Loki Checkout aimed to break through this monopoly by fixing those things that many found to be missing in the Hyvä Checkout.
Higher performance
Hyvä Checkout uses Magewire in addition to Alpine.js. This adds an additional JavaScript library of approximately 160 KB alongside the roughly 46 KB Alpine.js library. Regardless of the overall optimization strategy, this contributes to the amount of JavaScript loaded on a checkout page, where performance is particularly important. In addition, Magewire v1 can require multiple AJAX requests to update the page following a component change.
Loki Checkout uses Alpine.js for client-side reactivity and introduces its own Loki Components architecture to handle server-side interactions. This technology was developed specifically to reduce frontend overhead and streamline component updates.
As a result, Loki Checkout delivers measurably faster initial page loads and AJAX interactions compared to Hyvä Checkout. Performance is an important aspect of Loki Checkout, although it is only one part of the broader architectural differences between the two solutions.
Granular components
Hyvä Checkout is built around Magewire components. For example, an entire address form is represented by a single Magewire component. Adding fields or inserting additional blocks between existing fields therefore involves the Forms API, which introduces an additional abstraction alongside the Magewire component architecture.
With Loki Checkout, each field is an individual Loki Component and can be extended or repositioned through XML layout. Additional blocks between fields can similarly be added using standard XML layout concepts familiar to Magento developers.
The difference is also visible when the checkout is processing updates. In Hyvä Checkout, changes such as switching the account type, country, payment method, or shipping method can result in a loader blocking a larger part of the checkout. Loki Checkout limits this state to the components affected by the change. Unrelated components remain interactive, reducing the need for large, checkout-wide loading states.
The autocompletion story
Of all checkout scenarios, address autocompletion is one of the more challenging features to implement correctly. Multiple address fields need to be updated without disrupting the user experience. The number of AJAX requests should be kept to a minimum, validation messages should remain user-friendly, and—most importantly—current user input should never be overwritten by out-of-sync asynchronous responses.
Due to the asynchronous nature of Magewire, Hyvä Checkout has faced challenges with this functionality for several years. With Loki Checkout, address autocompletion was a consideration from the start. A prototype integration with Postcode.nl was built during the first month of development. In the first year, we refactored the internal architecture three times, in part to address the complexities exposed by this functionality.
Implementing address autocompletion properly is not just about fixing an individual feature. In some cases, it requires addressing the underlying architecture first.
First party integrations
Rather than relying solely on the ecosystem to build integrations over time, we made it a priority to provide Loki Checkout with essential integrations from the start—including payment solutions, shipping solutions, and a variety of smaller checkout components. Initially, these integrations served as proof of concept. They allowed us to validate whether Loki Checkout could support specific use cases and requirements. In practice, this process also led to solutions for more complex checkout scenarios.
How should payment methods that bypass the final place-order button be handled? Can the checkout be configured to provide a Shopify-like experience? Can the billing and shipping steps be reordered, with billing information collected first? We wanted to answer these questions ourselves. By exploring and implementing these scenarios, we have already built solutions that integrators can use in their own projects.
Stop overriding templates
Hyvä Themes introduced Tailwind CSS to Magento, and Hyvä Checkout naturally follows the same approach. However, when Tailwind CSS classes are defined directly in PHTML templates, adjusting styling can require agencies to create and maintain template overrides.
Loki Checkout introduces a $css() utility designed to provide more flexibility. Tailwind CSS classes can be extended or overridden through XML layout or PHP-based CSS parsers, allowing styling changes without necessarily overriding the underlying PHTML template.
Choose your checkout wisely
We believe Loki Checkout offers advantages over Hyvä Checkout in several areas. However, we also believe agencies should select a checkout solution based on its features, performance, and suitability for a specific project rather than on partnerships alone. We encourage integrators to compare solutions carefully and evaluate the details for themselves.
Compare loading times. Modify fields and observe how and when other parts of the page are updated. Enter invalid values, such as an incorrect postcode, and review how validation errors are communicated. Switch from a shipping method to pickup at a specific location and consider the experience from the customer's perspective.
The differences are often found in the details. A thorough comparison helps ensure you choose the right solution for your project and your customers.
