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

What dif­fer­enti­ates front-end frame­works

themer.dev

Post reply on HN
Print view View original

111–120 of 256 posts

Re: What dif­fer­enti­ates front-end frame­works

#111

Post by hinkley »

stickfigure wrote: post #90
hinkley wrote: post #79

Earlier quoted context omitted.

At peak jquery, I argued successfully for storing the metadata on DOM, because then you have a system of record, upon which you can build a straightforward source of truth. React does a ton of work to solve that architectural puzzle another way. The thing I have run into over and over again is that when we try to pretend the system is Y when it is in fact X, inevitably the impedance mismatch results in 1) bugs that s…

Data comes from the server as JSON. Data comes from the user as DOM events and changes. There's always going to be an impedance mismatch. The DOM API sucks, so React et al went all in with state-as-objects. IMO it was the right call.

I just don't think DOM->JSON->server->microservice->DB->microservice->server->JSON->DOM is sustainable long term. It's had a good run, but it's a big part of the reason I'm looking at Phoenix for a personal project. React is predicated upon solving the wrong problem.

Talk about impedance mismatches.

Re: What dif­fer­enti­ates front-end frame­works

#112

Post by esrauch »

sambroner wrote: post #75
8organicbits wrote: post #52

Earlier quoted context omitted.

Interesting. I'm seeing something slower. Pagespeed shows 2.7 seconds: https://pagespeed.web.dev/analysis/https-themer-dev-blog-the...

Even just an eye-test shows it's much faster than that for me. Pagespeed shows .6 for desktop, but locally I'm seeing frames loaded under 350ms. I would have guessed much faster, but I guess the devtools don't lie.

I think devtools can lie in the sense that it can be slower when devtools is open in some circumstances.

Re: What dif­fer­enti­ates front-end frame­works

#114

Post by suralind »

r_singh wrote: post #39

This website loads staggeringly fast (much faster than HN and my own static site which uses Gatsby and is hosted on Cloudfront). What’s the reason for this?

Served via service worker, but still Cloudflare serves it faster than my very minimalistic static blog. Perhaps it uses paid Cloudflare plan?

Re: What dif­fer­enti­ates front-end frame­works

#116

Post by ngFanboi45 »

> Angular’s change detection is a disaster. The developer gets two suboptimal choices: (1) the slow and naive default implementation, or the complexity of managing change detection manually.

This is completely wrong. The "naive" approach is the one you should always use, with the onpush strategy reserved for breaking certain cascading situations manually. But the default approach works perfectly fine, it is performant enough, and even more when compiled for production, as it runs only once (as compared to twice in the debug mode). The author is incorrectly assuming that the change detection is slow because it is automatic. That's the entire point of the framework btw.

Re: What dif­fer­enti­ates front-end frame­works

#118

Post by hinkley »

hombre_fatal wrote: post #88
hinkley wrote: post #79

Earlier quoted context omitted.

At peak jquery, I argued successfully for storing the metadata on DOM, because then you have a system of record, upon which you can build a straightforward source of truth. React does a ton of work to solve that architectural puzzle another way. The thing I have run into over and over again is that when we try to pretend the system is Y when it is in fact X, inevitably the impedance mismatch results in 1) bugs that s…

> I argued successfully for storing the metadata on DOM Who did you convince?

A team working on an AJAX webapp that typically was meant to comfortable manage around 1000 blocks of state at a time. Somewhere on the order of 6-10 pieces of data per block (Which we just changed as a unit of work because 1000 was already hard enough). And when you're dealing with 10^3 you need a couple of different ways to visualize the same data or you're getting nowhere, so we had one or two other views that dealt with different levels of detail.

Re: What dif­fer­enti­ates front-end frame­works

#119

Post by nine_k »

boxed wrote: post #51
emorning3 wrote: post #42

Totally disagree with this. Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky. Imagine a world where interacting directly with the browser DOM didn't suck, then none of these libraries would exist. The crux of the problem is that the browser immediately reflects changes to the DOM to the screen. And when you make a bunch of changes to…

That's not nearly all there is to it. If the DOM was fast and you could control redraws, it would still be horrible. A performant big pile of mud is still a big ball of mud.

"A performant pile of mud" is a description that fits many things that still stay afloat exactly because the performance allows them to. Consider C++ or x64 as examples.

Re: What dif­fer­enti­ates front-end frame­works

#120

Post by ngFanboi45 »

emorning3 wrote: post #42

Totally disagree with this. Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky. Imagine a world where interacting directly with the browser DOM didn't suck, then none of these libraries would exist. The crux of the problem is that the browser immediately reflects changes to the DOM to the screen. And when you make a bunch of changes to…

Change detection is one thing, and double buffering is another. Change detection is just projecting from state changes to UI changes. It doesn't try to solve this hypothetical "flashing". That is entirely up to the browser. Double buffering is a graphic technique meant to show smooth UI changes at the cost of doubling the memory used for the graphical object.
Post reply on HN