Live data from Hacker News

Evergreen: a React UI Framework built by Segment

evergreen.segment.com

191–200 of 309 posts

Re: Evergreen: a React UI Framework built by Segment

#191
post #33

I've wondered about React, although I haven't used it myself. I know that the new Reddit was written using React components, and it's very slow. Is that a React problem (i.e. is it hard to write fast web apps) or is it a Reddit problem (or both)?

React is not fast, clearly the simple idea of having a virtual Dom is very costly compared to do things by hand. However for a large scale app react makes it more easy to reason about and keep it maintainable, components are far easier to implement, etc...

So for many people, the benefits you get on the development side outweight the performance overhead

Re: Evergreen: a React UI Framework built by Segment

#192
post #51

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

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.

Second one is used only once in the code base to concat two strings together afaik

Re: Evergreen: a React UI Framework built by Segment

#193

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…

You want `undefined` and `null` to show up in class names? You'd at least need `${class1||''}` and your solution will grow in cases from there despite your one-liner.

Your solution doesn't do anything I'd expect someone wants that lib for, like merging in a map of classes.

I don't think this lib is the best pyre to die on to make a point I generally agree with.

Re: Evergreen: a React UI Framework built by Segment

#194
post #146

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 am on the same boat, hence why I am on Angular and Polymer side. Everything else that builds their little platform on top of the browser is not interesting to me.

That's radically inconsistent. Angular is not HTML, nor Javascript, rather it's its own thing -- precisely a "little platform on top of the web", to use your phrasing.

Re: Evergreen: a React UI Framework built by Segment

#195
post #69

Earlier quoted context omitted.

That's what I thought when I integrated Google Wave into my companies workflow... /s

Google is the exception that proves the rule.

How's your Silverlight app working out for you? Does it still connect to your WebObjects server?

Re: Evergreen: a React UI Framework built by Segment

#196
post #183
post #172

Earlier quoted context omitted.

> Apparently you haven't read my comment as you missed "which they are already developing." part. Apparently you haven't read my first comment either, since you can't tell the difference between "a spec is implemented" and "planning to implement a spec" which you obviously count as "a spec is implemented" for you or you would have refrained from making your first comment. And no, there is no polyfills for shadow DOM…

100% on mobile Web. Firefox already on beta. As for Edge it is already in development, and to be honest it doesn't matter with its insignificant market share. When Microsoft employees use only Chrome at BUILD to show Azure and .NET Core MVC features, the writing is on the wall how relevant the browser is on the market. Still you keep running away to clarify what "many browsers" means. Maybe it is my lack of native En…

> As for Edge it is already in development, and to be honest it doesn't matter with its insignificant market share.

Market shares are not the same across countries, clients or even industries. That's the first mistake you are making. If I develop a product, I target whatever browser my customers use, not some world wide statistic that has very little local significance.

You just don't get to ignore what goes against your point just to feel that you are winning an argument, that's childish.

> 100% on mobile Web.

Which is False, Firefox on Android doesn't support web components.

> Firefox already on beta.

Which doesn't matter if support has not shipped. "will ship" is not "has shipped". I am only interested in current support, as we speak, I was never talking about "will eventually ship" since I don't work with eventual features, obviously.

Re: Evergreen: a React UI Framework built by Segment

#197
post #174
post #165

Earlier quoted context omitted.

Edge is implementing (updated the roadmap), Firefox ships enabled WC's in closest release (it is already in the beta) I think Firefox 63 will ship in a week?. That leaves only IE11/Edge with polyfills.

> That leaves only IE11/Edge with polyfills. what polyfills are you talking about? And no, Polymer is not a polyfill for custom element. Please link me to a library that will polyfill the entire shadow DOM and Custom Element spec so that I can write the same code without polyfills on platforms that support both specs and only load the polyfills on platforms that do not.

https://github.com/webcomponents/webcomponentsjs - all frameworks use same polyfill.

https://github.com/vuejs/vue-web-component-wrapper

"You will also need the Shady DOM + Custom Elements polyfill." from Vue docs. Same polyfills are used by svelte etc.

Re: Evergreen: a React UI Framework built by Segment

#198
post #173
post #171

Earlier quoted context omitted.

Well, I mean, it's 1 week away from release... https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

Well you mean it's 1 week away from release in Edge as well? Give me an ETA for Edge.

Their roadmap was JUST updated, do probably few months.

Re: Evergreen: a React UI Framework built by Segment

#199
post #185
post #174

Earlier quoted context omitted.

> That leaves only IE11/Edge with polyfills. what polyfills are you talking about? And no, Polymer is not a polyfill for custom element. Please link me to a library that will polyfill the entire shadow DOM and Custom Element spec so that I can write the same code without polyfills on platforms that support both specs and only load the polyfills on platforms that do not.

https://github.com/WebComponents/webcomponentsjs Quote from the readme. " A suite of polyfills supporting the Web Components specs: Custom Elements v1: allows authors to define their own custom tags (spec, tutorial, polyfill). Shadow DOM v1: provides encapsulation by hiding DOM subtrees under shadow roots (spec, tutorial, shadydom polyfill, shadycss polyfill). "

.

Re: Evergreen: a React UI Framework built by Segment

#200
post #162
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?

I think rewriting UI systems every few years and reimplementing in various JS frameworks that come and go is a serious waste of manpower. I'd so wish people would embrace web components properly once and for all, with LitElement, Svelte or Stencil. This way we won't have to live with another framework-bootstrap clone again and again and everyone can contribute to one solution that will work with all JS frameworks.

Problem is, web components don't provide the same thing as frameworks like React. And the performance question still hasn't been solved.

React was released in 2013, has only had minor breaking chanhes since then, and doesn't show any signs of disappearing anytime soon.

Post reply on HN