Live data from Hacker News

Evergreen: a React UI Framework built by Segment

evergreen.segment.com

81–90 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

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

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

Re: Evergreen: a React UI Framework built by Segment

#82

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…

Playing devil's advocate, why is lowering your dependency count a good thing?

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 doing a code review at the same time, so you're aware of what's going on in your application.

Re: Evergreen: a React UI Framework built by Segment

#83
post #71

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…

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

> const cmpClass = classnames('componentsMainClass', props.className, { dynamicClassesHere });

This is a matter of convention. Another, equally valid convention:

  classNames({
    mainClass: true, // first key is main class
    [props.className]: true, // derived
    otherClass: true, // rest
    yetAnotherClass: true // ...
  })
At the end of the day, everyone has to learn their codebase's convention, and that's all that really matters. One convention isn't better or worse than any other, but it's best to have one and stick with it. I don't need a library which supports 10 different conventions if my chosen convention only requires 2 lines of code. Your convention could be implemented in a few lines of code, as well, and then you'd be forced to stick with it, which is probably better. Using this library, 5 different developers could be using 5 different conventions. The helper function I suggest forces a single convention, which lowers complexity.

Re: Evergreen: a React UI Framework built by Segment

#84

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've been working on a tiny vanilla js lib focused around web components: https://github.com/maximebf/gousse.js. It includes a set of components using Bootstrap: https://github.com/maximebf/gousse.js/blob/master/examples/u...

Re: Evergreen: a React UI Framework built by Segment

#85
post #80
post #30

Earlier quoted context omitted.

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?

These frameworks are inevitably much more generic than any in-house solution. On one side this is great, because it means that the abstractions need to be sensible - but it also means there is much more code to maintain. So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. Of course, even better would be to use a solution which will not be abandoned.

Also note that these frameworks lock you into design & feel of their choice. This might work for some use cases and for now, but when the requirements change you often end up fighting the framework. I don't have a solution to that though. :)

Re: Evergreen: a React UI Framework built by Segment

#86
Issue #1: When I scroll down the list of components, click a link to view a component and then go back to the list, I'm positioned at the top of the page, not down where I scrolled to. This is an issue with many (most?) JavaScript-rendered pages that I visit, and it's the main reason why I hate content sites (not web apps) that use JavaScript-rendered HTML.

Issue #2: Many (most?) of the form components show no indication of being selected when using keyboard navigation. This is the main issue I have with most web UI toolkits. (For example, Semantic UI is a notorious offender, even though it's frequently recommended at HN, including multiple times in the comments on this page.)

Issue #3: There are multiple problems in Firefox, including two carets displayed in each Select component.

Issue #2 and #3 almost make me miss the notices that used to be displayed at the bottom of web pages, such as "Best viewed in Internet Explorer 4 at 800x600 resolution". A lot of pages nowadays should have a warning like "Best used in Chrome with a mouse or touchscreen".

Re: Evergreen: a React UI Framework built by Segment

#87

Earlier quoted context omitted.

We've been happy with http://react.semantic-ui.com/ so far.

I liked Semantic-UI a lot in terms of looks , but the React aspect of it is separate, so even though it's done by the same people as the core team, it inherently always lags behind a bit in feature completeness. I especially ran into this with transitions and animations, and migrated to Blueprint.js instead, which I was extremely happy with from a feature-completeness perspective, but which I couldn't figure out how…

It's not done by the core team. It was a separate project by separate people that was brought under Semantic UI's umbrella. That's actually the major reason for the lagging behind: Semantic UI is designed for a circa 2008 jQuery website. It's a beautiful UI, but the CSS uses a horribly dated model which obligates child elements being aware of the parent elements.

End of the day, until it's rewritten with modularity in mind it will always be a drag to properly implement it in React.

Re: Evergreen: a React UI Framework built by Segment

#88
post #81

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…

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, whereas it takes 5 minutes to make sure you know all 50 combinatorial ways to concatenate a string with the classNames library. There is too much indecision in the API, so they decided to support everything they could think of. Now I have to be ready for the possibility that the 5 people on my team can't agree on a convention simply because the library allows every possible convention one could desire.

Re: Evergreen: a React UI Framework built by Segment

#89

Earlier quoted context omitted.

Playing devil's advocate, why is lowering your dependency count a good thing?

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…

Replace “dependency” with “code / function” in your post and you will see the problem.

Re: Evergreen: a React UI Framework built by Segment

#90

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.

Yeah, I really dislike Polymer's approach of using Web Components as an architectural pattern, but this is the exact use case they're good at. Then again, I can understand that you don't whip something like this up in a day, and support for Web Components might not be as widespread yet as a UI framework author would like.
Post reply on HN