A React implementation of Spectrum, Adobe’s design system
react-spectrum.adobe.com
react-spectrum.adobe.com
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.
Do you also plan to make a DateRangePicker and a TimePicker?
And yes, we have a DateRangePicker and TimePicker as well.
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.
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 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.
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. :-)
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.
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? ;-)
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.
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
Having said that, I don't miss it and I very much like the way things are now.
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.
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...
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.
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.
But I do agree, custom template syntax is a non-starter.
example: https://github.com/tantaman/fk-your-frameworks-todomvc
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).
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.
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?
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).
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.
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.
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.
A native select is the closest thing I can find but it has many limitations irt styling...