Live data from Hacker News

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

themer.dev

121–130 of 256 posts

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

#121

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…

I don't know... even if the DOM was super fast, would it really be ergonomic to keep all your state in the DOM tree and only work with that? I kinda doubt it. So then you'd have to store some state in JS, and some in the DOM, and again you get a syncing problem, since you lost your single source of truth. Or did I misunderstand your comment?

>> Or did I misunderstand your comment?

Well, I can see now that while I expressed my dislike for change detection I didn't paint a good picture of why I think we'd be better off without it :-).

While I appreciate React's declarative programming style I dislike the fact that React (and all the change-detecting alternatives) force me to interact with the DOM through their APIs.

JQuery allowed me to do whatever the hell I wanted to the DOM, but the resulting screens updates were very ugly. And yes, JQuery resulted in ugly and unmaintainable code but that's not on JQuery, there are rational ways to apply transforms to a DOM.

I want to "do whatever the hell I want" to the DOM because I want to apply cross-cutting, adaptive transforms to my application, like I could with JQuery. And I think that we'd all be better off for it. In the transition to React-like frameworks we have lost that ability

The view transition API lets me start a transition, do whatever the hell I want to the DOM, and then update the browser smoothly.

So what I'm imagining is a component-oriented framework like React that doesn't lock me into a component-only API. A framework that, when rendering occurs, starts a transition, let's me do whatever the hell I want to the DOM, and then updates the browser smoothly without doing change detection.

And the reason I would like that is because, while React's declarative, component-oriented development approach is nice and all, it's also very restrictive.

Reacts prevents me from directly traversing and mutating the DOM, and it's own virtual DOM, because if it did then it can't efficiently do change detection.

If we replace change detection with transitions then we can "do whatever the hell we want" (hopefully not in an unmaintainable JQuery way) and still have smoothly updating displays. We'd have a framework with all the benefits of React and without the restrictions.

Anyway, that's my best shot at explaining myself :-).

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

#122
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?

52ms for me. Pretty standard for an HTML page.

I don't think I've ever seen a page load in 52ms (`load`, not `DOMContentLoaded`) with caching disabled.

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

#123

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 has nothing to do with the speed of DOM updates, it's about directly encoding dataflow dependencies to avoid code duplication and redundant UI updates. You could paper over the lack of dataflow updates by just updating the whole screen every time, but you still need to preserve various state, like scroll positions, highlighted text, etc. which still means only some state changes and other state does…

Redundant UI updates could be okay if done quickly and cheaply. Games refresh entire framebuffers 60 times a second, redrawing the entire world, and it works fine, because they do that efficiently, and flip entire pages so that you never see a half-draw.

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

#124

Earlier quoted context omitted.

For example, there's the way it's still impossible to pass data between native Web Components without stringifying it first.

This is an absolutely stunningly false and ignorant statement. I can't believe it's still being repeated. Web components are objects and they have properties that can be set. The entire web components community - which includes the developers of apps like Photoshop, Reddit, Chrome, Firefox, and a lot more - passes properties down through trees of web components _all the time_.

There is a subtle grain of truth to it - the implied "declaratively" here. React has went south quite a bit, but the basic idea of JSX where HTML becomes a language with first class objects, functions and bindings is extremely compelling. It offers a solution to the problems of complexity that pure HTML cannot tackle while still staying somewhat true to its declarative nature and reaping most of those benefits (instead of fully switching to the imperative DOM paradigm).

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

#125
post #69

I don't agree, because in my experience every framework is fast enough unless you're either past what it's capable of (you probably aren't) or you're using it wrong (you probably are). It is far more important to fine a framework that you like and that you understand, because then you'll write good code that the framework can run fast.

What are you disagreeing with?

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

#126

Interesting to compare these with the results on the js-framework-benchmark page [1] (with the usual caveats about benchmarking). Without actually running the numbers, qualitatively it looks like there are 3 performance tiers: VanillaJS (fastest); Vue, Svelte and Elm (often close to vanilla); and Angular and React (sometimes comparable, sometimes much slower). [1] https://krausest.github.io/js-framework-benchmark/cur…

Yep. The author is making a big leap by falling into the "Angular slow" meme. In my experience it isn't, and it provides ease of use thanks to its bi-directional binding, as oposed to React's unidirectional binding. It is not the champion of speed though, might be even the slower out of the box, but still fast enough.

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

#128

Earlier quoted context omitted.

Why do you care about compilation output? Also, your component sounds cumbersome.

I’m mainly a C++ developer, not a frontend developer (though I dabble), and when I have a choice of multiple approaches the first thing I do is go to godbolt.org, implement MWEs and compare the assembly. I also do a lot of code generation, and my absolute goal is to have it write code that I’d write if I were doing it by hand. That’s pretty key for me. If the output is better, then good. If the output is doing a bunc…

FWIW it's a strange anecdote to me, as I remember the opposite being the case - svelte app being significantly smaller than React.

Svelte's whole shtick is using ASTs from the compiler to stuff at compile time where possible, to reduce bundle size and complexity.

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

#129
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?

The whole HTML is likely static, and it has only one , at the very end, that attaches some async update handler to the existing DOM. No wonder it renders instantly.

Modern computers are obnoxiously fast, and so are modern browsers. But modern websites overload them with a sickening amount of processing and network latencies before displaying the content.

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

#130

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.

PageSpeed Insights tests on a slow internet connection and an underpowered device
Post reply on HN