<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Bulk Barcode</title>
    <description>The latest articles on DEV Community by Bulk Barcode (@bulkbarcode).</description>
    <link>https://dev.to/bulkbarcode</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3903164%2F0c1985ba-06c5-40bc-8cdb-7d3ea5f996a6.png</url>
      <title>DEV Community: Bulk Barcode</title>
      <link>https://dev.to/bulkbarcode</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/bulkbarcode"/>
    <language>en</language>
    <item>
      <title>How I Built a Client-Side Engine to Process 75,000 Excel Rows in the Browser (Without Crashing)</title>
      <dc:creator>Bulk Barcode</dc:creator>
      <pubDate>Tue, 28 Apr 2026 21:18:24 +0000</pubDate>
      <link>https://dev.to/bulkbarcode/how-i-built-a-client-side-engine-to-process-75000-excel-rows-in-the-browser-without-crashing-1ehl</link>
      <guid>https://dev.to/bulkbarcode/how-i-built-a-client-side-engine-to-process-75000-excel-rows-in-the-browser-without-crashing-1ehl</guid>
      <description>&lt;p&gt;When building B2B SaaS tools, there is a dirty little secret in the industry: most "file processing" utilities are a data privacy nightmare. &lt;/p&gt;

&lt;p&gt;I recently launched &lt;a href="https://bulkbarcode-generator.com/" rel="noopener noreferrer"&gt;Bulk Barcode Generator&lt;/a&gt;, an enterprise tool that allows logistics managers to convert &lt;code&gt;.xlsx&lt;/code&gt; or &lt;code&gt;.csv&lt;/code&gt; shipping manifests into print-ready thermal barcode labels (Code-128, EAN-13, etc.).&lt;/p&gt;

&lt;p&gt;When I analyzed my legacy competitors, I noticed they all did the same thing:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;User uploads a sensitive corporate spreadsheet.&lt;/li&gt;
&lt;li&gt;The file is sent via POST request to a remote server.&lt;/li&gt;
&lt;li&gt;The server runs a PHP/Python script to generate images.&lt;/li&gt;
&lt;li&gt;The server zips the files and sends them back.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;The problem?&lt;/strong&gt; Latency is terrible, server compute costs are high, and most importantly, corporate users &lt;em&gt;hate&lt;/em&gt; uploading proprietary inventory data and customer tracking numbers to third-party servers.&lt;/p&gt;

&lt;p&gt;So, I decided to build the entire engine &lt;strong&gt;100% client-side&lt;/strong&gt;. Here is how I approached it.&lt;/p&gt;

&lt;h3&gt;
  
  
  The Client-Side Architecture
&lt;/h3&gt;

&lt;p&gt;To completely eliminate server uploads, the browser had to do all the heavy lifting. The workflow was broken into three distinct JS phases:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1. Parsing the Excel File (Locally)&lt;/strong&gt;&lt;br&gt;
Instead of relying on backend parsers, I utilized the browser's native File API combined with lightweight client-side parsing libraries (like SheetJS). The user drops their file, and the browser reads the buffer directly from their local RAM. &lt;/p&gt;



&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;
javascript
// A simplified look at local file reading
const handleFileUpload = (event) =&amp;gt; {
    const file = event.target.files[0];
    const reader = new FileReader();

    reader.onload = (e) =&amp;gt; {
        const data = new Uint8Array(e.target.result);
        // Process the workbook locally without server requests
        const workbook = XLSX.read(data, {type: 'array'});
        // Extract SKUs and Quantities...
    };
    reader.readAsArrayBuffer(file);
};
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

</description>
      <category>javascript</category>
      <category>webdev</category>
      <category>architecture</category>
      <category>saas</category>
    </item>
  </channel>
</rss>
