7 ms·

Learn how modern JavaScript frameworks work by building one

531 points by kristianp 3y ago

michael_forrest 3y ago
What a simultaneously wonderful yet horrifying idea!
djbusby 3y ago
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 3y ago
  Never heard of it. Looks sveltish.
  - djbusby 3y ago
    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 3y ago
  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 3y ago
    > 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 3y ago
    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?
    - izelnakri 3y ago
      [flagged]
chungy 3y ago
oblig. https://www.youtube.com/watch?v=Wm2h0cbvsw8 https://www.youtube.com/watch?v=Wm2h0cbvsw8
- quickthrower2 3y ago
  Excellent. Cracked up when JFK (original) becomes JDK! Weird aspect ratio.
threatofrain 3y ago
Does anyone have a recent one for building RxJS-lite?
- mickael-kerjean 3y ago
  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/public/assets/pages/adminpage/ctrl_about.js https://github.com/mickael-kerjean/filestash/blob/master/pub...
  - WorldMaker 3y ago
    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 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 https://github.com/WorldMaker/butterfloat/tree/main It's still very much in early "prerelease" stages, but feedback is welcome.
- sakesun 3y ago
  https://www.youtube.com/watch?v=m40cF91F8_A https://www.youtube.com/watch?v=m40cF91F8_A
satvikpendem 3y ago
I personally also like Build Your Own React: https://pomb.us/build-your-own-react/ https://pomb.us/build-your-own-react/
- 62951413 3y ago
  https://www.manning.com/books/build-a-frontend-web-framework-from-scratch https://www.manning.com/books/build-a-frontend-web-framework...
  - satvikpendem 3y ago
    Nice, I will have to pick that up once it releases.
stanislavb 3y ago
Please, do not build more JS frameworks (see-no-evil emoji).
- gumballindie 3y ago
  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 3y ago
  You mean, you want React to continue for the rest of human history? Hope not!
  - grey-area 3y ago
    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 3y ago
      Have a look at this video in Rails’ Turbo 8: https://m.youtube.com/watch?v=hKKycPLN-sk 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 3y ago
        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-cloudflare-workers-2cp4 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.
AlexErrant 3y ago
> 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 https://www.youtube.com/watch?v=cELFZQAMdhQ 1: https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p https://dev.to/ryansolid/building-a-reactive-library-from-sc...
- Kerrick 3y ago
  I think Ryan would point you to Knockout as the OG.
samsquire 3y ago
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 3y ago
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 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 3y ago
  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 3y ago
    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 3y ago
    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.
n2d4 3y ago
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-why-you-shouldn-t-care-152m https://dev.to/this-is-learning/how-react-isn-t-reactive-and...
- nolanl 3y ago
  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."
chupapimunyenyo 3y ago
Wow, what a site, I love that feel of blogs
- esafak 3y ago
  It's wordpress.
  - chupapimunyenyo 3y ago
    Yes, I realize this
valenterry 3y ago
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 3y ago
  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 https://react.dev/reference/react/Suspense
  - valenterry 3y ago
    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 3y ago
    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.
unlog 3y ago
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/ https://pota.quack.uy/ . Source code https://github.com/potaorg/pota https://github.com/potaorg/pota
diamondfist25 3y ago
Is there a way to make react “reactive” and have to define all the useState, useEffect?
hliyan 3y ago
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.
- deleted 3y ago
  [deleted]
- userbinator 3y ago
  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 3y ago
  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 3y ago
    Perhaps you could have said that it is built using more modern JS APIs - template literals instead of string manipulation, Proxy(), queueMicrotask etc.
- jillesvangurp 3y ago
  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 3y ago
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 https://en.wikipedia.org/wiki/Incremental_computing - Self-Adjusting Computation (Umut A. Acar) - https://www.cs.cmu.edu/~rwh/students/acar.pdf https://www.cs.cmu.edu/~rwh/students/acar.pdf - Introducing incremental (JaneStreet) - https://blog.janestreet.com/introducing-incremental/ https://blog.janestreet.com/introducing-incremental/ - Incremental computation and the web (JaneStreet) - https://blog.janestreet.com/incrementality-and-the-web/ https://blog.janestreet.com/incrementality-and-the-web/ - Self Adjusting DOM (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom/ https://blog.janestreet.com/self-adjusting-dom/ - Self Adjusting DOM and Diffable Data (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom-and-diffable-data/ https://blog.janestreet.com/self-adjusting-dom-and-diffable-... - Incremental Computation (Draft of part 1) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation/ https://rkirov.github.io/posts/incremental_computation/ - Incremental Computation (Draft of part 2) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_2/ https://rkirov.github.io/posts/incremental_computation_2/ - Incremental Computation (Draft of part 3) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_3/ 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.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
- genuine_smiles 3y ago
  Besides React, are any of the popular frameworks not on the signals type-train?
  - localvoid 3y ago
    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 https://github.com/vlcn-io/materialite 2. https://timelydataflow.github.io/differential-dataflow/ https://timelydataflow.github.io/differential-dataflow/
recursive 3y ago
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/ https://mutraction.dev/ The name is a portmanteau of mutation tracking.
- notnullorvoid 3y ago
  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.
  - recursive 3y ago
    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.
    - notnullorvoid 3y ago
      Wow, took a look at the ForEach code to better understand. That's a very novel approach.
      - recursive 3y ago
        I'm not too familiar with the state of the art, but I assumed this had been done before. I have some vague ideas about implementing efficient .splice() calls. Right now knowledge about splicing semantics is lost in between the proxy layer and `ForEach` DOM node array. But I have a bunch of other plans to do first.
gboza1 3y ago
[dead]
zubairq 3y ago
I ended up building a JS Framework too.. all part of the journey! ;)
noduerme 3y ago
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 3y ago
  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.
T3RMINATED 3y ago
[dead]
EGreg 3y ago
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 3y ago
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 3y ago
https://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com
zilti 3y ago
"Learn how a hole in a knee comes into existence by drilling one into your own knee"

531 points by kristianp 3y ago

What a simultaneously wonderful yet horrifying idea!

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 3y ago
Never heard of it. Looks sveltish.
- djbusby 3y ago
  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 3y ago
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 3y ago
  > 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 3y ago
  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?
  - izelnakri 3y ago
    [flagged]

chungy 3y ago

oblig. https://www.youtube.com/watch?v=Wm2h0cbvsw8 https://www.youtube.com/watch?v=Wm2h0cbvsw8

quickthrower2 3y ago
Excellent. Cracked up when JFK (original) becomes JDK! Weird aspect ratio.

threatofrain 3y ago

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

mickael-kerjean 3y ago
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/public/assets/pages/adminpage/ctrl_about.js https://github.com/mickael-kerjean/filestash/blob/master/pub...
- WorldMaker 3y ago
  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 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 https://github.com/WorldMaker/butterfloat/tree/main It's still very much in early "prerelease" stages, but feedback is welcome.
sakesun 3y ago
https://www.youtube.com/watch?v=m40cF91F8_A https://www.youtube.com/watch?v=m40cF91F8_A

satvikpendem 3y ago

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

62951413 3y ago
https://www.manning.com/books/build-a-frontend-web-framework-from-scratch https://www.manning.com/books/build-a-frontend-web-framework...
- satvikpendem 3y ago
  Nice, I will have to pick that up once it releases.

stanislavb 3y ago

Please, do not build more JS frameworks (see-no-evil emoji).

gumballindie 3y ago
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 3y ago
You mean, you want React to continue for the rest of human history? Hope not!
- grey-area 3y ago
  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 3y ago
    Have a look at this video in Rails’ Turbo 8: https://m.youtube.com/watch?v=hKKycPLN-sk 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 3y ago
      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-cloudflare-workers-2cp4 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.

AlexErrant 3y ago

> 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 https://www.youtube.com/watch?v=cELFZQAMdhQ 1: https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p https://dev.to/ryansolid/building-a-reactive-library-from-sc...

Kerrick 3y ago
I think Ryan would point you to Knockout as the OG.

samsquire 3y ago

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 3y ago

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 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 3y ago
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 3y ago
  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 3y ago
  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.

n2d4 3y ago

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-why-you-shouldn-t-care-152m https://dev.to/this-is-learning/how-react-isn-t-reactive-and...

nolanl 3y ago
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."

chupapimunyenyo 3y ago

Wow, what a site, I love that feel of blogs

esafak 3y ago
It's wordpress.
- chupapimunyenyo 3y ago
  Yes, I realize this

valenterry 3y ago

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 3y ago
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 https://react.dev/reference/react/Suspense
- valenterry 3y ago
  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 3y ago
  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.

unlog 3y ago

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/ https://pota.quack.uy/ . Source code https://github.com/potaorg/pota https://github.com/potaorg/pota

diamondfist25 3y ago

Is there a way to make react “reactive” and have to define all the useState, useEffect?

hliyan 3y ago

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.

deleted 3y ago
[deleted]
userbinator 3y ago
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 3y ago
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 3y ago
  Perhaps you could have said that it is built using more modern JS APIs - template literals instead of string manipulation, Proxy(), queueMicrotask etc.
jillesvangurp 3y ago
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 3y ago

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 https://en.wikipedia.org/wiki/Incremental_computing - Self-Adjusting Computation (Umut A. Acar) - https://www.cs.cmu.edu/~rwh/students/acar.pdf https://www.cs.cmu.edu/~rwh/students/acar.pdf - Introducing incremental (JaneStreet) - https://blog.janestreet.com/introducing-incremental/ https://blog.janestreet.com/introducing-incremental/ - Incremental computation and the web (JaneStreet) - https://blog.janestreet.com/incrementality-and-the-web/ https://blog.janestreet.com/incrementality-and-the-web/ - Self Adjusting DOM (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom/ https://blog.janestreet.com/self-adjusting-dom/ - Self Adjusting DOM and Diffable Data (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom-and-diffable-data/ https://blog.janestreet.com/self-adjusting-dom-and-diffable-... - Incremental Computation (Draft of part 1) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation/ https://rkirov.github.io/posts/incremental_computation/ - Incremental Computation (Draft of part 2) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_2/ https://rkirov.github.io/posts/incremental_computation_2/ - Incremental Computation (Draft of part 3) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_3/ 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.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....

genuine_smiles 3y ago
Besides React, are any of the popular frameworks not on the signals type-train?
- localvoid 3y ago
  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 https://github.com/vlcn-io/materialite 2. https://timelydataflow.github.io/differential-dataflow/ https://timelydataflow.github.io/differential-dataflow/

recursive 3y ago

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/ https://mutraction.dev/ The name is a portmanteau of mutation tracking.

notnullorvoid 3y ago
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.
- recursive 3y ago
  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.
  - notnullorvoid 3y ago
    Wow, took a look at the ForEach code to better understand. That's a very novel approach.
    - recursive 3y ago
      I'm not too familiar with the state of the art, but I assumed this had been done before. I have some vague ideas about implementing efficient .splice() calls. Right now knowledge about splicing semantics is lost in between the proxy layer and `ForEach` DOM node array. But I have a bunch of other plans to do first.

gboza1 3y ago

[dead]

zubairq 3y ago

I ended up building a JS Framework too.. all part of the journey! ;)

noduerme 3y ago

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 3y ago
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.

T3RMINATED 3y ago

[dead]

EGreg 3y ago

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 3y ago

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 3y ago

https://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com

zilti 3y ago

"Learn how a hole in a knee comes into existence by drilling one into your own knee"