Live data from Hacker News

You don't need React: creating a minimal UI library in Vanilla JavaScript

pedroth.github.io

91–100 of 117 posts

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#91
post #84

Earlier quoted context omitted.

> You will inevitably have some piece of functionality that's complex (say, a contact form) And this is why it pays to just learn React. It's never been easier. A contact form is not that complex. React won. The LLM can author it pretty well at this point, probably better (and cheaper) than at least 50% of FE devs. Treating a "contact form" as a potential fork in the road in 2026 is just sad.

> And this is why it pays to just learn React. It pays you, the developer, yes. It does not benefit the user. > A contact form is not that complex. Correct, my example was not a great one, just the first one that came to mind. Using a giant JS framework to do something as simple as a contact form should be seen as a failure of development culture. > Treating a "contact form" as a potential fork in the road in 2026 is…

SSG is solved for in React. The user is going to cope with a few extra KB of JavaScript just fine. Just like they cope when they watch Youtube or stream or w/e all day long. It's 2026. Data is cheap. The user really doesn't care until they hit your contact form that sucks because you tried to reinvent the wheel instead of just using React. Or when you need to branch out should your site ever do something actually interesting and this problem then gets even worse.

It's not hard anymore to get over the React learning curve. For a content heavy static site just use a good enough LLM and the right starter template and you'll never have to code, SSG and bundle size will just work, lighthouse will be all green. Your users do not care about the tech. The idea that React is the enemy of users sounds like a skill issue on your part. Good thing LLMs exist now, so you don't have to fret about the alleged perverse incentives. For a static site in 2026 a FE dev should be largely irrelevant. What could be more user friendly? Seems like big bad React has redemocratized the web right under your nose.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#92
post #84

Earlier quoted context omitted.

> And this is why it pays to just learn React. It pays you, the developer, yes. It does not benefit the user. > A contact form is not that complex. Correct, my example was not a great one, just the first one that came to mind. Using a giant JS framework to do something as simple as a contact form should be seen as a failure of development culture. > Treating a "contact form" as a potential fork in the road in 2026 is…

SSG is solved for in React. The user is going to cope with a few extra KB of JavaScript just fine. Just like they cope when they watch Youtube or stream or w/e all day long. It's 2026. Data is cheap. The user really doesn't care until they hit your contact form that sucks because you tried to reinvent the wheel instead of just using React. Or when you need to branch out should your site ever do something actually int…

Data is cheap and fast, CPU time still isn't. I've profiled numerous web sites on slow Android devices and they absolutely crawl when parsing JS and giant JSON blobs required to hydrate a page that's one big React app for no real reason.

> It's not hard anymore to get over the React learning curve.

> The idea that React is the enemy of users sounds like a skill issue on your part.

You're contradicting yourself here. Is React incredibly simply to learn or is optimizing it for speed a "skill issue"? I'm not talking about myself here, I'm talking about the state of the industry. The web is full of slow-as-shit web sites that are held back by JS and JSON parsing. You don't need to convince me they aren't because I've seen it with my own eyes time and time again. As an industry it's become far more important to fart out basic functionality and move on than take any kind of pride in your output. It's sad and I'm not going to apologise for caring.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#93
The 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

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-update...

But this should've been a W3C standard in like 1999.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#94
React 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?

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#95
post #92

Earlier quoted context omitted.

SSG is solved for in React. The user is going to cope with a few extra KB of JavaScript just fine. Just like they cope when they watch Youtube or stream or w/e all day long. It's 2026. Data is cheap. The user really doesn't care until they hit your contact form that sucks because you tried to reinvent the wheel instead of just using React. Or when you need to branch out should your site ever do something actually int…

Data is cheap and fast, CPU time still isn't. I've profiled numerous web sites on slow Android devices and they absolutely crawl when parsing JS and giant JSON blobs required to hydrate a page that's one big React app for no real reason. > It's not hard anymore to get over the React learning curve. > The idea that React is the enemy of users sounds like a skill issue on your part. You're contradicting yourself here.…

> You're contradicting yourself here.

>> Good thing LLMs exist now

It's not a contradiction. You were/are unskilled. But it doesn't matter anymore. Just wanted to help you understand this is not a contradiction. You sound like someone who made your mind up about "the state of the industry" a long time ago. While this replay of debates settled a decade ago has been a nice, I must wish you a good day now. I don't mean to be too harsh. Ultimately you can use whatever tool you like, obviously. If it works for you then it works for you. Often that is what matters most.

Thanks for the trip down memory lane.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#96
post #92

Earlier quoted context omitted.

Data is cheap and fast, CPU time still isn't. I've profiled numerous web sites on slow Android devices and they absolutely crawl when parsing JS and giant JSON blobs required to hydrate a page that's one big React app for no real reason. > It's not hard anymore to get over the React learning curve. > The idea that React is the enemy of users sounds like a skill issue on your part. You're contradicting yourself here.…

> You're contradicting yourself here. >> Good thing LLMs exist now It's not a contradiction. You were/are unskilled. But it doesn't matter anymore. Just wanted to help you understand this is not a contradiction. You sound like someone who made your mind up about "the state of the industry" a long time ago. While this replay of debates settled a decade ago has been a nice, I must wish you a good day now. I don't mean…

> You were/are unskilled.

You're being ridiculous and trying to bring personal insult into a conversation. I have, numerous times, asserted that I am discussing the state of the industry as a whole. I don't understand why you've repeatedly tried to misinterpret this, it's in extremely bad faith.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#97

I 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.

Counterpoint: 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.

Re: You don't need React: creating a minimal UI library in Vanilla JavaScript

#98
Re-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.

Post reply on HN