Live data from Hacker News

Evergreen: a React UI Framework built by Segment

evergreen.segment.com

131–140 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

#131

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?

Not sure what their bundle size looks like but my understanding is they're using PJAX so the site output should function without JS. Problem is good luck maintaining that stack and remaining secure. And then there's the fact there's no conceivable way it could scale properly for large sites static which would need something like Go/Rust to actually generate quickly then there's the matter of caching. Basically this all leads to headaches just in different places.

Re: Evergreen: a React UI Framework built by Segment

#132

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-…

Here are some more, separated out by React, React Native and Universal:

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

#133
Great, another UI framework that will not work with Vue, Marko, Angular, LitElement or basicly anything else than react. When will the trend stop :/

Can'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

#134

Earlier 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.

Yeah this argument falls flat in the case of classnames where we're comparing reading a two liner function with reading a page of docs for a library.

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

#135

I 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).

3 Different things. html, css & js are like raw materials, React is processing these raw materials, and a UI components or design systems are the result you get if you mix the React process with manual labor.

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

#136

Earlier 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…

Yeah and if you've analysed 100 sets of docs for 100 dependencies you've done a ton more work than writing 100 trivial functions.

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

#138
post #49

Earlier 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.

Not only that, for me in Safari the new reddit barely works and is not loading things very fast or sometimes at all.

Re: Evergreen: a React UI Framework built by Segment

#139
Does anyone knows a react ui framework which also includes concepts for more high-level interfaces? Not only atoms and molecules, but also "organisms" and "pages" as a compound of several components?

I 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

#140
post #81

Earlier 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…

Ok, no one is shoveling it down your throat. Just avoid it.

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.

Post reply on HN