6 ms·
You don't need React: creating a minimal UI library in Vanilla JavaScript
- huflungdung 2mo ago[dead]
- wild_egg 2mo ago> immediate mode You keep using that word. I do not think it means what you think it means. React most definitely falls under what would be called a "retained mode" of some sort. And the UI library described here is also.
- pedro_movai 2mo agoI think the author is referring to immediate mode because of UI=f(state)
- wild_egg 2mo agoI do understand that's what they have in mind. But that's not what immediate mode means. Function application is not the only criteria. We are talking about rendering into a browser by twiddling DOM APIs. That's definitely retained mode rendering and repeatedly claiming it's immediate mode doesn't make it true
- account42 2mo agoWith that argument, every UI is retained mode because everything gets saved in the GPU's scan out buffer.
- magicalhippo 2mo agoIf you compare the code using the presented framework to code using say immediate mode library like ImGui[1][2] for example, the presented framework does indeed seem to be exposing a retained mode API. [1]: https://pthom.github.io/imgui_explorer/ https://pthom.github.io/imgui_explorer/ [2]: https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- sroerick 2mo agoIsn't React specifically an attempt to build an immediate mode UI on top of the DOM?
- Flavius 2mo agoAfter looking at the code in the tic tac toe example I am now 100% convinced that I need React.
- inigyou 2mo agoReact and systemd feel the same way to me: both really sensible ideas at the core, surrounded in layers of bullshit.
- Oras 2mo ago> The only potential issue with immediate mode is performance, since we need to re-render the entire UI on every state change. How this made it to HN front page?
- pedro_movai 2mo agoI think the author is saying a potential issue of a vanilla implementation of immediate mode. The following text explains that there is already many optimizations for this
- inigyou 2mo agoNothing in HTML is immediate mode. Any framework with a DOM is retained mode, by definition.
- pedro_movai 2mo agoBut the api is trying to simulate immediate mode using DOM
- inigyou 2mo agoThat's called an "abomination". The advantage of immediate mode is not storing a DOM. If you write immediate-mode code but it stores a DOM anyway then it's the worst of both worlds.
- mythz 2mo agoMinimal UI library results in maximal App code, which makes it a good usecase for why you're better of with React/Vue
- gulugawa 2mo agoI looked at the author's website, and a typical page downloaded around 60kb or less of JavaScript.
- brazukadev 2mo agothat's less than just React
- hsn915 2mo agoIf you are going to advocate against something, the alternative you propose needs to be better in some important area, other than "not that thing". What is the thing you hate about react, and what is the thing you require in an alternative? I hate bloat and require lightness, so I use Preact. I also hate complexity and difficult to read stuff, so when I look at the proposal here, I don't see anything appealing, other than "look! it's not react!"
- jakelazaroff 2mo ago> The only potential issue with immediate mode is performance, since we need to re-render the entire UI on every state change. Notice that in the task list example, if you leave some text in the input and check off a task, your text will be erased. If we could truly treat the DOM as an immediate-mode UI, there would be no need for React/Preact/ Svelte/Solid/etc. But it turns out there are a fair number of quirks like this that preclude such simple replacements from working correctly. (That said: I am all for experiments like this for learning, or for fun, or to try out unexplored framework design space!)
- draw_down 2mo ago[dead]
- bryanhogan 2mo agoI agree that React gets overused for many websites, but I'm not sure about this project over something like Astro. I built an Astro Starter that uses just CSS in a scalable way for simple websites. Content is written in Markdown / MDX files. Design tokens are set in var.css. Other stuff is defined in one config.ts file. Global styling is set though a few CSS files (Global, Reset, Var, Util, Markdown), components are scoped in styling but utilise the tokens. Link: https://starter.bryanhogan.com/ https://starter.bryanhogan.com/ GitHub repository: https://starter.bryanhogan.com/ https://starter.bryanhogan.com/
- deleted 2mo ago[deleted]
- netdur 2mo agounlike many of the commenters, I found this pretty nice and educational, there are full stack developers who cannot write anything outside React and do not even understand why React was created in the first place
- pedro_movai 2mo agoNice! positive comment
- brazukadev 2mo agodon't let the negative comments affect your mood, lots of people here are too invested. It is difficult to get a man to understand something, when his salary depends on his not understanding it.
- bofadeez 2mo ago[flagged]
- afavour 2mo agoFramework, not language. And framework choice still matters.
- orphea 2mo agoSo do programming languages, fwiw. The argument of "we have Fable, X doesn't matter anymore" is a severe case of delusion.
- bofadeez 2mo agoI would have agreed before I used Fable. It's not even vibe coding anymore. It's just coding. E.g. Just always use Rust instead of Python.
- bofadeez 2mo agoTomato tomato. English is my favorite new programming language.
- afavour 2mo agoYou're showing your ignorance here. Different frameworks have different ways of working that can lead to better or worse performance on client devices, no matter what Fable spits out for you. You owe it to your users to care.
- bofadeez 2mo agoHave you tired using several billion Fable tokens in production? It will do whatever you want. So you can still have your opinions on what works best. But it doesn't matter much, it's not 2025 anymore. E.g. always use Rust instead of Python
- afavour 2mo agoI think React is way overused but every time you see a blog post with "replace it with this pet mini project instead" I groan because you know the reaction is going to be "what about X feature", and of course the mini framework doesn't do it. I've found the perfect balance to be Astro with Preact. You will inevitably have some piece of functionality that's complex (say, a contact form) and you can lean into Preact for that. But for the vast majority of a content-heavy site you can just use Astro and skip the client-side bulk entirely. STANDARD DISCLAIMER ANY TIME I COMMENT ON FRONT END DEV: your project may be different. A blog or a shopping site and have extremely different requirements to a full Gmail-style web app. There does not need to be a one size fits all answer.
- donatj 2mo agoI kind of agree but also > what about X feature To which I argue unequivocally YAGNI 95% of apps people actually develop are really just CRUD and could easily get by without JavaScript on the front end at all. They certainly don't justify the layers of complicated state maintenance React and similar systems entail.
- deleted 2mo ago[deleted]
- holoduke 2mo ago95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.
- jorisw 2mo agoSomething being 'made with AI' in no way translates to the framework used becoming irrelevant.
- pjmlp 2mo agoIt matters when you use an headless CMS from the MACH architecture enterprise culture, and they only support a specific SDK, which is mostly Next.js/React. - https://macharchitecture.com/ https://macharchitecture.com/ - https://www.sanity.io/studio https://www.sanity.io/studio (a possible example)
- codazoda 2mo agoEven this is more complex than many websites need to be. A few months ago I wrote about why I often create pages in pure html and css. https://joeldare.com/why-im-writing-pure-html-and-css-in-2025 https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
- inigyou 2mo agoRegarding small pages - there's a certain size threshold where the entire HTTP response is sent back in the first TCP window for most client OSes, which allows minimum round-trips.
- codazoda 2mo agoYes. You might be talking about the 14Kb problem. https://joeldare.com/the-14kb-problem https://joeldare.com/the-14kb-problem
- lelandfe 2mo agoThat post is so abbreviated as to be wrong in a few places (for instance, it's not that your "HTML" needs to be under 14kB, the packet, incl. headers needs to be). Fuller link: https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/ https://www.tunetheweb.com/blog/critical-resources-and-the-f... It's not worth chasing except for personal curiosity and some truly extreme cases.
- inigyou 2mo agoThe response needs to be. The response can span several packets, up to the maximum receive window chosen by the client's OS.
- jorisw 2mo agoWho knew the largest community in Web tech had it wrong all this time?
- gulugawa 2mo agoI read the blog post, and your framework looks great. I think React is overused, and I'm happy to see people support alternatives.
- fg137 2mo agoI wish that before someone writes yet another article on "You don't need React" they can do a Google search to look up all the 1000 articles already written with the same arguments and the discussions around that.
- imafish 2mo agoMaybe it’s not needed. But why not just use React anyway?
- imguienjoyer 2mo agohere is one that uses the fact that the raf loop will slow down when the tab is out of sync. makes state handling much easier. similar to dearimgui frontend example https://github.com/spirobel/counter/blob/master/frontend/counter-route.ts https://github.com/spirobel/counter/blob/master/frontend/cou... on the backend this obviously runs only once. the main issue with backend frameworks is, that the request and other context data has to be passed through the business logic + VIEWS. leads to tight coupling of all the components as it is downstream from the data structure + presentation this is resolved by resolving the html template strings at the end and allowing functions (that also produce html template snippets) to be passed into the template strings. this decouples views, business logic and data https://github.com/spirobel/mininext/blob/master/docs/architecture.md https://github.com/spirobel/mininext/blob/master/docs/archit... worked on this for the last few years. But it is still only a few hundred lines of code that you can understand in a few hours
- dbbk 2mo agoWhat is the point of this?
- killerstorm 2mo agoActually browsers already come with a minimal UI library. It's called HTML + CSS + JS. There's actually no need to make any wrappers - you describe what you want in HTML and make it look good with CSS. You only need to make UI using JS only for complex components. Case study: I tried porting an old strategy game from pygame to web using codex. Codex decided that it doesn't need any library and raw-dogged HTML. It was able to match look and feel of an old UI with a very simple, maintenable code. Doing that with just CSS sounds kinda tedious to me, but it can be done, and honestly it looks more maintenable than any UI library.
- gorgoyel 2mo agoThe problem is really folks trying to one-size-fits-all web projects. React basically exists to give a “good enough” GUI toolkit functionality in the browser. On the other hand, the web was built to publish content as in articles and information. Everything kind of sits somewhere on the continuum between static content and the interactive app experience. At the extreme it can be interactive “art” piece. It is important to consider digital media (as in art medium) best to convey an idea. And folks should start with HTML/CSS. Minimally, JS can be used for client-side validation. But that’s not necessary since the server needs to validate anyway.
- killerstorm 2mo agoI think main reason people choose React now is "nobody was fired for choosing React". (That used to be a saying about IBM as a vendor.) People can build their career around React. And it is better "job security" than pure HTML+JS: React apps need constant maintenance
- pjmlp 2mo agoAnother reason are SaaS and iPaaS SDKs having it as favoured stack, which kind of builds on your assertion.
- DANmode 2mo ago> React basically exists to give a “good enough” GUI toolkit functionality in the browser. and it’s sole usage for so many apps is one of the top-five reasons, following 2010s SPA frameworks, that people believe web apps inherently suck.
- progx 2mo agohttps://geajs.com/ https://geajs.com/ done.
- karol 2mo agoA 50-100 LOC library that provides 80% of what React does is very easy to create. I created one of those 14 years ago before React, to replace things like mustache and similar templating languages. That doesn't take away from your effort. It's a good idea for anyone to recreate their favourite lib to understand the principles.
- onesandofgrain 2mo agoReact is popular because it's pushed by Meta.
- crab_galaxy 2mo agoReact is popular because it mainstreamed components as a concept to modularize and reuse UI.
- onesandofgrain 2mo agoVue is better. It’s just pushed by Meta is why it’s more used.
- cyanregiment 2mo agoYou don’t need React until you do. And that’s fine. It’s easy to replatform later with LLMs. With vanilla you typically do class based components for organization (which can be quite clean in type=“module” with import/export) and you end up writing a complex View type class that does all the DOM manipulation. You gotta hide the framework somewhere or you’ll repeat yourself a lot Bonus points at scale you invent a templating solution. Maybe you use JSX
- Garlef 2mo ago> Bonus points at scale you invent a templating solution. Maybe you use JSX I think this is an underrated perspective in these discussions.
- actee 2mo ago> Bonus points at scale you invent a templating solution. Maybe you use JSX FYI this exists https://github.com/developit/htm https://github.com/developit/htm which couples well with preact browser only (no npm/node compilation)
- fidotron 2mo agoA major feature of React (like Java) is the ability to reduce the blast radius of errant colleagues through much stricter boundaries. In the AI/vibe coding world this becomes even more valuable, on top of the fact LLMs are well versed in React already and don't need to eat context to understand it. The problems are people then assume that because you're using React you must use next.js, vite etc. Then you're in trouble.
- css_apologist 2mo agohonestly if you go vanilla just go vanilla, don't imitate the vdom but worse use query selectors and manually do fine grained updates i don't think it works for everything, but a few years back i started doing it for side projects and never really missed any of the frameworks
- revetkn 2mo agoI agree - check out VanJS for minimal reactive library: https://vanjs.org https://vanjs.org
- atum47 2mo ago> You don't need React Yeah, I was thinking the same thing when I wrote TinyJS - https://github.com/victorqribeiro/TinyJS https://github.com/victorqribeiro/TinyJS
- davexunit 2mo agoPosts like this remind me how much JavaScript could benefit from something like Lisp's quasiquote. JSX is a terrible creation but templating in JS is pretty unpleasant without quotation operators. That said, I think Mithril's 'm' function did it the best of all libraries I have seen.
- specialist 2mo agoYup. The Correct Answer™ was and remains Scheme. Acknowledged by all parties involved (and us baffled bystanders). The negative consequences of JavaScript rival both \0x00 terminated strings and NULL. I've never forgiven Brendan Eich or Marc Andreessen. More positively, Marc did name the HTML's image tag IMG. Maybe by some cosmic measure, his contributions balance out.
- assimpleaspossi 2mo agoI ran a web dev company for decades. There are two web sites we created I would bet money you have visited so we weren't a small, one-off shop. We had never seen the need or desire to use React. We couldn't understand why anyone else would use it either. It was too big and too complicated versus just using the fundamental elements of programming for the web. So there.
- FeloniousHam 2mo agoCounterpoint: I'm currently employed building many apps for an enterprise you'll never visit. React+Typescript rewrite of our legacy "lean" Javascript has measurably improved the productivity of the team and the maintainability of code. I can't imagine going back to learning bespoke libraries written by (especially!) hotshot cowboy coders. React makes everybody on the team better, and literally no customer has ever complained about the extra 200ms load time.
- brazukadev 2mo ago> I can't imagine going back to learning bespoke libraries written by (especially!) hotshot cowboy coders you are giving too much credit to the React and NextJS maintainers. They are also "hotshot cowboy coders" whatever that means.
- FeloniousHam 2mo ago> They are also "hotshot cowboy coders" whatever that means. Popular public libraries are exactly the place for Hotshot Cowboy Coders. Boring bespoke software is not. A specific: generic machines taking in untyped data, executing unspecified functions at runtime. Thrilling to write, awful to maintain.
- torginus 2mo agoThe whole idea of SPAs is just unfortunate most of the time. If you look at the list of the most popular websites: https://en.wikipedia.org/wiki/List_of_most-visited_websites https://en.wikipedia.org/wiki/List_of_most-visited_websites Basically all of them can be decomposed to: - List of comments/recommendations/pictures (sometimes in a tree), virtualized and lazy loaded - A video - A comment box The irony is that this is super easy to represent in HTML semantically (HTML was literally made for this). The 'virtualized and lazy loaded' part should've been a HTML standard (or more generally, partial page updates, like when you submit a comment) and then we'd have basically very little reason to do Javascript at all. The irony of React is that what it does is make a mess of HTML, and allows you to ship your own semantic model in JSON/JS which will then get unpacked on the client into some display HTML. This is accentuated by the fact that React's support for virtualization is really quite poor, as it assumes that you have the 'state' in RAM, and you have to go out of way to use third party libs that can handle both partial state and partial display. Edit: Apparently I'm not the only one who thinks this, and Chrome/W3C seems to experimenting with something similar: https://developer.chrome.com/blog/declarative-partial-updates https://developer.chrome.com/blog/declarative-partial-update... But this should've been a W3C standard in like 1999.
- Scarblac 2mo agoAs usual this discussion is people talking past each other because some people work on web sites and others on web applications. React is great for applications, perhaps not as much for sites. I wouldn't know though.
- jakelazaroff 2mo agoI have no idea where this meme comes from. They're all just websites! Plenty of "web applications" make more sense as server-rendered Django or Phoenix apps than they do client-rendered React apps.
- satnhak 2mo agoReact isn't immediate mode. The dependency array, amongst other things determine what redraws and what doesn't. Yes, you can make React look like it's running in immediate mode, fully redrawing on every frame. But if you do that then you're probably in the wrong line of work. Maybe try management. This post is impressively bad. It's been AI generated and the AI doesn't even know what immediate mode is. Did you use Grok?
- avsn 2mo agoRe-creating minimal framework API is not that difficult. What is difficult is what frameworks are doing under the hood. To support ui=f(state) in the browser/dom you beed something more complex than pub/sub. The problems are 1. We need to calculate what part if UI depends on changed state 2.apply this to a dom efficiently. What author describes is a simple push-only reactivity which does not scale well because all updates are propagated to all subscribers. Libraries Solid and Vue (very simplified) are doing push-pull (push-pull-push) reactivity which involves traversing the dependencies for peace of the state, marking it as dirty and then recomputing the value of that peace of state. Another issue is DOM performance. When changing many parts of the state we want to apply changes to the DOM nodes in predictable and uniform fashion, avoid many writes/repaints, which usually involves some kind of scheduler. Another problem on top of that is measuring DOM before or after changes were applied (getBoundingClientRect can force synchronous layout/reflow, ResiseObserver is a more modern approach) and reacting to that. Having said that I’m all for using solutions appropriate for the problem, but what many of such tutorials miss is a better problem statement. Yes frameworks are heavy, yes we may not need them. But problems with doing complex DOM manipulations are still there.
- ChiperSoft 2mo agoThat useState hook doesn't work the way you think it does. It's going to reset state every time the hook is invoked on rerender. It also isn't triggering a render, which is the entire point of the hook.
- Jaygles 2mo agoIf your job is to write UI frameworks, by all means do that Otherwise, yes, you do need React (or something like it). Don't waste time re-solving the problems these frameworks were created to address. Spend your time creating value for your users. Building bespoke state management systems is not needed.
- Scarblac 2mo agoI feel the killer feature of doing everything in JS is components. I just want to import something from a library and use it. Web pages have their code split between HTML, CSS and JS. There is no common story that works for all three except for using JS.