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

201–210 of 256 posts

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

#201

Post by dgb23 »

shaunxcode wrote: post #172
dgb23 wrote: post #150

Earlier quoted context omitted.

I‘ve written a UI a few months ago with only lithtml and direct DOM manipulation and it worked pretty well. I needed to do calculations and reading bounding boxes from the DOM initially and on resize. Basically a hack to get around CSS limitations. It was crucial that this is fast enough to avoid flickering. I wouldn’t have attempted this with react. I think it would still be possible with useEffect, but I tried the…

in the cljs/reagent world anytime you need to do direct dom stuff you just use a ref - that must me the same for react proper?

You can pretty much do anything with a combination of refs, events and useEffect. It’s often fiddly and cumbersome though.

Aside:

That’s why I‘ve been gravitating towards approaches that have much simpler execution models.

You can still do declarative and functional. But you have more control when needed, create _much_ smaller bundles, have fewer dependencies, better default performance, allocate less garbage and you can reason about your code in more fundamental ways.

In cljs this would mean to not use a react wrapper.

However I personally try to avoid using any deps for frontend, and that includes cljs. Any dep needs a justification IMO.

That justification is often not good enough, since I’m mostly writing „interactive documents with some fancy parts“.

If you’re writing something like nextjournal, roam, data rabbit or similar then it’s a different story.

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

#202

Post by surrTurr »

8n4vidtmkvmk wrote: post #194
Izkata wrote: post #167

Earlier quoted context omitted.

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.

Mobx had one thing going for it -- it let you update your neighbor easily. But now Reacts useExternalStore achieves that cleanly with about 100 lines to wrap it in a cute API. The proxy stuff I don't trust. Burned me once, never again.

The proxy stuff always works great when fiddling around with it in a small project. However, my experience has been the same. Whenever a project using proxies leaves the playground phase, all sorts of nasty bugs and performance issues arise.

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

#203

Post by lozenge »

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…

Any changes to the DOM aren't reflected on screen until your code stops running. If you see a partial update it's because your code is "await"ing something.

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

#204

Post by incrudible »

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-based solutions are generally much more fine-grained: the framework knows which portion of the DOM was affected by the signal, and does not need to diff the entire state object

I believe this to be generally pointless. Diffs are not that expensive, DOM changes are. The only case where this would help is you have a very large diff but a small amount of actual changes. React offers tools to handle this without changing the entire state management paradigm.

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

#205

Post by troupo »

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.

This makes it a non-standard library-specific method of passing things.

I have no idea what you're arguing against.

There's literally no way to pass objects as attributes to web components. Web components had a great opportunity to get rid of attributes/properties dichotomy, but they doubled down on them.

> At least with web components there's a standard _interface_ for the components so that many different libraries can implement the declarative parts in a completely interoperable way.

Of course there's nothing standardised, and nothing interoperable. Because if one web component exposes its API through attributes, and the other one through properties, and a third one through both, never the three shall meet. Without library-specific hacks.

There's a reason the "standardized" lit uses a custom DSL to distinguish between things:

  ``
So much standardization.

Edit:

Stencil uses JSX (non-standard), so it doesn't care and probably sets properties directly, skipping attributes. For object props and HTML it says it explicitly that you cannot set them (of course): https://stenciljs.com/docs/properties#object-props

> But the question remains: where do those properties originate from? Most likely JavaScript, because HTML doesn't have any.

Indeed. That is another issue with anything web-component-related. Moar Javascript. As if we don't have enough. There are now dozens of more JS APIs existing just because of web components, and even more are incoming: https://w3c.github.io/webcomponents-cg/2022.html

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

#206

Post by travisjungroth »

dylan604 wrote: post #97
travisjungroth wrote: post #85

Earlier quoted context omitted.

You have to actively do stuff to make a house messy, but it can still be impressive when it’s clean.

I find it the opposite. You have to actively clean a house, but do nothing and it won't be clean

"Tidy" may have been a better word than clean.

The natural state of a home is tidy. It was probably empty when the current resident moved in. The natural state of a website is fast. A tiny website can be delivered in one packet.

The home only becomes messy through action. Not intention, but action. Someone has to dirty a dish for there to be dirty dishes. And it's not like you can avoid these activities, that's what a home is for.

It requires a countering action to put things back as they were. So it's action on both sides. Action to make things messy, action to keep things tidy. It's the second action we admire in the tidy home, the fast website.

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

#207

Post by dawnofdusk »

galaxyLogic wrote: post #176

Why can't we just use Model-View-Controller for change-detection? Views subscribe with the model to get notifications about changes to different "aspects" of the model. When they get a change-notification they update themselves by asking the model for its latest data for a given aspect.

Literally just Angular if you use RxJS, which the author evidently thinks is too hard to understand and so dismisses it.

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

#208

Post by rubymamis »

onsclom wrote: post #198
rubymamis wrote: post #187

Earlier quoted context omitted.

Haha I was typing fast just to show the QML syntax. I don't really think good code is about lower amount of lines, but rather more about "making sense". And that's what I tried to show. Regarding the timer, so in your Svelte code a new timer is being created each time? I wonder how to implement the efficiently in QML. I don't think it's as straightforward. EDIT: Probably the best way is to expose QTimer::singleShot (…

Fair gotcha, yeah honestly I find QML to be super intuitive in the same way Svelte is super intuitive. It feels like two framework authors in very different worlds came to a similar conclusion. > Regarding the timer, so in your Svelte code a new timer is being created each time? `setTimeout`[1] isn't even a Svelte thing, it's a JavaScript API that QML would have access to if it was real JavaScript ;). [1] https://dev…

I understand, but it's not quite necessary if Qt could add some better functionality exposing C++ code in QML. Luckily, someone created a cool library that allows you to create singleShot timer in QML as follows:[1] `lqtUtils.singleShot(5000, () => console.log("Hello!"))`

[1] https://stackoverflow.com/a/75288105/5865379

I also used his library to share ENUMs between QWidgets (C++) and QML.

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

#209

Post by mst »

galaxyLogic wrote: post #176

Why can't we just use Model-View-Controller for change-detection? Views subscribe with the model to get notifications about changes to different "aspects" of the model. When they get a change-notification they update themselves by asking the model for its latest data for a given aspect.

rxjs (see M. Kerjean's sibling comment for an example) or mobx/mobx-state-tree can be used to implement something like that, and I've quite enjoyed both react+mobx and lit+mobx as a result.

(googling 'thing mobx' where 'thing' is your preferred rendering system has results in quite a lot of cases)

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

#210

Post by cassepipe »

emorning3 wrote: post #95
robear wrote: post #61

Earlier quoted context omitted.

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…

I agree with you that going back to the JQuery days of unmaintainable imperative code would not be a good thing. But with JQuery I was able to create adaptive UIs by applying 'transforms' to the DOM, I really miss that. Think of the way that 'tag helpers' can apply cross-cutting transforms to Razor Page applications, I used to do things like that with JQuery. React et al cuts me off from both the browser DOM and it's…

It seems like you are a ripe candidate for Svelte !
Post reply on HN