Helping maintain the frontend of a clothing e-commerce platform in USA

1. Rails SSR and client-specific packs

I worked on a multi-page Rails storefront. HTML comes from the server. JS and CSS arrive as Webpack packs. Which pack you get depends on the page (default, product, account, checkout) and on the client (US store, CA store, or the mobile app).

Product pages are expensive to render, and deploys change asset filenames. Cached HTML cannot keep old pack URLs.

A single bundle for every client would ship a lot of unused code. Product detail pages use full-page HTML caching because they are expensive to render. The cached HTML keeps a placeholder for pack tags. When the page is served, those tags are filled from the current manifest, on a cache hit and on a miss, so the browser always gets the right files after a deploy.

The head loads page CSS first, then polyfills, deferred vendors, Vue vendors when the page needs them, analytics, the page pack, and a separate Tailwind pack. Checkout still loads webpack packs next to a leftover Angular runtime.

If I changed UI on a product page, I also had to think about the cache key and how pack tags get attached on the way out.

2. Critical CSS vs deferred packs

The storefront has a lot of Sass and Tailwind. If every feature stylesheet loaded with the first paint, listing and product pages would download CSS they do not need yet. A lot of the frontend work was deciding what belonged in the main pack and what could wait.

Feature CSS should not block first paint on a live catalog.

There is no critical-CSS extractor in the build. The main application or PDP pack CSS stays blocking. Secondary packs such as footer, payment logos, deliver-to, and cookie consent load as print media and switch to all once they arrive. On cached PDPs, deliver-to CSS uses a preload-as-style path instead. A few masthead styles have to look right immediately, so those SCSS files are imported into the main pack on purpose.

On a given ticket I would ask whether a style belonged in the main pack or could ship later with its feature. Layout shift and first paint already mattered on those pages.

3. WebView client, shared commerce

The iOS and Android apps embed the same Rails storefront in a WebView. I worked on the frontend in both places: mobile packs, app chrome, and a bridge back to native features.

A storefront change also has to work inside the app WebView.

The server sees the app from headers, stores a device cookie, and switches to mobile packs and a mobile-app layout class. Version gates turn native features on or off, including Apple Pay, filters, and PayPal. The page talks to the app with React Native WebView postMessage for experiments, cart quantity, payments, filters, and when the page is ready.

Pack choice, cache variation, and bridge events were part of shipping UI that still worked in the app.

4. Vue islands over Rails HTML

Cart and some product-detail flows are islands. Rails still renders the shell and the props. A deferred pack mounts Vue on a DOM node. I worked in that pattern. The catalog stayed on Rails HTML.

Cart and DTF need a real client app. The catalog still needs server HTML.

An ERB template defines the mount node. Props come through JSON attributes, window config, or slotted server HTML. Shared Vue vendors load when needed, then the island pack calls createApp and mount. Catalog pages stay server-rendered. Vue only mounts on the flows that need it.

Classic checkout can still load Angular next to webpack packs. Shipping there meant living with a mixed runtime.