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

151–160 of 256 posts

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

#151

Post by gyanreyer »

luketheobscure wrote: post #144
aluminum96 wrote: post #131

> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be a…

There are a large number of very incorrect statements in this article. > True to its de-facto tagline, change detection in React is “just JavaScript.” Then in the example, the author updates a variable with `setCount(count - 1)`. That's not "just JavaScript". Just JavaScript would be `count = count + 1`.

Well, JavaScript has no simple way to react to an assignment like count = count + 1 without introducing some magic between the code you write and the final code that runs in the browser. Svelte is only able to achieve that experience because it has a compilation step, but React does not; hence why setState() is necessary and why people argue it's more "just JavaScript" because the code you write is pretty much the final code that runs (aside from the transpilation necessary to convert JSX syntax into JS, but this doesn't alter the way that anything works).

This isn't to make any kind of judgement on either approach though, I personally really enjoy the DX that Svelte offers.

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

#152

Post by em-bee »

rubymamis wrote: post #6

QML wins with bindings and signal and slots! (In this example the the text property of the Text componenet is binded to count , so whenever count changes the text changes). ``` property int count: 0 Button { onClicked: { count--; } } Text { text: count.toString(); } Button { onClicked: { count--; } } Button { onClicked: { incrementLater.start(); } } Timer { id:incrementLater interval: 1000 onTriggered: { count++; } }…

you can do the same in aurelia:

counter.html:

    
      ${count}
      
      add one
      subtract one
counter.js:

    export class Counter {
        constructor() {
            this.counter = 0
        }

        inc() {
            this.counter++
        }
    }

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

#153

Post by throwaway4837 »

boringuser2 wrote: post #70
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.

Effects are way too easy to use improperly. I used to be a fan of useEffect when it came out because of its concision, but after working with countless devs/agencies, it's clear that most people misuse it. The rules of useEffect are inelegant, and creating readable state machines with useEffect is very hard. You end up with spaghetti code either in your custom hook, or directly in the component. While most components need 2-3 effects rather than 20, useEffect is not a scalable way of managing state IMO.

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

#154

Post by hinkley »

robertoandred wrote: post #149
hinkley wrote: post #111

Earlier quoted context omitted.

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.

I'm not sure switching to DOM->JSON->server->microservice->DB->microservice->server->DOM will make much of a difference.

Complexity is usually quadratic or factorial. Only a tiny number of systems are logarithmic. 20% reduction in parts can often be a 40-70% reduction in cognitive load.

But the funny thing with fractions is that if go above a threshold and come back from the brink, the path back is a smaller number than the path out. So if you go from 8 to 10 steps that's 25% worse and if you undo that bad decision you are getting 20% better. So you want to be careful to compare sustainable to unsustainable and not the other way around, if you follow me.

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

#155

Post by onsclom »

rubymamis wrote: post #6

QML wins with bindings and signal and slots! (In this example the the text property of the Text componenet is binded to count , so whenever count changes the text changes). ``` property int count: 0 Button { onClicked: { count--; } } Text { text: count.toString(); } Button { onClicked: { count--; } } Button { onClicked: { incrementLater.start(); } } Timer { id:incrementLater interval: 1000 onTriggered: { count++; } }…

Having used both QML and Svelte, I enjoy Svelte a lot more. The reactive APIs are very similar, just declare variables, mutate them, and use them. But Svelte is much nicer for many reasons:

1. It uses modern JavaScript and not some limited custom ES5-like JavaScript

2. Svelte can be used with TypeScript so your UI code can be statically typed

3. The integration with Svelte and VSCode is much better than QML and Qt Creator (the big thing is that IntelliSense is much better at analyzing JavaScript code than whatever Qt Creator uses)

4. Having an actual live reloading dev server is so much nicer than compiling and running for every change

5. Svelte has much better documentation than QML

These are just the first things that came to mind, but I could probably keep going for a while. Do you think I'm being unfair to QML? And/or have you used Svelte?

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

#156

Post by jeremycarter »

ngFanboi45 wrote: post #116

> 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 performan…

We've never had an issue with the Angular change detection. Large scale projects, multiple teams touching a modular front end. Its a win!

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

#157

Post by ChicagoDave »

The op forgot to tell you that if you use React, you have to add a slew of 3rd party libraries to make it work and no one tests every combo. This is called “unopinionated”.

Angular is “opinionated” in that you don’t need to add anything. It definitely has a higher learning curve, but from an enterprise perspective, it’s a safer tool.

And if you have so many things on a web page that performance is a problem, then I’d suggest you need a better user experience. You should never have a design that overwhelms the framework.

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

#158

Post by djbusby »

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…

Back in the VB6 days there was an option one had to toggle to enable the double buffer.

Without it all app paints had a noticeable lag.

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

#159

Post by plopz »

genuine_smiles wrote: post #141
aluminum96 wrote: post #131

> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be a…

> and they are not particularly similar to Svelte stores either How does Svelte differ? I’m somewhat familiar with SolidJS, and had always assumed Svelte was somewhat similar.

I'm not super familiar with svelte, but my understanding was that it solved it at compile time rather than run time.

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

#160

Post by [deleted] »

yakshaving_jgt wrote: post #17

So the single most important factor that differentiates front-end frameworks is DOM diffing performance? Well, IIRC, Elm is faster than all the examples given, and yet front-end developers find Elm to be weird and frightening. So I’m not sure I agree with the premise of the article. I also don’t agree that there can be so many valid answers to “Find a change detection paradigm that fits the needs of your application”…

[deleted]
Post reply on HN