How I built a fast JavaScript framework
In this technical retrospective (2018), @krapans shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 45 points
TOTAL DISCUSSIONS 61 comments
I am often frustrated in this ecosystem by how people build things without any clear conceptual model, and then they document them by saying "it is so fast, it just works like magic". It is impossible to compare two approaches because there are no facts available to compare them on.
Like for this one from a peek at the source code it appears to try to parse JavaScript at runtime using regexes (https://github.com/radi-js/radi/blob/master/src/index.js#L4 ↗) which is great for demoware and not at all something I'd want to use in production, but that is not mentioned anywhere in the site or blog post.
I don't mean to just dump on this project in particular, which could just be a fun toy side project for the author, because this problem is endemic. (But then why go to all the effort to make all the marketing materials for it without actually writing any docs?)
This looks similar in many ways to mithril[1] -- somewhat similar api - mount, view, r("input") vs m("input"). The counter example[2] looks similar[3] I'd be interested in seeing comparisons between the two.
[1] https://mithril.js.org/ ↗
[2] https://github.com/MithrilJS/mithril.js/blob/5956314e3655a3c85f8425bffc2bd76c1c541a3b/docs/mount.md ↗
[3] https://github.com/radi-js/radi/blob/master/examples/counter.html ↗
The reason diffing and virtual doms are used are to prevent unnecessarily repainting the browser window 1000 times a second. If I have 5 updates to make, I want to do those in one paint, instead of 5. So the process is change -> change -> change -> paint.
With this framework's model, the process would be change -> paint -> change -> paint etc. etc. Sure, you get nice FPS (because it's painting a LOT), but that will destroy battery performance on mobile phones and I don't need 60 FPS in my shopping web app.
I recently did a project with morphdom (https://github.com/patrick-steele-idem/morphdom ↗) using only ES6 template strings and a render loop that checked for changes to a global state object and patched a re-computed DOM string using morphdom. Couldn’t have been an easier and more pleasurable experience.
I'm not a frontend developer and don't know really know JavaScript frameworks. That said, it seems like something very well established like React would choose to have a virtual DOM for a good reason.
Surely there must be some tradeoffs that the author makes for his design to get better performance. Could somebody explain the cost/benefit of doing things one way versus the other?