[HN Gopher] Learn how modern JavaScript frameworks work by build...
___________________________________________________________________
Learn how modern JavaScript frameworks work by building one
Author : kristianp
Score : 496 points
Date : 2023-12-03 20:00 UTC (1 days ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| djbusby wrote:
| I'm always surprised when articles mention a bunch of JS
| frameworks and leave out RiotJS. I can't be the only person using
| it?
| nonethewiser wrote:
| Never heard of it. Looks sveltish.
| djbusby wrote:
| I feel like they are all very similar. I found RiotJS before
| Svelte. Somehow it never caught a hype-train like others did.
|
| I suppose, if which ever choice is doing the trick - keep it
| while practicable
| izelnakri wrote:
| Yeah these type of articles always have hypester tone with less
| substance unfortunately. RiotJS is great but ember.js API/tools
| are even greater, highly suggest learning ember.js, if you
| value good APIs, testing & good community ;)
| eyelidlessness wrote:
| > Yeah these type of articles always have hypester tone with
| less substance unfortunately.
|
| Oh come on! The article mainly mentions the specific
| frameworks it does to qualify and contextualize the set of
| features it discusses, which it _goes on to implement_. The
| article is excellent, and this kind of reflexive dismissal is
| so tiresome.
| demosthanos wrote:
| I can't tell if this comment is tongue in cheek or not.
|
| The walkthrough on how to build a JS framework from scratch
| is "hypester" because in the short section that mentions
| existing frameworks, your pet frameworks weren't included?
| chungy wrote:
| oblig.
|
| https://www.youtube.com/watch?v=Wm2h0cbvsw8
| quickthrower2 wrote:
| Excellent. Cracked up when JFK (original) becomes JDK! Weird
| aspect ratio.
| threatofrain wrote:
| Does anyone have a recent one for building RxJS-lite?
| mickael-kerjean wrote:
| 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...
| WorldMaker wrote:
| 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.
| sakesun wrote:
| https://www.youtube.com/watch?v=m40cF91F8_A
| satvikpendem wrote:
| I personally also like Build Your Own React:
| https://pomb.us/build-your-own-react/
| 62951413 wrote:
| https://www.manning.com/books/build-a-frontend-web-framework...
| stanislavb wrote:
| Please, do not build more JS frameworks (see-no-evil emoji).
| gumballindie wrote:
| Coincidence or not but since the tech winter started there are
| fewer js modules and frameworks released. As it should be. Hope
| react manages to somehow die in the process.
| breadwinner wrote:
| You mean, you want React to continue for the rest of human
| history? Hope not!
| grey-area wrote:
| 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.
| mosselman wrote:
| 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 other things
| update as they are changed in the database, etc.
|
| 2 lines of fucking HTML.
|
| Sure turbo is built in JavaScript, but I have to spend zero
| time writing any and I get all the benefits in a 7 year old
| server side rendered page.
| eddd-ddde wrote:
| 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.
| quickthrower2 wrote:
| Just long enough and without a hooks style revolution so I
| can cruise for a bit. Build some stuff without keeping up.
| Like a carpenter. Tell the LLM people to slow it down too.
| slmjkdbtl wrote:
| It's more about learning how current frameworks works, and the
| best way is to learn to build one
| AlexErrant wrote:
| > From my perspective, the post-React frameworks have all
| converged on the same foundational ideas... Using reactivity
| (e.g. signals) for DOM updates.
|
| For an intro from the OG, consider this 6 minute video from Solid
| [0] or this blog post [1] by Solid's author.
|
| 0: https://www.youtube.com/watch?v=cELFZQAMdhQ
|
| 1: https://dev.to/ryansolid/building-a-reactive-library-from-
| sc...
| Kerrick wrote:
| I think Ryan would point you to Knockout as the OG.
| samsquire wrote:
| I haven't really kept up with frontend developments. My
| experience was with Knockout which I enjoyed and I did some hacky
| React more recently for devops-pipeline.com
|
| I am curious, to find the sweet area of maintainability +
| performance.
|
| Is the problem usually latency ? If you load too many items into
| a grid view you get performance problems.
|
| Maybe this problem is solved already - Facebook solved it - I
| would like to be able to create a "weak iterator" that handles
| forward and back navigation of collections with extremely fast
| rendering when moved backwards or forwards.
|
| Computers are fast, I like the ideas of immediate mode but they
| burn CPU.
| xrd wrote:
| 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, a Jekyll clone (the original static
| blog tool).
|
| https://extrastatic.dev/svekyll/svekyll-cli
|
| Not to toot my own horn, but I'm really proud of it. Svekyll
| scores all 100s with lighthouse but still has all the cool things
| you get from a Svelte app. It's a true single page app, all JS is
| inlined and can be put on any web server for hosting. Plus, a
| bunch of other cool things that only are possible with a native
| JS blog.
| synergy20 wrote:
| Until svelte can have a client-side router builtin, and treat
| SPA as its first class citizen(the way Vue.js does so far.
| React also shifts to SSR-SPA mixed situation jus like svelte,
| both are impacted by Vercel, which is really sad), instead of
| just focusing on its sveltekit SSR-first, I have zero interest
| in it. Yes I know I can customize sveltekit to do SPA, but it's
| very ugly and I don't need all your SSR mental load to an
| already complex frontend world.
|
| Both Svelte and React are shifting to SSR-first, which is what
| Vercel can make money with, I read somewhere Vercel had many
| React core members now, after it bought out Svelte.
| xrd wrote:
| Svekyll was originally built on sveltekit and I couldn't
| figure out how to get SSR and figure out the right adapter
| for nodejs and static hosting. Which is why I abandoned it
| and am much happier with a Svelte only CLI, just like Jekyll.
| sirsinsalot wrote:
| Or, rather than being some great conspiracy, SSR (or as we
| used to call it, just rendering) makes a great deal of sense.
|
| What goes around, comes around. It has always felt like the
| front-end frameworks, from things like Backbone to React
| always failed to learn the lessons of history. Preoccupied
| with being "new" in an area that's rapidly gaining
| capabilities via the browser.
|
| Re-inventing the wheel isn't difficult. Improving it is.
| Aerbil313 wrote:
| True. The drive to SSR is caused by the rise of battery-
| constrained mobile devices with unreliable wireless
| connections, along with the rise of cloud computing.
|
| I recently used a Windows 10 machine after years and I
| suggest you try it. It could not be more evident that
| Microsoft is fully betting on Web and Cloud. Windows is
| increasingly a thin client. Even the mail app isn't an
| actual mail client now.
| 6510 wrote:
| Someone some day should write an article about frameworks
| with examples that show it's advantages.
|
| I just try different things in vanilla depending on the
| load. In terms of speed nothing can beat just serving a
| page rendered on the server. If you really need dynamic
| updates replacing dom nodes is good up to some very limited
| number, virtual dom and cloned nodes increase this number
| by a tiny irrelevant amount. If you need to update more
| than 100 nodes, from what I've tested, nothing beats
| replacing the parent node content with a html string.
| Sometimes inline onclick="" handlers are great compared to
| creating 1000 listeners one by one. Sometimes you put the
| listener on the parent and figure out what was clicked when
| it happens. I've even had cases where iframes are
| wonderful. At times I also put some or many hidden nodes in
| the html document and display them when needed.
|
| Writing this I'm curious what the performance is for
| <output>....
|
| https://jsfiddle.net/4ajzcfw9/
|
| (Didn't feel like doing it right)
| mhh__ wrote:
| 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?
| 698969 wrote:
| 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
| much analysis on it.
|
| At least that were the reasons I saw when I was thinking
| about the same. If anyone has ideas around it, please get in
| touch.
| mhh__ wrote:
| 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.
| explaininjs wrote:
| Kind of an aside, but I can't stand how in Svelte the
| statement "foo = foo" is semantically meaningful.
| jamauro wrote:
| I think this will no longer be necessary in Svelte 5. We'll
| see.
| kevindamm wrote:
| It sounds like you would appreciate Vue3 and its <script
| setup> mode, the compiler does a lot of ref() and data flow
| analysis to make the code for components very readable.
| TehShrike wrote:
| 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/
| jph wrote:
| Toot your horn because your project is really great. I blog
| with SvelteKit, and your way has many improvements galore.
| Thank you for sharing this!
| xrd wrote:
| That's so cool of you to say this. Please email me at
| chris@extrastatic.com with any questions or feedback!
|
| And, as a bonus I'll share all the warts with you! It's not
| perfect but I love blogging with it.
| sureglymop wrote:
| I love svelte too but I've found it hard to integrate it in
| different places where I may run js (e.g. obsidian plugins,
| browser plugins). It was hard to configure the necessary
| tooling but maybe it's not sveltes fault. I think svelte would
| really benefit from better documentation on how to do this (and
| I don't mean sveltekit documentation). It was also at least
| non-trivial to use with typescript and even more non-trivial to
| have some third-party dependencies/components that don't use
| typescript. Again, maybe not sveltes fault and hard in every
| framework but those were my show-stopping issues the last time
| I tried to build something real in svelte.
| xrd wrote:
| Interesting. I think you should ask some questions inside the
| Svelte discord channel. My opinion is that Svelte is the
| easiest to integrate because it doesn't require the runtime
| that react does, for example. I've got Svelte running inside
| lots of non standard places, like browser extensions
| (https://addons.mozilla.org/en-US/firefox/addon/please-at-
| me/). It can take a few minutes to figure out how to get it
| built correctly for the context but it has never blocked me.
|
| I don't disagree about your typescript point. Svelte
| community seems to have aligned around typescript being a
| challenge and I do like their assertion that jsdoc+eslint is
| a better approach.
| n2d4 wrote:
| 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 (useMemo has a
| different role; it lets you choose when to recompute or recreate
| a normal JavaScript object. But on its own it won't stop
| rerendering of child components!) [0]
|
| This invalidates some of their assumptions. The reason why React
| isn't "push-only" isn't because it does that, it's because it
| sometimes buffers updates instead of always pushing them
| immediately. In fact, other frameworks like ~~Svelte also aren't
| "push-only" and hence not strictly reactive~~! [edit: this is no
| longer true after Svelte v5, see discussion below] (Funnily
| enough, OP uses an article as a source that explains this
| correctly [1], but it seems they took the wrong lesson from it).
|
| The reason why signals are so cool is because the framework knows
| for any given state change which exact attributes in the DOM need
| to be re-rendered, even more specifically than "the element and
| all its children". But this neither implies reactivity nor the
| other way around. The two concepts are orthogonal.
|
| Anyways, kudos to the author for diving into this so deeply!
|
| [0] useMemo is useful in combination with React.memo sometimes,
| as the latter compares objects shallowly/by reference instead of
| their contents, so useMemo can be used to only recreate shallow
| references if its contents changed. You could probably also
| reimplement React.memo with useMemo, but you probably shouldn't.
| [1] https://dev.to/this-is-learning/how-react-isn-t-reactive-
| and...
| nolanl wrote:
| 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 mode" does exactly
| that. This is what I mean by "moving in that direction."
| n2d4 wrote:
| Appreciate the response! You're right on Svelte v5; I just
| confirmed that Svelte's new runes are indeed reactive:
| let count = $state(0); function increment()
| { count += 1; console.log(count + " + 1 =
| " + countPlusOne); // prints "1 + 1 = 2" }
| let countPlusOne = $derived(count + 1);
| anonzzzies wrote:
| I never used svelte, so it's probably a weird question, but
| how is increment() called?
| 698969 wrote:
| The calling location has been omitted from the snippet.
| You don't need to do anything special to call it, just
| `increment()` wherever it's in scope.
|
| `<button on:click={() => increment()}>+</button>`
| lifeisstillgood wrote:
| could you explain why this demonstrates svelte is reactive?
|
| What's the definition of reactive is I think my question
| and having a clear demo is useful - if I understood it it
| looks a useful piece code
| ketzo wrote:
| Hard to ride the line between clear, concise explanation and
| perfect technical correctness; I thought you picked good
| tradeoffs in your article.
| culi wrote:
| > I know that React doesn't invalidate the whole tree, but it
| does in the worst case
|
| You mean *invalidate the whole _subtree_ , right?
| thorway288 wrote:
| The quote quite literally states "grossly oversimplify". It
| being "not quite" correct is sort of the aim, for the sake of
| conveying a broader point.
| pavlov wrote:
| _> "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 basically a
| shorthand for useMemo that takes the props as the dependency.
| uryga wrote:
| > 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 :)
| pavlov wrote:
| _> "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.
| culi wrote:
| Using `useMemo` without using `React.memo` on the child
| component does not prevent a rerender at all.
| culi wrote:
| > 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
| pavlov wrote:
| I'm not sure what you're arguing here.
|
| useMemo() works for memoizing child elements. I linked to
| the React docs showing this.
| culi wrote:
| 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
| chupapimunyenyo wrote:
| Wow, what a site, I love that feel of blogs
| esafak wrote:
| It's wordpress.
| chupapimunyenyo wrote:
| Yes, I realize this
| valenterry wrote:
| Question to the folks with a lot of frontend framework
| experience:
|
| Is there a framework/library that supports the usage of an
| effect-system when it comes to rendering actions?
|
| For instance, in react, a component (or rather it's render-
| function) has to return the element(s) directly. Is there a
| framework where the render-function accepts something effect-like
| or promise-like instead, even if that means that the rendering
| might potentially be delayed?
| n2d4 wrote:
| React now supports this using Suspense boundaries [0]. Some
| frameworks (eg. NextJS) already ship variants of it but here is
| some code you could use in React's development version:
| function MyComponent() { const promise = ...;
| const result = use(promise); // use is like await //
| do something } function Wrapper() {
| return ( <Suspense fallback={<Loading />}>
| <MyComponent /> </Suspense> ); }
|
| You don't need to know this to use it, but the implementation
| is both interesting and horrifying: The `use` hook checks if
| the Promise has resolved, and if not, it throws an error that
| is caught by the Suspense boundary. And because there is no
| property like `hasResolved` on JS promises, `use` adds one
| itself. (At least this was how an early draft proposed it, a
| lot of changes have been done since, and my knowledge might be
| out of date.)
|
| [0] https://react.dev/reference/react/Suspense
| valenterry wrote:
| Thank you, this is exactly what I meant! Awesome that this is
| already being worked on in react.
|
| Yeah, the implementation under the hood seems a bit crazy.
| Reminds me of how I found out that angular used to call
| toString on functions to get the parameter names for
| dependency injection.
|
| But honestly, if I can use it without problems as a user,
| that's what I care most, even if the backend developer in me
| is horrified about it, haha. But I guess that is mostly
| Javascripts fault after all.
| eyelidlessness wrote:
| The way Suspense works is actually even a bit more
| interesting/horrifying: it doesn't throw an error, it throws
| _a Promise_. Which again you don't need to know to use it,
| and so it's a valid implementation detail, but it's a really
| odd one.
| SebastianKra wrote:
| To be fair, in js, throwing is the only way a function (aka
| Hook) can abort the execution of its calling function (aka
| Component).
|
| The decision to avoid a custom compiler is responsible for
| almost all oddities and downsides of React.
| theteapot wrote:
| Is a thing in Vue3 also -- https://vuejs.org/guide/built-
| ins/suspense.html
| marcelr wrote:
| If you mean effects as data, I can't think of anything off top
| other than elm which is a language + framework.
|
| I've made my own though:
| https://github.com/marcellerusu/capable-js.
|
| Its not for use but it was an interesting experience that
| enables a lot of new patterns by using generators.
|
| I don't claim that it is better than other frameworks though,
| there's a lot of times where this pattern is significantly more
| cumbersome than just using react.
| valenterry wrote:
| Very cool! Especially I liked your example of elements that
| have "finished". Funnily, this was one of the major problems
| of mine when I built [visakami](www.visakami.com) which
| essentially is just a survey on steroids.
|
| I think you should join the react developer's team. ;-)
| tipiirai wrote:
| > Question to the folks with a lot of frontend framework
| experience:
|
| I think this should be "...with a lot of _React_ experience ".
| unlog wrote:
| Recently, I wrote a web renderer/framework using solid-js
| reactivity to understand how a reactive renderer works. The docs
| website been written with it and mainly to test the library.
| https://pota.quack.uy/ . Source code
| https://github.com/potaorg/pota
| diamondfist25 wrote:
| Is there a way to make react "reactive" and have to define all
| the useState, useEffect?
| hliyan wrote:
| This is a good article, but I've noticed that the adjective
| "modern" is used disproportionately more in the world of
| JavaScript, compared to other tech stacks. Is it more performant,
| more maintainable, faster to develop, compatible with more
| devices/platforms? If not, what is the advantage of being modern?
| That said, I'm a fan of JavaScript and have been writing it since
| 2001, and many of the backends I write are Node.
| userbinator wrote:
| My observation is that there is a lot more cargo-culting /
| trendchasing in the JS world, largely due to its low barrier to
| entry. The overuse of "modern" is a dogma more than anything.
|
| (I mainly work on native desktop apps, but can use JS if
| needed.)
| nolanl wrote:
| Author here! I struggled with the word "modern" - I could have
| said "current gen" or "post-React" or even "Solid-inspired"
| frankly, but I thought "modern" was succinct with the right
| amount of punchiness.
|
| Obviously a lot of these techniques are pretty novel, and maybe
| they won't stand the test of time. Or maybe a new browser
| standard will make them obsolete eventually. But for now these
| seem to be the current wave anyway.
| hliyan wrote:
| Perhaps you could have said that it is built using more
| modern JS APIs - template literals instead of string
| manipulation, Proxy(), queueMicrotask etc.
| jillesvangurp wrote:
| It's a fair criticism. React has been around for ten years now.
| Which by Javascript standards makes it ancient. IMHO, the
| javascript community has been chasing its tail a bit for most
| of that time in the sense that there have been very few real
| innovations. People keep on reinventing the same wheels. But
| mostly the same things that were a problem ten years ago are
| still problems. Problems such as managing state in a sane way,
| preventing issues with performance related to state changes,
| and keeping code bases maintainable. I'm not sure that modern
| is a word I'd slap on the notion of not quite having figured
| out those things still.
|
| I have good hopes for some disruptions to arrive on the web via
| wasm. There are some interesting things happening in that space
| that are increasingly less about Javascript, dom trees, css,
| and all the limitations that come with those and more about
| leveling the playing field with mobile where UIs are more
| competitive and non Javascript frameworks seem to be preferred
| over the poor man's choice (aka. web based).
|
| I'm saying that as somebody actually pushing web based on
| mobile (we are about to release a PWA). Just acknowledging the
| reality that web-based is still considered a huge compromise on
| ux, performance, and capabilities on mobile. Good enough is the
| best you can say about it. Some of those mobile frameworks
| (flutter, compose web, and others) are now coming to the web
| via wasm. IMHO, there are a lot more interesting things that
| could be done in that space in the next years.
| localvoid wrote:
| If anyone is interested in this topic, I would recommend to start
| from fundamentals, so it would provide some answers on why some
| "not so modern" frameworks aren't jumping on a "signals" hype-
| train.
|
| - Incremental computing -
| https://en.wikipedia.org/wiki/Incremental_computing
|
| - Self-Adjusting Computation (Umut A. Acar) -
| https://www.cs.cmu.edu/~rwh/students/acar.pdf
|
| - Introducing incremental (JaneStreet) -
| https://blog.janestreet.com/introducing-incremental/
|
| - Incremental computation and the web (JaneStreet) -
| https://blog.janestreet.com/incrementality-and-the-web/
|
| - Self Adjusting DOM (JaneStreet) -
| https://blog.janestreet.com/self-adjusting-dom/
|
| - Self Adjusting DOM and Diffable Data (JaneStreet) -
| https://blog.janestreet.com/self-adjusting-dom-and-diffable-...
|
| - Incremental Computation (Draft of part 1) (Rado Kirov) -
| https://rkirov.github.io/posts/incremental_computation/
|
| - Incremental Computation (Draft of part 2) (Rado Kirov) -
| https://rkirov.github.io/posts/incremental_computation_2/
|
| - Incremental Computation (Draft of part 3) (Rado Kirov) -
| https://rkirov.github.io/posts/incremental_computation_3/
|
| - Towards a unified theory of reactive UI (Raph Levien) -
| https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
| genuine_smiles wrote:
| Besides React, are any of the popular frameworks not on the
| signals type-train?
| localvoid wrote:
| I've stopped paying close attention to the web framework
| scene in the past couple of years, as most of the interesting
| ideas on this topics are usually coming from different
| communities. But as I understand, the majority of popular web
| frameworks (React, Vue3, Angular) are still using tree
| diffing or hybrid "signals"+tree diffing strategies.
|
| In my opinion, one of the most interesting ideas to explore
| in this problem space is a hybrid solution: differential
| dataflow[1][2](model) + self-adjusting computations(view-
| model + view).
|
| 1. https://github.com/vlcn-io/materialite
|
| 2. https://timelydataflow.github.io/differential-dataflow/
| gherkinnn wrote:
| Vue.js is and isn't. It did ""fine grained reactivity getter
| setter proxy something"" before it was cool [0].
|
| At this point I can't stop myself from pointing out that the
| underlying reactivity/diffing system is rarely what makes an
| application slow. I've heard the creator of XState and
| Stately [1] say that React's vdom is not fast enough for
| updating edges in their state chart in real time without lots
| of optimisations and I believe him. It's just that most
| people don't encounter such issues and spend adding a dozen
| tracking scripts that run before the actual application does.
|
| 0 - https://vuejs.org/guide/extras/reactivity-in-
| depth.html#conn...
|
| 1 - https://stately.ai/
| scotty79 wrote:
| What does this use?
|
| https://apprun.js.org/
| recursive wrote:
| 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.
| zubairq wrote:
| I ended up building a JS Framework too.. all part of the journey!
| ;)
| noduerme wrote:
| You need a class called ScreenManager, one called Screen, and one
| called Component. Make Screen and Component able to load an htm
| file, then hook its tags on the DOM and do whatever you want.
| Update a counter? Write that in your component. Some static
| networking class in the background either long-polls or gets
| pushed new data, dispatches update events that any component can
| listen to. Each component can make its own calls and update its
| own data instantly when a user interacts with it.
|
| No abstraction, no nonstandard HTML tags, no <template>, no
| Proxy, no master class trying to figure out what part of the DOM
| should or shouldn't be redrawn based on inbound data. Every
| component should be autonomous, every screen should be able to
| destroy or resurrect its own components. If you need a central
| data cache, put that on the ping and let every component deal
| with it on the event firing.
|
| [edit] I've built and maintained two frameworks, one for websites
| and one for single page apps, rewritten and improved over 20
| years, originally in PHP, now in Nodejs. The main guiding
| principle for me has always been decoupling design from code.
| WA wrote:
| Sounds like you implemented MVC. Model (=Component) handles its
| own state. Screen (=View) subscribes to state changes in the
| model. ScreenManager (=Controller) glues it all together.
|
| It probably works just fine, but gets cumbersome if you want to
| know exactly where a piece of state is managed or the order of
| event processing is important for some reason.
| EGreg wrote:
| When they say Svelte "compiles" your code into Javascript,
| doesn't it still mean it has to ship some common code alongside
| your transformed code? Isn't that still the core of a Framework?
| sesm wrote:
| 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.
| exabrial wrote:
| https://dayssincelastjavascriptframework.com
| zilti wrote:
| "Learn how a hole in a knee comes into existence by drilling one
| into your own knee"
___________________________________________________________________
(page generated 2023-12-04 23:02 UTC)