> fast-anchor is a web component implementation of an HTML anchor element. Wait, what.... WHY? Can't you just use an a tag?
I was equally confused by fast-divider. I wonder what the rationale behind these were?
Microsoft Fast Design
91–100 of 216 posts
Re: Microsoft Fast Design
#92Kind of surprises me that Microsoft allowed this project to use Discord for external communication.
Teams doesn't have a free public mode at this time so it sounds like the best option to me. There are official Microsoft instances of Slack and Gitter as well and teams seem to be given a fair degree of freedom.
Re: Microsoft Fast Design
#93Possibly the best commercial for Microsoft is how ...fast... this site is. (clearly the pun was unavoidable, which is evident in their name selection)
Honestly, one of the quickest loading & changing sites I've seen, and gives HN a run for its money!
Re: Microsoft Fast Design
#94Have >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…
The template strings are sort of typed, using tagged template literals. These even come with editor support using extensions previously built for lit-html and the like.
You get compile-time checks for embedded JavaScript expressions. But you don't get checks for html tags and attributes. With JSX the TypeScript compiler checks JavaScript expressions as well as mismatched tags and attributes, all without any add-ons.
Re: Microsoft Fast Design
#95Have >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 Safari in spec talks. Libraries like LitElement have the concept of reflecting a property to an attribute and it's really easy to do so. Also, Chrome had a property explorer in dev tools that just got deprecated which also sucks.
3. Attributes are strings, yes, but you can also set properties on a component. Easy to have a setter and getter for a property (can easily be turned into a TS decorator) that just calls a render method on change, but again, the cost for attributeChangedCallback to serialize a primitive is very low. Passing objects should just be sent as a prop, but also, passing objects to child web components we've found is a bad habit. Often the props of an object should be spread (easy to make a directive of this in lit-html) over the props of the child and arrays typically easier to turn their contents into DOM nodes.
Also none of this takes into consideration of a web component using a state library like redux.
Re: Microsoft Fast Design
#96Earlier quoted context omitted.
Focus on Web Components and forget Fast you'll see the benefits then and then start looking around at other projects focusing on Web Components. The benefit is that you can have whatever frontend tech stack at your project, someone doing Vue another one in React.. another one in JQuery there's no limits.
Thanks I have asked another poster to fill me in because maybe I'm too old school and yelling at kids to get off my lawn. I might have to shut up now for a while until I run away and get back up to speed in this arena. But I have used react, vue, jquery, and my favourite which is just plain old JS and to me this is just generating templates with a different DOM structure and class semantics. IDK it just seems like th…
I'm in the same boat, I still like the plain old vanilla JS I do see the benefits of Typescript and all but I don't know I have been doing JS since I was 10 years old so I guess it's something that comes from my childhood haha. I just love JS in any fashion, it's a love relationship since the beginning and way back then I always saw that there was huge value around JS but never imagined back then that we would get to were we are today, back then Flash was the big deal and it was doing the more advanced functionality in the front-end could never imagined that Shockwave, Flash would all get basically banned due to security. Interesting turn around for JS and the open source nature it has always had since its infancy with the Mozilla Browser.
Re: Microsoft Fast Design
#97Have >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…
> the 3rd big gotcha of web components. Attributes are strings. You have to serialize and deserialize from strings. Sure you can listen to when they change via attributeChangedCallback and get immutability for free because of serialization, but that comes at a perf cost. for deeply nested objects, you have to serialize and deserialize from json.
In practice, most libraries built around web components only use attributes when serializing / deserializing HTML strings. When performing updates to existing DOM, it is very common for a library to use a corresponding property instead. This is very fast, supports all types of values, and many libraries enable users to think in terms of attributes while the library updates properties under the hood (conceptually similar to the React mental model).
Re: Microsoft Fast Design
#98Earlier quoted context omitted.
I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would y…
I'd say the important word there is "team", you use those libraries and frameworks because they are curated ways of doing what you want, reducing friction. If you are coding by yourself, you know everything about the codebase, and you focus on different trade-offs. In general those who use these frameworks are ok with adding build complexity if they allow to avoid, at least a little bit, problems that can come from l…
I understand the framework concept very well and have (oh god I hate this term) "spearheaded" multiple componentisation schemes over the years, to make code more reusable across teams, to reduce coding effort, to reduce expense for the business while improving the QA outcomes for the client etc. We standardised on frontend frameworks, set up and configured automated build systems way back when most web dev shops were still FTPing their shit up to servers, automated the task of installing dependencies and so forth. So I honestly get the value of frameworks and systems in a general context, I know what frameworks are...
It's more about I guess what context is this framework more applicable in? What does this exactly "standardise" - given that "standardisation" frequently just means "now we have x number of frameworks to support instead of x - 1)"
I still have to train my team to structure their components differently than they currently do, to refactor existing systems away from their current frameworks to this one, a significant investment in time and energy... so... Why? Why is this one the ultimate framework for "web components" (which used to just be called "semantic html")?
Re: Microsoft Fast Design
#99Earlier quoted context omitted.
Thanks I have asked another poster to fill me in because maybe I'm too old school and yelling at kids to get off my lawn. I might have to shut up now for a while until I run away and get back up to speed in this arena. But I have used react, vue, jquery, and my favourite which is just plain old JS and to me this is just generating templates with a different DOM structure and class semantics. IDK it just seems like th…
I'm in the same boat, I still like the plain old vanilla JS I do see the benefits of Typescript and all but I don't know I have been doing JS since I was 10 years old so I guess it's something that comes from my childhood haha. I just love JS in any fashion, it's a love relationship since the beginning and way back then I always saw that there was huge value around JS but never imagined back then that we would get to…
I started coding BASIC in the late 80s and built websites before CSS and JS was a thing in addition to just coding stuff in whatever language took my fancy to solve whatever whimsical project I had that day, I had a particular affinity for optimising getpixel and putpixel routines in ASM when you could still directly address video memory.
On the one hand this is great because programming is in my bones and I know whatever comes along I'll figure out.
It's also terrible because sometimes something that looks like a rebranded version of what I already know is actually a fantastic new and easier way of doing things, and it's really easy to miss something great.
This just doesn't feel like something great, it just feels like another branded corporate way to structure code that there's dozens of examples of already, it's not an improvement just an alternative, if that makes sense.
Re: Microsoft Fast Design
#100Earlier quoted context omitted.
Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)
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 deprecated, and v0 of another one is also already deprecated.
- The standards provide a verbose, error-prone imperative API that leaks implementation details left and right
- 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". And if you look at the frameworks, they try to not even compile/transpile down to this API
- Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else
- You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components
- They break accessibility
- They don't work without JavaScript
- They cannot be rendered server-side
- They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent)
- And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks