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

91–100 of 104 posts

Re: Learn how modern JavaScript frameworks work by building one

#91

Post by culi »

pavlov wrote: post #90
culi wrote: post #87

Earlier quoted context omitted.

> 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.

I see what you mean. I'm a little shocked the docs have an example of it being used in this way. Using `useMemo` in this way is generally considered a bad practice and a "hack". The new version of the react docs does not have an example of useMemo being (mis)-used in this way

Re: Learn how modern JavaScript frameworks work by building one

#92

Post by TehShrike »

mhh__ wrote: post #22
xrd wrote: post #16

I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework! I used this to build Svekyll,…

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?

I believe the constraints chosen could be summarized as

1. the code you write must parse as valid JS

2. you must be able to write traditional JS

3. we want the equivalent of the Destiny Operator https://paulstovell.com/reactive-programming/

Re: Learn how modern JavaScript frameworks work by building one

#95

Post by WorldMaker »

mickael-kerjean wrote: post #8
threatofrain wrote: post #6

Does anyone have a recent one for building RxJS-lite?

Yes, I rewrote my non toy project react app onto vanilla JS using nothing else than rxjs, didn't have the time to document it all yet but it looks like this: https://github.com/mickael-kerjean/filestash/blob/master/pub...

I've been taking a similar, but somewhat different approach to upgrading some old Knockout projects to mostly Vanilla JS+RxJS.

Here's one example app: https://github.com/WorldMaker/compradprog/blob/main/main.tsx

One of the obvious differences is that I'm still using TSX, but it is very different from React, it just looks a lot like React at first glance.

Also, because I was doing it across at least a couple of projects, I started it from the beginning as its own small framework and have been trying to document it: https://github.com/WorldMaker/butterfloat/tree/main

It's still very much in early "prerelease" stages, but feedback is welcome.

Re: Learn how modern JavaScript frameworks work by building one

#96

Post by satvikpendem »

62951413 wrote: post #93
satvikpendem wrote: post #7

I personally also like Build Your Own React: https://pomb.us/build-your-own-react/

https://www.manning.com/books/build-a-frontend-web-framework...

Nice, I will have to pick that up once it releases.

Re: Learn how modern JavaScript frameworks work by building one

#97

Post by acemarke »

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…

React actually has a little-known "same element reference" optimization. If your component returns the exact same JSX element reference in the same spot in consecutive renders, React will bail out of rendering that subtree, regardless of whether or not the child component is wrapped in `React.memo()`. This allows the parent component to control the behavior. So yes, `useMemo` would be how you do that:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Re: Learn how modern JavaScript frameworks work by building one

#99

Post by notnullorvoid »

recursive wrote: post #44

I recently did this because none of them are exactly what I wanted. I really like the idea of reactive proxies and pushing changes. Things get trickier when you try to address mutable arrays and other scenarios. The one I made is https://mutraction.dev/ The name is a portmanteau of mutation tracking.

For arrays, did you end up taking the diffing/memoization approach like solid?

I've yet to see any framework have O(1) collection mutation reactivity.

Re: Learn how modern JavaScript frameworks work by building one

#100

Post by recursive »

notnullorvoid wrote: post #99
recursive wrote: post #44

I recently did this because none of them are exactly what I wanted. I really like the idea of reactive proxies and pushing changes. Things get trickier when you try to address mutable arrays and other scenarios. The one I made is https://mutraction.dev/ The name is a portmanteau of mutation tracking.

For arrays, did you end up taking the diffing/memoization approach like solid? I've yet to see any framework have O(1) collection mutation reactivity.

There's no diff. Arrays get proxies just like everything else.

For mutations that change the length, extra elements are built or removed at the end. Assignment straight to an index (that doesn't change length) is able to use normal object property semantics.

arr.push(e) and arr[i] = e are both O(1). But not all array operations achieve this.

Post reply on HN