anthonyshort

https://www.dese.gov.au/quality-schools-package/fact-sheets/...

A simplified example of how the UX can break down if frontend teams are too isolated is notifications. If every team triggers a bunch of their own notifications the user might be getting slammed with notifications.

Sure the pieces might look cohesive, but it might suck for the user if the teams aren't thinking about it from the perspective of a user.

It seems useful for UI primitives, like a dialog, tooltip etc, that the browsers might not implement as native elements themselves. But as a building block for creating entire applications? I don’t think so.

Which means they’re always going to need to hook into the framework that’s rendering them, either to connect state, managing effects, or for styling.

I just don’t see sharing a component regardless of framework as a major problem worth solving right now. Buy into a framework and community like React and you can just drop components into your app. It’s not framework-agnostic but it works.

Web components kind of miss a lot of the reasons why React has taken off. Encapsulation is one thing but it’s the declarative way of handling state, effects, and the DOM that make it powerful. Web components would need a framework on top of it to make it usable by developers building anything significant.

Designers often get associated with fluffy exercises so I want to kill that stereotype. I don't think I've ever worked on a product team that used demographic personas like these.

Everyone is taking this fairly seriously. I doubt HN is the target demographic for this sort of thing though.

There's no pressure in the market to not value UX. Everyone wants and needs that. If anything there are pressures to only value efficiency rather than delight. Sometimes "fun" isn't efficient.

I think the problem people are struggling with is that it's a site created mostly for fun and delight, but the message is about "UX", which people generally think of as a way to maximize efficiency.

Products don't always need to be relentlessly efficient to be considered useful or "good". Some products are created for you to just enjoy.

I hated it (a lot) before I tried it out. You could just put the render function in a separate file since it's just a function and then it's basically the same as a template anyway

The original plan was to make a virtual dom plugin for ripple but it wasn't really possible with the way the worked behind the scenes.

Although there's no real benefit of doing that over using the manifest other than it's kinda cool :)

If a component.json is present, it'll use that to get the versions and you just require('emberjs/ember-component')

Point is, just use the git repos instead of needing that registry at all.

It still batches all changes using requestAnimationFrame and it'll support Object.observe when that's ready.

Yep, you can nest views in a similar way to React. It's not exactly the same, but it's similar. Data is kept in sync and components are re-usable.

Communication between views is either through events, passing in callbacks, the dispatch plugin (uses custom DOM events and bubbling like Flight). There are a few ways to do it depending on the problem. Views have references to their children and the owner too.