WebAssembly at eBay: A Real-World Use Case

WebAssembly at eBay: A Real-World Use Case

From the time it was announced, WebAssembly caused a huge buzz in the front-end world. The web community readily embraced the idea of taking code written in programming languages other than JavaScript and running that code in the browser.

From the time it was announced, WebAssembly caused a huge buzz in the front-end world. The web community readily embraced the idea of taking code written in programming languages other than JavaScript and running that code in the browser.

Above all WebAssembly consistently guarantees native speeds much faster than JavaScript. At eBay, we were no different.

Our engineers were very excited about this idea and kept a constant eye on the spec and its evolution. Once WebAssembly 1.0 was shipped in all major browsers, teams around eBay were eager to try it out.

But there was a problem. Though there are many use cases and applications that would benefit from WebAssembly, the scope of the technology within **ecommerce **is still primitive. We were not able to find a proper use case to leverage WebAssembly. A few suggestions came up, but we were better off with JavaScript itself. At eBay, when we evaluate new technologies, the first question we ask is “What potential value does this add to our customers?” Unless there is clarity around this, we do not proceed to the next step. It is very easy to be carried away by the new shiny thing, often forgetting the fact that it may not make any difference to our customers and only complicate the existing workflow. User experience always trumps developer experience. But **WebAssembly **was different. It has tremendous potential, we just did not have the right use case. Well, that changed recently.

A barcode scanner

eBay native apps both **iOS **and **Android **have a barcode scanner feature in the selling flow. The feature leverages the device camera to scan a product UPC barcode and automatically fill out the listing, thus removing the manual overhead. This was a native app-only feature. It requires some intense image processing on the device to detect the barcode number from the camera stream. The retrieved code is then be sent to a backend service which, in turn, fills out the listing. This means that the on-device image processing logic has to very performant. For native apps, we compiled an in-house built C++ scanner library into native code for both iOS and Android. It was extremely well performant in generating the product barcode from the camera stream. We are slowly transitioning to iOS and Android native APIs, but the C++ library is still solid.

The barcode scanner is an intuitive feature for our sellers, as it made the listing flow more seamless. Unfortunately, this feature was not enabled for our mobile web users. We already have a well-optimized selling flow for the mobile web, except that the barcode scanner was not available, and sellers have to manually enter the product UPC, thus adding more friction.

A barcode scanner for the web

We have looked into implementing a barcode scanner for the web before. We, in fact, launched a version of the barcode scanner with the open source JavaScript library BarcodeReader. This was 2 years back. The issue was that it performed well only 20% of the time. The remaining 80% of the time, it was extremely slow and users assumed it was broken. It was timing out the majority of the cases. This is sort of expected, as JavaScript can indeed be equally fast as native code, but only when it is in a “hot path,” i.e. heavily optimized by JIT compilers. The trick is that JavaScript engines use a lot of heuristics to decide if a code path is “hot,” and it is not guaranteed on every instance. This inconsistency obviously resulted in user frustration, and we had to disable the feature. But things are different now. With the web platform evolving at a rapid pace, the question resurfaced “Can we implement a consistently performant barcode scanner for the web?”

One option is to wait for the Shape Detection API. This proposed web API brings many native image detection features to the web, one of which is barcode detection. It’s still in very early stages and still has a long way to achieve cross-browser compatibility. Even then, it is not guaranteed to work on every platform. So we have to think about other options.

This is where WebAssembly comes into play. If a barcode scanner is implemented in WebAssembly, we can make strong guarantees that it would be consistently performant. The strong typing and structure of WebAssembly bytecode enable the compilers to always stay on the hot path. On top of it, we had an existing C++ library that was doing the job for native apps. C++ libraries are ideal candidates to be compiled to WebAssembly. We thought we had a clear path. Well, not exactly.


Our engineering design to implement a WebAssembly-based barcode scanner was pretty straightforward.

  • Compile the C++ library using Emscripten. This will generate the JavaScript glue code and .wasm file.
  • Create a Worker thread from the main thread. The worker JavaScript will import the generated JavaScript glue code, which in turn instantiates the .wasm file.
  • The main thread will send a snapshot from the camera stream to the worker, and the worker will call the corresponding wasm API through the glue code. The response of the API is passed to the main thread. The response can either be the UPC string (which is passed to backend) or an empty string if no barcode is detected.
  • For the empty scenario, the above step is repeated until a barcode is detected. This loop is timed by a configurable threshold in seconds. Once the threshold is reached, we display a warning message “This is not a valid product code. Please try another barcode or search by text.” This either means the user is not focusing on a valid barcode or the barcode scanner is not performant enough. We track these timeout instances, as it is a good indicator of how well the barcode scanner is performing.

WebAssembly Workflow


The first step for any *WebAssembly *project is to have a well-defined compilation pipeline. Emscripten has become the de facto toolchain for compiling WebAssembly, but the key is to have a consistent environment that produces a deterministic output. Our frontend is based on Node.js, which means we need a solution that works with the npm workflow. Fortunately, it was around the same time that the article “Emscripten and npm” was published by Surma Das. The Docker-based approach for compiling **WebAssembly **makes perfect sense, as it removes a ton of overhead. As recommended in the article, we went with the Docker Emscripten image by trzeci. We had to make a couple of tweaks to the custom C++ library to make it compatible to compile to WebAssembly. That was mostly a trial and error exercise. Ultimately we were able to compile and were also able to set up a neat **WebAssembly **workflow within our existing build pipeline.

It was fast, but…

The way we calculate the performance of the scanner is by analyzing the number of frames the wasm API can process in a second. The wasm API takes in a frame, in this case, an image snapshot pixel data from the live camera stream, performs the calculations and returns a response. This is done on a continuous basis until a barcode is detected. We measure it in terms of the well-known Frames Per Second (FPS) metric.

In our testing, the **WebAssembly **implementation performed at an astonishing 50 FPS on an average. However, it worked only 60% of the time with the current timeout threshold. Even with this high FPS, it was not able to quickly detect the barcode for the remaining 40% of valid scans and ended-up displaying the warning message. To put this in comparison, the JavaScript implementation that we tried earlier performed only at 1 FPS for the vast majority. So for sure, **WebAssembly **is faster (50x), but somehow it was not able to detect the barcode in the allocated time for nearly half of the scans. It should also be mentioned that in certain scenarios, JavaScript performed really well and was able to detect the barcode immediately. One obvious option would be to delay showing the warning message, but that would only increase user frustration, and we are not actually solving the real problem. So we dropped that idea.

Initially, we were clueless about why the custom C++ library, which worked perfectly well for native apps, did not produce the same result for the web. After a lot of testing and debugging, we found that the angle in which we focus the object, along with the background shadow, determines the time for successful detection. Then how did it work in native apps? Well, in native apps we use inbuilt APIs to either autofocus or provide user tap focus to the center of the object that is being scanned. This enables native apps to send high-quality image pixel data (i.e. information only about the barcode) to the scanner library at all times. This avoids the blurry image situation. Hence the consistently fast response times.

Now that we had an idea about what is going on, we thought maybe a different native library might perform better under varied focus conditions. The open source barcode reader ZBar is pretty popular and stable. More importantly, it works well with blurry and grainy images. Why not try that? Since we have a WebAssembly workflow already set up, compiling and deploying ZBar as WebAssembly was seamless. We then began evaluating the ZBar implementation. The performance was decent, around 15 FPS (not as good as our custom C++ lib). However, the success rate was close to 80% for the same timeout threshold. Definitely an improvement over our custom C++ library, but still not 100% reliable.

We were still not satisfied with the outcome, but we noticed something unexpected. The scenarios in which ZBar timed out, the custom C++ library was able to get the job done very quickly. This was a sweet surprise. Apparently, based on the quality of the image snapshot, the two libraries performed differently. This gave us an idea.

Multithreading and racing to the rescue

You probably guessed it. Why not create two web worker threads — one for ZBar and one for the custom C++ library — and race them against each other. The winning response (i.e. the first one to send a valid barcode) is sent to the main thread, and all workers are terminated. We set this up and started internal dogfooding to simulate as many scenarios as possible. This setup yielded us a 95% success rate when scanning a valid barcode. Much better than our previous success rates, but it still falls short of 100%.

One weird suggestion was to also put the original JavaScipt library into the mix. This would make it three threads. We honestly did not think that this would make a difference. But it was easy to try out, as we standardized the worker interface. To our surprise, with three threads racing against each other, the success rate was indeed close to 100%. This again was totally unexpected. As mentioned earlier in the post, JavaScript did perform very well on certain scenarios, and this factor seemed to close the gap. So yes, “always bet on JavaScript.” Jokes apart, the following diagram provides a good overview of the final architecture we implemented.

Web-based barcode scanner architecture

The following illustration shows a high-level flowchart:

Barcode scanner flowchart

A note about asset loading

The assets required for the barcode scanner are prefetched after the main page is rendered. This is to ensure that the sell landing page is loaded fast and ready to interact. The WebAssembly assets (wasm files and associated glue code scripts) and the JavaScript scanner lib are prefetched and cached after the load event of the page using XMLHttpRequest. The point to note here is that they are not executed. This is to keep the main thread free for user interaction. Execution happens only when the user taps on the barcode icon. In case a user taps on the barcode icon before the assets are loaded, we load them on demand and execute immediately. The barcode event handler and worker controller are bundled as a part of the initial page load, but they are very small in size.


After thorough testing and internal dogfooding, the feature was launched as an A/B test. The “Test” bucket in the experimentation showed the barcode scanner icon (screenshot below) and the “Control” did not.

The final product

The metric that was used to evaluate the success of the A/B test was something called “Draft Completion Rate.” It is the rate at which a listing goes from a draft stage to successfully completed and submitted. The Draft Completion Rate is a good indicator to support the notion that reducing friction and proving a seamless selling flow through a barcode scanner should enable more listings to be completed. We ran the tests for a couple of weeks, and when the results came back it was indeed very satisfying. It perfectly aligned with our original hypothesis. The Draft Completion Rate improved by 30% for the listing flow with a barcode scanner enabled.

A/B test results

We also added profiling to get the distribution on which type of scanner wins the race. The results were as expected, with ZBar contributing to 53% of successful scans, followed by the custom C++ lib with 34%, and finally JavaScript lib with 13%.


The whole **WebAssembly **journey was a great learning experience for us. Engineers get pretty excited about new technologies and immediately want to try them out. If the same technology makes a positive impact on a customer-centric metric, it is a double delight. This alludes to an earlier point in this post. Technology evolves at a very rapid pace. Every day we hear new things getting launched. But only a few make a difference to customers, and **WebAssembly **is one of them. This was our biggest learning from this exercise — “Saying “No” to 99 things and “Yes” to the one thing that really matters to our customers.”

As next steps, we are looking into expanding the barcode scanner to the buying side of the mobile web, which would allow buyers to scan items to search for and purchase. We will also look into augmenting this feature with the Shape Detection API and other in-browser camera capabilities. Meanwhile, we are happy that we found the right use case for WebAssembly at eBay and in bringing the technology to ecommerce.

Web Development Services in USA

Web Development Services in USA

HireFullStackDeveloperIndia goal is to get the app downloaded millions of times, generate revenue and featured on app stores.

HireFullStackDeveloperIndia is a leading Web Application Development Company in USA that mission is simple: To help our clients see what they cannot see themselves. We work alongside elite brands to uncover what we believe to be simple truths: that all roads lead to web app. That they should dream bigger. And most importantly, that they’re underestimating how an amazing mobile experience can revolutionise the way they interact with their customers.

Visit us: What is the best Full Stack Development Company in Nevada, USA?

Web Development Services

Web Development Services

As one of the best Web Application Development Company, it provides a fine quality mobile app development service at an affordable price. Especially, it encourage start-ups that have unique ideas, by offering a more competitive price

HireFullStackDeveloperIndia is rated as one of the top Web Application Development Company in India by various industry magazines and review sites. They have a right blend of award-winning designers, expert programmers and Google certified digital marketers which make them a unique one-stop solution for hundreds of our clients, spread across all countries.

A Good website reflects not only your business but also it is one of the main factors why a potential customer would convert into Client. A good website design helps increase traffic driving leads to grow business. The best web design company create a custom design for each corporate website so as to help them meet their business goals.

Get Quote: https://hirefullstackdeveloperindia.com/get-a-quote/

Top Web Application Developer

Top Web Application Developer

You can also contact a web application development company for your business but then why not to contact the best web application development company that can turn up your business and customer satisfaction ratio to sky touching heights.

Not long-ago internet came into existence and the world has never been the same ever since. The Internet made sure that people and business do evolve at a faster rate than ever and was never merciful to the slow ones. Because of this competition and availability of any business with few clicks made India one of the hubs as IT center. This trend of constantly updating has given rise to smartphones, smart machines, wearable gadgets and a lot more is yet to come in the upcoming years. In such time it is always a good idea to hire Web App Developer from India at your service. They are expert in developing not only websites but web applications as well.

We at HireFullStackDeveloperIndia, have a huge team of experienced developers that have grasped over different domains in front and back end development. You can hire web app developers in India from us with many advantages that you won’t get anywhere else in the industry.

Here is why we are the best option if you are looking forward to hiring web app developers in India:

  • Flexible hiring models available, as per your convenience and requirement
  • Maximum ROI, compared to any other company or team of developers.
  • We provide you with Source code Authorization meaning code written for you belong only to you. It cannot be used or copied anywhere else.
  • All of our developers are sound with agile development methodology, so you will be in a constant loop of suggestions, ideas, trends, and updates about your project.
  • Our developers are good with creating custom web applications as well; it guarantees you a better product without any compromise of non-existing functionalities.
  • You can save huge costing on infrastructure by utilizing our hire web app developer in India program.
  • Your hired developer or team will be easily accessible to your preferred mode of communication.
  • You get to exercise complete control over your team or individual that you hire.
  • We believe in Integrity and Transparency.
  • Our developers are highly creative and motivated to deliver excellence.

HireFullStackDeveloperIndia is a Web Application Development Company in India that is known worldwide for our Innovative guaranteed solutions. You can inquire with us about your project and we will be providing you multiple suitable developers that are the best fit for your requirements. You can evaluate them and select one or multiple whosoever deems fit to you. After this, all you have to do is provide your valuable input to the resource through sprint base project development until you get delivery of your project.

Our engagement model will also allow you to get our development team to your site location and proceed with development from your premises.