[HN Gopher] Microsoft Fast Design
___________________________________________________________________
Microsoft Fast Design
Author : no_wizard
Score : 381 points
Date : 2020-08-07 15:55 UTC (7 hours ago)
(HTM) web link (www.fast.design)
(TXT) w3m dump (www.fast.design)
| chrisweekly wrote:
| Web Components, as a standard, remain problematic. Among other
| things, they fail to address the critical need for server-side
| rendering.
| ramon wrote:
| I don't think that was the objetive of Web Components at all
| but to really create open standards around what React started a
| long time ago. Server-side rendering is not going away ever,
| there will always be a way to optimize things and to do tree-
| shaking and all so don't think that a new technology replaces
| everything else the rest of the eco-system will still remain
| with a clear purpose. You can do a small little project without
| builds and all but every "real" project will still need a build
| process in the end this concept was inherited from Continuous
| Integration and it's not going away.
| jjcm wrote:
| 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 <slot> element. In
| this situation a shadowroot does nothing to help. All it means is
| instead of just creating children for the element, you have to
| create them and add "slot='item'" to all of them. Shadowroots are
| great when you need encapsulation of styles or static non-content
| UI, but with this outer element neither of those are true. There
| isn't any additional UI, nor styles. This is something I see a
| lot in lazy libraries - they automatically create a separate dom
| tree even if it isn't needed whatsoever.
|
| This tells me either the library requires this every time (going
| against the "lightweight / low memory" motto), or the developer
| for this one didn't have enough understanding of when to use
| shadowroots.
|
| That's not to say this is all bad though - their design system
| tokens are really nice and provide a lot of flexibility. I'll
| probably emulate a lot of them for the next webcomponent based
| design system I'm working on. Their algorithmic color palettes
| are interesting, but so far I've never found a solid algorithmic
| color generator - color is simply too tied to trends and too
| subjective to be algorithmically made. Curious to see it work in
| practice, and a shame they don't provide examples of it.
| infogulch wrote:
| To clear my understanding of your first statement, you're
| saying that their "lightweight / low memory" claim is
| invalidated by components having one unnecessary level of
| nesting in DOM?
| jsf01 wrote:
| No. They're saying that it's creating an entirely separate
| DOM tree unnecessarily by using shadow DOM where it isn't
| needed.
|
| On a related note, I'm curious if anyone has a benchmark
| comparing performance and memory consumption when attaching a
| shadow root vs not.
| WorldMaker wrote:
| > Shadowroots are great when you need encapsulation of styles
| or static non-content UI, but with this outer element neither
| of those are true. There isn't any additional UI, nor styles.
|
| To my understanding of these components, because they are meant
| to be styled by the user or a downstream design system the
| component authors don't know ahead of time where style
| encapsulation needs to happen, so this approach makes sense for
| that.
| jumby wrote:
| Another funny thing with the accordion component: the icons for
| expand and collapse seem to my mind to be reversed (- for
| expand and + for collapse)?
| pearjuice wrote:
| Kind of surprises me that Microsoft allowed this project to use
| Discord for external communication.
| throwaways885 wrote:
| Why not? It's incredibly popular.
| CuddleBunny wrote:
| 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.
| badrchoubai wrote:
| I really love watching companies adopt the Web Components
| standard, Apple's adoption of it for building Apple Music's web
| player got me interested in learning them.
| jhardy54 wrote:
| This is great, I was hoping for another way to build websites
| that are completely broken with JavaScript disabled. Try
| selecting links on the sidebar or even just going to
| https://fast.design and see how broken it is.
|
| Sweet.
| megaman821 wrote:
| It looks like LitElement but more TypeScript first. The
| decorators do make it a bit more approachable for me.
| spankalee wrote:
| LitElement is written in TypeScript so has great typings for
| all APIs, and TypeScript (and Babel 7) decorators. There's also
| a template type-checker CLI, compiler plugin, and VS Code
| extension: https://github.com/runem/lit-analyzer
|
| The big difference from Fast is that LitElement's render()
| method is an instance method, so it can access any state with
| `this.` and any properties and methods it uses can be
| overridden. But it's all just as declarative:
| import { LitElement, customElement, property, html } from 'lit-
| element'; @customElement('hello-world')
| export class HelloWorldElement extends LitElement {
| @property() name: string = 'World';
| render() { return html` <h1>Hello
| ${this.name}</h1> `; } }
|
| We have decorators for reactive properties, registering
| elements, shadow root queries, and adding event listener
| options to methods: https://lit-element.polymer-
| project.org/guide/decorators
| megaman821 wrote:
| Yeah, LitElement definitely has a cleaner render template.
| How would one do a computed property in LitElement?
| spankalee wrote:
| You really don't need any special for a computed property.
| I'd start with a simple getter: class
| MyElement extends LitElement { @property() value:
| number = 42; get valueSquared() {
| return this.value ** 2; } }
|
| If the value is expensive to compute you can memoize it in
| the getter, or set it in update.
| bengale wrote:
| I don't know if i'm missing something, but this seems crap. Its
| really ugly, and there isnt a lot there. Why wouldn't I just use
| BlueprintJs?
| [deleted]
| ggregoire wrote:
| 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 you could even add Bootstrap on top of Fast.
|
| Some references:
|
| - https://en.wikipedia.org/wiki/Web_Components
|
| - https://developer.mozilla.org/en-US/docs/Web/Web_Components
|
| - https://developers.google.com/web/fundamentals/web-component...
|
| - https://caniuse.com/#search=components
|
| Also worth reading: https://dev.to/richharris/why-i-don-t-use-
| web-components-2ci... (discussion on HN:
| https://news.ycombinator.com/item?id=20232628)
| Vinnl wrote:
| > The important word here is Web Components, which is like
| React or Vue components but using only standard HTML and
| JavaScript (no frameworks).
|
| I wouldn't say that - Web Components (by themselves) do not
| allow you to write your view as a function of application
| state, which is the main draw of at least React.
|
| But the initial use case of Web Components is to create a
| standard that allows developers to iterate on the web's built-
| in components (inputs, date pickers, etc.) without having to
| wait on the standards track, and FAST appears to intend to
| provide a number of such components.
|
| (And there is more to such components than just styling (which
| is what Bootstrap provides) - it's behaviour, usability by
| people reliant on e.g. screen readers, an API to access its
| data, etc.
| sroussey wrote:
| Ionic Stencil let's you wrap webcomponents and turn them into
| React, Vue, or Angular components. MS should use that or do
| something of a similar nature. Otherwise there is a impedance
| mismatch between this and what most or used to.
| helixten wrote:
| 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.
| turadg wrote:
| 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 actually be used.
|
| _Handling events_ Because React implements its own
| synthetic event system, it cannot listen for DOM events
| coming from Custom Elements without the use of a
| workaround. Developers will need to reference their
| Custom Elements using a ref and manually attach event
| listeners with addEventListener. This makes working with
| Custom Elements cumbersome.
|
| Stencil provides wrapping to circumvent these
| limitations. https://stenciljs.com/docs/react
| Vinnl wrote:
| > they can be used in any with any framework, no wrapping
| required.
|
| That's the selling point, but is not quite true. At least
| a while ago there was still some ceremony needed at least
| in React. You could say that that's React's fault, but it
| doesn't really matter whose fault it is - Web Components
| are different from standard DOM elements, and thus need
| special treatment from frameworks that interact with
| standard DOM elements.
| sroussey wrote:
| Ah, thanks for the clarification. I know the developer of
| Framework7.io has a tool to take his components (not
| webcomponents though) and make them into React/Svelte/Vue
| native ones. So I kinda mixed the two tools together in
| my head.
| pc86 wrote:
| _That 's FAST._
| Udik wrote:
| > but using only standard HTML and JavaScript (no frameworks).
|
| Sounds like they ship a framework with the browser and call it
| "standard". Given that the size of a UI components framework is
| tiny anyway (3kb for preact) I'm not sure it's such a
| revolution.
|
| I'm open to hearing alternative takes on this though.
| lucasmullens wrote:
| If all the open source components I used all used preact, I
| wouldn't be concerned about the 3kb. But if each component
| author uses a different framework or even a different version
| of a framework, it quickly becomes something like 3kb *
| number of components.
| Udik wrote:
| True, but what I meant to say is that there is nothing
| revolutionary. It's not providing capabilities that we
| didn't have before. It's simply establishing a standard for
| a tiny subset of what a modern web framework does- roughly
| equivalent to those 3kb of code- by doing the equivalent of
| incorporating it natively inside the browser.
|
| Yes, now you can use components without a framework (you
| could use them without a build step also before). But if
| you want to do anything more complex than a static page
| with jquery, you still need both.
|
| To me it feels like the dream of 2005. It's cool, but we've
| been able to do the same for at least ten years at this
| point, and with the tools of our choice.
| rictic wrote:
| The big thing web components solve is interoperability.
| How do you use a preact component inside an angular app?
| How do you use an angular component inside a vue app?
|
| Web components are the solution. No matter what library
| or framework or whatever that you're using, you can
| render a <div> so you can render a <my-component>. That
| combined with shadow dom means that the element's
| internals and its styles are encapsulated, so that you
| can drop it into a page and it won't mess up the rest of
| the page and the page can't mess it up.
|
| This is particularly valuable for a design system,
| because a company will have a design and want their web
| properties to look consistent, but they'll have one app
| written with angular, and another couple with react, and
| a few ancient apps written with jquery. You could either
| convert _everything_ to the latest and greatest thing, or
| you could write your design system with web components,
| and it'll work everywhere.
| Someone wrote:
| So, like https://medium.com/ing-blog/ing-open-sources-lion-a-
| library-...?
| CuddleBunny wrote:
| The difference is that FAST is NOT a component library. It is a
| tool for building component libraries. The fast-components
| package is a showcase of what this library is capable of. You
| could use FAST to create web component libraries that consume
| bootstrap styles if you want. Microsoft is using this same base
| to write web components for Fluent UI (previously Office
| Fabric): https://www.npmjs.com/package/@fluentui/web-components
| reaperducer wrote:
| So, is this Microsoft's iteration of a more modern jQuery?
|
| Forgive me if I don't get what's happening here. The coffee maker
| broke last night.
| dynamite-ready wrote:
| At first glance, while the intro tries to differentiate the
| product from Fluent UI, I doubt anyone, even the most
| enthusiastic devotees, would read this...
|
| "Have you ever needed a reusable set of UI components that you
| could drop into your app and have an amazing experience? That's
| FAST."
|
| ...and think 'That's FAST'. They'd immediately think "That's
| Fabric (or Fluent)".
| andybak wrote:
| Is it just me or is the first thing you want to to see and try
| the damn things out?
|
| Ctrl+F "Demo" - nope.
|
| I think I found them eventually under "Component Explorer" - but
| that's in the secondary nav and not in the main menu.
| mark_l_watson wrote:
| I need to check this out. I have been using Bootstrap for years,
| and would like to try something new. I am not a very good front
| end developer, even though my https://markwatson.com site is now
| about 27 years old.
|
| I want something batteries included.
| qppo wrote:
| The "fast slider" is a perfect example of how animations make
| something perceptually slower, and might even be problematic as
| it implies the underlying value change is lagging behind the UI
| update.
| ourcat wrote:
| While sliding it from 0% to 100%, the 'thumb cursor' reaches
| 100% before the mouse pointer does, after some strange
| animation 'jumps' which have no bearing on the step value
| setting.
|
| Also, clicking anywhere on the bar doesn't set the slider to
| the centre of the click. They don't appear to be making the
| correct calculations based on Bounding Client Rects and Offset
| widths.
| dsego wrote:
| The slider thing is horrible, it animates while dragging so it
| looks like it's lagging behind the cursor.
| tehbeard wrote:
| That Slider's unusable on mobile. Seems to just be click for a
| value, hope you don't need to make a small tweak.
| ramon wrote:
| I was looking at the code it looks optimized, will do a couple of
| tests later maybe combining this as the main webcomponent
| controller with something like tailwind css makes sense, but just
| using this plain look and feel I don't think it's viable at this
| moment but it's a good structural start I would say. Was looking
| forward to do this with lit so maybe I might test this and see
| how the code looks, from a code output perspective it looks
| promising let us see this with something like snowpack. Till now
| Lit looks a lot easier to use and all let us see how it goes.
| eimg wrote:
| To my understanding, the point of this system is not actually how
| its default component looks or how rich the default components
| set are. It's to provide a framework to create Custom HTML
| Elements (which are browser native?) that we can re-use across
| projects with different front-end frameworks.
|
| e.g., Creating a React Button component using Fast Button like
| this:
|
| `const ReactButton = () => <fast-button>Button</fast-button>`
| trenchgun wrote:
| That is some seriously cheesy but brilliant copywriting!
| r-w wrote:
| For anyone who would like to take a look at the code for the
| respective packages, here it is:
| https://github.com/microsoft/fast/tree/master/packages/web-c...
| Datsundere wrote:
| There are plenty of these libraries. Can someone tackle the hot
| mess css is? Give me one way of doing things. Css breaks do much
| shit for me to the point where I don't want to code
| crooked-v wrote:
| If you use React, you might like Rebass
| (https://rebassjs.org/getting-started), which turns the most
| common CSS attributes into component props with assorted built-
| in functionality for common theming and media queries, or
| Emotion (https://emotion.sh/docs/introduction), which lets you
| composably define CSS per component that automatically gets
| scoped to that component only. Both are designed in a way that
| still render efficiently, such as turning static CSS rules into
| statically-defined bundles and only swapping out the dynamic
| bits on the fly.
| MR4D wrote:
| Possibly 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!
| azinman2 wrote:
| I find it hilarious that they put a dark mode toggle in the
| corner (why would I want this on a per-website basis?) that
| doesn't even change the rendering of their sample components (the
| only reason I can think why that would be useful).
| ggregoire wrote:
| > I find it hilarious that they put a dark mode toggle in the
| corner (why would I want this on a per-website basis?)
|
| They detect your OS preference and display their light/dark
| style automatically based on that [1]. The toggle is just there
| if you wanna switch it manually. My Mac is in dark mode but I
| usually prefer reading docs in light mode, so that toggle is
| handy.
|
| Agree that it should update the background of the examples tho.
| Probably just a bug or something they didn't think about.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/pref...
| azinman2 wrote:
| If that's the case then I think you should take your Mac out
| of dark mode. If we have to put it in every app and webpage
| in a non-standard way, then that suggests that dark mode
| itself is broken.
|
| That it doesn't change the example on the web page seems like
| a giant oversight, or a rendering error on Safari.
| mishkovski wrote:
| It looks like alternative for https://material.io/
| unnouinceput wrote:
| I like their transparent implementation. Went to text-area
| expecting ...something else, but I got Microsoft instead
| -\\_(tsu)_/-
|
| Is this a pre-pre alpha preview of the preview? Because it feels
| like
| [deleted]
| timvisee wrote:
| Took a quick look: It has limited components. It isn't fast on my
| mobile device. Some components appear to be broken. Why would I
| ever use this?
| mey wrote:
| Sliders and radio buttons do not seem to work on Firefox for
| Android nightly build.
| GrayShade wrote:
| Neither do they seem to work in desktop Nightly.
| XCSme wrote:
| Agree, UI and UX is really bad for the components demo, but I
| think their goal is not to be an UI framework, but a step
| before that? I am very confused about what they are trying to
| achieve and how. I personally that think this project has no
| future.
| the-dude wrote:
| And I was thinking they bought this for $1.3bn in 2008 :
| https://searchengineland.com/microsoft-to-buy-fast-search-fo...
| d0m wrote:
| There are many design issues with their website which IMHO don't
| provide great confidence in using their components
| [deleted]
| pjmlp wrote:
| For those that miss it, the dark mode can be turned off on the
| top right corner.
| darepublic wrote:
| On mobile Firefox the side menu is quite janky
| su8898 wrote:
| Not sure if it's just me but I kind of feel like these components
| are not very polished - at least not to the point of
| Bootstrap/AntDesign. May be it's the square unrounded borders or
| may be it's just the way the demo components are presented.
| rwieruch wrote:
| For anyone who is interested in seeing a practical example of
| using web components in a library like React
| https://www.robinwieruch.de/react-web-components Last year I
| worked for a large company which had Angular and React teams, so
| the idea was to use web components for their UI library and then
| just let the angular and react teams write wrapper for these
| components. I had to prototype how to use web components in
| react.
| sholladay wrote:
| 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 really seem to love these things. It's not entirely clear
| what the difference is between them.
|
| 1: https://developer.microsoft.com/en-us/office/blogs/ui-
| fabric...
| fassssst wrote:
| Fluent UI is the one the Office team is standardizing on.
|
| FAST is from the Edge team and used for their settings pages.
|
| That's life at BigCo for ya.
| nojvek wrote:
| 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 ended up in prod that only triggered for
| non english customers. It was a hard lesson that day never to
| touch untyped string based templates ever again. It's so easy to
| miss something. You want strict compile time checks, not run
| time.
|
| 2) Being dependent on slots. It's not easy to watch for changes
| in attributes to a slotted child. Yes you can add mutation
| observers but they aren't cheap either. All sorts of bugs poped
| up because some code does querySelector(x).setAttribute on a
| slotted child but the parent doesn't rerender and the UI doesn't
| look right. We ended up going to json strings inside attributes
| so components take their inputs via attrs rather than reading
| slotted children. The other avenue is props (like ionic), but
| props don't show up in dom explorer, so you have to make the
| tradeoff.
|
| 3) 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.
|
| All in all, I love that Microsoft is doing web components.
| Webcomponents are part of native dom api with simple lifecycle
| api. They're neat.
| flowerlad wrote:
| You can use JSX to implement as well as consume Web Components.
| See here: https://github.com/wisercoder/uibuilder
|
| This gives you compile-time checks, and attributes can be
| objects.
| CuddleBunny wrote:
| 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.
| flowerlad wrote:
| 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.
| CuddleBunny wrote:
| If the tagged literal approach takes off I'm sure tooling
| will keep up. JSX wasn't always as well supported as it is
| now.
| spankalee wrote:
| With the lit-html TypeScript and VS Code plugins you _do_
| get checks (and auto-completion) for HTML tags, attribute,
| and properties.
|
| Yes, it requires a plugin, but JSX required the parser,
| compiler, and type-checker to explicitly add support for
| it. They both require an extension to core TypeScript.
| spankalee wrote:
| Attributes are strings, but web components can have properties
| like any other object, and you can set properties on elements
| from JS and almost all template libraries.
|
| Properties can be complex objects, do not trigger
| attributeChangedCallback, and don't need to be serialized.
|
| What are you using to build your web components if you think
| they can only take strings?
| e111077 wrote:
| 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.
| cdata wrote:
| > 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).
| moneywoes wrote:
| Slider doesn't work for me on Chrome Android.
| nathanaldensr wrote:
| Allow me to ask the obvious question: How does Fast compare
| against React, Angular, VueJS, etc.?
| dudus wrote:
| At first glance it seems the fast-components are akin to
| material components and fast-foundation kinda reminds of
| angular cdk
| moenarch wrote:
| That's FAST!
| lucideer wrote:
| It doesn't.
|
| It's more comparable to something like Google Polymer[0]
|
| They can be used in conjunction with eachother[1][2], so I'd
| imagine the same/similar would be possible with Fast.
|
| [0] https://en.wikipedia.org/wiki/Polymer_(library)
|
| [1] https://www.digitalocean.com/community/tutorials/vuejs-
| vue-i...
|
| [2] https://github.com/jscissr/react-polymer#readme
| kutorio wrote:
| It reminds me more of https://material-ui.com/
| bokchoi wrote:
| From this page:
|
| https://www.fast.design/docs/fast-element/observables-and-st...
|
| > The arrow function bindings and directives used in templates
| allow the fast-element templating engine to intelligently react
| by only updating the parts of the DOM that actually change,
| with no need for a virtual DOM, VDOM diffing, or DOM
| reconciliation algorithms. This approach enables top-tier
| initial render time, industry-leading incremental DOM updates,
| and ultra-low memory allocation.
|
| > When a binding is used within a template, the underlying
| engine uses a technique to capture which properties are
| accessed in that expression. With the list of properties
| captured, it then subscribes to changes in their values. Any
| time a value changes, a task is scheduled on the DOM update
| queue. When the queue is processed, all updates run as a batch,
| updating precisely the aspects of the DOM that have changed.
|
| That's neat.
| atarian wrote:
| Apples and oranges. A design system is a collection of
| components that fit a certain look-and-feel; it is not tied to
| the implementation so it can be implemented by React, Angular,
| or VueJS:
| https://www.fast.design/docs/integrations/introduction
| arsome wrote:
| My understanding is this is closer to something like Bootstrap
| but using Web Components (or material-ui if you want a react
| component set) than it is to React itself.
|
| You'd probably still want to use React or similar ontop of it,
| but in the future we might get much lighter libraries covering
| that side of things.
| [deleted]
| sreekotay wrote:
| Appears to be a custom HTML elements (and some helper
| libraries) that you can plugin to vanilla, Vue, React, etc?
| crooked-v wrote:
| Well, the focus on Web Components is good for cross-
| compatibility, but means not being able to do the full static
| analysis of components that you can do with JSX or equivalents.
| duopixel wrote:
| 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.
| dmix wrote:
| Strange how the switch uses the default arrow cursor and the
| checkbox uses the pointer, while neither have a hover effects,
| but the other form elements and interactive components all have
| hover/active effects.
|
| There might be some interesting base stuff underneath but the
| UI/design part is pretty barebones and meh. Maybe that's not
| the point?
| spanhandler wrote:
| On desktop all of it looks like they either didn't do any
| styling, so I can hardly tell I'm not looking at unstyled HTML
| (lots of the static elements) or what they did is pretty bad-
| looking (everything else). Is this representative of the work,
| or is this presentation just weirdly bad for some reason?
| What's good about it? What am I missing?
| onion2k wrote:
| _default design is horrible_
|
| Good. That will encourage people to change it.
| kevincox wrote:
| How is that good? If they make it have good design then
| people don't have to try to make it good (and often fail).
| [deleted]
| neogodless wrote:
| I would imagine the design convention is to show a + when you
| have more content hidden, and a - to indicate you can hide
| (minimize) it.
|
| Is that the popular consensus, or is that an odd way of looking
| at it?
| achr2 wrote:
| Yeah, this threw me as well, it is implemented incorrectly..
| yodon wrote:
| The accordion tag doesn't make any assumptions about icons.
| You can use smiley faces & frowny faces for open and closed
| if you prefer, or you can use plus and minus signs in either
| order or anything else.
|
| The bigger more systemic documentation issue is the examples
| pages lack a view example source mode so there isn't an easy
| way to discover that icons are a user choice thing rather
| than a prebuilt styling thing.
| klohto wrote:
| 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?
| WorldMaker wrote:
| The impression I get is FAST is trying to simplify the markup
| you see in for instance Bootstrap's documentation by trying
| to build standard components that Bootstrap themselves could
| use (or Material or their own Fluent stuff). The emphasis is
| on a lot of the little things in Bootstrap's documentation
| that doesn't either get copy/pasted or it gets copy and
| pasted and ignored/forgotten/left-to-bit-rot. Stuff like
| aria- tags for accessibility. Seems the idea here is that by
| baking them into web components that do most of the work for
| you they are less likely to be forgotten or left to bit-rot.
|
| (I'm not a front end dev myself, but do enough full stack to
| think I know what is going on here.)
| dainiusse wrote:
| Don't want to be ride but that is yet more JavaScript
| fragmentation. That's it
| megaman821 wrote:
| Is it really? Web components seem good for reusable components
| and design systems.
|
| If you are making a reusable component like a switch, you make
| a web component (maybe with a helper library like Stencil,
| LitElement, or FastElement). If you are feeling nice you can
| create thin wrappers for React and Vue. As a consumer you just
| use an import and an HTML tag.
|
| If you take a bunch of reusable components and a theming
| system. Now you have a design system, but it is still just as
| easy to consume.
|
| For most front-end developers the choices remain the same.
| Build your site with React, Vue, or whatever you normally use.
| mrweasel wrote:
| > fast-anchor is a web component implementation of an HTML anchor
| element.
|
| Wait, what.... WHY? Can't you just use an a tag?
| Vinnl wrote:
| I was equally confused by fast-divider. I wonder what the
| rationale behind these were?
| wslh wrote:
| I always wonder where is the VB6/Windows Forms for web apps. I
| don't want to know the intricacies of Rect/Angular/Vue, I just
| want to do a declaration of the UI, not programming. Zillions of
| apps doing the same thing and spending weeks and months on the
| same problems. I start to think that this is not interesting for,
| for example, Microsoft because the developer market will shrink
| and their developers, developers, developers mantra. I remember
| when Bootstrap come up and suddenly we don't need a lot of
| graphic design time to build a web page.
|
| Just an additional note about VB6/Windows Forms. They helped to
| build commodity UIs but when you needed more advanced one you
| should rely on specific components.
| mstijak wrote:
| CxJS tries to solve common UI problems related to CRUD apps and
| dashboards.
|
| https://cxjs.io
| Animats wrote:
| _I always wonder where is the VB6 /Windows Forms for web apps?_
|
| Me too. Dreamweaver once did that. But the Javascript/CSS crowd
| complicated layout so much that writing WYSIWYG layout tools
| became extremely difficult.
|
| Blue Griffon is perhaps the last remnant of that era.
| red_admiral wrote:
| Pet hate: SQUARE radio buttons
| (https://explore.fast.design/components/fast-radio-group)
|
| In case it makes any difference: I'm on Win10, Edge 84.
| erikig wrote:
| Ditto on OSX+Chrome
| fareesh wrote:
| The slider performs terribly on Android Chrome
| pcr910303 wrote:
| Ok, so it looks like the main point of this is fast-components,
| which is a just a bunch of components styled as MS-style, but I'm
| more interested in the fast-foundation package.
|
| According to the instructions:
|
| > The exports of this package can generally be thought of as un-
| styled base components that implement semantic and accessible
| markup and behavior.
|
| > it exports parts and pieces intended to be composed into Web
| Components, allowing you to implement your own design language by
| simply applying CSS styles and behaviors without having to write
| all the JavaScript that's involved in building production-quality
| component implementations.
|
| Which means... if I want to make my own components, I can just
| take this package and don't worry about making broken components.
| Since the core HTML/JS is properly taken care (by MS, hopefully)
| I can less worry about re-implementing keyboard access, or things
| like accessibility which is hard to do properly. This is IMO
| huge, and should be more universal.
| ourmandave wrote:
| MS had this back in 2006 with CSS Friendly Control Adapters for
| asp.net.
|
| https://docs.microsoft.com/en-us/aspnet/web-forms/videos/how...
| CuddleBunny wrote:
| fast-foundation and fast-element are the main point of this.
| The components are mostly just a showcase. Though the MS-style
| set of components (https://www.npmjs.com/package/@fluentui/web-
| components) leveraging FAST will probably end up one of the
| most consumed products.
| RubenvanE wrote:
| The foundation package sounds a lot like the Lion components
| that ING Bank open sourced last year. It is indeed super handy
| to not have to worry about all the browser compatibility and
| accessibility issues!
| spankalee wrote:
| Link to Lion's storybook demos for those interested:
| https://lion-web-
| components.netlify.app/?path=/story/intro-l...
| Arkdy wrote:
| Any idea how FAST compares to using storybook directly?
|
| ( https://storybook.js.org/ )
| spankalee wrote:
| Fast is a set of components (and a base class). Storybook
| is a way to demo components.
| ramon wrote:
| Lit has been doing this for a while it's from that Polymer
| project. https://lit-element.polymer-project.org/ Web
| Components is a huge deal, you can do just web components on
| plain notepad and not need any build system for something very
| simple just using module based packages on the browser this is
| really cool. Snowpack for me was something huge, getting away
| from webpack was like getting back hours of work. But I don't
| know, till now for me I still see the Lit-Element and stuff as
| being more flexible than this one, the beauty is for example
| you can have a component in react and another on in Vue, it
| doesn't really matter and another one in JQuery. You can have
| whatever works best for you for each case.
| parksy wrote:
| edit - to thank everyone who took time out to explain what's
| going on - I'm still cynical but it all makes more sense now. I
| also like to think the ignorant guy asking the ignorant
| questions (in this case me) can sometimes be valuable for
| others who aren't in the club. Previous rant intact below for
| fun and hijinks.
|
| ---
|
| As a jaded old web developer I've seen so many frameworks along
| the way all promising this and that.
|
| Can someone who is familiar with this answer me this: Does this
| framework automatically sort out ARIA standards for me? Like
| tab ordering and stuff is dealt with automatically?
|
| I know it seems I am being lazy but I am just fed up.
|
| "FAST is a collection of JavaScript packages centered around
| web standards, designed to help you efficiently tackle some of
| the most common challenges in website and application design
| and development."
|
| COOL! (/s)
|
| "Have you ever needed a reusable set of UI components that you
| could drop into your app and have an amazing experience? That's
| FAST."
|
| UNIQUE! (/s)
|
| "Have you ever needed to create your own components, and share
| them across your company, including across groups that use
| different, incompatible front-end frameworks? That's FAST."
|
| <record scratch>
|
| Different, incompatible front-end frameworks?
|
| So like, this shit is magic that will let me streamline
| components between my Oceania team's WordPress and my German
| team's Magento frontends?
|
| And I don't have to learn any new paradigm to make this work?
|
| I don't have to use their specific, custom HTML in order to
| leverage it? https://www.fast.design/docs/components/accordion
|
| SWEET! (/s)
|
| Come on. We'd have to re-write everything to use this library
| specifically, and train our teams.
|
| Honestly this is to me just another bunch of shit that will get
| tacked into projects and have to be known and supported,
| because some sprightly young thing will convince management
| this is the panacea to seemingly redundant development work.
|
| What's the actual selling point here.
| spankalee wrote:
| > Come on. We'd have to re-write everything to use this
| library specifically
|
| That is not how web components work. Web components are just
| HTML elements, so any framework that can use HTML can use web
| components. That's what sharing across different,
| incompatible frameworks means.
| chrisweekly wrote:
| "just HTML elements"
|
| -- which depend on Javascript and have no good answer to
| "what about SSR"?
| parksy wrote:
| 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 you
| say is the best resource for me to go and upskill so I can
| see the actual value in this for me and / or my teams in
| the future?
| felipeccastro wrote:
| Frameworks mean React, Vue, Angular, etc. Usually, if you
| make a TextInput component in React, you can't use it in
| Vue and vice-versa. If you create a <text-input> web
| component, then you can use it in any of these frameworks
| (or with no framework at all), like a native html tag.
| parksy wrote:
| Thanks that actually sounds like it could have value, but
| again it's a new paradigm to learn.
|
| It's like a while back I trained myself up on GWT because
| in my mind it was the future of reusability.
|
| Sure it was Java based and everyone hates Java these days
| I guess, or at least hating Java is a meme. But the
| entire concept and value was that you write everything as
| reusable components.
|
| Then all you really needed to do was choose your compile
| targets and the compiler would do the rest, generating
| cross-browser / device versions of your application code
| as needed.
|
| I can see now what the OP means and honestly from my
| point of view the post-XHTML / DTD / XSD diaspora is
| circling back around to trying to find standard ways to
| separate data from presentation.
|
| I think I get it now, thank you.
| pupdogg wrote:
| 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 ;)
| parksy wrote:
| 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 dismay. That's not
| going to happen either.
|
| I did come out pretty strong in my apprehension but I am
| serious in wanting to know specifically what the benefit
| of this is, and I don't really care whether I am making a
| fool of myself for asking questions lol.
| dmitriid wrote:
| 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
| parksy wrote:
| Okay I think I get it:
|
| 1. Define elements in script by extending htmlelement
|
| 2. Follow the allowed structure in the DOM so that the
| custom elements don't break / conflict with anything
|
| 3. Use CSS to make the custom element look nice.
|
| Then, basically what we have is:
|
| 1. A class-based way to attach event listeners in a
| standard interface (which is nice)
|
| 2. what we always had to do anyway (unless framework
| forces using JS to inject HTML at runtime)
|
| 3. what we always had to do anyway
|
| 4. Can't use custom events anymore... Encapsulation fTW.
|
| But now that brings us to a situation where, essentially,
| it comes down to which htmlelement classes take
| precedence in our dependency hierarchy. Some libraries
| are probably compatible but you can't guarantee it
| because there's no explicit package dependencies between
| different implementations, so if you choose two different
| component libraries you may end up with unexpected
| behaviours and bugs.
|
| So if I were to build a component library that is
| "compatible" with all major component libraries,
| essentially what I'd have to build is a shit-ton of
| "mappings" and exceptions that define an order of
| precedence of which component variants my library should
| interact with or cede to? I don't really like the idea of
| "just magically working with incompatible libraries"
| right?
|
| Does that seem about right?
|
| I think I learned something new and fundamental today,
| and the overall approach makes sense if you pick a single
| library to build your application but I can't see it
| having any realistic value if you're to try and jimmy it
| into existing products, in fact I can see that being an
| extremely expensive exercise and potentially adding a
| load of overheads to maintain and configure.
|
| Also I can see now why no one really answered the
| question about ARIA tab orders and accessibility, it's
| not the job of these libraries.
|
| I'm not a very smart person, thanks again to you and
| everyone else jumping on my thread to take the time to
| explain :)
| dmitriid wrote:
| In theory you wouldn't worry about idiosyncrasies of
| specific component libraries if they are based on web
| components because they would provide only a single
| interface: properties go in (as in
| customElement.myCustomProp = <some-value>), events go out
| (as in customElement.attachEventListener(<some-custom-
| event>, (e) => <do something in your callback>)).
|
| This is definitely true for "dumb" components aka leaf
| components such as labels, footers, links, basic inputs.
| However, since you need more (for example, data-binding
| and reactivity), this may become a question of
| interoperability, and I don't really know how that plays
| out in the real world.
|
| > I'm not a very smart person, thanks again to you and
| everyone else jumping on my thread to take the time to
| explain :
|
| No stupid questions, right? :) And the whole web
| components discussion _is_ extremely muddied. Mostly
| because people expect you to already know what they are
| about, and talk about and use libraries on top of them:
| lit-html, stencil etc.
| parksy wrote:
| Is the only thing that stops components from colliding
| literally naming convention? Like <fast-dropdown> != <my-
| homebrew-dropdown>? So it's basically a convention-based
| standard rather than a fixed standard? This feels like
| another example of the XHTML apocalypse coming full
| circle and we're trying to find objective approaches to
| loosely defined data.
|
| I do feel I am exposing myself to some ridicule for being
| out of style and I regret my attitude in my original
| reply but it felt honest at the time, I am glad that we
| have had this conversation in general because it's given
| me a lot to think over.
|
| My main fear that I developed over the years is we end up
| developing frameworks for frameworks instead of
| delivering tangible results. I've been on projects that
| ended up taking far, far longer and costing way more to
| maintain simply because we had to nurse the framework
| rather than deliver the results.
|
| Anyway thanks for taking the time out again, I need to
| percolate for a while and look into some of the ideas
| that have been expressed here.
| dmitriid wrote:
| > Is the only thing that stops components from colliding
| literally naming convention? Like <fast-dropdown> != <my-
| homebrew-dropdown>? So it's basically a convention-based
| standard rather than a fixed standard?
|
| Yup :) They decided to go for a flat namespace where all
| that distinguishes between components is their name. I'm
| guessing this already leads to collisions between
| different versions of the same element. And there has
| been an open issue for it for three years now:
| https://github.com/w3c/webcomponents/issues/716 And the
| "solution" seems to be "let's add more Javascript":
| https://github.com/justinfagnani/scoped-custom-elements
|
| > I do feel I am exposing myself to some ridicule for
| being out of style and I regret my attitude in my
| original reply
|
| It's perfectly fine :) I've been way more rude about web
| components before (and still am :) )
|
| > My main fear that I developed over the years is we end
| up developing frameworks for frameworks instead of
| delivering tangible results.
|
| Indeed. That's my main gripe with web components, really:
| instead of providing tangible benefits to developers,
| they ended up being "an API primarily for library and
| framework developers"
| pupdogg wrote:
| What I meant was that are a lot of like minded developers
| here who cringe every time they have to hear how JS is
| going to teleport us from Earth to Mars. And since there
| are no bonus cookies that can won by proving that you can
| create a functional website simply by using some good old
| HTML with CSS and vanilla JS, a lot of us resort to being
| silent and enjoy the show!
|
| So, what do ya say? Would you React the same way? ;)
| parksy wrote:
| It's funny because in writing my previous reply to you I
| felt a momentary sense of inclusion into a special club,
| I did think something along the lines of "should I just
| enjoy the show" and then on reflection I realised that
| taking such a stance would be equivalent to having no
| voice at all, and it would also essentially evaporate my
| chances to learn anything new from the good folk here as
| it would set up a "me vs them" context, which I don't
| believe would lead to me learning anything new.
|
| Don't get me wrong, I can see where you're coming from
| and feel the same way many times myself, but I am no
| stranger to conflict, and I spent a great deal of my life
| fawning to people or deferring my opinion for some
| "greater ideal" that other people tried to set for me,
| like you are doing now. You have set up so many logical
| fallacies, talking about "so many developers", "bonus
| cookies", and some weird need to "prove" ourselves, that
| I don't even know where to begin unwrapping whatever
| complex you have.
|
| Get help. You will be happier.
|
| I decided in this instance to say whatever is on the top
| of my mind no matter how stupid it makes me look, I don't
| seek camaraderie with anybody at face value just because
| you purportedly represent a group that I can join. "Like
| minded developers"? You would have to try harder to
| entice me to be a part of your group, if you even have a
| group. I really don't care to feel superior to anyone,
| results speak for themselves, so good luck I guess
| establishing a weird inner circle of ideals but I really
| want no part of it, nor do I need any endorsement from
| such a group.
|
| Wow, that felt so fucking weird to type.
| cfcosta wrote:
| 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 lack of
| standardization and one-off solutions to deceptively
| simple problems, taking care of edge cases your team is
| likely to find but unlikely to think beforehand.
| parksy wrote:
| 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")?
| spankalee wrote:
| You can tell a framework by the "Hollywood Principle"
| (don't call me, I'll call you). A framework is the
| component host. It's responsible for defining the
| component model and calling the component lifecycle.
|
| Since frameworks define their own component model,
| components are typically incompatible between frameworks.
| You can't use an Angular component in React because React
| defines a different model.
|
| This leads to huge fragmentation across the ecosystem and
| internally within large companies, and a waste of effort
| to reimplement components in each framework.
|
| Web components are a standard component model where the
| _browser_ is effectively the framework. It calls the
| component lifecycle, and to other userland JS code, or
| HTML markup processors, web components act like any other
| HTML element. It's like being able able to add your own
| elements to the HTML spec.
|
| Web components only specify the interface between the
| components and the DOM, they don't specify how the
| components are implemented. So you see several libraries
| that help implement web components. These libraries
| usually do a subset of what a framework does: main
| templating and reacting to state changes. They don't do
| the component model part of a framework.
|
| Fast is another library that helps you build web
| components. Polymer was probably the first, and currently
| there are Polymer's LitElement, Ionic's Stencil,
| Salesforce's Lightning, and many more. They're all
| compatible with each other and with frameworks because
| the libraries only manage the internals of the
| components, the externals are standard.
| [deleted]
| parksy wrote:
| And I am trying to understand, I think I'm just in a bad
| mood about this (I think I have framework fatigue? if
| that's a thing?) so thanks for explaining.
| ramon wrote:
| 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.
| parksy wrote:
| 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 this is not something I'd
| want to retrofit but would have to adopt as a standard to
| see any value long-term over a bunch of projects.
|
| Usually I am more measured in my responses but this time I
| tried to just say what I am thinking (screw my ignorance)
| so maybe I can learn a thing or two.
|
| Thanks for responding.
| ramon wrote:
| 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.
| parksy wrote:
| I can't send DM's here and I don't know if you'll see an
| edit, so I wanted to add that I am sorry if I sounded
| condescending in my other reply, I initially just wanted
| to make sure you and other readers understand I am not
| new to the programming game to emphasise my frustration
| at not being able to understand something so simple as
| drawing html elements, and prevent assumptions about my
| ability to comprehend frameworks in general, but on re-
| reading it sounds like I'm trying to 1-up you, in reality
| I do find it hard to keep up and I am fearful that things
| are moving beyond my ability to comprehend. After some
| other discussions with other posters here this sounds
| like it might be a cool addition to the ug... component-
| o-sphere? It'll take me a while to get up to speed.
|
| Thanks for taking the time, and I will try to be better
| next time.
| parksy wrote:
| 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.
| EisenbergEffect wrote:
| 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 umbrella term. You may
| remember when the industry used to talk about "HTML5". This was
| also an umbrella term for a collection of new HTML standards.
| Similarly, "Web Components" refers to a collection of standards
| related to creating reusable custom HTML elements. Some of the
| standards that are under the umbrella include the ability to
| define new custom element tags, a standard component lifecycle,
| encapsulated HTML rendering and encapsulated CSS (shadow dom),
| CSS properties, CSS Shadow Parts, and more. These are all defined
| by W3C and have shipped in all major browsers today. The work on
| Web Component standards, like the rest of the web, is ongoing.
| New APIs continue to be designed and released. Some recent APIs
| include form associated custom element APIs and CSS Shadow Parts.
| W3C is currently working on standards for things like
| constructible style sheets, declarative Shadow DOM, custom
| element registries, custom states/pseudo selectors, and more.
| Microsoft, Google, Salesforce, and many others are working
| together on this.
|
| Because FAST is built on Web Components, it does not create its
| own component model; it's using the standard component model.
| What has traditionally been thought of as a "front-end framework"
| typically has its own component model, not based on web
| components. Examples of this include Angular, React, Vue, Svelte,
| etc. Any library that is based on web components isn't trying to
| create its own model, but rather to leverage the standards. This
| allows a web component to work like any normal HTML element. You
| do not need a framework to use them. However, if you want, you
| can use them in combination with a framework of your choice, or
| jQuery, or whatever.
|
| To drive the point home that these are web standards, here are 4
| lines of code that you can execute in a modern browser console to
| define, create, and add a web component. You can even execute it
| in this Hacker News page using DevTools.
|
| // define the custom element class
|
| class HelloWorld extends HTMLElement { constructor() { super();
| this.attachShadow({ mode: 'open' }).innerHTML = 'Hello World'; }
| }
|
| // register the custom element by tag name
|
| customElements.define('hello-world', HelloWorld);
|
| // create an instance of your new element
|
| const ele = document.createElement('hello-world');
|
| // add your new element to the body
|
| document.body.appendChild(ele);
|
| If you do this in your console now, you'll be able to scroll down
| to the end of the page and see your component rendering. Have a
| look in the element inspector and you'll see the custom tag,
| along with its shadow dom, including "Hello World".
|
| When you start to build web components, you're likely to notice
| that there's a pretty large amount of code you need to write to
| implement even a basic component. That's because the standard
| defines low-level protocols, rather than high-level abstractions.
| By doing this, the standard provides you with interoperability
| and flexibility to innovate without boxing you in. At this point,
| something like FAST comes along and provides a thin layer of
| opinions, lifting the level of abstraction just enough to make it
| easier and FASTer to build components. Things that FAST helps
| with include: providing attribute/property syncing, rich Model-
| View-ViewModel (MVVM), template rendering/update, style
| composition, etc. All of this is an internal implementation
| detail of a FAST component, allowing FAST to integrate with Web
| Components built in completely different ways or with different
| libraries. The entire fast-element library, without tree-shaking,
| is around 10kb minified and GZipped. It was designed for tree-
| shaking from the beginning, so any feature you don't use when
| building a component will be removed during build, allowing you
| to get it smaller based on your needs.
|
| Architecturally, today FAST is composed of 3 layers. At the
| lowest level is fast-element, which provides a basic mechanism
| for defining components. For many people, this is all they need.
| However, others need an actual component library to build their
| site/app with, and often times they need control over the
| look/feel/branding. To address this, you can add the second
| layer, fast-foundation, which provides a set of building blocks
| for creating component libraries and design systems. It itself is
| not a component library. Rather, it has the base behaviors for
| standard components like button, tree view, menu, etc. It also
| has the basic functionality that design systems typically need,
| such as color algos, design tokens (design variables), typography
| primitives, etc. Foundation allows you to build your own button,
| tree-view, etc, without having to design the semantic HTML, work
| out the correct Aria behaviors, mess with proper keyboard nav,
| manage the JavaScript state and behavior, etc. Instead, you can
| compose together a foundation button and foundation template with
| your own styles, giving you complete control over the appearance
| of your components. With these building blocks, it's possible to
| implement something like Bootstrap, Material Design, Lightning,
| etc. However, if you don't need to implement your own design
| system, you can use one that we build. This is the third layer.
| We provide two design systems today. One is called FAST Frame
| (featured on our web site). The other is Fluent UI Web
| Components.
|
| FAST Frame is an early, experimental design system that our team
| is working on. I saw some feedback below that it's "ugly" :-D As
| mentioned, this design system is a work in progress, being
| designed and developed in the open. So, we welcome you to
| contribute to the project and help us define something that the
| industry would feel proud to use in their apps. As for Fluent UI
| Web Components, Fluent UI is Microsoft's design language. I saw
| some comments below about how Microsoft was trying to consolidate
| and that FAST seems to add yet another option. The consolidation
| work is around our design system first. So, we're moving to a
| single design system "Fluent UI" across the company. We're then
| consolidating implementations as appropriate. Previously, there
| were several React implementations. There's work ongoing to
| consolidate that into a single React implementation. But what
| about people who don't use React? Well, that's what Web
| Components are for. FAST is providing the Fluent UI Web
| Components implementation. So, regardless of what platform,
| framework, etc. you use there will be a best fit implementation
| that provides you with a consistent Fluent UI experience.
| EisenbergEffect wrote:
| 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 Strings - Yes, this is part of the DOM API.
| That's the way HTML works. However, HTML elements also have
| properties, and those do not have to be strings. They can be
| any type. As such, FAST enables properties of any type, and
| will provide type conversion between attributes and properties
| if desired. It is considered "bad practice" to serialize to
| json and pass through attributes. Rather, just use a standard
| JS property.
|
| * Typing in Templates - If you use TypeScript with FAST, you
| can have full type checking and editor refactor support over
| the data in your template. Because FAST's templates leverage
| the JavaScript language's standard tagged template literal
| feature, popular editors (such as VS code) will provide syntax
| highlighting, documentation, and tag completion for both HTML
| and CSS written in this way. Additionally, lint tools
| understand tagged template literals and can lint the HTML and
| CSS that is written in them. So, there's strong support in
| tooling today and more coming in the future.
|
| * Web Components Break Accessibility - Accessiblilty is
| difficult. When you build re-usable web components, you have to
| think carefully about the best way to accomplish this. That
| said, it's incorrect to say that WCs break accessibility. Our
| team has worked extensively on the accessibility of our
| components and the results have been good. If you find an
| accessibility bug, let us know. We prioritize those types of
| issues pretty high.
|
| * They Don't Work Without JavaScript - This is true today not
| just of WCs but of every front-end framework (without
| leveraging SSR). However, it has never been the long-term plan.
| We are currently working with W3C on declarative shadow dom as
| well as declarative custom element definitions. Many WCs will
| always require JS but in the future a whole category of WCs
| will not.
|
| * 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 standard on
| which SSR and other WC capabilities will be built.
|
| * The WC API is Very Bad - As mentioned earlier, the focus for
| v1 WCs is to provide a low-level API that enables
| interoperability and flexibility. Baking a high-level API in at
| this point would shut down innovation when aspects of component
| models are still being deeply explored, experimented with, and
| debated. As such, platform WC APIs are more like Win32 and less
| like Java or .NET. Over time, as the industry establishes more
| patterns, new higher level APIs will be added, but they will be
| built on the low-level APIs, always leaving open the
| opportunity for "user-land" innovation.
|
| * You Can't Provide Callbacks for Custom Events - Maybe I
| misunderstand this but in my experience this is not true. You
| can use addEventListener on any web component to register for
| completely custom events. If you want an `onevent` property,
| you can set a function to as part of your API, you only need
| implement a property setter that internally calls
| addEventListener. Events from inside the shadow dom are re-
| targeted, but you have complete control over whether they
| bubble or compose. So, there's no issue there as long as you
| know how to use the composedPath() API.
|
| * Why does Accordion/Anchor/Divider, etc. have a slot and
| nothing else? - It does have something else. Styles. Shadow dom
| can be used to enable composition and encapsulate styles. In
| this case, these elements are not doing anything interesting
| with composition, but are providing encapsulated styles. If you
| are wondering why you can't see them, it's because FAST
| leverages a new standard for constructible style sheets, which
| allows it to attach style sheets to the Shadow Root, via its
| adoptedStyleSheets property. If you find the shadow root in
| your inspector, and look at its adoptedStyleSheets property,
| you will see what you are looking for. For browsers that do not
| yet support this new WC feature, we fall back to standard style
| element injection. FAST does not force you to use shadow dom or
| slots. Any FAST element can render into the light DOM as well.
| If we're using shadow dom, there's a reason for it (or there's
| a bug if there isn't).
|
| * It Has Limited Components - This is our first release, and
| includes a subset of the many components we have planned.
| Ultimately, we plan to at least implement everything in
| FluentUI.
|
| * The Components Are Broken - As our first release, I'm sure
| it's not perfect. FAST is MIT licensed and open sourced on
| GitHub. Please feel free to report bugs and we'll work to get
| them fixed. If you feel comfortable contributing, we'd love to
| have you work with us on the fixes as well.
|
| Ok, hopefully this helps a bit. At Microsoft, we're excited to
| begin our journey into Web Components with FAST. These are our
| first steps, but we've got a lot more planned for the future.
| We invite all of you to join us on this journey. You are
| welcome to provide feedback, contributions, docs improvements,
| thoughts on web standards improvements, etc. Looking forward to
| seeing you around!
| jabits wrote:
| Thanks for the detailed responses, and thanks for the
| release. I am looking forward to digging...
| mattlondon wrote:
| A lot of the components don't appear to work? Checkboxes, radios,
| sliders.
|
| There are also weird extra spaces and alignment issues on things
| like basic links or the list numbers in the tab demo.
|
| Bit of a shame
|
| This is on Firefox on Android.
| c-smile wrote:
| How I would do that in Sciter:
|
| fast.css : fast-something { // custom
| element aspect: FastSomething; // its function-
| controller display:block; }
|
| script: function FastSomething() { //
| note JSX is built-in in Sciter this.content( <b>Hello
| World</b> ); }
|
| and markup: <style src="fast.css" />
| <body> <fast-something /> </body>
|
| Easy, no?
| DethNinja wrote:
| 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 more confident
| with creating an internal library, at least I would be able to
| use web components in a cross compliant way between browsers
| and Sciter.
| c-smile wrote:
| 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 party"
|
| My pardon, I didn't get the "to share" part, who share, what,
| and with whom?
___________________________________________________________________
(page generated 2020-08-07 23:00 UTC)