Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn how modern JavaScript frameworks work by building one

nolanlawson.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Learn how modern JavaScript frameworks work by building one

#81

Post by mhh__ »

698969 wrote: post #31
mhh__ wrote: post #22

Earlier quoted context omitted.

I also like svelte but as a compiler-y person who happens to be doing some JS I can't work out why I'm annotating so much stuff by hand (even with svelte 5). I can get why you might want this for react, but isn't svelte a compiler? Can't we do dataflow analysis? I'm 50% convinced there's a Chesterton's fence I'm mising but where?

You can only do so many compiler-y things in a dynamically typed language like Javascript. And even less of it within the context of a single file, unless you implement a bundler (web jargon equivalent of linker). Otherwise by the time the run-of-the-mill bundler is done connecting parts of your component tree into a single file, so much of the high-level information of the component is lost that you can't really do…

But with a svelte component it knows a lot about the state, inputs, outputs etc.

The default paths should be pretty easy to analyze as long as you pick sensible defaults.

Re: Learn how modern JavaScript frameworks work by building one

#82

Post by sesm »

The article doesn’t state what problem those ‘modern’ web frameworks are trying to solve. It’s already been known that you can make a faster framework at the cost of less ergonomic API and more complicated mental model, but in most cases it’s not worth it. And when it’s worth it, React had the tools to ‘eject’ a subtree from the very start.

Re: Learn how modern JavaScript frameworks work by building one

#83

Post by uryga »

pavlov wrote: post #78
n2d4 wrote: post #23

I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.…

> "useMemo doesn't prevent that, but React.memo can" You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often. There's an example right in the React Hooks FAQ where it reads: "Conveniently, useMemo also lets you skip an expensive re-render of a child" https://legacy.reactjs.org/docs/hooks-faq.html#how-to-memoiz... AFAIK there's no magic to React.memo. It's basicall…

> AFAIK there's no magic to React.memo. It's basically a shorthand for useMemo that takes the props as the dependency.

Pedantic note: this isn't quite true. memo() also allows a second `arePropsEqual` argument that useMemo doesn't have. Also, memo() compares individual prop values, while useMemo() can only look at the whole props object (which would be "fresh" on every render -- it's a diffferent object, even if it has the same values). So it's not like you can easily reimplement memo() via useMemo(). But of course, conceptually they are pretty close :)

Re: Learn how modern JavaScript frameworks work by building one

#84

Post by pavlov »

uryga wrote: post #83
pavlov wrote: post #78

Earlier quoted context omitted.

> "useMemo doesn't prevent that, but React.memo can" You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often. There's an example right in the React Hooks FAQ where it reads: "Conveniently, useMemo also lets you skip an expensive re-render of a child" https://legacy.reactjs.org/docs/hooks-faq.html#how-to-memoiz... AFAIK there's no magic to React.memo. It's basicall…

> AFAIK there's no magic to React.memo. It's basically a shorthand for useMemo that takes the props as the dependency. Pedantic note: this isn't quite true. memo() also allows a second `arePropsEqual` argument that useMemo doesn't have. Also, memo() compares individual prop values, while useMemo() can only look at the whole props object (which would be "fresh" on every render -- it's a diffferent object, even if it h…

> “Also, memo() compares individual prop values, while useMemo() can only look at the whole props object”

Passing “Object.values(childProps)” as the dependency array for useMemo should do the same thing.

But yeah, there are good reasons to use React.memo for convenience with props. It’s not fundamentally different though, and you can definitely useMemo() for caching components when more convenient.

Re: Learn how modern JavaScript frameworks work by building one

#85

Post by eddd-ddde »

mosselman wrote: post #61
grey-area wrote: post #55

Earlier quoted context omitted.

Or maybe we could just ditch react and everything like it? Not everyone uses it now, and many large websites are built in simpler ways despite not using ‘modern JavaScript’. Is all this pain and complexity really worth the gain? In practice it often leads to a slower experience for users due to the massive globs of js.

Have a look at this video in Rails’ Turbo 8: https://m.youtube.com/watch?v=hKKycPLN-sk In a nutshell: we had a 7 year old server side rendered page on our site that shows a chat between two users that was more like email. So you have to refresh to see new messages. We added 2 lines of code to the HTML(!!) and now the page is fully multiplayer so messages come in directly when the other user sends one and you see othe…

Recently I just wrote a basic tutorial on building a real time chat web application using htmx: https://dev.to/viiik/making-a-real-time-chatroom-app-with-cl...

Minimal html, like just a couple of lines including regular html boilerplate.

The amazing thing of libraries like turbo or htmx is the client complexity does not increase with feature complexity.

Re: Learn how modern JavaScript frameworks work by building one

#86

Post by culi »

nolanl wrote: post #29
n2d4 wrote: post #23

I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.…

Author here. Thanks for the thoughtful reply! I did indeed mix up `useMemo` and `React.memo` – fixed it in the post. You're right, I am skipping a lot of details (hence "to grossly oversimplify"). I know that React doesn't invalidate the whole tree, but it does in the worst case. Maybe I should add a note about that. Svelte not being truly reactive makes perfect sense, but in Svelte v5 my understanding is that "runes…

> I know that React doesn't invalidate the whole tree, but it does in the worst case

You mean *invalidate the whole subtree, right?

Re: Learn how modern JavaScript frameworks work by building one

#87

Post by culi »

pavlov wrote: post #78
n2d4 wrote: post #23

I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.…

> "useMemo doesn't prevent that, but React.memo can" You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often. There's an example right in the React Hooks FAQ where it reads: "Conveniently, useMemo also lets you skip an expensive re-render of a child" https://legacy.reactjs.org/docs/hooks-faq.html#how-to-memoiz... AFAIK there's no magic to React.memo. It's basicall…

> You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often

Only if those child components are memoized. By default, whenever the state of a component changes, React will rerender the entire subtree. The only time it doesn't is when a child component is memoized (React.memo) AND the props haven't changed. Utilizing useMemo and useCallback is how we prevent non-primitive props from being recreated unnecessarily

Re: Learn how modern JavaScript frameworks work by building one

#88

Post by culi »

pavlov wrote: post #84
uryga wrote: post #83

Earlier quoted context omitted.

> AFAIK there's no magic to React.memo. It's basically a shorthand for useMemo that takes the props as the dependency. Pedantic note: this isn't quite true. memo() also allows a second `arePropsEqual` argument that useMemo doesn't have. Also, memo() compares individual prop values, while useMemo() can only look at the whole props object (which would be "fresh" on every render -- it's a diffferent object, even if it h…

> “Also, memo() compares individual prop values, while useMemo() can only look at the whole props object” Passing “Object.values(childProps)” as the dependency array for useMemo should do the same thing. But yeah, there are good reasons to use React.memo for convenience with props. It’s not fundamentally different though, and you can definitely useMemo() for caching components when more convenient.

Using `useMemo` without using `React.memo` on the child component does not prevent a rerender at all.

Re: Learn how modern JavaScript frameworks work by building one

#90

Post by pavlov »

culi wrote: post #87
pavlov wrote: post #78

Earlier quoted context omitted.

> "useMemo doesn't prevent that, but React.memo can" You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often. There's an example right in the React Hooks FAQ where it reads: "Conveniently, useMemo also lets you skip an expensive re-render of a child" https://legacy.reactjs.org/docs/hooks-faq.html#how-to-memoiz... AFAIK there's no magic to React.memo. It's basicall…

> You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often Only if those child components are memoized. By default, whenever the state of a component changes, React will rerender the entire subtree. The only time it doesn't is when a child component is memoized (React.memo) AND the props haven't changed. Utilizing useMemo and useCallback is how we prevent non-primi…

I'm not sure what you're arguing here.

useMemo() works for memoizing child elements. I linked to the React docs showing this.

Post reply on HN