61–70 of 117 posts
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
Earlier quoted context omitted.
Tell me, mister Bofadeez Nutz, why does every non-AI post have to have these dumb "hurr durr just use AI" comments?
You sound like me before I tried Fable.
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…
Same, at least for smaller projects where I want some kinds of interactivity, but also a good static rendered page first and just the ease of writing, Astro+preact has been very nice.
If you need React, then go ahead and use React, but I'd encourage people to try a simple s/react/preact/g on their websites. (Okay, not quite as simple as that, but even if you don't like vibe coding, this is something an LLM can be trusted with.)
[0] https://endtimes.dev/why-your-website-should-be-under-14kb-i...
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 importa…
And it is better "job security" than pure HTML+JS: React apps need constant maintenance
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.
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.
Nearly every app has some version of CRUD, but you're conflating the persistence model with the interaction layer. Just because an app is CRUD doesn't mean it doesn't require complex, client-side interactions.
I'm building an EMR and there is a large portion that is CRUD, but that doesn't mean I don't rely on enormous forms or don't need client-side validation.
And not only, but "you could get by" is true of a lot of things. I could get by with full-page refreshes every time a form is saved or a chart is pulled, but that doesn't mean it's the best option or that the users won't notice it.
This argument has big "I seldom build web apps but have a lot of opinions on them" energy. Like, the idea that I, myself, have seen enough of the different projects and use cases for the web that I can unequivocally state something like "95% of apps don't need a front-end framework" reeks of ego. You just flat out haven't. The field is enormous.
If 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…
The blog post page, which appears to use the author's library only loaded 58.6 kB of JavaScript, which is quite low.
Earlier quoted context omitted.
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.
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
React is popular because it's pushed by Meta.