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

601–610 of 756 posts

Re: If not React, then what?

#601

Post by prmph »

jillesvangurp wrote: post #578
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 wouldn't call it a win. Web UIs plateaued about 10-15 years ago. It was never the state of the art in what is possible with user interfaces; it always was a huge compromise between having something that feels vaguely responsive shoehorned into a platform (browsers) not really designed for being a platform for implementing UIs. Mediocrity is the norm on the web. And react is just the gold standard for shoveling that…

I agree on all your points. The basic web technologies are still primitive, and therein lies the problem.

All these arguments about frameworks and libraries would be moot if the web technologies were properly designed, so i believe that is where we should focus our energies.

Why is it that after several decades HTML, CSS and JS are still so primitive?

Re: If not React, then what?

#603

Post by hollowturtle »

crabmusket wrote: post #371
lihaoyi wrote: post #243

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…

I never want to go back to a non-declarative rendering framework. Does anyone remember a blog post from maybe 2016-ish which described the process of "building your own" react-like rendering loop? I remember it being a fantastic explanation of what the virtual dom is and does, and why the "UI is a function of state" paradigm is great. I remember it having a live example to the right side, with prose and code on the l…

To be fair it predates 2016 when the term “immediate mode ui” was “invented”. uis as a function of state were and still are the norm on game development. React introduced this concept on top of “retained mode ui” which is the dom. Never want to go back too despite people spreading so much hate which is not in the library itself I think but on the ecosystem. Maybe react become synonymous of too many companion libraries/bloated frameworks?

Re: If not React, then what?

#604

Post by KronisLV »

afavour wrote: post #228
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

I largely agree with your points, but wish it’d be easier to have server side rendering that’s not as tightly coupled to the rest of the system.

What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite.

However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above.

Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult.

I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end.

Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.

Re: If not React, then what?

#605

Post by WA »

crabmusket wrote: post #511
retropragma wrote: post #473

Earlier quoted context omitted.

This? https://pomb.us/build-your-own-react/

Sadly not. I did find this article too while searching for what I remember. It is a close match in so many ways, but also not quite. I remember the article very much taking the approach that you've never heard of React before, and walking through a series of problems and discoveries like "oh, what if we just render the state to the DOM every frame? let's see how that works". Almost like a "you could have invented Rea…

Not a live preview and not a button-counter demo at the end, but the overall structure and the whole O(n) vs O(n^2) argumentation was in this blog post from a now defunct domain. Maybe this is what you were looking for:

https://web.archive.org/web/20150414080539/http://hackflow.c...

Re: If not React, then what?

#606

Post by sabbaticaldev »

jakubmazanec wrote: post #265

Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language. Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.

COBOL developers also get stuff done

Re: If not React, then what?

#607

Post by 0xblinq »

7sigma wrote: post #526
jwblackwell wrote: post #524

Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton) A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things l…

I've been using Inertia.js with laravel and Vue and its been great, no need to write an API layer. You get the simplicity of writing server rendered with the interactivity of an SPA

Same. Using it at work (although with React/Rails) and it works great. Best of both worlds with minimal drawbacks.

Re: If not React, then what?

#608

Post by palata »

drunkenmagician wrote: post #428
palata wrote: post #223

Earlier quoted context omitted.

> Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size. They don't say "modern software is slow", they say "my computer is slow, I need to buy a new one" and they do. Let's be honest: for what the vast majority of people do on their computer, there is absolutely no need for a Macbook M3. The only reason is…

> the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?

A few seconds. It's a news webpage, that has mostly text, links and images.

And of course now it loads a ton of useless widgets, probably much bigger images (sometimes they load a video to serve the same purpose, just because they can), and a whole lot more code. And that's with uBlock origins; if I disable it it's a lot worse.

Objectively, in 25 years they have been paying people to make it an order of magnitude worse. And it's not only them: the vast majority of websites have followed that trend.

Re: If not React, then what?

#609

Post by [deleted] »

boredtofears wrote: post #366
crvst wrote: post #170

Earlier quoted context omitted.

That’s true. Just to note, I never claimed otherwise. See, useEffect is an evil remark. This is more based on my experience working with an average React codebase. As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?” I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encourag…

How do you fetch and persist server side data without useEffect? (Assuming vanilla react)

[deleted]

Re: If not React, then what?

#610

Post by qudat »

proto-n wrote: post #561
qudat wrote: post #227

Earlier quoted context omitted.

That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.

It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.

> It seems you only want to call MVC frameworks frameworks?

No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework.

> for which the definition is usually the calls into you/you call into it thing

Again there's nuance here:

    import { useEffect, useState } from "react";
    import { createRoot } from 'react-dom/client';
    document.body.innerHTML = '';
    const root = createRoot(document.getElementById('app'));
    root.render();

    function App() {
      const counter = useState(0);
      useEffect(() => { console.log('effect') }, []);
      return hello world: {counter}
    }
I'm "calling into" react (3) times here, while react is calling "into me" (1) time. Are we saying any external source code that accepts a function as a parameter is considered a framework?

All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?

Post reply on HN