Finding a good React UX library is tough. None is ideal. Too heavy, too small, too slow, too dirty. Settled on ant.design for a while, not perfect but good enough.
Any other good candidates? This is something I really need to look into soon.
Base Web, Uber’s New Design System for Building Websites in React
61–70 of 156 posts
Re: Base Web, Uber’s New Design System for Building Websites in React
#62Earlier quoted context omitted.
Cannot reproduce.
It's probably because I'm using uMatrix and it's blocking something "critical" that breaks when you try to visit the Welcome page.
Wait so you are blocking their javascript then claiming it's broken?
I was curious, and I just went in and tried blocking the google analytics, google tag manager, and everything from cdn.jsdelivr.net, and even some random scripts (like the commons.js file), and everything still worked fine as far as I could tell...
Re: Base Web, Uber’s New Design System for Building Websites in React
#63I guess we can add Uber to this list of corporate frameworks... https://news.ycombinator.com/item?id=18235887 https://element.eleme.io/ https://ant.design/ https://quasar-framework.org/ https://at-ui.github.io/at-ui/ https://developer.microsoft.com/en-us/fabric https://vmware.github.io/clarity/ http://appnexus.github.io/lucid/ https://ng-lightning.github.io/ng-lightning/ https://blueprintjs.com/ http://www.jetbrains.…
Github's https://primer.style/
Google's https://material.io/design/
I guess most companies have a design system in place
Re: Base Web, Uber’s New Design System for Building Websites in React
#64Earlier quoted context omitted.
You're ignoring the fact that many already went through that phase and ultimately decided that complexity is the only enemy worth fighting in software. It always pays off to take a closer look at the things you can't think or say, to ask why.
> You're ignoring the fact that many already went through that phase and ultimately decided that complexity is the only enemy worth fighting in software. No, this doesn't match my experience. The people who resist types are usually web designer types who haven't actually worked with type systems at all so they view it as ivory tower nonsense - complexity for complexity's sake. There is the occasional person who worke…
I've been writing code on a daily basis for over 30 years; in umpteen different languages, some more typed than others. And I'm still not very fond of having types shoved down my throat, nor any other kind of restrictions.
We've been building computers and writing code for quite some time now, so long that some of us are beginning to notice the repetitions.
The fact that experience is so often dismissed begins to explain the mess we're in.
Re: Base Web, Uber’s New Design System for Building Websites in React
#65Earlier quoted context omitted.
It's probably because I'm using uMatrix and it's blocking something "critical" that breaks when you try to visit the Welcome page.
Wait so you are blocking their javascript then claiming it's broken? I was curious, and I just went in and tried blocking the google analytics, google tag manager, and everything from cdn.jsdelivr.net, and even some random scripts (like the commons.js file), and everything still worked fine as far as I could tell...
It's loading the first-party scripts (all 58 of them), but there must be even more delivered by a CDN that it requires.
Re: Base Web, Uber’s New Design System for Building Websites in React
#66Nope. This is replacing composition with configs for no good reason. It's like the people who made Grunt and Webpack teamed up to ruin React for everyone.
I really hate dismissive comments like this. They laid out pretty well what problems this is trying to solve, why they want it that way, the benefits it has, and some of the tradeoffs it makes. Saying it "replaces composition with configs for no good reason" is not only wrong (they still heavily use composition here, it even makes it more powerful in some ways from what I can tell so far), but also doesn't really mea…
Ok, fair enough. It was a drive by shooting of a comment. So here’s a more considered criticism.
There’s already a way to overwrite props in react. Just use props.
If you need to expose the native API of the underlying element, do this (does HN format code?)...
``` const {foo, ...native} = props;
{foo}
```
Combine that with default props and you’re good to go.
There’s already a way to allow components to take multiple types of children.
``` { return {blah} }} /> ```
And there’s already a multitude of ways to adapt styles based on props, the most obvious of which is StyledComponents.
In addition, this highlevel config is brittle. It means parents must be coupled to their children, and children coupled to their parents.
And where does this config end? How deep does the nesting of this configuration go?
Here’s my opinion; if you think you need this sort of configuration to properly wrangle your UI, then you’ve failed to grasp the point of React and the true power of composition.
React components are just functions. Preferably pure functions. Once you strip away the JSX, you should be left with something that resembles functional programming (albeit taken to an extreme thanks to JSX’s goal of emulating HTML). Props are parameters. We’ve all come across code where functions take complex and convoluted objects as arguments that trigger an explosion of calls that are near impossible to track or reason about.
This override solution is the first step in towards turning React into the kind of tool that it usurped. It has the stench of ExtJs and it’s ilk.
This “solution” was created by people who believe all problems are better solved by abstraction.
As programmers, our time is spent on the edge cases. Our text book prefect algorithms and mathematically sound functions are exposed as frauds the second they’re exposed to user input. Our carefully crafted UI libraries fall to pieces when the designers choose to break their own rules.
For configuration to work, it requires god level foresight and will eventually become Turing complete in itself.
Config is for the birds. Declarative code has always been the answer.
Re: Base Web, Uber’s New Design System for Building Websites in React
#67Before even looking at the details ... why would I use this? Uber is not a company that is known for great websites. They get (I'm guessing) 99%+ of their usage through native apps. So why would I believe they're particularly good at building for the web?
It's probably got more engineers behind it than the vast amount of design frameworks, given Uber's size. And some of the components feel pretty nice, so maybe try looking at the details?
Re: Base Web, Uber’s New Design System for Building Websites in React
#68I guess we can add Uber to this list of corporate frameworks... https://news.ycombinator.com/item?id=18235887 https://element.eleme.io/ https://ant.design/ https://quasar-framework.org/ https://at-ui.github.io/at-ui/ https://developer.microsoft.com/en-us/fabric https://vmware.github.io/clarity/ http://appnexus.github.io/lucid/ https://ng-lightning.github.io/ng-lightning/ https://blueprintjs.com/ http://www.jetbrains.…
Dumb question maybe but why is Bootstrap (from Twitter) not on this list? What are the inclusion criteria?
Re: Base Web, Uber’s New Design System for Building Websites in React
#69I guess we can add Uber to this list of corporate frameworks... https://news.ycombinator.com/item?id=18235887 https://element.eleme.io/ https://ant.design/ https://quasar-framework.org/ https://at-ui.github.io/at-ui/ https://developer.microsoft.com/en-us/fabric https://vmware.github.io/clarity/ http://appnexus.github.io/lucid/ https://ng-lightning.github.io/ng-lightning/ https://blueprintjs.com/ http://www.jetbrains.…
Jane Street's minimal OCaml-based incr_dom
Re: Base Web, Uber’s New Design System for Building Websites in React
#70Earlier quoted context omitted.
I really hate dismissive comments like this. They laid out pretty well what problems this is trying to solve, why they want it that way, the benefits it has, and some of the tradeoffs it makes. Saying it "replaces composition with configs for no good reason" is not only wrong (they still heavily use composition here, it even makes it more powerful in some ways from what I can tell so far), but also doesn't really mea…
Ok, fair enough. It was a drive by shooting of a comment. So here’s a more considered criticism. There’s already a way to overwrite props in react. Just use props. If you need to expose the native API of the underlying element, do this (does HN format code?)... ``` const {foo, ...native} = props; {foo} ``` Combine that with default props and you’re good to go. There’s already a way to allow components to take multipl…
A big part of the goal with the overrides mechanism was to provide usable components out of the box that could optionally be modified if something needed to be changed for a given use case.
You can use the components as is, using props if you're ok with the out of the box style/functionality/etc, without ever touching overrides. The overrides provide a standardized interface to changing the component internals across the entire component library.
That approach may be overkill for simple components that are trivally composable (Card for example), but is incredibly powerful for a component like Datepicker where you may want to change styles or functionality of a deeply nested component without exposing a massive top level props interface.