A React implementation of Spectrum, Adobe’s design system

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

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! :)

"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

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.

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.