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

291–300 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

#291

Post by pjmlp »

jimsmart wrote: post #280
pjmlp wrote: post #204

Earlier quoted context omitted.

Firefox on mobile does not count for the majority of companies. Mobile web is all about Safari and Chrome. Again you keep avoiding to explain what "many browsers" means.

According to netmarketshare[0], on desktop[1], Edge currently has 3.8% market share, more than Safari and Opera together. Combining mobile+desktop Edge has 2%. Edge cannot be ignored if one is serious about any kind of business: that's 3-4 out of every 100 desktop users (existing or potential customers), or 'just' 2/100 if one includes mobile. — Honestly, it seems that you are trolling. But I post the above stats in…

You are reading it wrong, it is not me that mandates the browsers.

I have written already in multiple answers, it is the customers that decide which browsers should a given project support, by explicitly stating them on the project delivery contract.

So your customers care about EDGE, fine. Many don't.

Re: Evergreen: a React UI Framework built by Segment

#292

Post by xadhix »

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

And SAP's OpenUI5 - https://openui5.org/ - https://openui5.hana.ondemand.com/#/controls :)

Re: Evergreen: a React UI Framework built by Segment

#294

Post by jhall1468 »

anonytrary wrote: post #144
jhall1468 wrote: post #107

Earlier quoted context omitted.

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…

> If you write 100 ~50 line "trivial functions No, we're talking about 2-3 line functions. Stop arguing with a straw man. You're taking what you know to be true about complex code, and then asserting that those things are also true with simple code. That doesn't work. > And you can't write this particular utility function in 5 minutes and support all the uses-cases The beauty is that because we are rolling our own fu…

> No, we're talking about 2-3 line functions. Stop arguing with a straw man. You're taking what you know to be true about complex code, and then asserting that those things are also true with simple code. That doesn't work.

The library in question is literally 50 lines of code. About 30 when you remove the exports and comments at the top. I find it somewhat ironic that you are so opposed to using utility libraries and you didn't even bother to look at the one in play here.

> The beauty is that because we are rolling our own function, we only need to support the single function signature we decide we're going to stick to in our codebase. Supporting every use-case becomes a moot point.

No it doesn't. All the use-cases are useful. You use strings when you need default classes and objects when you have conditional classes. You can't implement both of those in two lines of code.

> The author of the library has to support the 10^5 people who use his code, meaning he's more likely to merge silly pull requests like "should take objects",

It's always taken objects as properties and for good reason: it's a clean way to separate conditional classes from unconditional ones.

But sure dude, all those features are insane. Put his code up to a solid 30 lines. Really saving the bacon by rolling your own that doesn't do the same thing.

> Learning dozens of APIs takes just as much time as implementing them for a certain set of functions. That set is different for everyone, but it is not the null set for anyone.

Yeah, that's why everyone writes their own lodash. It's just a set of trivial functions.

Re: Evergreen: a React UI Framework built by Segment

#295

Post by jhall1468 »

cmoscoso wrote: post #188
jhall1468 wrote: post #107

Earlier quoted context omitted.

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…

there is no need to support all use-cases.

There is if you use them all? We're talking about strings, arrays and objects as inputs. ~30 lines of actual code.

Re: Evergreen: a React UI Framework built by Segment

#296

Post by jhall1468 »

BigJono wrote: post #136
jhall1468 wrote: post #107

Earlier quoted context omitted.

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

You're absolutely wrong. If reading the docs were harder/more work than writing the code we'd have 100s of implementations of lodash. Instead people use lodash.

Dependency boundary? If you can't figure out what a function called classNames does in the context of a React render function in which the output of classNames is put as a value in to "className" attributes, you need to find a new job.

Dependencies cost time, effort and brain power when they actually require those things. Be thoughtful when using something that actually requires investigation. But honestly, a trivial function should be self-documenting or it really isn't trivial, is it? If I had an npm library called array-flatten are you seriously going to read the docs, or assume it flattens nested arrays?

Re: Evergreen: a React UI Framework built by Segment

#297

Post by jhall1468 »

anonytrary wrote: post #121
jhall1468 wrote: post #100

Earlier quoted context omitted.

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

> 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 > merge in some always-on defaults so you have string style There's some irony here -- all of this just to avoid dealing with string templates: `${class1} ${class2} ${class3}` > You'll often need to combine them Need is definitely not the right word here…

> There's some irony here -- all of this just to avoid dealing with string templates:

By that argument, we can just avoid everything by not making our apps dynamic!

> The classNames utility is a completely unnecessary abstraction.

The only necessary abstraction in programming is assembly since 0's and 1's are hard to reason about. The "need" in this case refers to needing to mix different primitives to make your app dynamic. Your arbitrary example above doesn't do anything because you still have conditional logic to determine what class1 class2 and class3 are, you are just doing a bunch of ugly crap in the render function rather than abstracting it. Or implementing your own version because you're smart.

It's a stupid hill to die on here... you want to argue about importing the entire lodash library because you like .chain, have at it. But I guess you can keep patting yourself on the back for avoiding importing a no-dependency 50-line library.

Re: Evergreen: a React UI Framework built by Segment

#298

Post by jhall1468 »

anonytrary wrote: post #125
jhall1468 wrote: post #110

Earlier quoted context omitted.

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.

> You are re-inventing the wheel Not quite, that would imply time and effort. I'm talking about reinventing the toothpick (2-3 lines of code), which is much different than reinventing a complex library for the sake of reinventing it. > Rolling your own diffing algorithm is exactly what actual engineering entails That's nice, but you're addressing a straw man. No one actually said rolling your own diffing algorithm is…

> Not quite, that would imply time and effort. I'm talking about reinventing the toothpick (2-3 lines of code), which is much different than reinventing a complex library for the sake of reinventing it.

Re-inventing 1000 versions of a tooth pick is reinventing the wheel.

> That's nice, but you're addressing a straw man.

You keep using that term and I'm not sure you understand what it means.

> It was said that no one is suggesting you recreate a non-trivial dependency for the sake of reducing your dependency count.

And my argument is that dependency count is one of the dumbest metrics to be interested in. Size, sure as that impacts bundle size, which in-turn, effects latency. But "count" is meaningless.

> Humor me -- the next time you use classNames for a small project

I use styled-components exclusively for React projects now.

> For example I've seen things similar to "classNames({myClass: true})" in code before.

So? Bad code is bad, that's not a library failure. Now that is a straw man.

> Can you see what is wrong with this line?

Of course I can, because I'm actually good at my job. I also wouldn't do that. Using your toaster in a bathtub is also REALLY stupid, but that doesn't mean we should ban toasters.

> When people get comfortable with abstractions, they completely forget how to write the simplest code.

No that's called laziness and it has nothing to do with dependencies. You have twice in this thread accused me of straw men inaccurately, and now wrote a paragraph dedicated to a huge straw man.

Re: Evergreen: a React UI Framework built by Segment

#299

Post by Vinnl »

pjmlp wrote: post #289
user1010198 wrote: post #180

Earlier quoted context omitted.

yes but real world applications often need to support more than safari and chrome, so until they are supported across the majority of them including older versions still in wide use then its still a no go for the majority of use cases.

Mobile is all about Safari and Chrome in what concerns Request For Proposals and delivery acceptance testing. So real world customers don't care about anything else. If it happens to work, or a team member decides to go at it on their own outside project budget, it is a nice to have feature that's it.

Yes, so my point was that the authors of UI frameworks perhaps don't care about mobile only.
Post reply on HN