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

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

331–340 of 756 posts

Re: If not React, then what?

#331

Post by em-bee »

harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

i am skeptical. there is way more than nice looking code to make a framework popular. in my opinion if nice looking code were to matter then aurelia would be a lot more popular: https://github.com/stickfigure/blog/wiki/Opinionated-Compari...

Re: If not React, then what?

#332

Post by hasanhaja »

QuiDortDine wrote: post #7

WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tel…

> though once you master it, it can be pretty efficient.

Would it be fair to say in which case that React shouldn't be a tool teams reach for unless they have people who have mastery of it or can pay for it?

> user won't be able to tell the difference.

I think the user can:

https://infrequently.org/2024/08/object-lesson/

Re: If not React, then what?

#333

Post by jakubmazanec »

throwaway284534 wrote: post #306
jakubmazanec wrote: post #271

Earlier quoted context omitted.

I generally agree (that the React isn't the main culprit), but what does Tailwind have to do with templating? It's still just CSS classes, but with specific names. Also, I bet you could have strongly typed class name strings using TypeScript's template literal type somehow.

The gist is something like a new cohort of front-end developers and some begrudging back-end folks who never actually learned how anything worked are now trying to inscribe their influence as the new smart people with tools like Tailwind and HTMX. Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation co…

> Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system.

I think you maybe don't understand what Tailwind actually does. The only abstraction is its "language" that is used to generate the list of class names you can then use to style elements, but that's not really an abstraction, because in the end it's not that different from using something like BEM and then having to remember project-specific classes. But with Tailwind, it's not specific to a single project. And you always have to understand CSS and how it works anyway.

Re: If not React, then what?

#334

Post by baobabKoodaa »

quantadev wrote: post #320
baobabKoodaa wrote: post #308

Earlier quoted context omitted.

I don't share your opinion but I'm too tired to go into another JS vs TS debate

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.

"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"

Re: If not React, then what?

#335

Post by emmanueloga_ »

floydnoel wrote: post #142
emmanueloga_ wrote: post #68

Earlier quoted context omitted.

... also TFA conflates web application architecture with frontend frameworks, creating a false dichotomy. For instance, I’m building a site that serves static HTML but still benefits greatly from Preact for the dynamic parts. The critique seems focused on SPA architectures heavily based on React, as seen in frameworks like Next.js and Remix. To be clear, I also lean away from that style of web application architectur…

I thought Next.js and Remix were SSR-based frameworks, both created as alternatives to building a SPA. After the initial "SPA fever" died down, these frameworks cropped up to address the shortcomings of SPAs such as a lack of SEO-compatibility.

Next.js and similar tools redefine server-side rendering (SSR) to mean generating HTML on the server using the same code that runs on the frontend, requiring server-side JavaScript and what they call "hydrating" on the client. Next.js and friends are very much SPA frameworks, they just try to address the shortcomings of SPA architecture and in the process introduce a lot of complicated layers.

Since the term SSR has been... "repurposed" now, what I was talking about a simpler CGI-style approach—no JavaScript, no async complications like Suspense. Rendering React components server-side often requires special tricks, especially when components interact with DOM APIs or make HTTP calls.

As an example, Templ has a detailed guide on using React in a traditional architecture without server-side rendering React components [1].

---

1: https://templ.guide/syntax-and-usage/using-react-with-templ/

Re: If not React, then what?

#336

Post by tmnvix »

flimsypremise wrote: post #208
deergomoo wrote: post #147

Earlier quoted context omitted.

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization…

> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.

I sincerely disagree. I am not about to add node to a project that gets by fine with Django + HTMX.

I'm tempted to say that adding hundreds of perishable npm packages to a project is a better heuristic for 'malpractice'.

Re: If not React, then what?

#337

Post by gherkinnn »

claytongulick wrote: post #151
pier25 wrote: post #102

Earlier quoted context omitted.

It's not recent. We've had memes for years about React devs using divs with click events instead of using links.

What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically? It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind. Or maybe I'm hooked into a router and I need to pass some…

> Non deep-linked sub-nav (tabs, etc...)

  href="?tab=tabName"
> need to pass some additional state

  href="?state=stateId"
> or control a transition direction

  href={condition ? "/direction/a" : "/direction/b"}
> maybe I want a navigation to happen after some async action completes

Smells like a mistake. Or a button.

> Also, not all clicks are navigation actions.

There are other interactive elements like buttons.

Re: If not React, then what?

#338

Post by incrudible »

"design for user needs, not organisational convenience"

If I've ever come close to something like a natural law in software development, it's Conway's law. Therefore, this strikes me as saying: Design your airplane according to what the pilot needs, not aerodynamics or gravity.

Re: If not React, then what?

#339

Post by LtWorf »

johnfn wrote: post #315
LtWorf wrote: post #273

Earlier quoted context omitted.

> But front end performance issues are almost never the most pressing issue Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D

I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.

Yes because loading 500 different css and js files is not a problem for performance.

Re: If not React, then what?

#340

Post by GMoromisato »

My answer to this is https://gridwhale.com.

GridWhale runs your code entirely on the server and then remotes the UI to the browser via a platform layer.

The advantage is that you can program a web app as if it were an old-style GUI app on a PC: your program has full and direct control over the UI. For example, imagine you need to disable a button due to permissions. In GridWhale, you just check the permissions and set .disabled = true on the control. This automatically propagates the setting to the UI. And because the .disabled property is on the server, it stays disabled even if you hack the client.

In contrast, with React or any framework-based UI, you need to write code in two places: on the server (at the API level) and on the client to show the proper UI. And if you're not careful, these two can get out of sync.

Of course, GridWhale is just a different trade-off. It works great for traditional business apps, but would not be appropriate for low-latency video games (at least not yet).

Post reply on HN