161–170 of 216 posts
And here's a ASP.NET Community Standup session that goes through the FAST framework by one of the core developers: https://www.youtube.com/watch?v=sYTH_xYH3iA
I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines. Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a element. In this situation a shadowroot does nothing to help. All it me…
Microsoft recently wrote a blog post saying they would be rallying around a single component library. [1] > What’s in a name? A lot it turns out. And we have a lot of them. Too many? We hear you and agree. That’s one of the key reasons we’re simplifying our story. To collectively rally around a single UI library for our web components—Fluent UI. Yet, here we are, and they've released another component library. They r…
"This package has been moved to FluentUI and has been renamed to @fluentui/web-components"
Earlier quoted context omitted.
I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and…
Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours. Reality: - WebComponents is a collection of 4 web standards, one of them is already deprec…
> one of them is already deprecated, and v0 of another one is also already deprecated.
Sometimes you swing and you miss. Instead of moving forward with the initial design, they iterated and improved it. That’s how software works.
> The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API".
It’s not because the API is bad, it’s because the term “component” has become ubiquitous with framework components and that’s caused A lot of confusion. Web components are lower level than React/Vue components by design, but people hear “component” and have the same expectations. Having worked with web components almost exclusively for more than a year, I feel like the APIs are thought out fairly well. They’re not perfect, but they are good and there’s momentum to continue improving them (e.g. declarative shadow DOMs).
> You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events
It’s still pretty new, but it’s coming. These things take time to get right and become supported by all browsers. Search for form-associated custom elements, for example.
> They break accessibility
Only if misused, which is also possible to do in any framework or even plain HTML.
> They don't work without JavaScript
I’m so tired of hearing this. How well does your React/Vue/Angular/Alpine/jQuery-based app work without JavaScript?
Browsing the web in 2020 with JavaScript disabled is like driving your car down the road without any wheels. Things just aren’t going to work right. The experience will be inferior even the when effort is made, but IMO it’s not reasonable to expect developers to accommodate the > They cannot be rendered server-side
I’m no expert in SSR, but Stencil offers some examples of how to achieve this with their compiler, which is a joy to use. [1]
> They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events
It wouldn’t make sense to provide an “onclick” style prop for custom events, but you can attach listeners with `addEventListener` like any other event. The syntax is identical.
> And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public
I’m a proponent and I’m happy to discuss these things in public.
It seems, however, there are a lot of misconceptions about the underlying specs. Maybe that’s deserved — it took a long time for web components to get this far and it’s been a bumpy road. That doesn’t mean it hasn’t gotten much better.
I’d encourage anyone who hasn’t explored custom elements, shadow DOM, et al recently to take another look. We’re building some awesome things with them!
Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.
The default design looks awful, especially on phone. I’m not a frontend dev, but I don’t see any reason why would I use this instead of, for example, Bootstrap for sideprojects. Can some FE comment on the project usefulness? Why go with Fast?
The API is easier, there’s less markup, and less room for error. A well-designed component also bakes in accessibility and provides encapsulation so your own styles and behaviors won’t leak in.
It’s a way better dev experience.
1. https://www.reddit.com/r/web_design/comments/hypdzz/comment/...
For all the comments asking what's the difference between this and Bootstrap, Ant, jQuery UI, React, Vue and friends: Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard _Web Components_. The important word here is Web Components, which are like React or Vue components but using only standard HTML and JavaScript (no frameworks). I guess y…
So, like https://medium.com/ing-blog/ing-open-sources-lion-a-library-... ?
Earlier quoted context omitted.
I love Sciter and it is pretty amazing for what it does, but I still wouldn’t use it to share internal web component libraries within my own company, never mind some other 3rd party. Sciter unfortunately uses it’s own dialect of JavaScript and CSS which might not be compliant with browser JavaScript engines. I really wish Sciter would move to some other commonly used JS engine and get rid of TIScript, then I would be…
That's just an illustration of how it can be done otherwise. The only non-standard thing there is that CSS glue construct: selector { aspect: Func url(script.js); } It tells that as soon as element matching that selector will appear in the DOM it will have Func() called (from script.js). No complex abstractions are required. "to share internal web component libraries within my own company, never mind some other 3rd p…
Sciter’s approach is pretty much the same approach used by web components (combining css/html/js to a single reuseable element). Unfortunately it isn’t 100% compliant with browser based web components and hence Sciter based widget libraries can not be used for web sites or vice versa.
Have >3 years of experience working with web components full time. 1) Their templating library has a learning curve. It's not quite like svelte, nor like JSX. If you have templates as strings that aren't typechecked, it makes it really hard to work on large code bases where the components are built by someone else and you're the consumer. I remember breaking powerbi.com due to missing > in an angular template that en…
Heyo, been working with WCs full time as well: 1. Libraries like lit-html have syntax highlighting and tooling to do type checking. For the developer: https://marketplace.visualstudio.com/items?itemName=runem.li... For node: https://www.npmjs.com/package/lit-analyzer For other Web Component libraries: https://www.npmjs.com/package/web-component-analyzer 2. Totally agree on slots. They suck and were hamstringed by Saf…
Things might have changed, but it’s easier to recreate web component features in JS than it is to convince people to use a two-way object-oriented API that’s mostly stringly-typed unless using JS. If the problem we’re solving is we want a faster web, bake in and follow top JS libraries such that how they render is part of the spec. I’d be very interested to see what a React scheduler would look like if implemented in C++ on top of the browser’s scheduler.
I really like parts of web components, but... I’d also like to see a Chrome experiment where JSX and TS is baked into the browser to natively solve the “stringly-typed” problem the Web Components spec has. Maybe that’s going too far, or maybe we’ll end up shipping these features as “modules” that can be toggled on if compatible.
I think it would help the web move to where developers are to include native understanding and support for semi-“proprietary” solutions given widespread adoption. For example, ES Modules are great, yes, until you have to start building your own vendor modules because somebody shipped a Webpack module as dist, for example.
Just as Babel lets us try new syntax earlier, so too could third-party libraries popularize new browser-native APIs as loadable modules, maybe? (My assumption being that integrating with existing C++ is cheaper than writing scheduling and DOM update logic in JS, but the JS is cheaper to ship, so some kind of browser-module-loading-with-JS-fallback is the only way we can have performance wins for existing approaches while still shipping new versions of features given how fast JS syntax and preferences change?)