Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Fast Design

fast.design

Post reply on HN
Print view View original

171–180 of 216 posts

Re: Microsoft Fast Design

#171

Post by pupdogg »

parksy wrote: post #134
pupdogg wrote: post #111

Earlier quoted context omitted.

What I meant was that are a lot of like minded developers here who cringe every time they have to hear how JS is going to teleport us from Earth to Mars. And since there are no bonus cookies that can won by proving that you can create a functional website simply by using some good old HTML with CSS and vanilla JS, a lot of us resort to being silent and enjoy the show! So, what do ya say? Would you React the same way?…

It's funny because in writing my previous reply to you I felt a momentary sense of inclusion into a special club, I did think something along the lines of "should I just enjoy the show" and then on reflection I realised that taking such a stance would be equivalent to having no voice at all, and it would also essentially evaporate my chances to learn anything new from the good folk here as it would set up a "me vs th…

Take it easy Freud, there’s no need to break your intellect down into so many pieces and get personal. Cheer up!

Re: Microsoft Fast Design

#172

Post by russellbeattie »

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

Re: Microsoft Fast Design

#174

Post by jjcm »

rckoepke wrote: post #162
jjcm wrote: post #24

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 element. In this situation a shadowroot does nothing to help. All it me…

Just curious - where did you learn this level of detail w.r.t DOM, and what would you recommend I take a look at to learn it the right way?

Honestly just by making components and benchmarking them. Webcomponents are too new to really have a solid best practices guide at the moment and there's a lot of varried opinions out there. My main recommendations are to benchmark early and often. Tachometer is a library from the polymer team that I find does this very well:

https://github.com/Polymer/tachometer

I.e. for testing shadowroot performance, I threw this together: https://github.com/jjcm/shadowTests

You can see the results here: https://raw.githubusercontent.com/jjcm/shadowTests/master/re...

TL;DR - a custom element with no shadowroot is about twice as fast.

Re: Microsoft Fast Design

#175

Post by jjcm »

infogulch wrote: post #34
jjcm wrote: post #24

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 element. In this situation a shadowroot does nothing to help. All it me…

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?

It's more than one unnecessary level of nesting in the DOM, it's that they're creating an entirely separate DOM tree they aren't using. I threw together a test using tachometer to demonstrate the differences: https://github.com/jjcm/shadowTests

The results are here: https://raw.githubusercontent.com/jjcm/shadowTests/master/re...

TL;DR - the withShadow element takes about twice as long to render as the withoutShadow element. Don't use them unnecessarily.

Re: Microsoft Fast Design

#176

Post by zelly »

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.

Re: Microsoft Fast Design

#178

Post by zelly »

chrisweekly wrote: post #82

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

I think a Web Component is meant to be like a . 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.

Re: Microsoft Fast Design

#179

Post by abraham »

zelly wrote: post #176

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.

What makes you say web components are slow or have an unstable API?

Re: Microsoft Fast Design

#180

Post by zelly »

abraham wrote: post #179
zelly wrote: post #176

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.

What makes you say web components are slow or have an unstable API?

It's slow and unusable, not unstable. The one benefit of WC is that it's going to be stable for the next hundred years, just like 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

Post reply on HN