3 ms·

As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up wi

As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components, and you can use tools like Storybook to run visual regression tests without standing up your full environment. I know I'm speaking tactically here, but a shift away from SPAs seems like a loss for shared UI components and design consistency. I can't just give a CSS file (which is portable across tech stacks) and leave it to engineers to write accessible HTML; there's huge value-add in isolating a11y in something like a React component abstraction.

bestinterest 4y ago
My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place. I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team. Thinking more on this, I'd love the https://tailwindcomponents.com https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss
adrianmsmith 4y ago
> I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.
regularfry 4y ago
"Everything is simpler if we all use MY tool." I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.
- 88913527 4y ago
  You end up with a Frankenstein application where different product areas feel like they were built by entirely different companies. There's a real price to giving that much autonomy to each development team. You want teams to be empowered, but there has to be ground rules. Having to unwind the "every team had all the freedoms" and having dozens of databases and hundreds of microservices makes implementing anything cross-cutting (auditing, analytics) a slow-as-molasses multi-quarter initiative.

bestinterest 4y ago

My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place. I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team. Thinking more on this, I'd love the https://tailwindcomponents.com https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss

adrianmsmith 4y ago

> I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.

regularfry 4y ago

"Everything is simpler if we all use MY tool." I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.

88913527 4y ago
You end up with a Frankenstein application where different product areas feel like they were built by entirely different companies. There's a real price to giving that much autonomy to each development team. You want teams to be empowered, but there has to be ground rules. Having to unwind the "every team had all the freedoms" and having dozens of databases and hundreds of microservices makes implementing anything cross-cutting (auditing, analytics) a slow-as-molasses multi-quarter initiative.