5 ms·

I can kind of see your point, but from my POV, every framework or library (even "none") enables the UI to be partitioned into logical groupings, whether they're

I can kind of see your point, but from my POV, every framework or library (even "none") enables the UI to be partitioned into logical groupings, whether they're called components or not. Some technical stacks might make that more or less difficult, but that's a decision for the engineers. I'm interested in seeing design and dev work closer together, but I think what will help them best is an interface that clearly defines the roles and responsibilities of both groups.

bastawhiz 3y ago
> every framework or library (even "none") enables the UI to be partitioned into logical groupings, whether they're called components or not. Here's the thing: nobody builds a design system for themselves—well, maybe they do, but it really doesn't matter what you choose if that's your prerogative. Design systems are about people. It's about getting your whole company on one page and making a broad set of UIs look good and consistent. Sure, you can build your design system with anything or nothing, but the point is making sure it's well-used, and the framework you use is an absolutely paramount part of that.
- danielvaughn 3y ago
  I may be misunderstanding, let me take a step back. In my usage of the term “framework”, I mean the UI technology used to implement the product UI. So if a design system is “built in React”, it means that any usage of the DS must also be in React. If that definition holds true, then making consistent UI across a company basically requires that the DS be not only framework-agnostic but platform-agnostic as well. My favorite example for this problem is Netflix. You could restore a BlackBerry from 2005 that you found at a pawn shop and it would probably have a Netflix app on it. They might be the most ubiquitous technology on the planet. This means their UX has to be consistent between iOS, Android, TV, Web, PlayStation, Xbox, etc. Even on the web, you have the experience itself, as well as several backend/b2b and internal UIs. At that scale, the question of “react vs vue vs htmx” is waaaay out of scope, no?
  - bastawhiz 3y ago
    > This means their UX has to be consistent between iOS, Android, TV, Web, PlayStation, Xbox, etc. Nobody expects all of these platforms implemented to be a single codebase (though you perhaps could). The intention of a design system is for all of the UIs to be consistent, not all of the underlying code. Zero people expect a button component for the PS5 to work on the Web. And of course they wouldn't! One is clicked and tapped and one is interacted with a controller. Stripe is a great example of this. Their design system, SAIL, runs on every web surface (internal and external) at the company. And ignoring versioning, it's essentially one design system codebase. But that doesn't mean they aren't principled about using React. Their latest major version was originally going to be multi-framework but that plan was scrapped because it meant sacrificing composability. There's exactly one way to build UIs for the web.
    - bobthepanda 3y ago
      I’ve seen design systems that preserve flexibility primarily by restricting to html, css classes and js, so that the only thing that really matters is that the developer’s chosen framework outputs said stuff.
      - danielvaughn 3y ago
        Yeah this is the solution I'm imagining in my head. IMO the true separation between design and dev is that designers are responsible for pixels-on-screen. They manage visual behavior, whereas developers manage functional behavior.
  - rrdharan 3y ago
    > You could restore a BlackBerry from 2005 that you found at a pawn shop and it would probably have a Netflix app on it. No, you could not. There were never any versions of Netflix that ran directly on any BlackBerry OS, unless you count the Android ports that some folks managed to port and get running on BlackBerry 10 devices as the platform was dying around 2014 or so…
    - 3y ago
eternityforest 3y ago
Any one framework lets you do reusable groupings. 29472 different frameworms mean nothing is cross compatible and you have to reimplement. It might not be design layer.... But I'm more than happy to learn a new technology(Within reason) to get more reuse. They're mostly all the same anyway, learning a new framework is easier than creating new code.
- danielvaughn 3y ago
  Oh for sure, but again, it’s an engineering decision and shouldn’t be considered part of the design system.
  - zacharycohn 3y ago
    Engineers are allowed to work with Designers, especially on the boundary between their work.
    - danielvaughn 3y ago
      Agree totally, I think all I'm saying is I don't want a situation where the design team (inadvertently or otherwise) decides the Javascript framework. In an ideal world they wouldn't care.
      - zacharycohn 3y ago
        That's why they'd work in collaboration with the engineers. To enshrine engineering specific things - names of reusable complements, etc - into the design system. The designers aren't deciding on those, but they can still be included to make the most effective and useful design system possible.

bastawhiz 3y ago

> every framework or library (even "none") enables the UI to be partitioned into logical groupings, whether they're called components or not. Here's the thing: nobody builds a design system for themselves—well, maybe they do, but it really doesn't matter what you choose if that's your prerogative. Design systems are about people. It's about getting your whole company on one page and making a broad set of UIs look good and consistent. Sure, you can build your design system with anything or nothing, but the point is making sure it's well-used, and the framework you use is an absolutely paramount part of that.

danielvaughn 3y ago
I may be misunderstanding, let me take a step back. In my usage of the term “framework”, I mean the UI technology used to implement the product UI. So if a design system is “built in React”, it means that any usage of the DS must also be in React. If that definition holds true, then making consistent UI across a company basically requires that the DS be not only framework-agnostic but platform-agnostic as well. My favorite example for this problem is Netflix. You could restore a BlackBerry from 2005 that you found at a pawn shop and it would probably have a Netflix app on it. They might be the most ubiquitous technology on the planet. This means their UX has to be consistent between iOS, Android, TV, Web, PlayStation, Xbox, etc. Even on the web, you have the experience itself, as well as several backend/b2b and internal UIs. At that scale, the question of “react vs vue vs htmx” is waaaay out of scope, no?
- bastawhiz 3y ago
  > This means their UX has to be consistent between iOS, Android, TV, Web, PlayStation, Xbox, etc. Nobody expects all of these platforms implemented to be a single codebase (though you perhaps could). The intention of a design system is for all of the UIs to be consistent, not all of the underlying code. Zero people expect a button component for the PS5 to work on the Web. And of course they wouldn't! One is clicked and tapped and one is interacted with a controller. Stripe is a great example of this. Their design system, SAIL, runs on every web surface (internal and external) at the company. And ignoring versioning, it's essentially one design system codebase. But that doesn't mean they aren't principled about using React. Their latest major version was originally going to be multi-framework but that plan was scrapped because it meant sacrificing composability. There's exactly one way to build UIs for the web.
  - bobthepanda 3y ago
    I’ve seen design systems that preserve flexibility primarily by restricting to html, css classes and js, so that the only thing that really matters is that the developer’s chosen framework outputs said stuff.
    - danielvaughn 3y ago
      Yeah this is the solution I'm imagining in my head. IMO the true separation between design and dev is that designers are responsible for pixels-on-screen. They manage visual behavior, whereas developers manage functional behavior.
- rrdharan 3y ago
  > You could restore a BlackBerry from 2005 that you found at a pawn shop and it would probably have a Netflix app on it. No, you could not. There were never any versions of Netflix that ran directly on any BlackBerry OS, unless you count the Android ports that some folks managed to port and get running on BlackBerry 10 devices as the platform was dying around 2014 or so…
  - 3y ago

eternityforest 3y ago

Any one framework lets you do reusable groupings. 29472 different frameworms mean nothing is cross compatible and you have to reimplement. It might not be design layer.... But I'm more than happy to learn a new technology(Within reason) to get more reuse. They're mostly all the same anyway, learning a new framework is easier than creating new code.

danielvaughn 3y ago
Oh for sure, but again, it’s an engineering decision and shouldn’t be considered part of the design system.
- zacharycohn 3y ago
  Engineers are allowed to work with Designers, especially on the boundary between their work.
  - danielvaughn 3y ago
    Agree totally, I think all I'm saying is I don't want a situation where the design team (inadvertently or otherwise) decides the Javascript framework. In an ideal world they wouldn't care.
    - zacharycohn 3y ago
      That's why they'd work in collaboration with the engineers. To enshrine engineering specific things - names of reusable complements, etc - into the design system. The designers aren't deciding on those, but they can still be included to make the most effective and useful design system possible.