Microsoft Fast Design - <AUTHOR> https://www.fast.design/docs/introduction <comment><USER3> 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://en.wikipedia.org/wiki/Web_Components)

\- [https://developer.mozilla.org/en- US/docs/Web/Web_Components](https://developer.mozilla.org/en- US/docs/Web/Web_Components)

\- [https://developers.google.com/web/fundamentals/web- component...](https://developers.google.com/web/fundamentals/web-components)

\- [https://caniuse.com/#search=components](https://caniuse.com/#search=components)

Also worth reading: [https://dev.to/richharris/why-i-don-t-use-web- components-2ci...](https://dev.to/richharris/why-i-don-t-use-web- components-2cia) (discussion on HN: [https://news.ycombinator.com/item?id=20232628](https://news.ycombinator.com/item?id=20232628))

<comment><USER4> So, like [https://medium.com/ing-blog/ing-open-sources-lion-a- library-...](https://medium.com/ing-blog/ing-open-sources-lion-a-library-for- performant-accessible-flexible-web-components-22ad165b1d3d)?

<comment><USER5> Lion is similar in that it's intended to be customized from the start. For something more "batteries included," see [https://shoelace.style](https://shoelace.style).

</comment></comment></comment><comment><USER6> 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.

<comment><USER7> 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...](https://marketplace.visualstudio.com/items?itemName=runem.lit- plugin)

For node: [https://www.npmjs.com/package/lit- analyzer](https://www.npmjs.com/package/lit-analyzer)

For other Web Component libraries: [https://www.npmjs.com/package/web- component-analyzer](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.

<comment><USER8> I've found that for an object-oriented web component API, you end up with less flexible rendering — yes, redux can one-way bind attributes, etc., but you're missing half the reason why you'd want to write code that way, how React schedules and renders to make immutable one-way data flows relatively cheap/quick with little to no persistent state. (Note, less code is less work, but caching and diffing DOM can also be less work...)

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?)

</comment></comment></comment><comment><USER9> 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.

<comment><USER10> 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](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.

<comment><USER11> > 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.

<comment><USER10> 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?

<comment><USER11> 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.

</comment></comment></comment></comment></comment><comment><USER12> 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 - <USER2> 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.

<comment><USER13> 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?

<comment><USER14> 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.

</comment></comment></comment><comment><USER15> Check out the FAST Component explorer to see it in action: [https://explore.fast.design/](https://explore.fast.design/)

Looks very flexible but the presentation and default design is horrible.

<comment><USER16> 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?

<comment><USER17> 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.

</comment></comment></comment><comment><USER18> 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...](https://developer.microsoft.com/en-us/office/blogs/ui-fabric-is- evolving-into-fluent-ui/)

<comment><USER19> 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.

</comment></comment><comment><USER20> Pet hate: SQUARE radio buttons ([https://explore.fast.design/components/fast- radio-group](https://explore.fast.design/components/fast-radio-group))

In case it makes any difference: I'm on Win10, Edge 84.

<comment><USER21> Ditto on OSX+Chrome

</comment></comment><comment><USER22> There are many design issues with their website which IMHO don't provide great confidence in using their components

</comment><comment><USER23> 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.

<comment><USER24> 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.

</comment></comment><comment><USER25> 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?

<comment><USER26> Sliders and radio buttons do not seem to work on Firefox for Android nightly build.

<comment><USER27> Neither do they seem to work in desktop Nightly.

</comment></comment></comment><comment><USER28> 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](https://markwatson.com) site is now about 27 years old.

I want something batteries included.

</comment><comment><USER29> 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.

</comment><comment><USER30> 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!

</comment><comment><USER31> > fast-anchor is a web component implementation of an HTML anchor element.

Wait, what.... WHY? Can't you just use an a tag?

<comment><USER32> I was equally confused by fast-divider. I wonder what the rationale behind these were?

<comment><USER33> The primary reasons seem to be encapsulating accessibility and styles. There is nothing forcing you to use fast-anchor or divider. The theme is exposed in CSS vars so you can use it from a stylesheet on native elements.

</comment></comment></comment><comment><USER34> 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>`

<comment><USER35> Okay, but how its default components look and how rich the default component set is is how you sell the benefits of such a component creation system. As it is, it makes it look like you can only make limited, badly designed components.

</comment></comment><comment><USER36> Did the concept of atomic design never take off? A few years ago i remember various css and js bundles spawned around Brad Frost's atomic design movement but i don't recall any of them lately being on HN.

It's a shame if they're not making the grade, i thought the idea of composable UI elements sounded spot on.

<comment><USER37> Tailwindcss is getting quite big.i would dare to say mainstream even.

</comment></comment><comment><USER38> 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.

<comment><USER39> > I always wonder where is the VB6/Windows Forms for web apps.

they tried. it's called asp.net webforms.

it sucked hard. bécause they forced event driven paradigm in a stateless environment (http) resulting to hacks (hello viewstate).

but hey it was my gateway drug into web development as a winforms guy. im the sucker and i shouldnt be complaining. but 15 years later im back to aspnet webforms because of legacy apps the client doesn't want to upgrade yet.

</comment></comment><comment><USER40> 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.

<comment><USER40> 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!

<comment><USER41> > 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.

I mainly develop using ASP.NET Core, with some vanilla JS as needed.

I'm just starting to hear about Web Components, and have heard that you can't use them with SSR because of the shadow DOM. I don't actually know what shadow DOM is, but does this mean _no_ Web Components work with SSR, or that _some_ don't? What precisely is the issue?

<comment><USER42> According to a fairly recent article (Feb 2020):

> It's a common myth that you can't server side render Web Components. Turns > out you can if you look in the right place.

[https://dev.to/steveblue/server-side-rendering-web- component...](https://dev.to/steveblue/server-side-rendering-web- components-320g)

The article mentions a few libraries for this purpose.

\- Vaadin Router - [https://vaadin.com/router](https://vaadin.com/router)

\- SkateJS - [https://skatejs.netlify.app/](https://skatejs.netlify.app/)

\- SkateJS: Web component server-side rendering - [https://github.com/skatejs/skatejs/tree/master/packages/ssr](https://github.com/skatejs/skatejs/tree/master/packages/ssr)

This latter looks good, I hadn't seen that before.

As a possible successor to React, Vue, et al, there's a wide range of functionality expected of Web Components. Server-side rendering of shadow DOM (I don't know what that really means, but) seems to be one of the tough questions yet to find a definitive answer.

</comment></comment></comment></comment><comment><USER43> 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.

<comment><USER33> I'm using FAST with the design system props mapped to Tailwind config for my Blazor app team. This lets them consume the awesomeness without writing JS.

<comment><USER43> That is a great idea and usage. I was thinking about a Blazor setup.. but I will think more about the approach first. I think in a very near future a Fast-Tailwind repo will arrise.

</comment></comment></comment><comment><USER44> 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](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.

</comment><comment> c-smile 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?

<comment><USER45> 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.

<comment> c-smile 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?

<comment><USER45> I meant creating a web component based widget library and sharing that for use on anything from desktop GUIs to web sites.

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.

<comment> c-smile Again, that's not about Sciter but rather discussion of Web Components idea in general.

Essentially WebComponent is the way of associating some JS class with custom DOM elements.

At the nutshell, WebComponents is just this one JS function:

        customElements.define('hello-world', HelloWorld);

But it is quite limited as you see - a) only custom elements and b) you need to load some JS file in order to initialize bindings.

That element->JS code binding could be done by CSS with much greater flexibility:

        /* custom element */
        hello-world { aspect: HelloWorld url(hello-world.js); }

        /* existing element */
        span.hello-world { aspect: HelloWorld url(hello-world.js); }

        /* existing element, conditionally */
        a[href^="http"] { aspect: HelloWorld url(hello-world.js); }

Yet note that, in case of CSS bindings, hello-world.js will be loaded _only if your document will have matching elements_ \- better componentization I would say.

</comment></comment></comment></comment></comment><comment><USER46> Very interested in the background image on their home page that slowly animates as well. That looks really great. Anyone know how are they doing that? [https://fast.design/](https://fast.design/)

<comment><USER47> The background image is a <canvas> element on which they draw using JavaScript.

</comment></comment><comment><USER48> 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.

</comment><comment><USER49> Love it when I'm on a design system's website and it's broken on mobile.

[https://postimg.cc/N509Z8Kr](https://postimg.cc/N509Z8Kr)

</comment><comment><USER50> I like their transparent implementation. Went to text-area expecting ...something else, but I got Microsoft instead ¯\\_(ツ)_/¯

Is this a pre-pre alpha preview of the preview? Because it feels like

</comment><comment><USER51> 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.

</comment><comment><USER52> For a non developer like me,

Is it any different from Ant Design ([https://ant.design/](https://ant.design/))?

Also, almost every company I worked with (> 500 employees), eventually built their own UI components. And in every company, developers seldom use these, always customize or use something else.

Which brings the question - Why do we invest (internally) and open source components? Whats the value?

<comment><USER53> Ant shipped 1MB CSS minified, last time i used it at work.

</comment></comment><comment><USER54> The project homepage is easier to understand than text: [https://www.fast.design/](https://www.fast.design/)

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](https://www.youtube.com/watch?v=sYTH_xYH3iA)

</comment><comment> dynamite-ready 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)".

</comment><comment> r-w 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...](https://github.com/microsoft/fast/tree/master/packages/web- components)

</comment><comment><USER55> The slider performs terribly on Android Chrome

</comment><comment><USER56> On mobile Firefox the side menu is quite janky

</comment><comment><USER43> I just wrong a little tutorial on FAST with Snowpack if anyone interested: [https://www.linkedin.com/pulse/microsoft-fast-snowpack- ramon...](https://www.linkedin.com/pulse/microsoft-fast-snowpack-ramon-lima/)

</comment><comment><USER57> It looks like LitElement but more TypeScript first. The decorators do make it a bit more approachable for me.

<comment><USER11> 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](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](https://lit-element.polymer- project.org/guide/decorators)

<comment><USER57> Yeah, LitElement definitely has a cleaner render template. How would one do a computed property in LitElement?

<comment><USER11> 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.

</comment></comment></comment></comment><comment> the-dude And I was thinking they bought this for $1.3bn in 2008 : [https://searchengineland.com/microsoft-to-buy-fast-search- fo...](https://searchengineland.com/microsoft-to-buy-fast-search- for-123-billion-13082)

</comment><comment><USER58> 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).

<comment><USER3> > 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...](https://developer.mozilla.org/en- US/docs/Web/CSS/@media/prefers-color-scheme)

<comment><USER58> 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.

<comment><USER35> It's there so developers can look at the components in both colour schemes.

</comment></comment></comment></comment><comment><USER59> For those that miss it, the dark mode can be turned off on the top right corner.

</comment><comment><USER60> Even though they may be slow and have an unusable API, Web Components being built into browsers means they will continue to work long after React, Vue, etc. are all dead and unmaintained.

<comment><USER61> What makes you say web components are slow or have an unstable API?

<comment><USER60> It's slow and un _usable_ , not unstable. The one benefit of WC is that it's going to be stable for the next hundred years, just like <marquee> still works in 2020. It's unusable because of all the boilerplate it requires and doesn't provide the most important thing of all which is data binding. So you have to bring in some other support code to do data binding such as the Rx/Observables or Redux patterns, but since this can't be shared with other shadow-rooted WCs, the cost of that bloat is multiplied by the number of different WCs you have on a page, which could be hundreds.

In benchmarks WC scales very poorly compared to React. It just wasn't designed for performance. I could go on.

\- strings as the only native serialization format

\- templates are also strings

\- messages are passed to children as attributes which are strings

\- no way to take advantage of efficient tree algorithms (virtual DOM), just manipulate a giant string every tick like a caveman

<comment> c-smile You'd be surprised but in general this

        element.html = "...";

is faster then

        ReactDOM.render(vdom,dom);

at least for initial DOM tree population.

There are many reasons for that. `element.html =` is implemented as single update transaction, JS function call is significantly more expensive then HTML parsing of single element, etc.

<comment><USER60> This is thanks to how extremely optimized V8 and Chrome is for string manipulation. It is faster in the small cases but doesn't scale to, say, 10000 rows in a table. Then it becomes several orders of magnitude slower than React and virtual DOM. On low memory devices it could crash and never render. This should just be kept in mind when choosing WCs. WCs are perfectly fine for the Settings page in Edge, for example.

<comment> c-smile "extremely optimized V8"

JS code is always slower than native html parsing code. No matter what.

"10000 rows in a table"

This:

        element.html = 10000 times "<tr>...</tr>";

is by order of magnitude faster than

        element.appendNode( document.createElement("tr") ... ); // ReactJS code

no matter how optimized JS runtime is.

array.forEach(func) is 30 times slower than plain for/at loop. Because of function call.

</comment></comment></comment></comment></comment></comment><comment><USER62> Does FAST checkbox component have some sort of delay built in?

Compared to regular vanilla checkbox it seems to respond slower(100-200ms delay perhaps).

This is on slowish 4G connection but that shouldn't matter.

</comment><comment><USER63> That is some seriously cheesy but brilliant copywriting!

</comment><comment><USER64> Slider doesn't work for me on Chrome Android.

</comment><comment><USER65> It looks like alternative for [https://material.io/](https://material.io/)

</comment><comment><USER66> Allow me to ask the obvious question: How does Fast compare against React, Angular, VueJS, etc.?

<comment><USER67> 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)](https://en.wikipedia.org/wiki/Polymer_\(library\))

[1] [https://www.digitalocean.com/community/tutorials/vuejs- vue-i...](https://www.digitalocean.com/community/tutorials/vuejs-vue- integrate-web-components)

[2] [https://github.com/jscissr/react- polymer#readme](https://github.com/jscissr/react-polymer#readme)

<comment><USER68> It reminds me more of [https://material-ui.com/](https://material-ui.com/)

</comment></comment></comment><comment><USER69> I could have bet there was a low quality / compressed image on this when I saw Microsoft. Low and behold the site logo is low res.

Why is that at MS... Switching to teams everyone's face turned to mush which while it might save on aggregate network traffic, it greatly reduces the niceness of the conversation.

</comment><comment><USER70> It Looks and Feels very much like Google's Material Design.

</comment><comment><USER71> Microsoft and design in the same sentence! They have come far.

<comment><USER72> What about "Windows 8 introduces new Metro Design language", huh

</comment></comment><comment><USER73> 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.

</comment><comment><USER74> Ha, can we add fast-comments as a component? :)

</comment><comment><USER75> On a side note, is Microsoft acquiring Tik Tok?

</comment><comment><USER76> Kind of surprises me that Microsoft allowed this project to use Discord for external communication.

<comment><USER33> 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.

</comment></comment><comment><USER77> Not responsive, in 2020 ?

</comment><comment><USER78> Web Components, as a standard, remain problematic. Among other things, they fail to address the critical need for server-side rendering.

<comment><USER60> I think a Web Component is meant to be like a <div/>. It's one of the pieces that you render on the server. That way the client is dumb and just implements a design language in Web Components/JS, and the server sends commands to lay them out with data already bound.

</comment></comment><comment><USER79> One of the worst things about Windows and other Microsoft products is the design of their interfaces and typography - not sure why anyone would ever want to use their design principles for anything.

</comment><comment><USER80> 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

<comment> crooked-v If you use React, you might like Rebass ([https://rebassjs.org/getting- started](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](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.

</comment></comment><comment><USER81> Don't want to be ride but that is yet more JavaScript fragmentation. That's it

<comment><USER57> 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.

</comment></comment><comment><USER82> Oof. When will this "dark mode" fad end?!? Is this project made for edgy 14 year olds or actual professionals?

(Yes, yes. You can switch some of the site to light mode and, besides, you're an elite uber-hacker and white text on black background is totally easier on your eyes, and you always read everything like that since blahblahblahblahblah. Uh-huh. There's reasons we've been printing with black ink on white paper for 500 years.)

</comment><comment><USER83> 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.

</comment><comment><USER84> 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?</comment>


USA to spend 500M on offensive and deadly Cyber Weapons [pdf] - <AUTHOR> https://www.fbo.gov/utils/view?id=185ca85709407f796ae81cb348f167bb <comment><USER2> Possibly inaccurate title? I see nothing in this that says it is $500 million to buy "offensive and deadly cyber weapons".

It looks more like a requisition for staffing of management and leads to help with (from the doc):

      This TO provides Cyberspace Operations support services to USCYBERCOM.
      ...
      1. Cyberspace Operations
      2. Cyberspace Planning
      3. Cyberspace Training & Exercises
      4. Strategy/Policy/Doctrine Development and Campaign Assessments
      5. Information Technology/Communications (IT/Comms)
      6. Business Area Support and Project Management
      7. Engagement Activities

      The objectives of this TO are as follows:
      1. Define and analyze cyberspace capabilities needed and Cyberspace Operations to meet both deterrent and decisive National Security objectives
      2. Conduct planning, integration, coordination, and execution, of the Cyberspace Operations mission ISO the Joint warfighter
      3. Receive, track, and resolve cyber issues and provide input to the Commander Situational Awareness Reports of Cyberspace Operations

Am I missing something? I didn't read the whole thing, but I did read a fair amount of it.

<comment><USER3> Nope - you've got it right. This looks like a typical operations and staff aug style support contract. Didn't see anything in here about buying cyber weapons. That said, C.4.2.13 Subtask 2.13 could be expanded to support something like that with the "REcommend, develop, evaluate, analyze, and integrate cyber weapons/tools/capabilities" line item. Sounds more like "developing capability" instead of "software development" which can be related to processes.

</comment></comment><comment><USER4> For the second time in a century humans have developed a technological advancement with the potential to change the course of our entire race for the better and all those in power care about is how to kill with it.</comment>


Show HN: Teleport Flock – plan the next meeting of your distributed team - <AUTHOR> https://flock.teleport.org

<comment><USER2> Looks quite good</comment>


Google braced for Brussels penalty over abuse of Android market dominance - <AUTHOR> https://www.ft.com/content/e41c8d86-6997-11e8-b6eb-4acfcfb08c11 <comment><USER2> It's about time. All credit due for thoroughness, but it's insane how long antitrust cases take. You'd think open and shut cases could be processed faster.</comment>


Snap: A Microkernel Approach to Host Networking - <AUTHOR> https://ai.google/research/pubs/pub48630/ <comment><USER2> "While early microkernel work saw significant performanceoverheads attributed to inter-process communication (IPC)and address space changes [15,16,20], such overheads areless significant today. Compared to the uniprocessor systemsof the 80s and 90s, today's servers contain dozens of cores,which allows microkernel invocation to leverage inter-coreIPC while maintaining application cache locality. This ap-proach can evenimproveoverall performance when there islittle state to communicate across the IPC (common in zero-copy networking) and in avoiding ring switch costs of systemcalls. Moreover, recent security vulnerabilities such as Melt-down [43] force kernel/user address space isolation, even inmonolithic kernels [25]. Techniques like tagged-TLB supportin modern processors, streamlined ring switching hardwaremade necessary with the resurgence of virtualization, andIPC optimization techniques such as those explored in theL4 microkernel [29], in FlexSC [58], and in SkyBridge [44],further allow a modern microkernel to essentially close theperformance gap between direct system calls and indirectsystem calls through IPC."

<comment><USER3> You're right to quote some text that addresses the idea that "microkernels are slow", which keeps popping up.

To that, I add this article[0], which is sufficient in destroying that idea.

[0][https://blog.darknedgy.net/technology/2016/01/01/0/](https://blog.darknedgy.net/technology/2016/01/01/0/)

<comment><USER4> IPC is a tad slower than not IPC.

However, stuff like WebAssembly and other sandboxing methods can be used to leverage two processes into the same address space. Your filesystem driver then simply lives as a module in address space and it's a normal process. The IPC turns into a simple jump using a pointer value provided by the kernel (which depending on the trust level can provide parameter validation or can be a plain pointer to the correct function).

<comment><USER5> How would that work? The entire premise of Microkernels is that everything runs in a dedicated processes such that if one crashes, the system can continue all other processes and only need to recover that single process.

The cost of switching processes are not a problem of address space, the MMU makes sure that is not a problem as shared memory is a reasonable tradeoff for certain domains where performance is necessary. Normally you'd rather want use messages but that is a different topic.

In either case, the cost of a process switch is handling the registers and cache - that will not go away no matter how you do it, which is why multicore implementation with messages can actually turn out being faster. Less switching and more locality.

<comment><USER4> Well, with webassembly the process can run under ring0 but still be isolated as if it was running in ring3. The crash mechanism isn't different; if the driver crashes then the kernel can kill it and deallocate it's resources, a device manager process can then restart the driver. The advantage is that you can include small, audited and verified binaries that can run code as ring 0 to remove abstraction from accessing the raw hardware.

The cost of switching processes is significantly reduced when you don't need to switch privilege levels and not having to invalidate the TLB as well as not having to change address space at all will make a context switch not significantly more expensive than a function call.

You get compile-time isolation and can still take advantage of the MMU when needed.

And using such an implementation does not prevent you from implementing your driver such that it can run on each core and take advantage of it or even passes messages. An ethernet driver could still, for example, pass a message when the "send data to tcp socket" function is called while allowing another program to use the same function without any message passing, depending on what is better for your use case.

<comment><USER5> I'm not sure I believe it's a good idea to give up on the hardware protection, as that leaves it to the software implementation to ensure it's secure. If you compromise an application in user mode, it will not get you far without another exploit in something that runs in supervisor mode. The hardware makes that certain, and it's well verified. We've seen time and time again that simple buffer overflows exploit things, and the more the runs in supervisor mode, the larger the attack surface is.

If a driver runs in user mode, an exploit needs to exploit the hardware as well - and that is for all intents and purposes something that we see very rarely.

If the same driver runs in "software user mode", but executing as supervisor (basically inside an VM environment), we need constant security checks in software, and an exploit now have the VM code to further exploit, if successful that will automatically grant it supervisor access.

In both cases it's assumed that neither implementation has access to more interfaces than necessary for it to do it's work. For instance, a driver for a mouse does not need access to the disks.

<comment><USER4> The thing is, you don't have to give up hardware protection. If you don't trust code, you can still run it in ring 3 with all the associated overhead. The point is being able to choose how close an application runs to "no overhead" until you're at a level where the driver is a function call away.

From my experience, a lot of hardware is terribly insecure against exploits. Not necessarily the CPU but stuff like your GPU or HBAs, ethernet cards, etc.

With software containment, the advantage is that you can set it up that drivers need to declare their interfaces and privileges beforehand. In an ELF or WASM you have to declare imported and linked functions, it should not be difficult to leverage that to determine what a driver can effectively do. With WASM you get the added benefit that doing anything but using declared interfaces results in a compile-time error.

A driver can be written so that a minimal, audited interface exists to talk to the hardware almost directly with some security checks and then the WASM part that handles the larger logic parts and provides the actual functionality.

WASM isn't a supervisor, so exploits on VM code aren't that relevant. Exploiting the WASM compiler/interpreter/JIT is more interesting but those are exposed to the daily internet shitstorm exploits, so I think they are fairly safe.

<comment><USER5> I suppose it remains to be seen if someone can make a PoC. I'm skeptical but ultimately I do not know enough to decide either way.

> it should not be difficult to ...

Famous last words.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> There are already so many software projects called Snap.

<comment><USER7> For Google that's a non-issue, they will simply promote their own use of the term over the previous uses.

<comment><USER8> Even Google has a limit though, they could've named their programming language "The".

<comment><USER7> I would say taking the '+' character and attempting to make it their own is proof positive that they don't have limits.

</comment></comment></comment></comment><comment><USER9> Wonder if their MicroQuanta microsecond granularity Linux scheduler would be useful for other near realtime things like audio or electronics interfacing. I guess the low latency scheduler is a key part of making Snap work in userspace.

[https://lkml.org/lkml/2019/9/6/177](https://lkml.org/lkml/2019/9/6/177)

</comment><comment><AUTHOR> "A change to the kernel stack takes 1-2 months to deploy; a new Snap release gets deployed on a weekly basis."

<comment><USER10> At many companies rolling out a new kernel in a month would be an outright miracle.

</comment></comment><comment><USER10> The actual paper, where their TLS certificate is not yet expired, is [https://storage.googleapis.com/pub-tools-public- publication-...](https://storage.googleapis.com/pub-tools-public-publication- data/pdf/36f0f9b41e969a00d75da7693571e988996c9f4c.pdf)

</comment><comment><USER11> Unpopular opinion ahead:

The deal with user facing libraries like this is that I'd rather they generalize this and expose the existing network library drivers with a uring interface, and the user processes can take care of packet decap the way they want it.

Of course, helpful to have the stub to map the PCI BARs to userspace, and hopefully without any message signalled interrupts.

These two alone, may be hard to do, with all the existing network drivers out there. Engineering feats like these are good but not helpful to most people unless they are simple and generic enough to work on most devices.

I hope the guys who wrote this take note and eventually layer out and open source this library.

</comment><comment><USER12> looks like certificate for ai.google expired today, what a coincidence!

<comment><USER13> And with HSTS, modern browsers will make sure you can't ignore it :) In the meantime [https://storage.googleapis.com/pub-tools-public- publication-...](https://storage.googleapis.com/pub-tools-public-publication- data/pdf/36f0f9b41e969a00d75da7693571e988996c9f4c.pdf) works.

<comment><USER14> Not sure about Firefox but in Chrome you can type "thisisunsafe" on the page to bypass even HSTS (you can test at [https://subdomain.preloaded- hsts.badssl.com/](https://subdomain.preloaded-hsts.badssl.com/) )

</comment></comment></comment><comment><USER15> Oops, the TLS cert on this site expired just nine minutes ago.

<comment><USER16> Is it still safe?

</comment></comment><comment><USER17> "Snap has been running in production for over three years, supporting the extensible communication needs of several large and critical systems."

Are there many systems using microkernels in production environments? I mean at least at this kind, or a somewhat similar, scale?

3 years seems like a long time, while up until this moment microkernels seemed fairly niche to me and something reserved for more experimental systems.

The only one I can think of off the top of my head is Fuchsia.

<comment><USER18> QNX has been around for quite a while and used across many areas: [https://blackberry.qnx.com/en](https://blackberry.qnx.com/en)

Edit: The Wikipedia entry has a little less fluff than the official homepage: [https://en.wikipedia.org/wiki/QNX](https://en.wikipedia.org/wiki/QNX)

</comment></comment><comment><USER19> I'm surprised that microkernel-like IPC still hasn't found its way into any *NIX system. The closest we've gotten is System V IPC, which has never really taken off.

Is this just difficult to design well or are people genuinely okay with socket(AF_UNIX, SOCK_SEQPACKET, 0)?

<comment><USER20> I don't think it's difficult to design an IPC mechanism. But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC, others also asynchronous (out of order responses), some want multicast, some want events without associated request, some want pub/sub, etc.

If at the end people continue building their own IPC mechanisms on top of TCP/IP or unix domain sockets then the in-kernel mechanism will just be another thing to maintain.

There had been some endaveurs to bring new IPC mechanisms into the Linux Kernel (AF_BUS, KDBUS, BUS1). I think those failed for similar reasons (although I'm not sure were BUS1 now is - the others are definitely discontinued).

<comment><USER7> KISS: QnX MsgSend, MsgReceive, MsgReply. That's really all it takes.

[http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2F...](http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_lib_ref%2Fm%2Fmsgsend.html)

You can go all the way from the lowest level kernel uses to very high level application constructs with that. Re-inventing existing wheels badly is something the software world excels at.

<comment><USER21> > That's really all it takes.

Not quite. Those functions need established connections, so you need ConnectAttach and ConnectDetach as well. But none of that is useful unless you can identify clients so you also need ConnectClientInfo.

This isn't a dig, having worked on a custom IPC system I found the QNX approach to be the best of all worlds.

<comment><USER7> Sure, but the essence of the actual transfer, the part where performance matters is send/receive/reply.

</comment></comment></comment></comment></comment><comment><USER22> Projects need to stop calling themselves snap

<comment><USER23> ans to dead question.

> Do they pay people to do this?

Yes you fucking bet they do.

<comment><USER23> > 0 points by Gibbon1

Makes my point</comment></comment></comment>


Samsung phones don't let users delete Facebook - <AUTHOR> https://www.bloomberg.com/news/articles/2019-01-08/samsung-phone-users-get-a-shock-they-can-t-delete-facebook <comment><USER2> Same thing with my Sny phone. But the solution is simple

1) deactivate the app, as stated in the article

2) create a shortcut to mbasic.facebook.com. This allows private FB messages without the need for Messenger

3) Prefer discussions in private groups to avoid spamming all friends with one's Facebook activity.</comment>


The world's best countries [Infographic] - <AUTHOR> http://www.newsweek.com/2010/08/15/interactive-infographic-of-the-worlds-best-countries.html

<comment><USER2> Ah, another one of those country rankings designed to provoke flamewars, chest-thumping, brow-beating and teeth-gnashing.

The error bars on these sorts of things are big enough, though, that any country in the top twenty or thirty is a pretty damn good place to live, so if you live in one of those you should be happy.

If you live in the bottom twenty or thirty... well, sorry, your country sucks, you should move to a better one.

<comment><AUTHOR> It's amazing how uneven the overall living conditions are across the world, yet so many people who are living in one of the top 20 countries still complain that they don't have enough opportunities and can't do what they want, while other people from the rest of the countries would change to world if they would have the opportunity to live in a better place.</comment></comment>


Apis Cor builds world's largest 3D-printed building in Dubai - <AUTHOR> https://www.dezeen.com/2019/12/22/apis-cor-worlds-largest-3d-printed-building-dubai/ <comment><USER2> It's almost poetic how the robot uses one of the most primitive forms of building a 'hut': stacking layers of mud.

I believe a combination of printing prefab pieces at the site in a controlled environment could also be a great possibility.

</comment><comment><USER3> Apis cor had some dealing with Samsung I remember. To me, they felt almost like marketing shop for their partners than a genuine engineering company.

When I voiced something about their engineering during an event, they weren't really able to reply with anything other than recital of their marketing.

IMHO, in its current iteration, 3d printed building are completely nonviable commercially.

The main point of 3d is to expensive, and error prone manual labour with a single pass automated process. 3D printed buildings as of now require more labour, more operations, and more materials than most conventional building techniques.

<comment><USER4> If we are still thinking of a house that has hidden wires in the walls and plumbing that is hidden in walls.... Then yes, printed homes as they are currently are not going to work.

If we embrace exposed conduit, exposed ducting and exposed plumbing lines, printed homes could be an order of magnitude cheaper.

<comment><USER3> What about getting a house with conduits for hvac, electric, and plumbing, and still get it cheaper than 3d?

Construction technologies to make lowrise housing super duper cheap are already here: panels, lgsf, large prefabs, light concretes

And for really tall highrises, they are already coming within 50-40% of their materials costs in Asian countries. So for them, it will make no difference even in the most optimistic case.

You can't do much physically about price of steel and cement, other than finding ways to use less of them.

</comment></comment></comment><comment><USER5> I don't understand why these are considered notable. A building is a lot more than simply the concrete. In fact I would say that pouring the concrete is not that difficult or time-consuming. There's a lot of work that comes before, such as excavation and compaction and grading. There's a lot more work comes after to rough in plumbing, electrical, HVAC, etc. And then of course the finishing.

So what is the net benefit of this process?

<comment><USER4> If you could own a $10000 dollar machine where you add concrete and a sd- card... then it printed a new room for your house, wouldn't that be revolutionary?

I don't know how much these machines will cost in the future, but I do know that I would love to have one. Construction is very expensive even for houses that are basically sticks and stucco. I would like to buy some land and print a house with modules for plumbing, electrical, etc. This enables a complete rethink of how we currently build homes.

<comment><USER6> No. In that sense, you can already just give a guy at the Home Depot $500 to "add a new room to your house". Are you living the revolution?

If construction is labor-intensive and expensive, stick framing is the cheapest and easiest part. If you come up with an automated solution that replaces the need for expensive interior finishing processes, you'll have a huge market... finishing out existing stick-framed construction. No one selling houses wants this.

If you want to use modern technology to mass-produce homes with less labor, that's called prefabricated construction and it's a process that's only about a _thousand_ years old. Someday robots will do it all automatically on-site but we're no where near doing that in the foreseeable future, in part because the demands on houses are predictably rising at pace with the capabilities of robots.

I don't mean to be snide, but this is a little like dropping by a homebuilding forum and they're all talking about how some day soon desktop PCB fabrication is going to replace all of Silicon Valley, because they don't _quite_ know the difference between a chip and a circuit board. It's just embarrassing, y'all.

<comment><USER3> > If you come up with an automated solution that replaces the need for > expensive interior finishing processes

There is already a large panel prefab process, which is highly automated, including finishing, but it doesn't seem to be anywhere near "revolutionising" the industry.

The thing is, in North America the preference for single family houses is so strong that making people care about extra $100k is really hard.

</comment></comment></comment></comment><comment><USER7> I spoke to one of the founders to explore opportunities and partnerships with my professional network.

They are not consumer facing. They are looking for partnerships and investment.

</comment><comment><USER8> Lots of cynicism in the comments here, but what the potential applications of a technology like this on the Moon or Mars?</comment>


Libraries, languages, the cathedral and the bazaar: a social Haskell - <AUTHOR> http://blog.ezyang.com/2010/08/the-radical-hackage-social-experiment/

<comment><USER2> I think it may turn out that the real genius of Scala (and Clojure) may be in discovering the only truly viable model of real-world adoption for a functional language - piggybacking on a bigger, dumber, mainstream success. Just consider what Scala gets for free that Haskell has to build itself: a fast, robust VM, libraries for any mundane thing under the sun, and a foot in the door at any common dev shop.

The real cathedral vs bazaar issue here is deeper than the library issue. It's the runtime that counts and sharing a runtime with something like Java delegates all the grunt work to the legions of Java programmers and lets Scala hitch along for the ride picking up all the interesting work on the top of the heap. The future of functional languages is in symbiosis.

<comment><AUTHOR> Your comment seems to imply that a lot of resources are wasted developing the runtime. However, that's not the case. E.g. the Haskell runtime is kind of "done" -- its not like that's the weak spot, going by any metric.

And it is robust and has great performance.

[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc)

Having a runtime doesn't free up any grunt programmers -- since they're not involved in writing the runtime in the first place.

\</comment></comment><comment>-

 _Edit_ I really don't understand "sharing a runtime with something like Java delegates all the grunt work to the legions of Java programmers"

sharing the _libraries_ helps delegate gruntwork. Sharing the runtime does very little for a mature language.

<comment><USER2> Haskell does seem to have a good runtime, although I've read lots of posts talking about problems with high memory load. How much could you have accomplished if you hadn't had to spend resources on building that runtime though? How much energy are you going to expend going forward maintaining parity with the JVM, with 1/100th of the resources?

And I really do mean _runtime_. You can share libraries in any language but sharing a runtime with Java means I get things like bulletproof Oracle drivers, Hadoop, Netty, Mina for free and I can use Scala at the top of a very rich food chain. It took me all of about 15 minutes to get Hadoop queries running in Scala. What's the Haskell story there?

<comment><AUTHOR> > get things like bulletproof Oracle drivers, Hadoop, Netty, Mina

No, that means sharing libraries. You're using Java libraries now. The JVM has nothing to do with Oracle.

> read lots of posts talking about problems with high memory load

Look at the shootout stats. The JVM is a memory hog in comparison.

<comment><USER2> _No, that means sharing libraries. You're using Java libraries now. The JVM has nothing to do with Oracle._

I'm sharing libraries _with Java_. I don't have to wait for somebody to write a Scala version. Big difference.

The JVM is a hog but it also holds up really high well under high memory and CPU load. Much better than most other VMs.

</comment></comment></comment></comment><comment><USER3> This article got me thinking a little. I know base pretty well; whenever I'm writing some code, I always end up hitting the "source code" link and checking out the implementation. I never really wonder "how does this work" as I'm programming anymore.

The question is, how can one go from knowing a library to contributing to the library? One of the problems with HackageDB is that you can see everything, but you can't see where you can make changes.

I had a problem with C2HS a few months or so ago; it didn't work on Windows (because DLLs use "stdcall", not "ccall", and the "ccall" string was hard- coded). I clicked the darcs link on Hackage to get the source. Dead. So I just edited the source on my local machine and moved on.

A few months later I noticed that darcs was working again and there was a new maintainer, and I did get to contribute my patch. But it was kind of dumb luck, I could have easily had never noticed, and this bug never would have been fixed.

So right now, it's easy to find libraries, it's easy to understand libraries, but it's not always easy to improve the libraries. And incidentally, the biggest problem with libraries in Haskell is that they never get out of the "rough draft" stage, by getting contributions from people other than the author.

Incidentally, I don't have this problem with Perl, because everyone happens to use Github. This has created an interesting effect where libraries that aren't on Github become very difficult to work on, and people seem to favor rewriting instead of fixing things "the old way". (diff + an email to the author.)

</comment><comment><USER4> What sucks is that Hackage has been down all day (and is down not infrequently) and I've needed it desperately. Also, Don Stewart's (evangelized by OP) 'Download' package won't build on OS X, with a different cryptic error message than it gave me last week. Yes, these are piddly little whines of personal anecdote, and objectively it's absurd to suggest should be flawlessly and continuously taken care of by the Haskell establishment at this stage in its development, but Haskell is pretty quickly becoming my language now:

I love it, I think in it, it is a daily struggle to fight the urge to evangelize like a douchebag. With the problems I've just mentioned, I'm writing what I need to in Python, hideously functional Python that would make Guido cry, but prototyping everything in Haskell. If this stuff is pissing me off, a momentarily curious Ruby bro sticking his neck out and cautiously circling the >>= in the stone is going to get bit, fuck off and not look back.

Please build the cathedral soon.

<comment><AUTHOR> > package won't build on OS X

There is a binary installer. We're discussing how to work with MacPorts, but at the moment it only has 3rd party support status.

<comment><USER4> ... whoa, that's pretty cool. Also, I feel like a douchebag. Thanks for building and sharing this stuff at all. Where's that binary at?

Also, what's this about MacPorts? I only ever tried using cabal (as installed with Haskell Platform) and have no understanding of the structure of the underlying installation. As perhaps the prototypical semi-clueless amateur, potential vanguard of the article's "mainstream", who's stumbled early onto this serious and enormous thing, I am scared and confused by the idea of having to install MacPorts again to muck up my pretty filesystem.

<comment><USER5> <http://hackage.haskell.org/platform/>

Works like a charm!

Only hitch I had was that the prebuilt libraries are 32bit, and if you want to link something to a native library under Snow Leopard, and said library happens to be available only in 64bit, you're out of luck. Case in point: I tried to customize XMonad under X11.app/10.6 with a custom xmonad.hs. Running straight XMonad worked fine, but trying to use the recompilation failed... -> Would be nice to have a 64bit Haskell Platform build.

But that's probably a more exotic usecase as you'd usually either stay in Haskell-land (which compiles in a compatible way), or link against *nix style libraries, which you probably fetch via MacPorts, and there you can control the compilation as well.

A big thank you to Don for the packaging effort, it's very much appreciated by newbies (incl. me).

</comment></comment></comment></comment><comment><USER6> Wow, I started reading this without looking at the bottom to see what the proposed solution was. It turns out there is none.

Still, it was pretty interesting for the quick analysis of the various ways that an open source programming language's basic libraries are currently developed.

<comment><AUTHOR> Well, this is an exposition of the solution space that is currently being explored. Hackage 2.0 will go live soon, which exhibits many of these characterstics,

* "batteries"/cathedral-style core: the Haskell Platform * bazaar/CPAN-style cloud: hackage * distribution mechanism: cabal * social aggregation: hackage 2.0 voting and ranking</comment></comment>


Judiciary Launches Redesigned Pacer Website - <AUTHOR> https://www.uscourts.gov/news/2020/06/26/judiciary-launches-redesigned-pacer-website <comment><USER2> Long overdue.</comment>


DMT Models the Near-Death Experience - <AUTHOR> https://www.frontiersin.org/articles/10.3389/fpsyg.2018.01424/full <comment><USER2> It sounds very... Odd? Basically they asked questionnaires to two totally unrelated groups (people who took DMT; and people who had NDEs in the past) and then did some ANOVA magic in SPSS and decided that they were related because people score similarly on a quiz? I'm a bit confused by how reliable this method would be. Also the sample size < 20 seems questionable to me.

But this is just me with very little statistics experience so I am probably wrong in all these thoughts. And there's probably someone way more knowledgeable who can give a better opinion about the research methods and results

<comment><USER3> Yes. This is, to put it plainly, pseudo-scientific bullshit.

<comment><USER4> Eh, it's a very limited study that basically says two sets of subjective effects are similar. Useless, maybe, but not pseudo.

<comment><USER3> Many things share similarities, and aren't otherwise related.

</comment></comment></comment></comment><comment><USER5> Further than this, DMT is endogenous and protects against hypoxia:

[https://www.frontiersin.org/articles/10.3389/fnins.2016.0042...](https://www.frontiersin.org/articles/10.3389/fnins.2016.00423/full)

[http://beckleyfoundation.org/2016/09/15/the-first-study- to-s...](http://beckleyfoundation.org/2016/09/15/the-first-study-to-show-that- dmt-protects-brain-and-immune-cells-under-stress/)

Some are lead to believe that DMT is released during a NDE as a last attempt at survival.

<comment><USER6> There is also a pretty interesting movie: "DMT: the spirit molecule" [0] which touches the topic of releasing DMT during NDE.

[0] [https://www.youtube.com/watch?v=LtT6Xkk- kzk](https://www.youtube.com/watch?v=LtT6Xkk-kzk)

<comment><USER5> Rick Strassman's book which this film was inspired by IIRC is a great read that I found hard to put down. People like him, at least how he comes across in his book, seem to deserve a lot of credit for the psychedelic science renaissance we are now experiencing.

</comment></comment></comment><comment><USER7> Ive never had a NDE, but I have had DMT. Reality itself pales in comparison to how "real" and vivid the experience was.

Unlike other hallucinogens which apply a "filter" to the senses, DMT was like a wormhole to another dimension.

If that's what death is like, it makes me think consciousness would asymptotically approach anhiliation but live "forever" in whatever state a DMT trip is.</comment>


Ask HN: Which browser is your default, and why? - <AUTHOR> On Linux I used https://en.wikipedia.org/wiki/Conkeror for its speed. On Windows Ive been mostly in Opera but frequent crashes and problems with many Google apps made me switch to Chrome again.
I've loved Braves privacy and Operas/Firefoxs ability to send tabs directly to my phone, but not so much that I can stand instability.
tl;dr: Im back in Chrome and not too happy about it. <comment> green-bottle Firefox. When I first got to use a Computer to surf the internet I remember using Firefox and that is what I have used ever since.

A lot of people here have said that Firefox was a slow and bloated mess pre- Quantum. I suppose I stuck to Firefox when most people shifted over to Chome because my internet connection had been slow enough that internet was unusable without javascript and images disabled (this is no viable as a significant proportion of websites don't work without JS). Hence my browser ran pretty light and never gave me any issues.

At work for development I now use Chrome (for devtools) as Firefox still chokes up on really large javascript files. For anything else Firefox remains my default as it is comparable to chrome now in terms of performance (this only means I haven't noticed any noticeable difference for my web browsing workloads) and has a lot of features that I like (containers, customisability,...).

edit: The above refers to my choice of browser on Desktop.

</comment><comment><USER2> I use Brave, previously was a Chrome and Opera (but never again after I learned what the f is going on there).

I love that it has the chrome ecosystem but with better built in privacy and some other extra features I wanted (right click and block element). Everything works, sometimes sites break due to script blocking but that's a click away to fix.

<comment><USER3> thecupisblue _> "...previously was a Chrome and Opera (but never again after I learned what the f is going on there)."<_

What _is_ going on there?

<comment><USER2> [https://hindenburgresearch.com/opera-phantom-of-the- turnarou...](https://hindenburgresearch.com/opera-phantom-of-the-turnaround/)

<comment><USER3> What a great analysis and reveal. Thank you!

</comment></comment></comment></comment><comment><USER4> For Windows, I prefer _portable_ first, I don't want some auto running background services from Google/Mozilla. So I chosen IronPortable & Firefox Development Portable. For Linux, I sticked with default Firefox from OS repository. For mobile, I highly recommend Kiwi Browser - the one of very few Chromium base which let you install Chrome extension like Ublock.

<comment><USER5> Nice! Firefox Mobile also lets you install extensions like uBlock. I thought it was the only one.

</comment></comment><comment><USER6> Firefox. It doesn't feel like it's actively working against my interests, unlike Chrome and Safari.

</comment><comment><USER7> Using GNU/Linux on all my computers at work and home and I have Firefox as my default one. I trust it the most when it comes to protecting my privacy and having an open/democratic governance of the project.

</comment><comment><USER8> Firefox.

Because Mozilla is actively (and publicly) committed to privacy, which is the opposite intention of Google (Chrome) and Microsoft (IE/Edge/Whatever).

</comment><comment><USER9> At home I'm using Vivaldi as my main browser. As a heavy YouTube user Firefox isn't a option for me, it crashes frequently and the performance is inferior than Chrome (I think it's not their fault, but it turns it unusable anyway).

Vivaldi has the benefits of Chrome for Google sites, is much more customizable than Chrome and it has some nice features that those who used Opera 12 in the past would feel happy about, like tab stacking, tree view and my favorite: mouse gestures. All baked in the browser without the need of buggy extensions.

I wish I could be back to Firefox and support the work they are doing regarding privacy, and I'll keep testing every release to see if there are any improvements to performance.

</comment><comment><USER10> Safari because it integrates with all my Apple devices and it's much more battery/memory efficient than Chrome.

The reader mode is fantastic and the password autofill/keychain works great on all my devices too.

</comment><comment><USER11> Firefox without interruption since 2004/2005 sometime. I almost switched due to how slow FF had gotten compared to Chrome. Improvements FF have made more recently have kept me very happy as a user. On mobile I use Chrome.

I dislike FF's increasing sprawl / bloat. I suppose a browser with <1% device market share has to survive somehow. I dislike how they instigate opted-in spyware from first install now ("Firefox Data Collection"). I like how text renders on FF versus Chrome, their engine produces a superior aesthetic.

</comment><comment><USER12> Firefox for day to day activities and work, but when I have to use websites that are only available in their native languages I use chrome for the translation capabilities.

</comment><comment><USER13> Pale Moon at the office for anything even vaguely non-work related (i.e. anything I'd browse on my lunch break, etc.). Google Chrome for all official work stuff. At home, Vivaldi on Linux for absolutely everything.

Even with that strict separation, the cross-over of adverts from home to work is astonishing. There are things I search for at home that I absolutely don't want showing up on my corporate browser.

</comment><comment><USER14> I use Safari for all financial services, Chrome for Google stuff, newspapers, and some other sites I'm fine with being logged into and tracked, and Firefox for routine web browsing (like hn). Firefox is set to purge all cookies and offline data on closing. Chrome is set to purge offline data if I "log out" of Chrome. I use Vivaldi occasionally for questionable sites.

</comment><comment><USER15> Firefox. I am using it since 2008. Once I tried to switch to chrome, but memory and other issues were there. The initial reason I used firefox was for firebug,Chrome was not even launched at that time. I have now a soft spot for Firefox, But on mobile I use Chrome, firefox lite is looking impressive but I will wait to get it matured.

</comment><comment><USER16> Firefox, because it starts up fast, allows me to customize it to fit my system color scheme, and lets me set up autohide for the toolbar. I open and close my browser constantly so startup time is more important than how fast it is when running. Also chrome doesn't fit with my theme and has a big address bar so it looks ugly.

</comment><comment><USER17> Chrome on Mac, it's convenient, and despite robbing all the RAM my 2015 MBP has to offer, it works well.

I tried switching to FireFox for two weeks, but found a lot of visual tearing/glitches, and it didn't have pinch to zoom which I use on Chrome constantly.

</comment><comment><USER18> Safari because the integration with iCloud Keychain, Apple Pay, and its ability to show videos "Picture in Picture" in the Mac from sites such as YouTube. At work I use also Safari, but 40% of the time I use Chrome because the Safari dev tools are kind of limited IMHO

</comment><comment><USER19> At Home (Windows), use Firefox browser with add-ons for ad blocking, media control etc

At Work (Windows), use Chrome. Like their dev-tools for debugging purposes.

On Mobile, I use default Samsung browser on Note 8. I believe browser is lightweight and fast with ad blocking feature.

<comment><USER20> Same. Samsung internet is a hidden gem for android.

</comment></comment><comment><USER21> Chrome for work because i like the dev-tools and most of our users are on it either way.

FireFox for everything personal because its fast and i love the containers.

On Android I also use Firefox because I like having extensions to block ads and get youtube to play videos while the screen is locked.

</comment><comment><USER22> Firefox so I can keep my mobile and desktop experience the same and keep away from the big G

</comment><comment><USER23> Used to use Chrome, now I use Brave for home & mobile browsing. At work I'm locked into "approved" browsers so I'm using Chrome. The only alternatives are IE/Edge.

</comment><comment><USER24> Google chrome. At the end of the day, this is the most convenient one for me

</comment><comment><USER25> Firefox. If not for some stupid corporate policies, I would use it at work too. Tried Vivaldi cuz the cool kids were using it but didn't get around to explore all its features.

</comment><comment><USER26> Firefox for everything but development.

I actually run both simultaneously and it's handy because I know docs/notes/confluence will be in the FF windows and dev stuff in Chrome's

</comment><comment><USER27> Finally uninstalled Chrome after X amount of years after using Brave successfully for a year. Kept Firefox around just in case. :)

</comment><comment><USER28> Firefox by far. Besides being a browser that doesn't spy on you, it is light on resources, fast, and has tab sending to all my devices.

</comment><comment><USER29> Chromium. Does everything I need it to. No reason to switch. Also Firefox DoH plan concerns me

</comment><comment><USER30> Firefox because privacy. Also container tabs to keep multiple accounts open on the same site, etc.

</comment><comment><USER31> Google chrome

<comment><USER32> The question was which browser and why.

</comment></comment><comment><USER33> Safari for everything personal, Chrome for work-related and Firefox for banks.

</comment><comment><USER34> at home:

        MacOS X: firefox developer edition
        Linux: firefox

( basically for privacy concerns )

at work:

       MacOS X: chrome/safari

( chrome/safari are the target platforms for our SPA on mobile )

</comment><comment><USER35> Chrome, because nobody bothers to do cross browser testing :(

</comment><comment><USER36> FireFox at home, the new Edge for work/development.</comment>


Oil prices could fall below zero: Analyst - <AUTHOR> https://finance.yahoo.com/news/oil-prices-could-fall-below-152446634.html <comment><USER2> > He says the "physical reality" of the market is that oil is pumped out of > the ground and has to be consumed or stored. When the cost of storage goes > high enough -- or space runs out -- companies might pay customers to take > it.

Wild. Kind of like negative yield, but for a physical good.</comment>