A React implementation of Spectrum, Adobe’s design system(react-spectrum.adobe.com)
react-spectrum.adobe.com
A React implementation of Spectrum, Adobe’s design system
https://react-spectrum.adobe.com/react-spectrum/
73 comments
Having spent the past couple years working on a large design system, I am most excited about @react-aria and @react-stately. There is huge potential for allowing resource constrained teams to build out a truly customized DS in a fraction of the time. Even for a well resourced team, these hooks can make extending their existing DS and borrowing complex behavior much simpler/faster. The biggest challenge for a DS at scale is in how you can adapt it to the infinite edge cases that a product eventually uncovers- while staying consistent and leveraging existing code. I think these libraries offer the best model yet for achieving this. Congrats to @devongovett and the team at Adobe for realizing these ambitious projects and successfully open-sourcing them.
One of the things that I always find missing in these libraries/collections is a date/time picker. I know these are available via many separate projects, but it's nice if one picks a collection like that, that all inputs are homogeneous.
ant-design is the most complete component collection I've come across. I'm in the process of swapping out element-ui for ant-design-vue in a serious project.
Very mature and very active, while being tree-shaking friendly and lets you select just the components/css you need. Used on Baidu and other major sites.
https://ant.design/components/date-picker/
Very mature and very active, while being tree-shaking friendly and lets you select just the components/css you need. Used on Baidu and other major sites.
https://ant.design/components/date-picker/
Our date picker is in progress right now actually. Should be available relatively soon. Date pickers are one of the most complicated components, especially due to internationalization/accessibility requirements.
Who is "our"?
I appreciate their complexity and applaud your efforts. Good stuff.
Can confirm. Date pickers and tables with pagination and sort/pagination functionality are hard.
Had to input my birthday recently and the web-form only allowed input via the date picker which started with the current date. The year had small minus and plus buttons next to it. This did not only make me feel old while I was clicking through the years, but it also cost me valuable time.
About tables, most developers forget that a paginated table needs to do search sorting on the data provider side. Sorting and searching through the visible 20 entries isn't helpful at all IMO.
Had to input my birthday recently and the web-form only allowed input via the date picker which started with the current date. The year had small minus and plus buttons next to it. This did not only make me feel old while I was clicking through the years, but it also cost me valuable time.
About tables, most developers forget that a paginated table needs to do search sorting on the data provider side. Sorting and searching through the visible 20 entries isn't helpful at all IMO.
Will it have moment.js as dependency like react-dates?
Do you also plan to make a DateRangePicker and a TimePicker?
Do you also plan to make a DateRangePicker and a TimePicker?
No, moment is not a dependency. We're using the native Intl.DateTimeFormat APIs that are built into browsers now. This makes sure we support internationalization properly, but without the giant locale data needing to be downloaded.
And yes, we have a DateRangePicker and TimePicker as well.
And yes, we have a DateRangePicker and TimePicker as well.
That's only an "issue" of all that "modern" stuff.
Many, many years ago I've used Dojo[1] and it's component lib Dijit. It had all that complex widgets in the toolbox. With all the "advantage" stuff like ARIA and internalization.
Or you could use Ext, if you could pay it.
But than all this "modern 'component' stuff" came form nowhere and you've been back to stone age, where you didn't have even the most basic components (like dialogs or menus) OOTB for many years to come.
[1] https://dojotoolkit.org/
PS: Did I actually mention that Dojo managed to deliver updates for over 10 years without breaking the API? ;-)
PPS: They invented AMD by the way (the by far most sane JS module system).
PPPS: Require.js was more or less an (extended) rewrite of the ansync Dojo loader. (I think even the same people involved).
And this stuff exited at a time people where just discovering jQuery, even before the jQ "hype".
Many, many years ago I've used Dojo[1] and it's component lib Dijit. It had all that complex widgets in the toolbox. With all the "advantage" stuff like ARIA and internalization.
Or you could use Ext, if you could pay it.
But than all this "modern 'component' stuff" came form nowhere and you've been back to stone age, where you didn't have even the most basic components (like dialogs or menus) OOTB for many years to come.
[1] https://dojotoolkit.org/
PS: Did I actually mention that Dojo managed to deliver updates for over 10 years without breaking the API? ;-)
PPS: They invented AMD by the way (the by far most sane JS module system).
PPPS: Require.js was more or less an (extended) rewrite of the ansync Dojo loader. (I think even the same people involved).
And this stuff exited at a time people where just discovering jQuery, even before the jQ "hype".
It's funny to see facts down-voted by an usually well informed and rational public. :-D
Still, facts are facts, no matter how sloppy the wording I've chose.
I didn't mean to diminish the effort put into that one incarnation of those so called design systems. I've only mentioned that it's (like all others of the "modern" ones I've seen until now) light years behind what you could have got 10+ years ago.
If I would like to really offend some people here I would have said that actually Visual Basic 6 was far more advanced than today's "web component libraries" when it comes to building GUIs. Most likely this could be even proved: One would only need to build (from scratch) a typical GUI for some business app with web-tech and VB6 against a timer. I know on which tech I would bet delivering results faster. ;-) Not that I'm saying a VB6 app would be a proper replacement for a web app, that's not the point. But the productivity of web tech for application development is just somewhere on the level of 20 years ago. But the down-voters are likely just to young to know that. So the down-votes are likely fine. :-)
Still, facts are facts, no matter how sloppy the wording I've chose.
I didn't mean to diminish the effort put into that one incarnation of those so called design systems. I've only mentioned that it's (like all others of the "modern" ones I've seen until now) light years behind what you could have got 10+ years ago.
If I would like to really offend some people here I would have said that actually Visual Basic 6 was far more advanced than today's "web component libraries" when it comes to building GUIs. Most likely this could be even proved: One would only need to build (from scratch) a typical GUI for some business app with web-tech and VB6 against a timer. I know on which tech I would bet delivering results faster. ;-) Not that I'm saying a VB6 app would be a proper replacement for a web app, that's not the point. But the productivity of web tech for application development is just somewhere on the level of 20 years ago. But the down-voters are likely just to young to know that. So the down-votes are likely fine. :-)
At least for me I find it very hard to believe your rosy story about Dojo. Are you telling me that 15 years ago you were using a framework that had out-of-the-box support for internationalization that is comparable to what we have today?
Actually he's right. I did work with Dojo many years ago. It was very complete, but I found it clunky and slow for my use case. I rewrote the entire app in ExtJS. At the time, this was the most polished toolkit around. If your project was not open source you had to pay for it, but it was worth it. It had every single thing you can think of and it was all working very well, i18n included. However, it was an all-in proposition, and felt like coding a Java Swing application in some way.
Having said that, I don't miss it and I very much like the way things are now.
Having said that, I don't miss it and I very much like the way things are now.
Nobody needs to believe me. I've left a link. Anybody really interested is free to see for them self. The stuff is still out there. (Actually I've looked lately into their forum to see how this ancient stuff is doing after I've left it years ago, and you can read there for example form people that have a very hard time to find reasons to rewrite all their "legacy Dojo apps" as that stuff is still working more then fine for mission critical projects so management won't give any budget).
One of the reasons we chose Dojo back than was for example its first class internalization support. And yes, you have for example all widgets with right-to-left variant support OOTB… Or you had some DateTime class that had more or less all the features of Moment.js (years before Moment.js came into existence)… Ah, you had actually a "class" ("dojo declare" if I remember correctly)! :-) It had multiple inheritance (mixins) as this is quite useful for widgets and their common traits. It had observable data stores & pub / sub messaging. It fully supported screen readers OOTB (accessibility is quite important for example if you develop for state authorities; one more of the reasons we chose it back than).
As the "modern" stuff "started" (at the time Angular.js got quite popular) my first impression of that "modern" frameworks was that I'm literally back to stone age. At least it felt like that. You needed for "everything" some third party lib, nothing was integrated, features were missing everywhere.
Additionally working with something like Bower and Grunt was a big step backwards compared to the integrated build system of Dojo. It bundled, and even Closure compiled, all of your modules / widgets, building optimized "layers", with moderate configuration. It had the features you got back years later with Webpack. Actually I'm not sure Webpack isn't also an extended standalone version of Dojos build system as I was wondering when working for the first time with Webpack that the configuration file looks so familiar… (Like Require.js is for sure derived form Dojo's AMD loader).
And the main point is: Even Dojo was ahead of its time in JS land, it was "just" a shallow JS port of the style of application frameworks you had for desktop dev. Ever worked with Delphi, or so? Even though people made jokes about the term "RAD" back than this was indeed "rapid application development" compared to all that low level pixel-shoving you do today. The "components" you worked with back than where one level above something like React-Admin (which is for Web land already bombastic!).
The main point is, and I guess this is clear to most: The web wasn't build as an application platform. As such a platform it just sucks. That's a fact, imho. And I think everybody who did desktop development back than would agree.
I don't say the web is a bad thing as such. Also I fully understand the reasons why it's misused as an application platform (it has just some very convincing advantages). But that doesn't change imho anything about the fact that "the web" sucks as application development platform. It's obviously the wrong tool… (Even without any alternative at the moment). This issue won't go away with the next rehash of some lib / framework that "makes using the wrong tool a little bit more convenient". We need a new tool. One that it designed form the ground up to be again a proper application development framework. I want to see true productivity improvements compared to the time of "RAD"; not steps back on any axis, be it effort to develop something high level, be it performance, be it resource usage. Where is the Delphi / VB6 of the new century? Smart people here around. Someone will come up with something sooner or later, I'm quite sure! :-D
One of the reasons we chose Dojo back than was for example its first class internalization support. And yes, you have for example all widgets with right-to-left variant support OOTB… Or you had some DateTime class that had more or less all the features of Moment.js (years before Moment.js came into existence)… Ah, you had actually a "class" ("dojo declare" if I remember correctly)! :-) It had multiple inheritance (mixins) as this is quite useful for widgets and their common traits. It had observable data stores & pub / sub messaging. It fully supported screen readers OOTB (accessibility is quite important for example if you develop for state authorities; one more of the reasons we chose it back than).
As the "modern" stuff "started" (at the time Angular.js got quite popular) my first impression of that "modern" frameworks was that I'm literally back to stone age. At least it felt like that. You needed for "everything" some third party lib, nothing was integrated, features were missing everywhere.
Additionally working with something like Bower and Grunt was a big step backwards compared to the integrated build system of Dojo. It bundled, and even Closure compiled, all of your modules / widgets, building optimized "layers", with moderate configuration. It had the features you got back years later with Webpack. Actually I'm not sure Webpack isn't also an extended standalone version of Dojos build system as I was wondering when working for the first time with Webpack that the configuration file looks so familiar… (Like Require.js is for sure derived form Dojo's AMD loader).
And the main point is: Even Dojo was ahead of its time in JS land, it was "just" a shallow JS port of the style of application frameworks you had for desktop dev. Ever worked with Delphi, or so? Even though people made jokes about the term "RAD" back than this was indeed "rapid application development" compared to all that low level pixel-shoving you do today. The "components" you worked with back than where one level above something like React-Admin (which is for Web land already bombastic!).
The main point is, and I guess this is clear to most: The web wasn't build as an application platform. As such a platform it just sucks. That's a fact, imho. And I think everybody who did desktop development back than would agree.
I don't say the web is a bad thing as such. Also I fully understand the reasons why it's misused as an application platform (it has just some very convincing advantages). But that doesn't change imho anything about the fact that "the web" sucks as application development platform. It's obviously the wrong tool… (Even without any alternative at the moment). This issue won't go away with the next rehash of some lib / framework that "makes using the wrong tool a little bit more convenient". We need a new tool. One that it designed form the ground up to be again a proper application development framework. I want to see true productivity improvements compared to the time of "RAD"; not steps back on any axis, be it effort to develop something high level, be it performance, be it resource usage. Where is the Delphi / VB6 of the new century? Smart people here around. Someone will come up with something sooner or later, I'm quite sure! :-D
Down votes are fun. A good sign of being right and others being wrong. :)
> But the productivity of web tech for application development is just somewhere on the level of 20 years ago
To be fair, the web was never meant to be an application development platform. It has only become that because of the ubiquity of the web, and the many advantages that web applications confer (multi-platform, instant updates etc.)
Given that, it's not surprising that the web application space continues to evolve as new solutions are tried, iterated and adopted widely, or abandoned.
To be fair, the web was never meant to be an application development platform. It has only become that because of the ubiquity of the web, and the many advantages that web applications confer (multi-platform, instant updates etc.)
Given that, it's not surprising that the web application space continues to evolve as new solutions are tried, iterated and adopted widely, or abandoned.
> the web was never meant to be an application development platform
That! Exactly that!
That's the point. But for some strange reasons people get offended if you tell them this. Maybe because you telling them they're using the wrong tool? Even if it's obvious? ;-)
That! Exactly that!
That's the point. But for some strange reasons people get offended if you tell them this. Maybe because you telling them they're using the wrong tool? Even if it's obvious? ;-)
Indeed the web was not initially meant to be an application development platform.
But it has been meant to be one now for 10+ years, basically since chrome arrived, along with ideas like chrome OS and others...
And as a matter of fact it is now the most ubiquitous application development platform.
But it has been meant to be one now for 10+ years, basically since chrome arrived, along with ideas like chrome OS and others...
And as a matter of fact it is now the most ubiquitous application development platform.
That’s how I feel about all of this Javascript stuff after coming from Rails. You mean I have to do [insert basically anything] all on my own, from scratch? But Rails gave me all of that out of the box!
It's not just Rails, it's basically any semi-modern development toolkit. JavaScript's minimal standard library is one of its biggest flaws and one of the richest sources of exploitation, as exemplified by the left-pad fiasco.
It's not even about the standard lib as much as the culture. Ignoring the fact that it would take years for the changes to become widespread enough to be usable, "pull in 400MB of dependencies for everything, including dependencies of dependencies" is practically a cultural value in the JS scene. It demonstrates why JS is voluntarily practiced primarily by the inexperienced all these years after it established itself as the universal platform.
It's not even about the standard lib as much as the culture. Ignoring the fact that it would take years for the changes to become widespread enough to be usable, "pull in 400MB of dependencies for everything, including dependencies of dependencies" is practically a cultural value in the JS scene. It demonstrates why JS is voluntarily practiced primarily by the inexperienced all these years after it established itself as the universal platform.
Which is why I am glad that in what concerns Web projects, I keep getting those where SSR does most of the work, with selected pieces of JS for the frontend.
Finding a datepicker is the worst part of any project for me and if a design library doesn’t include one I’m going to find another library. I’ve actually had app ideas that I’ve thrown away because they relied too heavily on datepickers and working with them is one of the worst experiences.
hey everyone. I work on React Spectrum. Happy to answer any questions. :)
I'd also point to our introductory post where we discuss the architecture. I think the most interesting thing is that you can reuse most of the behavior, accessibility, etc. without our design in your own component library using our hooks. https://react-spectrum.adobe.com/blog/introducing-react-spec...
I'd also point to our introductory post where we discuss the architecture. I think the most interesting thing is that you can reuse most of the behavior, accessibility, etc. without our design in your own component library using our hooks. https://react-spectrum.adobe.com/blog/introducing-react-spec...
Overall this looks nicely architected. However I don't see any data-intensive controls. Adobe being a graphics company may not need such controls, and this will probably be the weak point of this lib. If you want to see what data intensive controls take a look at Azure Portal. Hope to see such controls in a future version of this lib.
Adobe actually has a pretty big marketing business as well, along with applications like file managers (think web based versions of Finder or Windows Explorer). Tables are one of our most complex components, and are quite commonly used in some of our products. Our table implementation is a work in progress right now. It supports keyboard navigation, sections, sticky columns, multiple selection, infinite loading, drag and drop, etc. Should be available in a month or so. We'll also support other collections like trees/grids/column views in the future, and possibly some charting stuff as well. Lots still left to build! :)
That's good to hear! Here's another very important control: ComboBox. Data-intensive applications need powerful and flexible ComboBox with options such as dynamically supplying suggestions, ability to select multiple items (i.e., multi-select Combo which has checkboxes next to each option displayed in the dropdown), ability to search for an option in the dropdown (so the dropdown has a searchbox at the top) and so on.
Yep! ComboBox is also in progress/close. ;) https://github.com/adobe/react-spectrum/pull/421
Nice work, thanks for sharing.
Hello - I may be blind but I don't see any examples of what the components look like on actual screen. Is there a storybook or something?
Each component page has live examples. e.g. here's Button https://react-spectrum.adobe.com/react-spectrum/Button.html
Great work, looks really good and useful! Will try it out tomorrow. Thank you for contributing to open source.
Can you give a few sentences of why someone would want to use this?
I think it's more likely that people will want to use the React Aria and React Stately libraries that underpin this than React Spectrum itself, unless you're wanting to match the Adobe look and feel for some reason (e.g. plugin developers). React Aria and React Stately provide Hooks that give you a lot of the behavior, accessibility, internationalization, etc. features out of the box, but let you completely customize the styling and rendering in your own components. Here's an example I made of using the hooks with Tailwind CSS to build completely custom components with full accessibility in a very small amount of code: https://codesandbox.io/s/tailwind-react-aria-3ngmw.
Nice work. Questions: 1) What is the minified size of the library 2) Is there a kitchen sink app to review all features together?
1. Depends on how many components you use! Each component is a separate package, so you pay for only what you use. We also offer a monopackage containing all components, but it is fully tree shakeable so it should be equivalent to using the individual packages if you have a good build setup.
2. We're working on building some example apps, but for now, the docs are the best example. You can also try out the storybook that we use for development if you clone the repo locally.
2. We're working on building some example apps, but for now, the docs are the best example. You can also try out the storybook that we use for development if you clone the repo locally.
There's also a cross-framework web components implementation for the Angular, Vue, Svelte, Ember users out there: https://opensource.adobe.com/spectrum-web-components/
Regardless of the react aspect, Adobe could use some lessons on usability fundamentals. This design system's use of pervasive fade animations and low contrast are rather upsetting.
+1 on these shortcomings, though I think it's also worth celebrating what they do right. Namely, I'm glad the system has the concept of "desktop" and "mobile" scales, and doesn't use the same size components for every platform. They also differentiate between touch and cursor hit areas, which is neat [1].
https://spectrum.adobe.com/page/platform-scale/
https://spectrum.adobe.com/page/platform-scale/
Is it me / my environment or is the low contrast nature of that design just really hard to look at / read?
Not sure if its because I've been using React for the last 6 years and I've "fallen out of love" or it is actually starting to show its age but...
React, which was once the greatest thing to happen to UI frameworks, now looks like a very leaky abstraction.
The prevalence of `useMemo` and `useCallback` to get around perf issues, `useEffect` to try to interact with event systems outside of React, and `useRef` to save things that don't quite work when persisted in the component's state.
I'm watching Svelte with interest these days. It seems like we're ~1 year away from Svelte, or a framework very much like it (one that moves concerns into the compiler), taking off and revolutionizing things the way React did 7 years ago.
React, which was once the greatest thing to happen to UI frameworks, now looks like a very leaky abstraction.
The prevalence of `useMemo` and `useCallback` to get around perf issues, `useEffect` to try to interact with event systems outside of React, and `useRef` to save things that don't quite work when persisted in the component's state.
I'm watching Svelte with interest these days. It seems like we're ~1 year away from Svelte, or a framework very much like it (one that moves concerns into the compiler), taking off and revolutionizing things the way React did 7 years ago.
I disagree. So far NO other UI library/framework than react offered the “interface as a function of state” paradigm. All others (Svelte, Vue partially) are based on templates with their ad-hoc syntax for ifs and maps/loops and so on. This is a non starter for me. I will consider other things than react, as long as they use this concept of interface as a function of state. This is non negociable for me at this point.
Can you clarify what you mean by "interface as a function of state"? All the templated-frameworks still fit this definition... they are reactive to the state of your component. In fact, they are more performant than React because their template syntax provides static analysis, so the app can be optimised at compile time.
also, it is pretty amazing what you can do without a framework and how simple your code can be if you code in an "interface as a function of state" style.
example: https://github.com/tantaman/fk-your-frameworks-todomvc
example: https://github.com/tantaman/fk-your-frameworks-todomvc
Svelte is technically "interface as a function of state"
But I do agree, custom template syntax is a non-starter.
But I do agree, custom template syntax is a non-starter.
Choo-Choo!
https://choo.io
https://choo.io
Interesting, hadn't looked into Svelte. I do agree that something _like_ it can be useful in the future. I currently have my own framework that does this at compile time for non-UI code for performance reasons. Previously, Weblocks did something similar for Lisp IIRC.
We should standarize these "UI themes" so that other frameworks don't get left out (e.g. easy for Angular/Vue to use this). In Java world, it's called SPI (Service Provide Interface), like API but the opposite.
It's called Web Components, a standard built into browsers for many years now which means it will be backwards-compatible in perpetuity.
Web Components only really covers half the picture here. Libraries like this provide integration with their chosen framework, including tying events into however the framework should do such things, and places where data flows without DOM nodes (e.g. if a widget renders based on some dynamic data source that isn’t child elements). Often you could do this with Web Components, but it would substantially harm expressivity and/or performance.
Also you can generally make the implementation lighter and faster if you implement it within the framework, especially if the way you make Web Components uses a different framework (so now you have n+1 frameworks on your page).
Also you can generally make the implementation lighter and faster if you implement it within the framework, especially if the way you make Web Components uses a different framework (so now you have n+1 frameworks on your page).
Web Components can be barebones, use no dependencies, do all DOM manipulations directly. That would give you vanillajs performance. It won't be easy to scale to big components this way--the use case is small components with minimal state, something like a time picker at most. Integrating the Web Component into React should not be much harder than integrating an <video> element. At best, do nothing or at worst, create a Ref and attach an event listener. The benefit is this would work across all other JS frameworks. Web Components are primitive, like the C ABI, but everyone can speak it, like the C ABI.
This is great!
It would be nice to make `react-primitives` compatible with this as well: https://github.com/lelandrichardson/react-primitives.
I hope every UI platform gets a react-like library and becomes compatible with react-primitives. It would be really nice to write things once and make it compatible on every platform instantly.
It would be nice to make `react-primitives` compatible with this as well: https://github.com/lelandrichardson/react-primitives.
I hope every UI platform gets a react-like library and becomes compatible with react-primitives. It would be really nice to write things once and make it compatible on every platform instantly.
Very nice to look through. Does anyone have a list of React "design systems"? I was not familiar with this term.
Also, I am wondering: looks like there is https://spectrum.adobe.com. What is the purpose of Spectrum without an implementation like this? Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
Also, I am wondering: looks like there is https://spectrum.adobe.com. What is the purpose of Spectrum without an implementation like this? Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
"design systems" in recent frontend parlance is generally colors + fonts + screen wids + methodology + components (usually) that all fit a certain visual style/philosophy. Material Design can be considered a "design" system.
While the pieces of design systems make sense in and of themselves (you can argue for a clearer, easier to read font), I think a lot of bullshit gets dragged in along with people wanting to embrace "design systems" for the sake of doing it, or because it looks good on a resume "X designer built a design system at Y company". If I were to think even more cynically than usual, you can think of design systems as bundles of components.
> What is the purpose of Spectrum without an implementation like this? > Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
Cynically -- marketing for adobe, and some easy press, internally maybe a deliverable for the design/frontend teams that was on the roadmap for this quarter. Less cynically -- other companies can choose to use Adobe's design system instead of creating their own, also everyone benefits if Adobe has done stuff that goes above and beyond the usual bundle-of-components (ex. their React Aria[0] effort).
[0]: https://react-spectrum.adobe.com/react-aria/index.html
While the pieces of design systems make sense in and of themselves (you can argue for a clearer, easier to read font), I think a lot of bullshit gets dragged in along with people wanting to embrace "design systems" for the sake of doing it, or because it looks good on a resume "X designer built a design system at Y company". If I were to think even more cynically than usual, you can think of design systems as bundles of components.
> What is the purpose of Spectrum without an implementation like this? > Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
Cynically -- marketing for adobe, and some easy press, internally maybe a deliverable for the design/frontend teams that was on the roadmap for this quarter. Less cynically -- other companies can choose to use Adobe's design system instead of creating their own, also everyone benefits if Adobe has done stuff that goes above and beyond the usual bundle-of-components (ex. their React Aria[0] effort).
[0]: https://react-spectrum.adobe.com/react-aria/index.html
> What is the purpose of Spectrum without an implementation like this? > Why would Spectrum be a public published thing, considering that only Adobe makes Adobe products?
From what I've seen, design system teams at MegaCorps are usually at most 10 people, in an org of thousands of internal engineers and external contractors that may be consuming their product.
Discoverability is pretty important, otherwise engineers will try and get around the guard rails your system imposes.
Also yeah, it helps for recruiting frontend developers.
From what I've seen, design system teams at MegaCorps are usually at most 10 people, in an org of thousands of internal engineers and external contractors that may be consuming their product.
Discoverability is pretty important, otherwise engineers will try and get around the guard rails your system imposes.
Also yeah, it helps for recruiting frontend developers.
You might have responded to the wrong comment -- hopefully OP will see it here, but agreed.
In the ideal situation the team of 10 produces the components/style decisions and the resulting components that the whole company uses and then you never see a weirdly styled/non-standard part of their offerings every again. In practice, it can get really messy as that team can become a bottleneck for various parts of the org trying to move in very different directions and management gets difficult.
In the near future, once one of the design tools really nails generating (probably React) components that devs don't hate, I think it will be much easier for the teams of UX/Design and UI (devs putting react components on pages and dealing with technical feasibility) to work together. It feels like design has only recently started to receive the automation/tooling love that devs have (tools that intelligently manage iteration, sharing designs, "branches", etc), so once someone bridges that gap hopefully tooling gets rid of some back and forth.
In the ideal situation the team of 10 produces the components/style decisions and the resulting components that the whole company uses and then you never see a weirdly styled/non-standard part of their offerings every again. In practice, it can get really messy as that team can become a bottleneck for various parts of the org trying to move in very different directions and management gets difficult.
In the near future, once one of the design tools really nails generating (probably React) components that devs don't hate, I think it will be much easier for the teams of UX/Design and UI (devs putting react components on pages and dealing with technical feasibility) to work together. It feels like design has only recently started to receive the automation/tooling love that devs have (tools that intelligently manage iteration, sharing designs, "branches", etc), so once someone bridges that gap hopefully tooling gets rid of some back and forth.
Many of our products also support third party extensibility, so the main business reason we pitched internally was making this easier for external developers. This helped us convince the bosses to invest in the project and let us open source and maintain it. And hopefully with React Aria, we provide value beyond the standard "look at our fancy components".
Congratulations on the launch! The external developer use case is one I didn't even think of -- I assume this is something like helping people make products that look and fit in with the feel of your other offerings.
Please feel free to amend/improve my definition of design systems above -- the term has meant so much over the years inside and out of the strict boundaries of pure graphic design -- I am not a designer/UX person by trade (I do it only when there is literally no one else), but write frontend code and have had some friends bellyache to me recently about trying to get design systems implemented in a local mid-large size company with a startup-like environment.
Please feel free to amend/improve my definition of design systems above -- the term has meant so much over the years inside and out of the strict boundaries of pure graphic design -- I am not a designer/UX person by trade (I do it only when there is literally no one else), but write frontend code and have had some friends bellyache to me recently about trying to get design systems implemented in a local mid-large size company with a startup-like environment.
You are looking for https://github.com/alexpate/awesome-design-systems
Is there a listbox component similar to a pivot table slicer from excel? One which would always show the complete list (or part of it), be multi selectable with a drag functionality and one in which elements can be made semi-transparent to indicate that they’re empty/missing. I’m looking for something like that since ages.
A native select is the closest thing I can find but it has many limitations irt styling...
A native select is the closest thing I can find but it has many limitations irt styling...
[deleted]
For those that rather not delve into React, there is also a CSS version, framework free implementation.
https://opensource.adobe.com/spectrum-css/index.html
https://opensource.adobe.com/spectrum-css/index.html
The more competition there is in this space, the better, and this looks like a very nicely polished solution right from, the get-go. I would definitely give this a go for smaller projects, as an alternative to MaterialUI or ant.
Devon, thanks for sharing and congratulations on the release! Nice to see Adobe push more open-source work, is that something we can expect more of (vs the proprietary software)?
For someone who hears about Spectrum the first time...what is this stuff? It is not explained on the site either, like I was supposed to know.
They lost me at "css-loader". How about just import your components and they style themselves? The whole philosophy of React is JS-first and really, JS-only.