Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evergreen: a React UI Framework built by Segment

evergreen.segment.com

Post reply on HN
Print view View original

71–80 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

#71

Post by city41 »

anonytrary wrote: post #59
city41 wrote: post #50

Earlier quoted context omitted.

Curious what your issue with classnames is? Is it just because it’s a small and simple module (50 lines of code)?

I was curious so I checked out their Github page. I found this example: classNames('foo', 'bar'); // => 'foo bar' classNames('foo', { bar: true }); // => 'foo bar' classNames({ 'foo-bar': true }); // => 'foo-bar' classNames({ 'foo-bar': false }); // => '' classNames({ foo: true }, { bar: true }); // => 'foo bar' classNames({ foo: true, bar: true }); // => 'foo bar' ... var btnClass = classNames({ btn: true, 'btn-pres…

My usage is typically

  const cmpClass = classnames('componentsMainClass', props.className, { dynamicClassesHere });
I like that the component's main class stands out and is easy to find, that allowing the consumer to pass along their own class is trivial, and that the dynamic classes are grouped together.

So I'd argue multi argument and falsy thinning are welcome features. I've never used array flattening.

Does it really need to be a dependency? I guess that's a matter of opinion. I like that the various React projects I deal with on a regular basis all handle classes in a consistent manner. I also don't usually mind dependencies that don't pull the entire world in with them.

Re: Evergreen: a React UI Framework built by Segment

#72

Post by jameslk »

ianhawes wrote: post #10

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

Shopify also has one:

https://polaris.shopify.com

Personally, I've found Ant Design to be the most comprehensive, feature and behavior-wise.

Re: Evergreen: a React UI Framework built by Segment

#73

Post by chrisco255 »

matsemann wrote: post #54
chrisco255 wrote: post #52

Earlier quoted context omitted.

It's not a React problem. React runs Facebook, Instagram, and mobile Twitter, for example. But it's possible to build inefficient React implementations. Reddit rebuilt their front end from the ground up. It is possible they have front end issues there. Some flame chart analysis on Reddit's current front end and old front end would reveal the source of the problems.

While I agree React isn't the issue here, you chose horrible examples. Loading Facebook on my computer (especially trying to open a chat window) brings my computer to a knee. And using twitter on mobile browser you quickly learn how the spinner looks.

I haven't had performance issues on Facebook in quite some time. And Twitter works like a charm on my Nexus. I'm wondering how much of your issues have to do with either round trip latency or network issues.

Re: Evergreen: a React UI Framework built by Segment

#74

Post by darekkay »

anonytrary wrote: post #61
yuchi wrote: post #51

Earlier quoted context omitted.

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.

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

I get the "dependency hell" issue in Javascript world, but why would I rewrite this particular utility? It's well tested (both unit and field tested), includes edge cases and has zero dependencies. As a dependency, I will also get any future bug fixes or features if I wish to. An even better example is lodash. Would you really rewrite every util you need just for the sake of not having external dependencies?

Re: Evergreen: a React UI Framework built by Segment

#75

Post by bthornbury »

ernsheong wrote: post #63

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

Re: Evergreen: a React UI Framework built by Segment

#76

Post by krikou »

blumomo wrote: post #68
ernsheong wrote: post #63

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.

I guess we're all looking forward to your open source web components library!

This is already a start: https://www.webcomponents.org/

Re: Evergreen: a React UI Framework built by Segment

#77

Post by anonytrary »

paperpunk wrote: post #65
anonytrary wrote: post #59

Earlier quoted context omitted.

I was curious so I checked out their Github page. I found this example: classNames('foo', 'bar'); // => 'foo bar' classNames('foo', { bar: true }); // => 'foo bar' classNames({ 'foo-bar': true }); // => 'foo-bar' classNames({ 'foo-bar': false }); // => '' classNames({ foo: true }, { bar: true }); // => 'foo bar' classNames({ foo: true, bar: true }); // => 'foo bar' ... var btnClass = classNames({ btn: true, 'btn-pres…

Roll your own, untested function vs a small, widely used library with a well-understood, well-tested API that your devs have a good chance of being familiar with already. I too want to avoid bloated npm dependencies but this seems like a fair engineering trade-off..

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", () => {
    expect(classNames({a:true})).to.equal("a")
  })
  it("should work with booleans", () => {
    expect(classNames({a:true, b: false}).to.equal("a b")
  })
  it("should work with falsy and truthy values", () => {
    expect(classNames({a: 5, b: ""}).to.equal("a b")
  })
This isn't redux. It's a trivial utility function. Your kind of thinking is too often applied without thinking. Before depending on someone's code, ask yourself if you can roll your own in under 5 minutes. The answer could easily be yes. There is no good reason to depend on someone else's code if it's trivial. Having more dependencies than you need is a cardinal sin that way too many javascript developers commit.

Re: Evergreen: a React UI Framework built by Segment

#78

Post by orhanhenrik »

anonytrary wrote: post #61
yuchi wrote: post #51

Earlier quoted context omitted.

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.

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

Re: Evergreen: a React UI Framework built by Segment

#79

Post by darekkay »

anonytrary wrote: post #56
siftikha wrote: post #45

always hilarious to see the dumb dependencies that these projects have https://github.com/sindresorhus/arrify https://github.com/JedWatson/classnames

const arrify = a => a && (Array.isArray(a) ? a : [a]) vs. introducing a potential attack vector.

arrify(null) returns null, unlike the arrify library . I expect that a function which turns things into an array returns an empty array as fallback. This ist just an example for why one would favor well-tested utilities over re-inventing the wheel (not that I would use arrify as a dependency myself).

Re: Evergreen: a React UI Framework built by Segment

#80

Post by jameslk »

dmortin wrote: post #30
ianhawes wrote: post #10

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

The question is: how many of these will be maintained several years later? Can you build a long term project on these? Or the expectation is that one has to make a new UI anyway every several years to keep up with the changing fashion, so rewrites are inevitable?

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?
Post reply on HN