This 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-…
Do any of these produce finished output that is less than a few kB, and works reliably in say the past two major versions of browsers? Bundle sizes are getting ridiculous. Is there a React UI framework that focuses on tiny build size and browser compatibility?
Evergreen: a React UI Framework built by Segment
131–140 of 309 posts
Re: Evergreen: a React UI Framework built by Segment
#132This 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-…
https://habd.as/awesome-react-components/
https://habd.as/awesome-react-boilerplates/
Just added evergreen to the components list as it doesn't look like more than a UI kit.
Re: Evergreen: a React UI Framework built by Segment
#133Can't we embrace web components already and have those UI frameworks work in all popular solutions out there? Every time something new comes out existing solutions are being rewritten from scratch.
Re: Evergreen: a React UI Framework built by Segment
#134Earlier quoted context omitted.
> You can, for example, pass an object {string:booleanish} and it will add only the keys whose values are truthy. Why is this something you can't do on your own in a few lines of code? const classNames = (o, c=[]) => { for (let k in o) if (o[k]) c.push(k) // booleanish return c.join(" ") } This is not cool at all! Why import a trivial function over NPM to do this for you? Better to lower your dependency count and hav…
What’s nice about it is that a lot of projects use the same util, meaning it is very easy to read or edit if you are familiar with the library. If everybody writes a custom function you will need to learn how to do classNames separately in every project you work on.
It's like everyone in JS land is allergic to writing a piece of code that isn't just playing lego with things written by a real developer.
Re: Evergreen: a React UI Framework built by Segment
#135I 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.
My first thought was that this is a UI Framework (Evergreen) built on UI Framework (React) built on a UI Framework (js + html). No real point here, but I do find it curious that there is this tendency to build new UI frameworks all the time. Personally, I still like html + js (and I have used React).
The're frameworks and design systems. A React UI framework refines or enhances the React process to build UI components or design systems.
Bootstrap e.g. is 2 things in 1, it's a process/framework and design system that sits directly on top of html, css & js.
Re: Evergreen: a React UI Framework built by Segment
#136Earlier quoted context omitted.
This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expec…
If you write 100 ~50 line "trivial functions" you've now written 5000 lines of code that doesn't actually solve your underlying problem, it just makes it slightly easier. And you can't write this particular utility function in 5 minutes and support all the uses-cases, particularly if you are going to write a bunch of unit tests. The reason to depend on someone else's code in trivial use-cases is entirely because they…
Why does everyone in JS land treat dependencies like they're just some free magic, as if an intimate familiarity with the source code is injected into your entire team's brains the moment you type 'npm install'? I've worked with far too many people that blow out the package.json file for every little thing then wonder how every other dev on their team seems to be paralysed by the smallest task.
Every time someone on your team runs into a dependency boundary they need to stop reading code, pull up a browser, and start reading docs. You can't trace the path of execution through a black box dependency, which means if you use a bunch of them in one place your developers are going to have to hold a hell of a lot of information in their head while they analyse that code. If they drop something, it's back to the docs again. At the extreme, it's a context switching nightmare.
Dependencies cost time, effort and brain power. Make sure you're getting enough in return.
Re: Evergreen: a React UI Framework built by Segment
#137Re: Evergreen: a React UI Framework built by Segment
#138Earlier quoted context omitted.
There may be some fast components in the Reddit web app, but I think there must be a valid reason why so many users are switching to the old Reddit (not just because of the way it looks, but due to performance complaints). I just went in and even scrolling through Reddit comments is laggy. Switching to old mode is like day and night.
they're sticking with the old reddit because the information density is much higher. it's a design problem.
Re: Evergreen: a React UI Framework built by Segment
#139I feel like, a lot of ppl still create horrible UIs based on good components, because they lack the bright overview.
Re: Evergreen: a React UI Framework built by Segment
#140Earlier 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…
But be prepared because it is the de-facto standard way of building classNames in React, also because it was part of the standard utilities provided by React.