Great, but not a single clickable item works in Safari :'D
It was same here, latest macOS/Safari. Weirdly enough now I visited the page again and it works.
Evergreen: a React UI Framework built by Segment
91–100 of 309 posts
Re: Evergreen: a React UI Framework built by Segment
#92Evergreen looks quite nice, but their website isn't responsive and that gives me pause when considering it for my own projects. The components themselves may work fine, but I can't be sure without digging in further. Just something to consider if you're looking at using Evergreen.
"Currently there is no opinionated way to construct responsive layouts in Evergreen. In the case of responsive layouts you might want to simply use a div with a class name and use breakpoints in CSS — or potentially a CSS-in-JS solution." https://evergreen.segment.com/components/layout-primitives
Responsive design isn't just adding breakpoints.
It's responding to the device and the ways the user will interact with it. For example, the combobox example in Evergreen doesn't actually use a in the background, so users on mobile devices will actually have to use the dropdown implementation rather than the browser displaying a proper native mobile select. That's a much worse experience. Not to mention Evergreen will be completely inaccessible for users who need assistive technology, which potentially poses legal issues...
Re: Evergreen: a React UI Framework built by Segment
#93Earlier quoted context omitted.
They're open source right? Would you expect to build your own design language, responsive/accessible components, documentation and maintain it any better than an open source solution?
These frameworks are inevitably much more generic than any in-house solution. On one side this is great, because it means that the abstractions need to be sensible - but it also means there is much more code to maintain. So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. Of course, even better would be to use a solution which will not be abandoned. Also n…
> So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution.
I'd argue this depends on your needs. If you're using one of these for your consumer-facing product, perhaps so. Otherwise, if your UI is not what you're selling or your product/team is big enough to end up creating one of these from scratch anyway, then no. In the latter case, that's probably why there's so many of these to begin with.
> Also note that these frameworks lock you into design & feel of their choice.
Some of these frameworks actually let you re-theme them. For example, Ant Design can mostly be re-themed.
Re: Evergreen: a React UI Framework built by Segment
#94I wish people would stop making UI frameworks in , and instead make it web components based with vanilla JS/very light lib dependency, so that everyone can enjoy the benefit. React is becoming a bubble of its own, and it's exclusive.
Personally I like LitElement: https://github.com/Polymer/lit-element
It's a super-lightweight base class for web components, and a descendant of the Polymer framework.
A Material Design framework uses this: https://github.com/material-components/material-components-w...
Re: Evergreen: a React UI Framework built by Segment
#95Earlier quoted context omitted.
Playing devil's advocate, why is lowering your dependency count a good thing?
Dependencies have cost. You have to monitor for updates, notify the maintainer(s) of any bugs, keep an eye out for security vulnerabilities, and sometimes ( gasp ) even step through them with a debugger. Doing that for one dependency is bad enough, but for 100s it's a nightmare. Personally, I prefer to just pull the pieces I need out of an open source library (unless it's very well maintained, or huge). It's like doi…
Copy/pasting has a nearly identical cost (aside from notifying the maintainer), except you have to catch all of them, you removed an easy upgrade path when other people catch the issues and you're spending vastly more time "code reviewing" every dependency you have rather than actually producing the software you're trying to write.
Don't know about you, but we have actual goals and I'd never meet them if I tried your method.
Re: Evergreen: a React UI Framework built by Segment
#96always hilarious to see the dumb dependencies that these projects have https://github.com/sindresorhus/arrify https://github.com/JedWatson/classnames
While I can understand your skepticism on the first one, the second package is actually very useful. It doesn't just concatenate strings filtering out falsy values, it supports the whole old AngularJS class format. You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Pretty neat, actually.
In ideal world all functions should be pure and be a dependency and all code should be just pure functions.
Re: Evergreen: a React UI Framework built by Segment
#97In a fresh create-react-app project, their getting started example that includes only a button results in a minified js of 570K. Apparently the whole of Blueprint.js is included as a dependency. Shouldn't tree shaking take care of this seamlessly?
Tree shaking isn't automatically supported for CSS. You can use third party tools like PurifyCSS though.
It's the js bundle that is large.
Re: Evergreen: a React UI Framework built by Segment
#98This list was posted a few weeks ago, but here is a fairly definitive list of similar UI frameworks: 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.org/ring-…
What about PrimeReact? https://www.primefaces.org/primereact
Re: Evergreen: a React UI Framework built by Segment
#99Earlier quoted context omitted.
"Currently there is no opinionated way to construct responsive layouts in Evergreen. In the case of responsive layouts you might want to simply use a div with a class name and use breakpoints in CSS — or potentially a CSS-in-JS solution." https://evergreen.segment.com/components/layout-primitives
Responsive design isn't just adding breakpoints. It's responding to the device and the ways the user will interact with it. For example, the combobox example in Evergreen doesn't actually use a in the background, so users on mobile devices will actually have to use the dropdown implementation rather than the browser displaying a proper native mobile select. That's a much worse experience. Not to mention Evergreen wil…
Did you try it on mobile? It actually does seem to use the native selector and not the custom one for me
Re: Evergreen: a React UI Framework built by Segment
#100Earlier quoted context omitted.
Your little utility here doesn’t cover the whole 'classnames' API. export default function classNames(...args) { return args.filter(valid).map(single); } function valid(arg) { return arg && (!Array.isArray(arg) || arg.length); } function single(arg) { if (typeof arg === 'string') { return arg; } else if (Array.isArray(arg)) { return classNames(...arg); } else { return Object.keys(arg).filter(k => ……… This is getting…
> Your little utility here doesn’t cover the whole 'classnames' API. Thats partly the point. The whole API doesn't really need to be covered in order to achieve the same utility. I think the library clearly over-engineered the simple task of string concatenation, and their API is redundant. Their API caters to too many styles and that increases its complexity. It takes 2 seconds to grok the two lines in my utility, w…
You don't "agree" on a convention, they have different use cases. Sometimes you'll want to merge a bunch of class names so you use array-style. Other times you have class names that have prop dependencies so you use object style and finally you'll want to merge in some always-on defaults so you have string style. You'll often need to combine them, depending on use-case.
That's a whole lot of complaints for 50 lines of code.