Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pedroth.github.io

Post reply on HN
Print view View original

51–60 of 122 posts

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

#51

Post by bofadeez »

afavour wrote: post #40
bofadeez wrote: post #25

Earlier quoted context omitted.

Tomato tomato. English is my favorite new programming language.

You'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.

Have 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

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

#52

Post by account42 »

wild_egg wrote: post #31
pedro_movai wrote: post #16

Earlier quoted context omitted.

I think the author is referring to immediate mode because of UI=f(state)

I 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

With that argument, every UI is retained mode because everything gets saved in the GPU's scan out buffer.

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

#53

Post by draw_down »

jakelazaroff wrote: post #9

> 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…

[dead]

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

#55

Post by karol »

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

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

#56

Post by [deleted] »

donatj wrote: post #41
afavour wrote: post #20

I 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 fo…

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

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

#57

Post by gorgoyel »

killerstorm wrote: post #48

Actually 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…

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

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

#59

Post by holoduke »

donatj wrote: post #41
afavour wrote: post #20

I 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 fo…

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

95% of the frontend apps can easily be made with AI. Doesn't matter in which framework.

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

#60

Post by lelandfe »

codazoda wrote: post #35
inigyou wrote: post #32

Earlier quoted context omitted.

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

Yes. You might be talking about the 14Kb problem. https://joeldare.com/the-14kb-problem

That 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-f...

It's not worth chasing except for personal curiosity and some truly extreme cases.

Post reply on HN