Hacker News Reader

React (and similar frameworks) make the code much more maintainable. You basically define your state and how that state should look like. You don't manually change your UI, it just re-renders when your state changes.

Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

I understand what React does. My point is that what it does is unnecessary for the vast majority of websites, and I stand by this.

> Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

False dichotomy, and a somewhat strange one, given jQuery and React aren't even remotely aimed at solving the same problem?

You're free to stick to a functional paradigm in JS without requiring the overhead of React (and all the cruft that tends to pile up around React - build systems, compile times, masses of dependencies, the inevitable CVEs for those dependencies, etc.)

But more importantly, I'd respectfully note that you're pre-supposing that UI state rightly lives in JavaScript, which is a point of view already limited by framework-centric assumptions.

It's not unnecessary if you don't want to write and maintain a backend. Single page apps are easily statically hosted on a CDN. They don't run, they can't go down. They can use a server less platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc.

I think it's time to question what "necessary" means for a product/service delivered online.

If it's unnecessary to use React et al, why is it necessary to complicate your application server with UI concerns so that it can build a big html UI string that is sent over the wire? And this only works for web browsers and no other clients?

Instead, it could be a simple API server that doesn't need to know about the UI at all.

There are obviously trade-offs in either direction, but to talk about necessary vs unnecessary doesn't seem to reflect that. There is nothing more necessary about one set of them over the other.

Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML.

A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server.

For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere).

But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.

> given jQuery and React aren't even remotely aimed at solving the same problem?

Both are used for rich UI experiences.

> Both are used for rich UI experiences.

So is Microsoft Frontpage, or Figma, or wgpu over wasm, or my friend John, the UI designer. Are these all directly comparable tools? Does John lose marks for not being downloadable over npm? (I can get him to compile TypeScript, but I can't seem to get him to compile into TypeScript)

Yep. A simple shopping site or tweet site doesn’t need to be an “app”. These devs are up their own asses thinking they need an app for their stupid (and simple) idea because it’s easy for them and they are “engineers” and we’re all stuck with delayed reactions, missed/double clicks, and broken middle clicks (X, Target) on every click now. Some app.

I think I despise throbers and spinners more than slow page loads at this point.

At least the throbbers and spinners are real. The true evil is "optimistic rendering".

"Our framework is so slow that we can't possibly manipulate data in a reasonable time frame, so we'll just lie to the user and say we did! What could possibly go wrong?"

Also in the running: giving absolutely no indication whatsoever to the user that anything succeeded or failed or is in progress at all (aka the Apple approach).

This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site

> This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site

You're describing websites simple enough that they're often used in beginner tutorials for web development.

Online shopping and text-based social networking absolutely and emphatically do not require a spaghetti soup of JavaScript frameworks. These were relatively simple websites to build for decades before web frameworks ever came along.

Compilers are a common project for university CS students. That doesn't mean GCC is overly complicated.

There's a huge difference between making a simple prototype of a concept and making an actual production app that fulfills a myriad of requirements that help you run a successful business.

Agreed, but not even a battle-hardened production compiler requires a particle accelerator or an optical fibre cable to the Webb space telescope. Similarly, a shopping site or text-based social media does not require a soup of web frameworks. It just doesn't - it's not a solution commensurate with the scale of the problem. Complexity is expense, and this doesn't remove complexity, it introduces it, reams of it, and totally needlessly.

No one has ever sat in front of a shopping site and thought - 'you know what this needs? A dozen extra mb of JavaScript that introduce no actual new customer-facing features, but that put a noticeable delay in every interaction, break the user's scrollbars and screen readers, and dramatically complicate maintenance.'

> soup of web frameworks

What a beautiful Straw man. What are these social media sites with more than one framework?

> ever sat in front of a shopping site and thought

But do you know what actually think? That they want to have products filtering, they want to have more products loaded with a simple button click, they want to add reviews and comments, they want to see product photos (or maybe even 3D models) - all fast without unnecessary page reloads. It's your problem you can't build it without breaking user experience.

All of the things you list can be achieved with minimal or no JavaScript, and many are completely trivial (filtering? adding reviews and comments?).

In general, if a prospective employee told me they needed React to implement website comments, I would not walk away with a very high opinion of that dev's abilities.

They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).

As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs.

> But without framework you in the end just create a custom one

Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web.

* Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.

But we're not talking about SPAs, we're talking about e-commerce websites.

> full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons)

I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS".

> Only if you've only ever written React-style webpages

Again, I'm not saying anything about using React specifically.

> convoluted web framework

Yet another straw man.

ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API.

I wrote an essay about this here:

https://htmx.org/essays/splitting-your-apis/

Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression:

https://github.com/1cg/html-json-size-comparison

in most real world systems i expect data store access to be the dominant latency issue

some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption):

https://htmx.org/essays/a-real-world-react-to-htmx-port/

but of course it depends on your use case.

I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.

As I said, using HTMX isn't "minimal to no JS". I agree that HTMX can be fast - but that's not what we're talking about. Even in the video of converting a React app to HTMX you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.

i think it's reasonable to call htmx "minimal JS" in that it is relatively small, dependency free, can be used without a typical javascript build chain (npm, etc.) and frees the end user of writing javascript in many cases

the speaker is referring to them not needing to write javascript for a specific feature, which is true, but they do use scripting for some aspects of the application, which is perfectly acceptable in hypermedia-driven applications:

https://htmx.org/essays/hypermedia-friendly-scripting/

regardless, the wins are obvious

> call htmx "minimal JS"

"Minimal", maybe, "small to no", nay :D

> "Minimal", maybe, "small to no", nay :D

Considering the original phrase was 'minimal or no', I am glad that you now agree.

> you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.

It's difficult to take this seriously. Just wait until you find out most of Python is written in C! Very dishonest!

On the contrary, you are still wrong. HTMX is simply using JavaScript and looking at it, it isn't minimal (it's still 15 kB min+gzip).

> It's difficult to take this seriously. Just wait until you find out most of Python is written in C! Very dishonest!

Now I understand, you're just obtuse.

> Now I understand, you're just obtuse.

This seems like an exceedingly mean-spirited and unconstructive type of response to have to people who have been giving up their time trying to explain a different point of view to you. I would also gently point out the HN guidelines at this point.

I note you haven't responded to my more substantive reply here,[0] so I am unsure you saw it. I would encourage you to read it with less of a zero-sum 'I-win-you-lose' mentality. I won't be engaging with you further though.

[0] https://news.ycombinator.com/item?id=42386090

> Full-page reloads are, ceteris paribus, always slower than some JSON payload

That must explain why websites are so fast and responsive these days! /s

If you're wedded to the idea of dynamic reloads, which - imho - you ought not be, HTMX or Turbo are ways of achieving that without needing to write any JS. HTMX is designed to complete HTML as a hypermedia language, which it does using JS, but it itself does not require any additional JS to use. I'm sure the authors would dearly love it if HTMX's ideas were taken directly into HTML5, and they could scrap the JS library altogether. Its use of JS is an implementation detail borne of necessity.

If you're coming from SPAs and can't imagine websites working any other way, I highly recommend reading something like Hypermedia Systems (https://hypermedia.systems/). Come with an open mind, let it be your gateway drug. HTMX builds on a very old tradition of hypermedia, all the way back to Computer Lib/Dream Machines, through systems like HyperCard, to the actual, original definition of RESTfulness (that modern Ajax SPAs generally do not meet). It draws deep from the hacker ethos (you know, that thing that this website is about!).

Personally, I don't even think HTMX is all that necessary. What I feel like you're missing is that the overwhelming majority of websites are technically very simple, and their value to their users is in their contents, not in their stack. Did you notice the full page reload when you hit Reply on your comment, here on HN? Were you terribly put out by it? Would HN be an improved website were it full of spinners and Ajax? I would respectfully suggest it would not. It delivers amazing value running as a Lisp program on a machine under someone's desk.

> This seems like an exceedingly mean-spirited and unconstructive

It's not, it's precise.

Sorry you wasted time writing all this, because I don't care about hypermedia systems - it's not that it's bad technology, I simply don't want to write yet another awful templating language. But that's just an aside, because once again you're talking about something else. But okay, let's switch to debating HTMX. My point then still stands: you simply need JavaScript. Now instead of this useless arguing, go find/build some big e-commerce website with this hypermedia stuff (or truly with no JavaScript) and then we'll see.

https://www.amazon.com uses hypermedia for most navigation

they are pretty big

Wow, most navigation - what a feat! /s

ikr!

My bank website uses very old js and no react. Yet middle click doesn’t work (as well as back button). These problems have nothing to do with framework/library.

It’s what’s encouraged. The react way for links that’s easiest and used in tutorials is one that breaks middle click.

I was talking to my classmate from x10, and he said to have shipped one page app with WP backend, React frontend in Azure VM :|

Incurred a bill of $800, and reached out to me. Gobsmacked!!

> The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess.

I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.

the vast majority static "sites" don't need to exist at all, how about that?

It's the apps with unique requirements that need to be coded, not some pages that present some info in some way that's slightly different, stylistically, and not standard at all.