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

161–170 of 256 posts

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

#161

Post by plopz »

JohnFen wrote: post #98
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've used a technique called 'double buffering' to rerender complete pages off-screen, fast. I'm absolutely not a web dev (as this comment will make clear), but I'm very surprised that browsers haven't been doing this all along. I just assumed that they did.

I'm sure they do, theres even a construct to do this called OffscreenCanvas

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

#162

Post by eyelidlessness »

nine_k wrote: post #138
RandallBrown wrote: post #46

Earlier quoted context omitted.

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.

Directly surfacing the effects involved, e.g. HTTP calls via all the event handlers through layers of nesting, would indeed be nice.

I’m not sure how other browsers’ dev tools do on this front, but at least in Chrome most requests in the Network tab will link to the file/line of code which initiated the request. From there you should be able to set breakpoints or whatever to track subsequent requests.

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

#163

Post by apatheticonion »

robear wrote: post #61
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…

Having worked extensively with the major frameworks in multiple orgs, I have largely found that templates synced with state via change detection (like Angular) result in more readable/maintainable projects.

While I personally like React, it's pretty tricky to use in reality. I have found that its idiosyncrasies make it less resilient to suboptimal contributions from engineers that are still early in their careers.

Broadly, the projects I have entered using React tend to be pretty wild, messy and unreliable.

There is cross over though, Angular projects using Redux (ngrx) are horrific. The criticism of Angular for me is the lack of control you have over the compiler, dependency versions and testing strategy.

Svelte and Vue are both interesting, but they use custom file formats (.vue, .svelte) which can add an extra layer of unreliability to projects using TypeScript and testing frameworks.

The advantage of Angular is that it's an ergonomic abstraction that allows optimisations to occur at the engine level. It's more like an ORM, where React is more like writing SQL queries directly.

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

#164

Post by nwienert »

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…

Signals have their own shortcomings as well. Once you leave the "re-run the render function on state change" you suddenly are dealing with implicit dependencies, stale closures, cyclical updating, and all sorts of weirdness in debugging things, figuring out what triggered what, etc.

Signals as a concept existed well before React and I think part of the genius of React is actually not using them. In a way a signal is just a very simple version of RxJS that Angular is moving away from, with a lot of the same downsides, just without all the pipe/abstraction mess.

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

#165

Post by insin »

Just leaving this here (typed without having to look it up) for anyone else who's ever maintained large Angular app which got to a certain size and complexity before anyone _really_ understood what they were doing:

ExpressionChangedAfterItHasBeenCheckedError

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

#166

Post by nonethewiser »

i-use-nixos-btw wrote: post #100
boringuser2 wrote: post #63

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…

> the way DOM updates are issued

This one, id wager. There isn’t necessarily anything wrong with your approach but Id agree that you should try svelte for this reason.

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

#167

Post by Izkata »

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…

For a little while it looked like mobx was going to displace Redux in React-world, and if that had happened it would have brought this to React without having to change React itself.

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

#168

Post by Izkata »

spankalee wrote: post #135
spion wrote: post #124

Earlier quoted context omitted.

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 (inste…

Adding "declaratively" doesn't make it true either. You can declaratively pass objects between web components in every web components library out there like Lit or Stencil. Now, you may claim that that doesn't count because the declarative part is implemented in non-standard userland libraries, to which I would reply: 1) So what? React is a non-standard userland library. You can't pass data declaratively between Reac…

> You can declaratively pass objects between web components in every web components library out there like Lit or Stencil.

They capitalized Web Components, I think they're talking about what browsers natively support and not a library or framework.

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

#169

Post by Izkata »

rubinlinux wrote: post #74
RandallBrown wrote: post #46

Earlier quoted context omitted.

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.

React and Redux both have similar addons as well, to inspect the component tree and to see the state changes over time (and even roll back; "time travel debugging" has been one of Redux's primary features since it was released).

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

#170

Post by djbusby »

Surprised nobody, and the article, mentioned RiotJS. It's maybe less framework and more library but, it is easy to make these little web-components. It's also one of those setState and repaint types. My primary drivers is that is easy to bolt into existing projects - so one can gradually add more dynamic features without the mega-rewrite-all-at-once-to-new-tools dance.
Post reply on HN