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

101–110 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

#101

Post by rckclmbr »

anonytrary wrote: post #77
paperpunk wrote: post #65

Earlier quoted context omitted.

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", () => { expec…

    it("should work with booleans", () => {
      expect(classNames({a:true, b: false}).to.equal("a b")
    })
Shouldnt this just equal "a" though? See, already a bug in your homegrown solution!

Re: Evergreen: a React UI Framework built by Segment

#102

Post by laurent123456 »

That's a minor thing but when I press the back button on one of the documentation pages it takes 6 seconds to go back (first it changes the title of the tab then it seems to wait for 6 seconds, probably parsing and running several MB of JavaScript). Sometimes the tab titles is blinking and displaying "Evergreen" and "Components - Evergreen" very quickly during these 6 seconds.

You'd think in 2018 going back to a page would be a solved problem, but apparently each new framework needs to re-solve this in a new orignal way.

Re: Evergreen: a React UI Framework built by Segment

#103

Post by jhall1468 »

darekkay wrote: post #74
anonytrary wrote: post #61

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…

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?

So much this. It's 30 lines of code. The remaining code is comment fluff and 15 lines dedicated to the various types of export utilities (AMD, NPM, window). Seriously this is such an odd package to start these arguments with.

Re: Evergreen: a React UI Framework built by Segment

#104

Post by anonytrary »

jhall1468 wrote: post #95
bthornbury wrote: post #82

Earlier quoted context omitted.

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…

I think he might be talking about trivial dependencies, like leftpad, classNames, arrify, etc. In the case of trivial dependencies, rolling your 30-line "util.js" file to remove 3 dependencies is definitely worth it. No one is suggesting you roll your own diffing algorithm.

Re: Evergreen: a React UI Framework built by Segment

#105

Post by onion2k »

statictype wrote: post #99
onion2k wrote: post #92

Earlier quoted context omitted.

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

I did, and it doesn't on my Android phone.

Re: Evergreen: a React UI Framework built by Segment

#106

Post by anonytrary »

rckclmbr wrote: post #101
anonytrary wrote: post #77

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…

it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) Shouldnt this just equal "a" though? See, already a bug in your homegrown solution!

My test would fail, and I would fix it. + 2 seconds. Actually, the next test has the same problem. 2 more seconds. I'm gonna be in trouble with my boss!

Re: Evergreen: a React UI Framework built by Segment

#107

Post by jhall1468 »

anonytrary wrote: post #77
paperpunk wrote: post #65

Earlier quoted context omitted.

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", () => { 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 are trivial. There's nothing you're doing aside from wasting time by writing it. lodash is literally a massive library of mostly "trival" functions that no one is every going to write themselves because WHY waste the time?

The only cardinal sin at play here is thinking that wasting your time reinventing the wheel is time well spent. This approach is what I'd expect from either a very young developer or a very self-centered one.

Re: Evergreen: a React UI Framework built by Segment

#108

Post by darekkay »

onursenture wrote: post #98
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-…

What about PrimeReact? https://www.primefaces.org/primereact

From a 5 min glance, this framework looks really inaccessible. Most outlines ("focus rings") are removed and it's really hard to navigate the components with a keyboard, even as a sighted person. The focus indicator for buttons is just another shade, which is not sufficient. I was not able to set a value in the "Rating" component using my keyboard.

All those things can be fixed, but I would rather go with a library with accessibility in mind.

Re: Evergreen: a React UI Framework built by Segment

#109

Post by anonytrary »

darekkay wrote: post #79
anonytrary wrote: post #56

Earlier quoted context omitted.

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

> This ist just an example for why one would favor well-tested utilities over re-inventing the wheel

No, it really isn't. The library does not dictate how things should be done, that's the fantastic thing about using your own utilities. In my implementation, we return the value itself if it's falsy. In yours, we return an empty array. Again, trivial "fix" (not that there's anything to "fix", it's a matter of convention, not correctness).

Re: Evergreen: a React UI Framework built by Segment

#110

Post by jhall1468 »

anonytrary wrote: post #104
jhall1468 wrote: post #95

Earlier quoted context omitted.

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…

I think he might be talking about trivial dependencies, like leftpad, classNames, arrify, etc. In the case of trivial dependencies, rolling your 30-line "util.js" file to remove 3 dependencies is definitely worth it. No one is suggesting you roll your own diffing algorithm.

I think I already responded to you elsewhere, but in case I'm incorrect: No it is not worth it. You are re-inventing the wheel so you can pat yourself on the back. Nobody hires a software engineer to write leftpad. Rolling your own diffing algorithm is exactly what actual engineering entails.
Post reply on HN