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

61–70 of 256 posts

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

#61

Post by robear »

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 see it that way. The main need for change detection in my opinion is to remove the need to update parts of the DOM in an imperative manner. It is fine to do that for smaller projects but when a project gets large, it becomes difficult to reason about the myriad of changes happening without a system to handle that. I find any one of the examples in the linked post way more easy to reason about than manual DOM updates.

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

#62

Post by boringuser2 »

MauranKilom wrote: post #9

Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?

My experience:

JSX is the best templating language.

Svelte hides complexity and this can bite you in tracking down issues.

React just feels better to me for a professional project, though I like Svelte.

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

#63

Post by boringuser2 »

grayrest wrote: post #34
MauranKilom wrote: post #9

Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?

> maybe someone can shed some light into the downsides of Svelte Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option. I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased…

Why do you care about compilation output?

Also, your component sounds cumbersome.

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

#64

Post by boringuser2 »

bobolino123 wrote: post #28
Aerbil313 wrote: post #11

Earlier quoted context omitted.

Well it is very new. React has a massive inertia, so it dominates for now. I do FE work and see Svelte is gaining popularity.

2016 is not very new

Actually, that's very old in frontend years.

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

#65

Post by crooked-v »

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.

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

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

#66

Post by cloogshicer »

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?

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

#67

Post by lincon127 »

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…

So what are you disagreeing with? Are you disagreeing that change detection is what mostly diffentiates the front-end frameworks? If so, what is that important factor that differentiates them if not the mechanism that modifies when change is detected? Why do you have such a strong belief that this factor isn't it?

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

#68

Post by boringuser2 »

dezmou wrote: post #16

React is not reactive at all, the "state" management is you calling a function "setState" to re-render the component. And I find manual render very usefull and once you do it, you can have a global state as simple as a global object, no need to use useState anymore. https://github.com/dezmou/useRender

This is extremely inadvisable for numerous reasons and goes against the entire design philosophy of React.

In short, injecting a naive render function over the react virtual dom calculation is wildly inefficient.

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

#69

Post by onion2k »

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.

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

#70

Post by boringuser2 »

alana314 wrote: post #33

The problem I have with react is that if I set a variable using a hook, it's asynchronous and not immediately available in my code. It's nice for updating the DOM but causes me lots of race conditions.

This is an issue of you not understanding how to properly manage the state of your application, not React.

It's very likely that you're using effects improperly.

Post reply on HN