3 ms·

I work for a company that enables businesses to drop eCommerce into their websites. When I started, this was done via a script that embedded an iFrame. This was

I work for a company that enables businesses to drop eCommerce into their websites. When I started, this was done via a script that embedded an iFrame. This wasn't great for SEO, and some competitors started popping up with SEO-optimized products. Since our core technology is a React app, I realized that we could just mount the React app directly on any path at the customer's domain. I won't get into the exact implementation, but it worked, and our customers' product pages started being indexed just fine. We even ranked competitively with the upstarts who used server-side rendering. We had a prototype in a few months, and then a few months after that we had the version that scaled to 100s of customers. We then decided to build a new version of our product on Remix (SSR framework similar to nextjs). It required us to basically start over from scratch since most of our technologies weren't compatible with Remix. 2 years later, we still aren't quite done. When all is said and done, I'm really curious to see how this new product SEOs compared to the existing one.

chrisabrams 2y ago
Given that your Remix version has been ~2 years in development by X number of developers, what are the other expected outcomes? It sounds like potential SEO performance is unknown? Is the development team happy with the choice? I can't recall working somewhere that allowed us to work on a project for two years and not release to production, how did you get business buy in?
- dlevine 2y ago
  The other outcomes are a redesign and more configurability plus a bunch of new features. It wasn't really an apples to apples comparison. The non-iFrame version was more of a 1.1, where the new thing we are building is a 2.0. Based on some other projects, I do suspect it would have gone faster if we built it on the old stack. The development team made the choice to go with Remix (well, the tech lead and VP of engineering). No one had used this tech before. We have subsequently talked about whether it would have been better to do the whole thing with Rails + Hotwire. We have been using this approach elsewhere in our stack, and it seems to be a lot conceptually simpler than rendering JS server side and then hydrating it.
- giraffe_lady 2y ago
  You don't need buy-in when they tell you to do it! Not OP but I've definitely seen a "leadership has decided on a rewrite into a new technology" project not ship for a couple years. I doubt it ever shipped, I didn't stay around to find out.
sanex 2y ago
Currently building something similar and following your path. Rendering an iframe and are working on bundling react app into a custom HTML tag and dropping that onto the page. Would be curious to hear more about your experience.
- dlevine 2y ago
  We ended up using a reverse proxy since we wanted each product page to have a separate URL. Basically /shop/* would resolve to our React app, which rendered the correct page based on the URL. You could configure this pretty easily using NGINX or Apache, but our customers were pretty technically unsophisticated so it was too much work for them to do it this way. In the end, we built a Wordpress plugin since it turned out that most of our customers used Wordpress. This plugin acted as the reverse proxy. We went a step beyond this and did some cool stuff to let them use a shortcode to render our eCommerce menu within their existing Wordpress template. One wrinkle with ditching the iFrame was getting our CSS to not conflict with their CSS. I ended up putting our stuff within a shadow DOM, which was a bit of work but ended up working pretty well.
38 2y ago
> nextjs FYI nextjs is notoriously user hostile and one of the worst pieces of client side code I've ever seen, second only to Widevine. Who dumps 2mb of JSON directly into the HTML?
- cjblomqvist 2y ago
  It's been SSR SPA best practice for a decade at least (when keeping your model data client side).
  - 38 2y ago
    SSR is when the server creates HTML, not JSON. nextjs is very obviously client side rendering
  - CharlieDigital 2y ago
    You can do that and still not dump some really bad markup and JSON. Compare Astro.js output HTML+JS to Next.js and there's a striking difference.

chrisabrams 2y ago

Given that your Remix version has been ~2 years in development by X number of developers, what are the other expected outcomes? It sounds like potential SEO performance is unknown? Is the development team happy with the choice? I can't recall working somewhere that allowed us to work on a project for two years and not release to production, how did you get business buy in?

dlevine 2y ago
The other outcomes are a redesign and more configurability plus a bunch of new features. It wasn't really an apples to apples comparison. The non-iFrame version was more of a 1.1, where the new thing we are building is a 2.0. Based on some other projects, I do suspect it would have gone faster if we built it on the old stack. The development team made the choice to go with Remix (well, the tech lead and VP of engineering). No one had used this tech before. We have subsequently talked about whether it would have been better to do the whole thing with Rails + Hotwire. We have been using this approach elsewhere in our stack, and it seems to be a lot conceptually simpler than rendering JS server side and then hydrating it.
giraffe_lady 2y ago
You don't need buy-in when they tell you to do it! Not OP but I've definitely seen a "leadership has decided on a rewrite into a new technology" project not ship for a couple years. I doubt it ever shipped, I didn't stay around to find out.

sanex 2y ago

Currently building something similar and following your path. Rendering an iframe and are working on bundling react app into a custom HTML tag and dropping that onto the page. Would be curious to hear more about your experience.

dlevine 2y ago
We ended up using a reverse proxy since we wanted each product page to have a separate URL. Basically /shop/* would resolve to our React app, which rendered the correct page based on the URL. You could configure this pretty easily using NGINX or Apache, but our customers were pretty technically unsophisticated so it was too much work for them to do it this way. In the end, we built a Wordpress plugin since it turned out that most of our customers used Wordpress. This plugin acted as the reverse proxy. We went a step beyond this and did some cool stuff to let them use a shortcode to render our eCommerce menu within their existing Wordpress template. One wrinkle with ditching the iFrame was getting our CSS to not conflict with their CSS. I ended up putting our stuff within a shadow DOM, which was a bit of work but ended up working pretty well.

38 2y ago

> nextjs FYI nextjs is notoriously user hostile and one of the worst pieces of client side code I've ever seen, second only to Widevine. Who dumps 2mb of JSON directly into the HTML?

cjblomqvist 2y ago
It's been SSR SPA best practice for a decade at least (when keeping your model data client side).
- 38 2y ago
  SSR is when the server creates HTML, not JSON. nextjs is very obviously client side rendering
- CharlieDigital 2y ago
  You can do that and still not dump some really bad markup and JSON. Compare Astro.js output HTML+JS to Next.js and there's a striking difference.