201–210 of 216 posts
For a non developer like me, Is it any different from Ant Design ( https://ant.design/ )? Also, almost every company I worked with (> 500 employees), eventually built their own UI components. And in every company, developers seldom use these, always customize or use something else. Which brings the question - Why do we invest (internally) and open source components? Whats the value?
Howdy! I'm the architecture lead on FAST at Microsoft. There's a great conversation here with lots of questions, so I thought I would chime in and try to clarify a few things. The first point of note is that FAST is built on Web Component standards. I see a number of comments that indicate some folks aren't familiar with Web Components. So, let me give a brief explanation. First, the term "Web Components" is an umbre…
Ok, let's get on to a few other items mentioned below... * Being Dependent on Slots - Web components don't need to use slots and neither does FAST. When slots are needed, FAST provides facilities to respond to changes in slots and respond to changes in slotted child attributes. The render system is reactive in nature and specifically has features that enable rendering around these slot scenarios. * Attributes are Str…
I mainly develop using ASP.NET Core, with some vanilla JS as needed.
I'm just starting to hear about Web Components, and have heard that you can't use them with SSR because of the shadow DOM. I don't actually know what shadow DOM is, but does this mean no Web Components work with SSR, or that some don't? What precisely is the issue?
Earlier quoted context omitted.
Ok, let's get on to a few other items mentioned below... * Being Dependent on Slots - Web components don't need to use slots and neither does FAST. When slots are needed, FAST provides facilities to respond to changes in slots and respond to changes in slotted child attributes. The render system is reactive in nature and specifically has features that enable rendering around these slot scenarios. * Attributes are Str…
> You Can't SSR a Web Component - Strictly speaking, this is not quite correct. Custom elements are just html tags and can be rendered by any server framework. If you want to SSR the shadow DOM itself, that's possible by inlining the template and using a small bit of JS to attach the shadow after streaming the template in. That said, as mentioned, we are working on declarative shadow dom, which will provide the W3C s…
> It's a common myth that you can't server side render Web Components. Turns out you can if you look in the right place.
https://dev.to/steveblue/server-side-rendering-web-component...
The article mentions a few libraries for this purpose.
- Vaadin Router - https://vaadin.com/router
- SkateJS - https://skatejs.netlify.app/
- SkateJS: Web component server-side rendering - https://github.com/skatejs/skatejs/tree/master/packages/ssr
This latter looks good, I hadn't seen that before.
As a possible successor to React, Vue, et al, there's a wide range of functionality expected of Web Components. Server-side rendering of shadow DOM (I don't know what that really means, but) seems to be one of the tough questions yet to find a definitive answer.
Earlier quoted context omitted.
They're not different from built-in elements and don't need special treatment. The way that frameworks that work well with web components do it is be not giving special treatment to things. Vue, Angular, and lit-html all treat built-ins and custom elements then same, and they have different syntax for setting attributes and properties. React treats elements different from components and sets properties on React compo…
They're different from built-in elements at least in the fact that they're not built-in - that is the problem with React, which works with a list of built-in components that are treated differently from React components. Which means React needs special treatment for Web Components. Whether React should or should not be doing that is irrelevant; what's relevant is that as a developer, you need to be aware that you can…
You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing.
This is fundamentally React's problem. It's the only major framework to even have issues here.
Earlier quoted context omitted.
It's slow and un usable , not unstable. The one benefit of WC is that it's going to be stable for the next hundred years, just like still works in 2020. It's unusable because of all the boilerplate it requires and doesn't provide the most important thing of all which is data binding. So you have to bring in some other support code to do data binding such as the Rx/Observables or Redux patterns, but since this can't b…
You'd be surprised but in general this element.html = "..."; is faster then ReactDOM.render(vdom,dom); at least for initial DOM tree population. There are many reasons for that. `element.html =` is implemented as single update transaction, JS function call is significantly more expensive then HTML parsing of single element, etc.
Earlier quoted context omitted.
They're different from built-in elements at least in the fact that they're not built-in - that is the problem with React, which works with a list of built-in components that are treated differently from React components. Which means React needs special treatment for Web Components. Whether React should or should not be doing that is irrelevant; what's relevant is that as a developer, you need to be aware that you can…
That seems a rather silly distinction to me: "They're a special case because they're not on React's list of special cases". You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing. This is fundamentally React's problem. It's the only major framework to even have issues here.
Earlier quoted context omitted.
That seems a rather silly distinction to me: "They're a special case because they're not on React's list of special cases". You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing. This is fundamentally React's problem. It's the only major framework to even have issues here.
Again: I don't care who's to "blame". I care about whether I can just use Web Components in any web framework, which is not the case.
React just had a more complicated way of setting properties. Entirely due to React's choices.
Earlier quoted context omitted.
You'd be surprised but in general this element.html = "..."; is faster then ReactDOM.render(vdom,dom); at least for initial DOM tree population. There are many reasons for that. `element.html =` is implemented as single update transaction, JS function call is significantly more expensive then HTML parsing of single element, etc.
This is thanks to how extremely optimized V8 and Chrome is for string manipulation. It is faster in the small cases but doesn't scale to, say, 10000 rows in a table. Then it becomes several orders of magnitude slower than React and virtual DOM. On low memory devices it could crash and never render. This should just be kept in mind when choosing WCs. WCs are perfectly fine for the Settings page in Edge, for example.
JS code is always slower than native html parsing code. No matter what.
"10000 rows in a table"
This:
element.html = 10000 times "...";
element.appendNode( document.createElement("tr") ... ); // ReactJS code
array.forEach(func) is 30 times slower than plain for/at loop. Because of function call.
Earlier quoted context omitted.
Not quite, Ionic Stencil is library to helps build webcomponents. Since fast.design are webcomponents, they can be used in any with any framework, no wrapping required.
Web Components can't be directly used in React due to these limitations documented at https://custom-elements-everywhere.com/ Handling data React passes all data to Custom Elements in the form of HTML attributes. For primitive data this is fine, but the system breaks down when passing rich data, like objects or arrays. In these instances you end up with stringified values like some-attr="[object Object]" which can't…
Earlier quoted context omitted.
Again: I don't care who's to "blame". I care about whether I can just use Web Components in any web framework, which is not the case.
The do work in React. It's hard for them not to, since they're just elements. React just had a more complicated way of setting properties. Entirely due to React's choices.
tl;dr you'll still be doing the wrapping in practice.