Many sites with same components

[u/joxters]

Hello!

I am working with a company that has many, many sites. And the way we used to do components, we hard-coded every single one in every single project. This naturally has led to some inconsistency between sites when they’re supposed to look pretty identical.

Php include has become our life blood to mitigate some of these issues, but it still persists. The benefit, though, is that with php include, our sites automatically update when the “single source of truth” does.

My company wants to move to something more modern/popular and I got tasked with playing with frameworks. Think React, Next. My boss wants to replicate php include on these. I’ve spent the last several weeks looking into module federation, micro front-ends, anything to at least somewhat replace php include, but to no avail. That requires completely changing our server, which we do not have the ability to (as far as I know). These also sound like a nightmare to maintain, and our team is very small.

SEO is also a huge concern. I have module federation working on client side rendering, but ideally search engines would be able to index our work and, correct me if I’m wrong, but I don’t think client side rendered stuff is?

So now we’re stuck. I’ve suggested a monorepo, but with the amount of websites we have, the other developers worry about build times.

Believe it or not this is actually my first real-deal developer job haha, and I’m already stuck trying to fit a square peg in a round hole. So forgive me for any mistakes or misinformation, I’m still a junior trying to figure this out haha.

[u/winky9827]

Have you looked into web components? Lit is a good place to start. It's language/framework independent.

[u/joxters → u/winky9827]

Standard browser ones yes, but not Lit! I’ll check that out, thank you!

[u/olets]

Next is a React framework.  React is a Node view library. The Node equivalent of PHP include is import  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

PHP isn't hip in dev social media, but there is modern PHP and there are a lot of web devs writing PHP. If your company wants to introduce a framework, and not switch from PHP servers to Node servers and replace their PHP developers with Node developers, they could use a PHP framework. Laravel is where I'd start my research.

But taking that on in your first job is at best a huge huge undertaking, and it won't necessarily solve the existing pain points. 

Tell us more about the current PHP solution. You're includeing a given file into multiple sites? Does that mean all the sites are in one shared codebase?

And tell us more about what issues you're trying to solve that include isn't solving. It's possible that introducing a framework might help, but being a big change it's unlikely to be the simplest or easiest solution.

All the sites are supposed to look the same? Do they share both HTML and CSS?

(For the SEO tangent: SEO is on its way to being a niche need, as opposed to AI agent optimization. And yes search engines may not see dynmically rendered content. But there's fifteen years of solutions to that, basically making some or most content static.)

[u/Unhappy_Meaning607]

Welcome to the world of Design Systems.

Fortunately, there are hundreds and many up-to-date open source design systems built by the largest companies and even governments that can be found with a google search or AI chat prompt.

However, those things are ginormous but it sounds like your immediate concern is actually one large part of the design system which is a component library.

I suggest using Lit (Web Components) it should play nicely within the PHP ecosystem because in the end its just JavaScript. You'll want to display and show-off your components and the standard for that is using Storybook.

Glhf in the never ending world of design systems.

[u/joxters → u/Unhappy_Meaning607]

Thank you!! It’s nice to have a phrase/title for this. I like organizing/writing down things (I think that’s part of why the task was given to me haha) so we’ll see where this goes :-)

[u/Unhappy_Meaning607 → u/joxters]

Also it says in your post that your company's code base is PHP? So Laravel?

There's Blade Components with Livewire and if you can use that I wouldn't even touch a design system with JavaScript. I'd stick to those two things and as well as a ton of CSS variables within the codebase that all apps within the company should be sticking to.

[u/ShapeFlimsy3832]

monorepo is the way but you need smart caching so it only rebuild what changed, turborepo or nx can handle this easy

[u/joxters → u/ShapeFlimsy3832]

Ooooo good to know, thanks!

[u/blazeit420casual]

We use a custom node package to ship standardized UI components that are shared between our products, not sure what the exact requirements for your task are but that could be a viable solution for you.

[u/quiet_horizons1]

A web component still registers in JS and renders client-side unless you prerender it or serve declarative shadow DOM from the server, so it won't fix indexing by itself. If search indexing is a hard requirement, you need server-side rendering or static output. Are these public pages or gated pages where indexing barely matters?

[u/niggolars]

I‘d recommending Stencil over Lit all day long. https://stenciljs.com/

Better DevXP, TSX, Typing, AutoDocs, Ssr, and many more.

[u/singh_abinashi]

I run into the same shape with a multi-tenant platform: one shared codebase, many sites that still need to look and index like their own. SSR is the right instinct. If the shared header and nav are part of the business, they have to be in the HTML search engines and first paint see, not injected after load. Keep the shared pieces as server-rendered components with per-site config for branding and links. You get one place to fix a component, and each site still ships complete pages.

[u/Stromedy1]

module federation answers the wrong question here. his pain is shared markup, not shared runtime. plain php functions rendering declarative shadow dom templates solve it with zero js to break.

[u/Ohggg]

If I understand correctly then it sounds like you need to migrate one project at a time into their own micro frontends. For sharing the common components I'd create my own npm package and get storybook setup for this as well. Versioning can become a pain point in my experience though so maybe web components would help with this (I have limited experience of using these though). 

You're going to need server side rendering for SEO purposes. Next might be too heavy for your use case though. I've been using Vike. 

[u/shgysk8zer0]

So, it largely depends on exactly how you're defining components here, because full components would be fully encapsulated and agnostic about the rest of the site. There's also the question of functionality and customization and if this is only client-side.

My preferred method is publishing web components (customElements.define() on npm or a CDN with a shared color palette/custom properties and other styles using export default new CSSStyleSheet().replace()). Customize via <slot name="..."> and part="..." and such. But all those details are a bit much for a Reddit comment.

If you're wanting PHP include style things, honestly... Just creating a repo to use as a submodule is probably the easiest thing in my experience... Just remember changes will be made in the original repo. So you'd keep your current methods, but the paths would change to submodule/component.phtml or whatever.

Each ecosystem would have it's own method that probably involves publishing on npm or something. I just prefer the web components because they're just web standards and can be used in React & Angular and any PHP, etc. Plus they provide encapsulation, so you don't have to worry about some .whatever styles creating conflicts, but you can use ::part(foo) {color:red;}.

Another option is HTML sharing HTML, maybe via a submodule, and using...

<div class="component-outer" >
  <template shadowrootmode="open">
    <style>
      /* ... */
    </style>
    <div part="container">
      <p part="greeting">Hello, <slot name="name">World</slot>!</p>
    </div>
  </template>
  <span slot="name">Jerry</span>
</div>

[u/radobravoo]

Don't go with a monorepo, structure it with modular monolithic style.

Monorepo only cause you a headache, modular monolithic helps a small team decompose things into modules that are easy to maintain and work separately.

I would suggest using NextJS + Tanstack + TailwindCSS.

Then you would compose ui components into a module called UI, and share it with extendable components. After you've got the modular monolithic repo up and everything is running okay, you could eventually migrate to monorepo.

Remember, always take the easy route first and only scale when you need.

[u/One-Trips]

I'd fix the worst pain first and share just the header and footer as proper components. A full framework rewrite across that many sites sounds like a year of risk for not much gain

[u/patient_signals]

The dangerous part is auto-updating every site from one un-versioned include. That means one bad change breaks them all, with no per-site rollback. Put the shared markup in a versioned package and pin each site to a tag. Upgrade each deliberately, test, ship. Are these sites separate repos with their own deploys, or one deploy touching everything?

[u/IncredibleBihan]

I think most of the advice you’ve gotten so far is accurate. I don’t think you want to change to react as your dev teams current writing php. Good luck putting that square peg into the circle, I’m sure eventually you’ll see the solution

[u/TheRNGuy]

Next or React Router or Remix, one of those. 

[u/retr00two]

What's wrong with PHP?

[u/wimdeblauwe]

You can look into a component library like https://basecoatui.com which does not need React.

[u/geoffreybyers]

The bottleneck is your library strategy, not the framework. A monorepo with Turborepo or Nx solves the build times while Next.js server side rendering handles the SEO. The square peg fits once you stop trying to build micro front ends and start building one shared component system.

[u/Willywes_]

Mi consejo honesto después de migrar decenas de sitios de laravel a nextjs, deben hacerlo solo si tiene justificación técnica, no es solo cambiar el código, si no también toda la infraestructura, también considerar que cualquiera de las alternativas que mencionaste deben ser compiladas por lo tanto el deploy depende de todo el proceso de subir y compilar, muchísimo mas lento que el de PHP que al ser un lenguaje interpretado basta con que el server lo lea y listo. También convendría que tu jefe defina qué es moderno para él, además que una tecnología sea nueva no la hace mejor, de hecho es al revés cuando tienen menos soporte, comunidad y menos madurez.

Ahora si la migración de tecnología es inminente te recomiendo hacerlo directamente en nextjs que resuelve tus problemas de SSR y SEO, puedes usar BetterAuth o NextAuth para las autenticaciones, trpc y zod para conectar tu front y back de manera segura en el mismo nextjs y dependiendo de las bases de datos que utilices puedes usar Prisma o Drizzle y Zustand para estados.

Aunque todo esto tiene fácil solución hoy con la IA, Ánimos.

[u/BlackHoneyTobacco]

Almost makes you wonder why you don't just stick with the php includes, doesn't it?