Edit: More Research

There's only a small number of elements affected by slds-hint-parent even appears in SLDS. I suspect that this CSS rule is probably on the way out, since it doesn't do anything in Data Tables in the current version. The items that still has rules for slds-hint-parent are: buttons, button icons, and data table/inline edit. The main purpose is to provide a visual cue that something is active. It appears to be on the way out, though, since it's still using the slds-*--* CSS style name (newer styles use slds-*_* instead). At this point, I don't think I see a reason for using it, since it's no longer in the documentation. However, just to be sure, I'm going to ask the Salesforce UX team for clarification.

slds-hint-parent provides a visual cue for certain types of elements when the user moves the cursor over the object, particularly icons. It's rarely mentioned in the documentation, but we have a few quotes.

If a navigation bar item has an icon then we want to provide visual indication that its active when a user hovers into its region. To make this happen, apply the class .slds-hint-parent to the hover region, most cases would be .slds-context-bar__icon-action element.

--Global Navigation

.slds-hint-parent

Applied to: <tr>

Outcome: Highlights action overflow ribbons on row hover

Required: No, optional element or modifier

Comments: When you have an overflow action menu

--Data Tables

As you can see, its primary purpose is to provide hinting for active elements.

Lightning web components (LWC) are a new programming model for the Lightning Component Framework that is slated to be released in the Spring 19 release. This programming model was architected with three principles in mind.

• Align with modern web standards
• Interoperability with the original Aura-based Lightning component development model
• Performance

Standards

LWC is compliant with most ES2015 (aka ES6) and later standards that have seen good adoption across modern browsers. JavaScript APIs such as Class, Module, Shadow DOM, CustomComponent, decorators, mix-ins, and many more figure heavily into the architecture, as do modern HTML and CSS features. This brings a great deal of benefit for the developer. First, the main body of knowledge and skill required is modern JavaScript. It also brings a much simplified component bundle structure and developer experience where a given component is comprised solely of an HTML template, a JavaScript module, and a CSS file (where required).

Here's a screen shot of the component bundle (no CSS) in a project in VisualStudio Code.

Here's an example of the code from a Lightning web component:

HTML Template:

<template>

    <lightning-card title="RecordEditFormDynamicContact" icon-name="standard:contact">

        <div class="slds-m-around_medium">

            <lightning-record-edit-form
                object-api-name="objectApiName"
                record-id="recordId">
                <lightning-messages></lightning-messages>
                <lightning-input-field field-name="Name"></lightning-input-field>
                <lightning-input-field field-name="Title"></lightning-input-field>
                <lightning-input-field field-name="Phone"></lightning-input-field>
                <lightning-input-field field-name="Email"></lightning-input-field>
                <div class="slds-m-top_medium">
                    <lightning-button variant="brand" type="submit" name="save" label="Save"></lightning-button>
                </div>
            </lightning-record-edit-form>

        </div>

    </lightning-card>

</template>

JS Module:

import { LightningElement, api } from 'lwc';

export default class RecordEditFormDynamicContact extends LightningElement {
  @api recordId;
  @api objectApiName;
} 

While this is a very simple component that simply surfaces two attributes (the @api decorated properties), you can already see how the JS code reflects modern standards in the import statement for including other JS modules, the export of the class of this module, the use of the class and extends syntax, and the use of JavaScript decorators.

Interoperability

In designing a new programming model for the Lightning Component framework, interoperability with existing Aura-based components is a must. With the GA of LWC, any component built using the LWC programming model can be used in an existing Lightning Component page. To prove this model, Salesforce have used LWC to build Lightning base components for the last year. Any of your existing Lightning Web Components that use a lightning:xxx base component is already using LWC.

Performance

Salesforce has yet to publish any benchmarks or performance data related to Lightning Web Components. But look for upcoming blog posts from the LWC engineering team.

Anecdotally, as more and more of the Lightning Experience UI has become composed of LWC over the past year, many customers have reflected back to Salesforce an experience of better performance.

Learn More

For more details about LWC, please see the introductory blog post on the Salesforce developer blog which has many links to documentation, sample code and applications, and of course, Trailhead.

Aagh! I don't want to read a whole blog, I just want to do something!

No problem. Just go to this quick start project on Trailhead and get the badge.