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

71–80 of 256 posts

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

#71

Post by 8organicbits »

AceJohnny2 wrote: post #14

Offtopic: The cursive italics are apparently a feature of the Victor Mono [1] font used for the full page. While it'd be amusing in Tumblr context (where cursive is used for hyperbolic emphasis), I can't fathom why one would consider it in a code context, but to each their own... You can change it (at least on Safari) by going into developer tools, clicking any node, and removing "Victor Mono" from --font-family [1]…

One of the first things I do on a new browser install is to disable web fonts. I've never seen a site where they improve things, often they flicker in after page load, which is jarring.

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

#72

Post by hinkley »

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…

With the exception of list comprehension, which is IMO not only the best feature of jquery but almost enough of a reason to use it on its own, browsers have copied most of the features at this point. Do you (or anyone else here) see an opportunity to copy features from React into the browser?

I know there have been earlier tricks to pop elements off the DOM, modify them heavily and then pop them back on. I wonder if it would be better to a) provide a way to mark a node and it’s children as suspended reflow, or b) provide a virtual view where you can do operations on off-DOM nodes including ones that typically trigger reflow. c) something else entirely

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

#73

Post by [deleted] »

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

Earlier quoted context omitted.

Really impressive stuff. Seems to have slowed down slightly now that it's on the front page, but blazing fast when I first opened it.

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

[deleted]

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

#74

Post by rubinlinux »

RandallBrown wrote: post #46
nsxwolf wrote: post #37

You know what I've always wanted in a front end framework, as a back end developer that sometimes is forced to work on front end tickets? I want a development build mode that generates some kind of project metadata where I can just point to something on the screen and get a report of all the interesting files in the project that are responsible for what I'm seeing: * API calls * Templates * CSS * Controllers, etc. My…

Apologies if you're aware of this already but every browser has a web inspector built in where you can point and click on something and at least see the HTML and CSS associated with it.

And vuejs has a browser plugin which can sort-of show you which components call which components to get there.

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

#75

Post by sambroner »

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

Earlier quoted context omitted.

Really impressive stuff. Seems to have slowed down slightly now that it's on the front page, but blazing fast when I first opened it.

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.

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

#76

Post by jeremyjh »

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…

You want to store your application state in a widget tree? This was the part about the old bit 'o jquery approach that drove me absolutely batshit. The logical state of your UI is strewn about in Dom objects and their listeners, closures etc. There is no one place you can go to see what state is relevant to this component.

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

#77

Post by spankalee »

Svelte isn't a strict win-win. It requires a compiler, and forks of JavaScript and HTML.

And it isn't actually very different from React or Vue anyway, and in fact quite a bit more limited than Vue (not necessarily bad).

Saying:

  “I’ll figure it out for you at compile time.” —Svelte
is just a non-technical, basically non-meaningful statement.

You need to know _what_ it figures out exactly. What state and what state changes are observable? These things matter more than whether it's done at compile time or runtime.

And I think the author is ascribing far more power "compile time" than what's actually happening. Svelte is not doing some kind of sound data flow analysis on your JS code to figure out what could change and rewriting your code to be observable (something not really possible anyway). It's using specific syntax conventions to make some variables into shallowly observable properties. And it adds "store" concept, which is more-or-less Signals as popularized in Solid, now Preact, and soon Lit and Angular.

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

#78

Post by 12_throw_away »

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/current.ht...

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

#79

Post by hinkley »

cloogshicer wrote: post #66
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…

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?

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 should be easy to reason about but are difficult to fix, and 2) a form of pulling the ladder up behind you.

If I want to continue to work on interesting things I have to be able to carve out chunks of my code to gift to #3 on the bus number list, so I have the bandwidth to double down on some other topic or expand into another.

I know which side my bread is buttered on. Many don’t. Which is why I have a more consistent supply of mentees than many of my peers.

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

#80

Post by lnenad »

spankalee wrote: post #77

Svelte isn't a strict win-win. It requires a compiler, and forks of JavaScript and HTML. And it isn't actually very different from React or Vue anyway, and in fact quite a bit more limited than Vue (not necessarily bad). Saying: “I’ll figure it out for you at compile time.” —Svelte is just a non-technical, basically non-meaningful statement. You need to know _what_ it figures out exactly. What state and what state ch…

> Svelte isn't a strict win-win. It requires a compiler, and forks of JavaScript and HTML.

These points weren't touched upon by the author. He compared the frameworks from one perspective and one perspective only.

Post reply on HN