I don't think I would support this in an engineering organization. There are so many people focused on solving these problems, that I believe not being able to make an existing solution work well is for lack of trying. I'm a bit out of the loop on React, however if I had to guess Segment would be better off investing in adapting an existing framework, no matter how nice this one might be.
Evergreen: a React UI Framework built by Segment
281–290 of 309 posts
Re: Evergreen: a React UI Framework built by Segment
#282Earlier quoted context omitted.
Not at all true. Where's your onClick? People want their buttons to actually do things, right? With Web Components you're back in the land of saving element references, querySelector, addEventListener, and string-only attributes. It sucks. If you want something more like what React provides, where attributes (props) can be objects, functions, other React elements, etc. then you need to use a library (e.g. Polymer) th…
Nope, you're wrong. onClick works with web components just the same way as it does with any other element. Proof: https://codesandbox.io/s/j3jmkr98pw
That uses React to attach onClick, so obviously yes. I'm saying without React. You said:
> The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `` they would do ``.
If you're not using React, you obviously can't do `onClick={...some function here...}` with Web Components, you have to use the shitty DOM APIs.
Re: Evergreen: a React UI Framework built by Segment
#283Earlier quoted context omitted.
Not at all true. Where's your onClick? People want their buttons to actually do things, right? With Web Components you're back in the land of saving element references, querySelector, addEventListener, and string-only attributes. It sucks. If you want something more like what React provides, where attributes (props) can be objects, functions, other React elements, etc. then you need to use a library (e.g. Polymer) th…
Of course you can set props on a WC, it's just a DOM node. You can do everything you can do with any other standard node + exposed API. You could use jsx/vdom any other solution to set up props/events. IMO saying 60kb of react+vdom code vs 6kb of templating library that builds on top of template literals is equally non-standard is not a fair comparison. https://custom-elements-everywhere.com/
I realize you can set properties, obviously. Those are not the same as using attributes, which is what React's props are more equivalent to. e.g. you can't do . So using it does indeed suck the same way using normal DOM elements sucks: you need a reference to the created node, addEventListener, etc.
That's what makes the grandparent's statement incorrect:
> The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of `` they would do ``. That's it.
^ wrong.
Re: Evergreen: a React UI Framework built by Segment
#284Earlier quoted context omitted.
Of course you can set props on a WC, it's just a DOM node. You can do everything you can do with any other standard node + exposed API. You could use jsx/vdom any other solution to set up props/events. IMO saying 60kb of react+vdom code vs 6kb of templating library that builds on top of template literals is equally non-standard is not a fair comparison. https://custom-elements-everywhere.com/
I realize you can set properties, obviously. Those are not the same as using attributes, which is what React's props are more equivalent to. e.g. you can't do . So using it does indeed suck the same way using normal DOM elements sucks: you need a reference to the created node, addEventListener, etc. That's what makes the grandparent's statement incorrect: > The only difference between if this were a web component vs…
You can with lit-html/stencil, but yes you need something to take care of that for you, which is very small dependancy. WC's are NOT supposed to be consumed directly unless you do very simple things.
Re: Evergreen: a React UI Framework built by Segment
#285Earlier quoted context omitted.
https://stefankrause.net/js-frameworks-benchmark8/table.html - thats old lit release there vs react 16 (react pre 16 would be slower and everyone agrees its generally fast already), on slack channel I believe I saw newer release benchmarks that are better (it also depends at which specific test you look at). New version of repeat is interesting: https://slack-files.com/T03PF4L4C-FCY51FZAB-c2fcf32931
I compared my usual candidates: vue, inferno, Surplus and vanillajs, and lit-html was dead last overall in almost every category. Also slower than Preact now that I checked, so I'm not sure that performance benefits are one of lit-html's unique strengths.
There you go, https://rawgit.com/krausest/js-framework-benchmark/master/we..., much faster than vue and react (still not inferno speed yet, but the gap is closing).
Re: Evergreen: a React UI Framework built by Segment
#286Earlier quoted context omitted.
I compared my usual candidates: vue, inferno, Surplus and vanillajs, and lit-html was dead last overall in almost every category. Also slower than Preact now that I checked, so I'm not sure that performance benefits are one of lit-html's unique strengths.
There you go, https://rawgit.com/krausest/js-framework-benchmark/master/we... , much faster than vue and react (still not inferno speed yet, but the gap is closing).
Not bad. I'm always amazed at Surplus though, that's the one to beat!
Re: Evergreen: a React UI Framework built by Segment
#287Earlier quoted context omitted.
Nope, you're wrong. onClick works with web components just the same way as it does with any other element. Proof: https://codesandbox.io/s/j3jmkr98pw
That uses React to attach onClick, so obviously yes. I'm saying without React. You said: > The only difference between if this were a web component vs a React component is that the consumer would not capitalize the name. Instead of ` ` they would do ` `. If you're not using React, you obviously can't do `onClick={...some function here...}` with Web Components, you have to use the shitty DOM APIs.
I guess I see what you're saying that web components can seem be consumed as expected from a React app. I thought we were talking about not using React at all.
But I would expect this still would not work as expected with props like `children` or other props that accept React elements. It seems like the web component would be expecting Node instances, not React elements. Since components can decide whether or not to render their children, they wouldn't be backed by Nodes yet when the web component received them. So it seems like it'd have to know whether it's dealing with React and use ReactDOM.render directly.
Re: Evergreen: a React UI Framework built by Segment
#288Issue #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 indica…
Issue #4: Go to the Tables page, click a header on the example table, the entire page disappears.
Re: Evergreen: a React UI Framework built by Segment
#289Earlier quoted context omitted.
There is 100% support on the mobile web across Safari and Chrome.
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.
Re: Evergreen: a React UI Framework built by Segment
#290Earlier quoted context omitted.
React is fast. If you are not experienced in react you'll make a mess because they work against its principles. To me the Reddit web app is fast, the show part I think is the server side.
The new Reddit design is often much slower loading the first time than the old one. It's performant after that, but that first load is annoying.
I just had to come back to this comment after testing in a couple of browsers, focusing on Safari and Chrome.
Going to https://www.reddit.com/r/whatisthisthing/comments/9oz5sa/wha... and scrolling is OK in Safari but actually pretty laggy compared to old mode. It's definitely not how a modern web site should perform. Testing with Chrome, it was fast in the beginning, but if you scroll up and down for about 15-20 seconds, CPU load goes up and my laptops fan start spinning.
So no, I do not believe reddit's new design is "performant" at all.
One has to wonder - if Reddit's engineers can't get React right (I'm sure they hire smart people), is it really not a problem with React in the end?