React Vs. Backbone in 2025
Posted2 months agoActive2 months ago
backbonenotbad.hyperclay.comTechstory
calmmixed
Debate
20/100
ReactBackbone.jsFront-End DevelopmentJavascript Frameworks
Key topics
React
Backbone.js
Front-End Development
Javascript Frameworks
The article compares React and Backbone.js in the context of 2025, sparking a discussion on the relevance and advantages of each framework.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
2h
Peak period
1
0-3h
Avg / period
1
Key moments
- 01Story posted
Oct 22, 2025 at 11:47 PM EDT
2 months ago
Step 01 - 02First comment
Oct 23, 2025 at 1:41 AM EDT
2h after posting
Step 02 - 03Peak activity
1 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 24, 2025 at 9:48 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45677968Type: storyLast synced: 11/17/2025, 9:12:00 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I've been thinking and experimenting with re-rendering the whole DOM[1]. I'm aware there are libraries for merging DOM trees, but I'm limiting the project to native APIs. I'm following React's declarative model with a 10 LoC React.createElement implementation. Since there's no native DOM merge API, I'm mutating the DOM in two places, but reusing the components.
So far, I believe that given a merge DOM function or native API, we can get the benefits of React with a few utilities.
[1] https://github.com/ericfortis/mockaton/blob/main/src/Dashboa...
---
> Is there a better model?
IMO, React class components with something like Meteor’s ReactiveVar for state. Here’s an implementation for that standalone state:
https://github.com/uxtely/js-utils/tree/main/reactive-state
You're absolutely right that a native DOM merge API would unlock this pattern completely. I just wish this could happen in the DOM instead of JS, so that we could get the power of the DOM as an intuitive model to think about instead of abstracting it into an amorphous data structure.
The fact that it has no build step and works directly on the DOM is fantastic — very similar to Backbone in terms of being able to understand what's happening under the hood! You can pop open devtools, see exactly what's happening, and modify it on the fly. No virtual DOM, no reconciliation mysteries, just functions returning DOM descriptions that get wholesale replaced.