[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: didreact.png (104 KB, 1153x516)
104 KB
104 KB PNG
Why don't people just throw in the towel and admit React won and just contribute to React instead?
>>
>>107068755
Well, it certainly won at making websites that send you 20MB of JS to make you rerender stuff all the time.
>>
Why are you making Javascript write a <h1> tag when you can write it in plain HTML?
>>
>>107068867
Because you want to do more than that eventually
>>
>>107068755
React has a lot of baggage. It's hella slow, compared to *all* of its competitors. That said, I use it because I understand it well and it's ubiquitous.
>>
i'll keep using elixir
>>
>>107068985
How does Elixir have any relevance to this thread hype monkey.
>>
>>107068755
worthless for most static sites that aren't complicated. normal HTML is fine
>>
>>107068963
Do you find it actually saves you time with components
>>
>>107068859
>randomly invalidates cache and redownloads the whole thing
>>
>>107068997
No. React is extremely niggling, shit will just not work the way you expect it to.
>>
>>107068997
I literally architect my entire app as components.
>>
>>107068997
>>107069064
It isn't about "saving time," btw, it's about architecture. There's OOP, there's functional programming, and there's component-based architecture, which I use.
>>
>>107069068
Well the guy who made it at facebook did it bc of all the repetition in making elements, has it changed in purpose?
>>
>>107069011
>update leftpad from version 5.3.23 to version 5.3.24 and invalidate the entire vendor bundle
>>
>>107069080
I would attribute React's initial success to the Virtual DOM, and it's present momentum to state.
>>
>>107069064
>webshitters using fancy words like "architect"
>>
>>107069184
My app makes the company hundreds of millions of dollars.
>>
>>107069194
And it could also do so in PHP and jQuery.
>>
>>107069239
It would be a buggy mess.
>>
>>107068755
I’m too busy as the CEO of HTMX to contribute to React
>>
>>107068755
>...and just contribute to React instead?
Most people, most companies, don't contribute to anything, so this is an irrelevant factor.

I have found that Vue and Svelte are better for engineering velocity when building a medium-sized component-based application (where I think 80% of successful companies' services are "medium-sized"). In past years, the reason I might advise a company to choose React is when they need to hire a large team fast (which I would advise against as well, but sometimes that's what they think they need to do). These days, the applicants come flooding in, and are more desperate to get a job, so choosing a less-popular technology isn't the downside it used to be.

Notice that "contribute to" never factors into anything.

Also, if the application isn't a super-interactive "web app", and they think they can get away with HTMX, LiveView, Intertia, or Hotwire, then that is a great call as well.
>>
Big companies don't use React. That's telling.
>>
>>107069315
Facebook isn't a big company?
>>
>>107068755
When Github started using React, it got worse.
>>
>>107068755
Why dont we just make alternative frontend. All browsers need to do is ad extra rendering option
>>
File: standards.png (24 KB, 500x283)
24 KB
24 KB PNG
>>107069716
>>
>>107069278
react was designed to be fool proof so dei hires can use it
>>
>>107069309
> engineering velocity
Hello mba wannabe and self proclaimed scrum master
>>
>>107068755
Yes react won at ruining the internet. It works as a great filter for me. Every time a react "developer" says anything I know to disregard their opinion with prejudice.
>>
File: didreact.png (142 KB, 1153x516)
142 KB
142 KB PNG
>>107068755
Anon...
>>
File: 1757146887679712.jpg (9 KB, 255x300)
9 KB
9 KB JPG
>mfw i see react code
Usually it's total bullshit. No idea of logic vs ui, all logic is almost always coded into the components. No isolation, no idea of anything, no structure.
>>
>>107070309
The ideal is small, atomic components, everything collocated in the same file

Not a React developer btw
>>
>>107068755
Shitload of tutorials, blog posts, documentation and projects on Github create a very goos training set for LLMs
>>
>>107068755
Vanilla HTML\CSS\JS. Anything else is baggage.
>>
>>107070448
don't talk about things you don't know
https://react.dev/learn/sharing-state-between-components
>Sometimes, you want the state of two components to always change together. To do it, remove state from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as lifting state up, and it’s one of the most common things you will do writing React code.
>>
>>107068859
skill issue
>>
>>107068755
There are no good js frameworks. So none of them could have won.
Solid and Svelte comes close but have a stupid branch syntax
How hard can it be to let people use branches in JSX?
React is the worst offender. more than a decade and still has to rely on ternary bullshit, still affected by rerender memes absent from other frameworks and the compiler cope won't change that
WASM DOM support can't come soon enough
>>
>>107070490
no worries, we'll just add reactivity to vanilla JS:
https://github.com/tc39/proposal-signals
let counter = 0;
const setCounter = (value) => {
counter = value;
render();
};

const isEven = () => (counter & 1) == 0;
const parity = () => isEven() ? "even" : "odd";
const render = () => element.innerText = parity();

// Simulate external updates to counter...
setInterval(() => setCounter(counter + 1), 1000);

>This has a number of problems...
>
>The counter setup is noisy and boilerplate-heavy.
>The counter state is tightly coupled to the rendering system.
>If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation of the parity and unnecessary rendering.
>What if another part of our UI just wants to render when the counter updates?
>What if another part of our UI is dependent on isEven or parity alone?
>Even in this relatively simple scenario, a number of issues arise quickly. We could try to work around these by introducing pub/sub for the counter. This would allow additional consumers of the counter could subscribe to add their own reactions to state changes.
>
>However, we're still stuck with the following problems:
>
>The render function, which is only dependent on parity must instead "know" that it actually needs to subscribe to counter.
>It isn't possible to update UI based on either isEven or parity alone, without directly interacting with counter.
>We've increased our boilerplate. Any time you are using something, it's not just a matter of calling a function or reading a variable, but instead subscribing and doing updates there. Managing unsubscription is also especially complicated.
>>
>>107069315
yea except microsoft using it for office 365, teams, w11, etc
>>
>>107069728
It would just be 2 standards here, which is okay. Especially if you stop adding features on the previous one.
>>
>>107068755
>react won
Only for a while
Eventually westoids will be forced to learn how to actually use vanilla JS and DOM APIs without crutches
>>
>>107068755
maybe skill issue but I find Single-Page Application to be slow and buggy, I had to reload the page to fix the issue
and every pages that you clicked from a links all get remembered in that one instance of a webpage, which makes it bloat beyond belief
>>
>>107069080
>repetition in making elements

Working on a site right now and I finished writing the API.
For reusable components I just used string templates.
Then created a system of tags like ${block} ${endblock} and that was it. Can create any component like that.
>>
>>107070307
It's always them
>>
>>107070774
I mean I wrote the whole thing using nothing but plain HTML and vanilla JS.
And it's possible to create reusable components like that. With string templates.
>>
>>107070694
I don’t see the problem, your dumb components just receive state from and pass along state changes to your smart components

Literally every component based front end framework uses these concepts
>>
>>107070307
holy shit electrons were jews
>>
File: .png (84 KB, 1170x348)
84 KB
84 KB PNG
>>107070806
>Literally every component based front end framework uses these concepts
??
strict unidirectional dataflow is a react thing. other frameworks like vue and svelte don't care.
>>
>>107070309
sveltekit doesnt have this issue
>>
>>107070798
how do you manage state?
>>
>>107070913
svelte literally died due to this issue:
https://svelte.dev/blog/runes
<script lang="ts">
let count = $state(0);

function increment() {
count += 1;
}
</script>

<button on:click={increment}>
clicks: {count}
</button>

>At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn’t it better if let count is reactive by default?
>Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren’t can get tricky. And the heuristic only works for let declarations at the top level of a component, which can cause confusion. Having code behave one way inside .svelte files and another inside .js can make it hard to refactor code, for example if you need to turn something into a store so that you can use it in multiple places.
so now there's a new framework with runes that misuses the svelte name while sharing nothing with the original svelte.
>>
>>107070694
That's the wrong way to share state and it ends up shooting you in the foot, because it leads inevitably to drop drilling and forcing re-renders of entire component subtrees.

If you have shared state, you either move it into a store, or you create a get/set-able signal at a higher layer, pass that down to all the child components that need it, and have those components continue to manage the when/how of getting/setting the state encapsulated in the signal.
The gain of using a signal is that the signal itself is stable - the state of the parent component thus won't have to change and you avoid it needing a re-render. Only the (grand)child components that need to get or set the state value contained in the signal will need to re-render.

Also - you can consider carrying all state in signals at which point all components can be wrapped in memo and whenever a parent component re-renders it doesn't result in the performance pitfall of having to re-render all child components. They'll just re-use their previous output since the input props never changed.


If you want to write React at scale, AND have it perform well, then step 1 is forgetting everything about state propagation that React is built upon and advises you, and instead shoehorning in signals.
>>
>>107070918
The site itself is too simple for having much state management.

But the library I wrote generally uses a lot of event handlers, promises and even setTimeout/setInterval routines to make sure it catches any DOM updates and reacts to them accordingly. It's kinda retarded and old-skool but it works and it's plain vanilla JS.
And I don't need any dependencies or particular type of notation to handle this. It's all native.
>>
>>107070739
>cites the vanilla JS example instead of the actual signals proposal
anon ...
>>
>>107070969
vanilla JS has proxies now. easiest way to do reactivity is:
        function reactive(obj) {
const listeners = new Set();

const proxy = new Proxy(obj, {
get(target, property, receiver) {
if (typeof target[property] === 'object' && target[property] !== null) {
return reactive(target[property]);
}
return Reflect.get(target, property, receiver);
},
set(target, property, value, receiver) {
const result = Reflect.set(target, property, value, receiver);
listeners.forEach(fn => fn());
return result;
}
});

proxy.subscribe = function (fn) {
listeners.add(fn);
};

proxy.unsubscribe = function (fn) {
listeners.delete(fn);
};

return proxy;
}
>>
>>107068755
>Did React Win?
the ideas and principles it brought with it sure. as with everything that gets bit as some point it becomes legacy software and people need new shiny toys to play with
>just contribute to React instead
why would anyone contribute to it when it got basically taken over by vercel now?
>>
File: .png (221 KB, 1170x902)
221 KB
221 KB PNG
>>107071082
>the ideas and principles it brought with it sure.
which ideas and principles would that be?
>>
I think React can be very good but it's opinionated and not a 1 size fits all framework.
The fact that it re-renders all subcomponents makes it unsuitable where you have a large master states.
This is why there's redux, saga and whatever they're using now.
But even still React has changed over the years, it's not a stable API, there's always some new way to do React.
I think the components have led to staying power as creating a subcomponent library of your brand makes it harder to move away from your JSX work that doesn't work anywhere else.
>>
>>107071024
Right. Forgot about proxies, last time I studied them I didn't find a use for them with DOM manipulation.
But I guess I wasn't paying attention, as they can detect certain object operations.
>>
>>107071093
i'm honestly too lazy right now to look up what features libraries like knockout or embers already had and which react itself came up with
>>
>>107068755
The worst technology always wins.
Literally all of its competition is better. Vue, Svelte, Solid, even fucking Lit-HTML.
Why do developers always choose the most bloated shit with the worst performance.
>>
File: .jpg (186 KB, 1976x1232)
186 KB
186 KB JPG
>>107071138
that would be vdom
>>
File: .png (107 KB, 960x720)
107 KB
107 KB PNG
>>107071148
none of those were react's contemporary competitors. react killed them all. frp won.
>>
>>107071024
Isn't this just syntactic sugar?

You can do the same thing with classic getters and setters and still detect when an object property was changed:

            let obj = {};

Object.defineProperty(obj, 'setNewIndex', {
set(o) {
this.newIndex = o;
console.log('index changed');
},
get() { this.newIndex },
enumerable: true,
configurable: true
});

So vanilla JS can already do proxies without having to write fancy constructors and such.
If you have to go through the proxy itself what's the point. Might as well build it right into the object.
>>
fuck react, I use web components
https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
>>
>>107071407
how do you manage state?
>>
>>107071416
getter and setter
>>
>>107068963
>It's hella slow, compared to *all* of its competitors.
Got any benchmarks?
>>
>>107068859
The whole idea of reconciliation algorithm, which is the back bone of React, is to make it not defender stuff all the time.
If you have complex webapp and want to only want to update things that need it, you are going to come up with something like this.
>>
>>107071466
>defender
*rerender
>>
File: .jpg (96 KB, 1320x1114)
96 KB
96 KB JPG
>>107071437
old react takes double the time than modern signal-based frameworks like solid.
however new compiled react will take half the time of modern signal-based frameworks.
>>
>>107071474
>old react
>random photo of a presentation
Got any real benchmarks?
>>
File: .png (92 KB, 1164x364)
92 KB
92 KB PNG
>>107071480
questioning react core devs isn't a good look. solid is already in the acceptance phase.
>>
>>107071466
Yet that's actually not what React does. Whenever a component updates state, it re-renders itself and any grandchildren. React also actively advocates that to solve the problem of communicating sibling components, they should share state by lifting it up from each sibling to a common parent. Which thus means *everything* (not just those siblings) below that component re-renders.

There's actually a lot of wasted CPU cycles there, to reconstruct the same virtual DOM, which the reconcilliation algorithm will then end up discarding.

This used to (somewhat) make sense back when we were still dealing with Internet Explorer and early Firefox when real DOM manipulation was really REALLY fucking slow, and bottlenecked everything. This meant that React's core lifecycle loop was actually not a dominating factor.

Things changed though. The real DOM is quite fast nowadays and thus the overhead of React becomes a very clear thorn in the side.
>>
>>107068755
Because midwits are too retarded to understand React. I have meet so many webdevs who are utterly confused by React functional approach and hooks and spread all sorts of just wrong and unfounded ideas about React. Like even here we had some retarded poster who kept claiming how React is so slow that they need to add placeholders before it renders anything and if you see a placeholder somewhere on a website it means it's React and it's clogging your CPU. And he would repeat that crackpot theory on multiple threads arguing over same shit.
>>
>>107071474
>new compiled react will take [..]
Any performance aspects of React Compiler have to be taken with a few spoonfuls of salt.
It is still incredibly buggy, and likely getting all of those fixed so it behaves proper on all edge cases is going to make it tank a substantial portion of its current performance gains.

Also - it does nothing, absolutely zilch, to resolve the full-subtree-rerender problem which is the thing that actually cripples React performance and make it both a memory and CPU hog in larger apps.
>>
>>107071499
>Whenever a component updates state, it re-renders itself
Nope. Read about reconciliation algorithm and virtual dom
>any grandchildren.
>Which thus means *everything* (not just those siblings) below that component re-renders.
Nope. Read about memoization.
>This used to (somewhat) make sense back when we were still dealing with Internet Explorer and early Firefox when real DOM manipulation was really REALLY fucking slow, and bottlenecked everything.
>Things changed though. The real DOM is quite fast nowadays and thus the overhead of React becomes a very clear thorn in the side.
And now you are advocating for rerendering everything?

>the overhead of React becomes a very clear thorn in the side.
Got any benchmarks?
>>
>>107071474
react compiler doesn't inherently speed anything up, all it does is automatic memoization, meaning you don't need to use memo(), useMemo, useCallback
other frameworks don't have this issue because they have fine grained reactivity which doesn't inherit react's over-rendering issue
>>
File: hotwire.png (18 KB, 900x569)
18 KB
18 KB PNG
Frontend JS frameworks are a dead meme
>>
File: .png (232 KB, 1168x754)
232 KB
232 KB PNG
>>107071840
hotwire is a shitty clone of google's wiz. google is killing wiz in favor of angular. so we know who's the real dead meme.
>>
>>107071901
Angular is still used? Whoa
I thought google stopped developing it
>>
>>107071407
just use Lit
>>
>>107071550
>Nope. Read about reconciliation algorithm and virtual dom
Yes. 'Render' in React is a loaded term. It means to re-execute the render body and have the JSX reproduce a new segment of VDOM.

> Nope. Read about memoization.
Only works if you judiciously apply memo() to all components. (Which React itself recommends against, btw.)

>And now you are advocating for rerendering everything?
No. I don't know how you got that from the prior post, but that conclusion is non-sequitur.
>>
>>107071675
Bingo. This guy gets it.
>>
>>107071499
Actually, come to think of it. React is poorly named as well.

React isn't truly reactive in any proper sense of the terminology of reactive programming.
React is essentially, a very basic, crappy, and ill-understood partial output cache.
>>
File: .png (204 KB, 1178x1036)
204 KB
204 KB PNG
>>107071407
web components are the worst js framework there is. like stuck 15 years ago because committees can't decide on anything.
https://dev.to/richharris/why-i-don-t-use-web-components-2cia
https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh
>>
>>107068755
Yeah it did.

>>107068963
Next.js fixes every problem with React.

There's literally no reason to use plain React over Next.js.
>>
>>107072264
>just give everything to vercel
>>
>>107071901
Google is constantly killing tech products which is why I stopped using anything they create
>>
>>107072276
Just self host, retard. Nobody is forcing you to use Vercel for anything.
>>
>>107072264
>There's literally no reason to use plain React over Next.js.
Next.js is built by Vercel who are doing it completely self-serving to promote deployment on their own cloud services. They're basically waiting to snap the vendor-lockin trap shut.
>>
>>107072288
>Just self host, retard.
youre the retard, theres no reason for nextjs to exist besides vercel making money off of it
>>
>>107072288
>Nobody is forcing you to use Vercel for anything.
You forgot the operative word: yet
>>
>>107070730
Maybe you're one of a few devs that doesn't npm install heavy components libraries, knows when to use memoization, and that [ 'a' ] != [ 'a' ], but the entire industry has a skill issue as basically every React site out there sucks balls.
>>
>>107072376
the
>just self host it
is a meme anyways, a lot of the "coolest" features don't work like their incremental static regeneration which was really neat, vercel only because its all based on their backend server bullshittery that you'd have to re-replicate but they use as a cool selling point for nextjs.
its the reason i switched to sveltekit not because it solved that issue, bare in mind. but because fuck them
https://on-demand-isr.vercel.app/
>>
>>107072199
>Only works if you judiciously apply memo() to all components. (Which React itself recommends against, btw.)
Because for small components, it might be slower to check for all the dependencies instead of just letting the function call go.
This is why benchmarks are crucial in this sort of stuff.

>I don't know how you got that from the prior post
Because first you said that rerendering things is slow and then proceed to say that Dom is fast enough.
>>
>>107072458
yeah it's faster to just re-render most components than check diff
>>
>>107072479
And to find when exactly it is faster, we need benchmarks.
>>
>>107072458
>>107072479
>>107072490
check this article from coinbase
https://attardi.org/why-we-memo-all-the-things/
>>
>>107072458
>Because first you said that rerendering things is slow and then proceed to say that Dom is fast enough.
Congrats. You can't into reading skills.

I wrote that VDOM used to be comparitively light-weight to real DOM, which used to mean the costs of React's heavy-handed approach of re-rendering everything into a fresh VDOM and then using a reconciler to distill patches to the real DOM, would be hidden behind the real DOM's updates being a bottleneck.

In no way does this means I'd be advocating for 'just re-render everything all the time.'
Far from it - that's ACTUALLY what React is doing. And that jig is up, now that the real DOM has caught up performance wise, and all the VDOM diff machinery is starting to show its true colors as overhead.

What I'd be advocating for is signals-based reactive updates which directly attach to only those parts of the DOM that they need to modify. (Which is basically what more modern frameworks like SolidJS and Svelte do, afaik.)
>>
>>107068755
Win making websites for corporations? I guess it did but I use it for work not for fun.
>>
>>107072564
You're using react wrong if it's rerendering everything all the time. It should only rerender what you modified. The problem is react makes it difficult to understand what's going to be rerendered and why you don't want to mutate instead.
>>
>>107071954
Angular is faster than React+Next and uses signals
>>
>>107072925
Doesn't matter when most corps use an ancient version
>>
>>107072658
>You're using react wrong if it's rerendering everything all the time. It should only rerender what you modified.
That's literally not how React works. If state in a component is modified, it will re-execute top-to-bottom to produce a new VDOM, what React refers to as a re-render. That includes any and all child components in the component tree.

Child components CAN opt out of that by wrapping them in memo() and implementing equality comparison to know whether the props passed into a component haven't actually changed and thus - given idempotency - it can just spit out the last known render pass's old VDOM, but React actively discourages using memo.

Not to mention it's a total fucking pain in the ass to program correctly by hand. And it has serious bugs and shortcomings still with the React Compiler flow in React 19. (Which doesn't even exist in prior versions of React.)


React is doing a fucking TON of heavy lifting by hand, generating all that updated VDOM before handing it all off to the reconciler and the reconciler deciding: "nope, nothing's changed - we're good here," meaning all those CPU-cycles were wasted cycles.
>>
>>107072658
>You're using react wrong
The only way to use React right, is to take it 5 miles out into the desert and bury it in a shallow grave. Then piss on it.
>>
>>107072961
It's a pain for sure but the idea was for the developer not to bother with any of that. If you start trying to manually fine grain the advantage of react easier maintenance goes away. React basically copied elm, purescript, or other FP, but in JavaScript, without the same guarantees. It's less than ideal but Svelte and friends aren't going the right direction either.
>>
>>107072932
The only version that presents trouble migrating would be AngularJS -> Angular, if they are behind on versions it’s likely due to other issues and they will eventually catch up
>>
>>107072248
there's a nice course about web components on frontend masters, if your job has a subscription check it out.
https://frontendmasters.com/courses/vanilla-js-apps/
>>
i stopped frontend web dev back in 2016 and we are still arguing about the same doomer shit like reactjs? is there even anything exciting to look forward to in this space?
>>
>>107070959
This killed svelte for me. It felt like they changed the soul of it. Instead of changing it, they should have taken notes from htmx and published articles on their site for when svelte wouldn't be a good fit for your project
>>
>>107072564
>heavy-handed approach of re-rendering everything into a fresh VDOM and then using a reconciler to distill patches to the real DOM
Use memoization

>would be hidden behind the real DOM's updates being a bottleneck.
Benchmark needed
>>
>>107072961
>Not to mention it's a total fucking pain in the ass to program correctly by hand.
Linters catch 99% of errors regarding hook dependencies.
>>
>>107073349
>is there even anything exciting to look forward to in this space?
Native ECMAScript signals and async local context, which combined means you can make async computed derived reactive values, which automagically retain tracking of dependent reactive values across await statements.
>>
>>107070959
>>107073360
looks like vue
<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>

<template>
<button @click="count++">Count is: {{ count }}</button>
</template>

<style scoped>
button {
font-weight: bold;
}
</style>
>>
>>107072525
That's what I do in my React projects as well.
It kind of boggles me that some guides or documentation just don't give a fuck and yolos naked closures into callback. This is a recipe for sluggish website and potential rerender loops.
I memoize every callback and every value that is not cheap to compute and every object/array that will be passed down or used in another callback or memo.
I don't memoize all the children though, but only the larger ones.
>>
>>107073666
memo is not a hook dependency.
You are confused with the useMemo hook.

Also - linters catch jack shit wrt hooks.

They only work with the built-in hooks by default.
You have to painstakingly configure them with additional patterns capable of correctly recognizing any other hooks custom to your application, or imported from third-party packages.

The linting plugin's maintainers refuse to implement anything based on the type information from TSLint / eslint-typescript's enhanced syntax tree, which would 100% succesfully be able to identify the type of a hook parameter as a proper DependencyList, but - oh well. (These are the same retards that used to maintain Create React App after all, and that claimed there was no need or responsibility to keep its dependencies up to date because npm audit screaming bloody murder doesn't matter.)
>>
>>107073742
speaking of that, why did create react app get abandoned?
>>
>>107072445
ISR does work when self-hosting, but you have to write the cache handler yourself

>>107073801
1) react team started pushing people towards frameworks like nextjs
2) vite had better DX in every conceivable way
>>
>>107073349
>is there even anything exciting to look forward to in this space?
The only thing to look forward to in webshit is being replaced by LLMs. Unironically a completely dead career at this point, which is being phased out in every industry.
>>
The idea of a "web app" should sound absurd in itself.
>>
Svelte won but then lost it with runes
>>
>>107073742
>You have to painstakingly configure them
It's like one extra array to linter configuration.
>>
>>107069827
Yes, and it just so happens that you can make incredibly well-architected apps with it that DEIs can also perform in.
>>
I hope React dies, Vue should take over
>>
>>107075777
Vue cracked open the door on React alternatives, but it isn't the destination. Check out Solid.
>>
>>107075806
yeah solidjs looks nice, need to play with it a bit
>>
what's so good about solidjs? never heard of it before
>>
>>107075946
took rxjs (observer pattern) and made it better to work with
>>
>>107075806
solid was a proof of concept for signals.
vue now has signals. vue also is popular enough to have an ecosystem unlike solid.
>>
>>107075978
every other framework except react has signals now: angular, preact, svelte, vue
>>
>>107076924
Yeah i know and thats good. Reactive programming is a nice pattern when you need it, just that before the dx all those rx libraries have (not just javascript) a pretty bad dx and signals massively improve it. The concept is now new but the way it's executed is
>>
>>107077019
re-frame is still nicer
>>
>>107070307
IT WAS RIGHT FUCKING THERE AND I NEVER SAW IT
>>
>>107068990
>you can't discuss alternative web frameworks in a thread about a web framework
>>
>>107073678
it just took a decade dawg
>>
>>107078066
>web framework
First, elixir is a language. Second, React is a frontend framework meanwhile Phoenix is primarily SSR with Websocket slop on top. Mentioning Elixir signals you have no clue on what the difference is.
>>
>>107076894
vue will get even better once vapor is ready too
not to mention you can even use jsx if you want
>>
>>107070739
You have no idea how angry you just made me
>>
>>107071550
>Got any benchmarks?
Open any modern website with devtools open and then compare that to any website that predates react. That's your performance benchmark.
>>
>>107068755
>The Eternal Refactor Simulator™
>React introduces a new ‘best practice’ that breaks your old best practice that replaced the previous best practice.

I’ve been writing React since before hooks were a twinkle in Dan Abramov’s eye, and I swear at this point it’s less of a framework and more of an elaborate social experiment in developer Stockholm syndrome.
Lets start with the syntax crime scene itself: JSX. Nothing quite like writing HTML inside JavaScript inside a build toolchain that requires 14 dependencies just to display “Hello, world.” Then came TSX, because why not add a few more layers of type gymnastics so that your <div> now complains about missing generic type parameters.
>Bruh my hooks
Hooks were supposed to “simplify” things. Remember that? Instead, we got useEffect, useMemo, and useCallback... three functions that together can emulate the complete lifecycle of a small mammal
useEffect alone could have an entire course dedicated to “how to avoid infinite render loops because you accidentally referenced a function in your dependency array.” The number of Medium articles on “why your useEffect runs twice” compete with the number of stars in the observable universe.
And don’t even get me started on useMemo and useCallback. You add them because React’s reconciliation logic keeps recreating functions.

Every six months the React team drops a blog post that basically translates to:
>Hey remember that pattern we told you to use last year? Yeah, don’t do that anymore. it causes subtle performance issues in rendering mode.

Adding TypeScript to React should’ve been an upgrade. Instead, it’s like strapping a seatbelt onto a unicycle. Now every prop definition is a mini research project. “Why is children suddenly of type never?” “Why is my forwardRef incompatible with ComponentPropsWithRef?” “Why do I have to write <T extends keyof JSX.IntrinsicElements> just to render a damn <button>?
>>
>>107078732
phoenix is not idiomatic elixir.
if you want rails idioms and magic stay in rails. leave elixir alone.
>>
>>107079898
unlike any other js framework, react never broke backwards compat.
you are free to not refactor and keep using class-based components from over a decade ago.
react is the framwork you choose when you want to avoid the usual js churn.
>>
>>107079924
Kek.
That's not my point.
Re(f)act became:
The React Full-Employment Act

At this point, it’s hard to shake the feeling that React’s “innovation cycle” is less about improving developer experience and more about guaranteeing job security. Every “major refactor” comes packaged with enough breaking changes, new patterns, and shiny APIs to keep entire teams busy for quarters... refactoring perfectly functional code just to stay “modern.”
It’s a self-sustaining ecosystem: React creates the churn, consultancies and dev shops bill the hours, and we all get to feel productive while rewriting the same logic in slightly trendier syntax. In a way, React isn’t a UI library anymore... it’s a work creation framework disguised as progress.

And then there’s state management... the wound that never heals. React’s lack of coherent, built-in state handling birthed one of the most masochistic inventions in frontend history: Redux.
Redux was pitched as “predictable state management,” but in practice it became a ceremonial pattern involving reducers, action creators, middleware, and endless boilerplate.
Its grand promise was “observability through DevTools,” but anyone who’s used it in a real project knows the truth: half the time, you’re still sitting there yelling
>Why the fuck did the state change?!
while watching fifty dispatches fly by like tracer fire.

To be accurate, it’s not ceremonial... it’s a developer humiliation ritual. A rite of passage for anyone brave (or unlucky) enough to open a “legacy” React codebase. You can almost hear the screams of the devs who came before you, echoing through the reducers.

Yeah sure if you have a "green field project" it would be fine no need for that hustle. But since Devs need money it's unavoidable to witness the hot pile of garbage React is, even with all the new meme features, because you mostly get thrown into already existing legacy* codebases.

*3y+ react projects
>>
>>107079912
You're retarded.
>>
Why does React re-inevnt itself every 3 years, rendering your entire React codebase "obsolete"?
>>
SSR is better. Rails won
>>
File: file.png (324 KB, 480x451)
324 KB
324 KB PNG
Did Unix Win?
Why don't people just throw in the towel and admit Unix won and just contribute to Unix instead of creating GNU?
>>
File: megumin-konosuba-guix.png (195 KB, 814x576)
195 KB
195 KB PNG
>>107070309
>>107070913
That has nothing to do with react though. React has its ethical and computational problems, but when it comes to structure and design, it has more to do with the type of programmer who uses React than anything else. Look, if the average web programmer is already a disaster, a web programmer who uses React is twice as bad. The reason is simple: since React is the most popular framework/library, it also ends up being the one that receives the most attention from online course sellers, turd worlders, and other groups. So it's to be expected that the average React codebase will have a lot of garbage. You don't have the same percentage of garbage in Scheme codebases, for example, precisely because it's a language with practically no popularity among turd worlders, pajeets, and negroes. So the percentage of bad code and bad architecture is much lower.
>>
>>107080360
>it has more to do with the type of programmer who uses React than anything else
No shit sherlock? Most react "programmers" are total trash.
>>
>>107080457
To add to this: My point was this, but partially also that React itself does not enforce any kind of sane design.
>>
>>107080457
I don't know if you're illiterate or trying to bait me. My point wasn't specifically about React; I didn't mean to imply that programmers who use React are bad just because. My point is that the popularity of a tool/language will inevitably fill the environment with bad code. It has nothing to do with React, but rather with the fact that React is extremely popular. The same thing happens with PHP, Java, and other similar things. You're confusing the effect with the cause.
>>
>>107080481
>has nothing to do with React
Yeah but as I said in >>107080461 - React does not enforce any sane design. It does not enforce any design pattern in any of its docs or examples. And all the idiotic react "programmers" just parrot each others teachings, which are usually just trash and make no structural sense.
>>
File: 1757223933730761.png (71 KB, 984x486)
71 KB
71 KB PNG
>>107080481
And just look at this, one of their official examples. This code is fucking ugly and useEffect is advertised as this do-all hook which it is not. I don't fucking understand react, they could just have separate component initialization hook but they decided hey lets clump all functionality inside useEffect to make the code as ugly and as ambigious as possible.
>>
File: 1755177555927.png (236 KB, 1440x3040)
236 KB
236 KB PNG
>>107079752
>Open any modern website with devtools open and then compare that to any website that predates react.
Ok. I will use lighthouse because it's a bit more reliable than just doing it by feel.
Here is the result for my website.
>>
File: 1755177590297.png (209 KB, 1440x3040)
209 KB
209 KB PNG
>>107079752
>>107080631
And here is result for /g/

My react website work way faster than non-react 4chan. Therefore react makes websites faster according to your way of benchmarking frameworks.
>>
>>107080631
Imagine having over 1 second LOL
>>
>>107080481
Yet still the dev-blogs and best practices proposed by the react team, which are subsequently defacto a "guideline" cause what I described here:
>>107079973
>>107079898


Green field projects tend to be easy in any framework, but if you require a decent amount of money, you will get thrown into "legacy" artifact contaminated react projects, which "followed all the guidlines and best practices".

The ecosystem of react is polluted with bad advice FROM THE MAINTAINERS of react. Which makes the whole argument that react is such a trash framework, that not even the react team have a consistent way of developing with it.
>>
>>107080645
I think I know why is that but it doesn't matter. What matters is that it compares "any modern website and any website that predates react."
>>
>>107080490
And that's a good thing, that's what makes it so flexible. Opioniated, handholding frameworks become pain as soon as you want to do something developers did not predicted.
>>
>>107080636
>>107080663
Comparing performance to 4chan is a bit of a low blow, it's picking on the sick man of the internet.
Here's a benchmark of a random Wikipedia page.
So not that different but IDK how complicated your website is.
>>
>>107080676
Well it still makes 99% of react code jeet trash. These "programmers", who are employed btw, do not understand basic design principles. They do not understand why they should separate UI and business logic. They do not understand what unit testing is or why it is useful and they certainly don't know how to design react code so that it can be easily unit tested without actually running the UI.
>>
>>107080682
>Comparing performance to 4chan is a bit of a low blow
Why are you trying to move the goalpost?

It doesn't matter. What matters is that 4chan qualifies as "any website that predates react" which is how >>107079752's benchmark works.
>>
>>107080682
>>107080663
>>107080645
Kek.
You really believe that responsetimes matter?

Most enterprise websites with react, do not even have their react sites indexed, they have low response time CMS landing page navigating to the react SPA.

The main problem with react is the maintainability. Response time metrics, are a dumb metric, because websites can easily just use a minimal cms page as front.

The developers and POs are the onse suffering the most from react. If enterprises use react and are established, then you have the problems mentioned here:
>>107079973
>>107079898
>>
>>107080690
That doesn't matter. 99% of C code is CS freshman trash but that doesn't mean they should add GC and seatbelts to C. C is good because it is simple and unopinionated. That's what makes it useable in so many contexts.
>>
>>107080717
React is not unopinionated. Their whole philosophy is just trash because react is made by those 99% jeet coders nowadays.
>>
>>107080715
>React is slow
>give me a benchmark
>no, you do the benchmark this way
>ok, here is benchmark, it shows that React is fast
>uhh, it's not about speed, it's about maintainability
???
>>
>>107080726
Other competing frameworks are general significantly more opinionated than React.
>>
>>107080696
Well you may have won your little internet argument by comparing your React blog to a badly maintained imageboard but his point is still generally true.
React websites pack megabytes of JS for functionality that can be contained in kilobytes.
>>
>>107080752
>Well you may have won your little internet argument
Thank you

>his point is still generally true.
Not really, it felt apart as soon as I made the benchmark.
>>
>>107068755
I do everything in plain html, css and js, stuff loads instantly and works great
React is just modern day dogshit like jquery was but worse because you have to have a packager
>>
>>107080765
My react website loads instantly too. It even works without JS.
>>
>>107080739
I am a different anon. My point is that react is a a hot pile of trash, that is a huge meme.
And my suggestions is to rename react to Refact.

Performance is a meme for low to mid level e commerce platforms.

The bandwagonhoppers of big enterprises who used react and made it to their habbit, are the problem.
My first post was this:
>>107079898

I am not the benchmark anon.
Benchmark discussions are unemployed developer topics who phantasize about le meme performance and pleasing the SEO google good.

Real devs care about maintainability.
>>
>>107079898
Yeah original react was way different. It's just insane how react keeps changing.
>>
>>107080862
Your writing style reminds me of MikeeUSA
>>
>>107080862
>I am a different anon. My point is that react is a a hot pile of trash, that is a huge meme.
That's like your opinion. It doesn't mean anything tangible.

>Benchmark discussions are unemployed developer topics
I am employed and I always check benchmarks when talking about performance, therefore you are wrong.

>Real devs care about maintainability.
I never had any issues with maintaining my react websites.
>>
>>107080877
It got refined. Hooks are way more powerful and minimal than the OOP trash old react was.
>>
>>107081000
>I never had any issues with maintaining my react websites.

>my websites
>my

How large is your codebase and what do your websites accomplish?!

So you never had a real developer job, where react is used?
>>
>>107081000
>always check benchmarks when talking about performance, therefore you are wrong.

Benchmarks literally are useless in the real world.
Since most emplyoing enterprises already have their shitty systems established they use a front. If you care about "employability" or a well paying job, which includes react, you get always a shiny "minimal" front landing page with a cms, and then follows the hot garbage billion feature SPA or SSR app.
Even bad performing websites reach high pageranks if the company or product is already established.

You live in a sandbox playground world with your assertions.
>>
>>107081034
>How large is your codebase and what do your websites accomplish?!
My hobby projects are few thousands LoC each. The biggest ones are booru and a modular voice chat bot. At work, I made many larger projects, with the biggest project that was done from scratch by the team I lead totaling at 50k LoC.

>So you never had a real developer job, where react is used?
Yes. I have always been the team lead and I enforced practices that I think are good for making react websites. So I don't really have any experience working professionally on a badly written react code.

>>107081138
>Benchmarks literally are useless in the real world.
>Since most emplyoing enterprises already have their shitty systems established they use a front.
Whenever a company has some unspecified system established or not, it doesn't change the fact that if you want to reason about performance, benchmark is a start point.

>If you care about "employability" or a well paying job, which includes react, you get always a shiny "minimal" front landing page with a cms, and then follows the hot garbage billion feature SPA or SSR app.
And? I don't see what are you trying to say.

>You live in a sandbox playground world with your assertions.
I can say the same about you.
At least I base my argument on quantifiable aspects instead of just outputting unverifiable stream consciousness and random observations that do not lead to any concrete and verifiable point.
>>
>>107080529
>useEffect is advertised as this do-all hook which it is not
this is not true. This is from the official docs - https://react.dev/learn/you-might-not-need-an-effect
>>
>>107081216
>I have always been the team lead and I enforced practices that I think are good for making react websites

I don't know what a luxurious position you have or if you making shit up.

I usually get called into projects when things have gone off the rails, to figure out why the problems exist and put together an architectural plan to fix them. I work as a consultant in that space.

Because my job often involves assessing, rescuing, and redesigning critical legacy systems, I tend to end up knee-deep in massive (100k+ LoC) React codebases that… let’s just say, haven’t aged gracefully, and are defacto unmaintainable and should asses why it takes so long to create a new feature and why that breaks a buckload of stuff.

And honestly? Almost every large React project I’ve encountered has been a horror show, especially in the B2B, banking, insurance, or government sectors. No fun meme side-projects, just enterprise-grade chaos with many forms and features.
>>
React is the front-end equivalent to a Java back-end.
>>
>>107081282
Jesus christ react code is ugly. Like what the fuck are these javascript niggers thinking.

You don't fucking need something like JSX or React. Just fucking render shit with PHP and your website will work flawlessly. Or even better serve static HTML if that's all you need. Fucking cancer I say, "yeah let's include this billion line framework to output few static pages, fucking great idea".
>>
I can't even comprehend this shit. Like what the actual fuck is wrong with humanity. Javascript itself is horrible but it is what it is because browsers adopted it. Fucking UI code should be as simple as possible but react niggers write billion trillion line frameworks with million dependencies to server hello world pages.
>>
>>107080771
>My react website loads instantly too.
Eat shit
Oh wait
You already do
>>
>>107081567
>PHP
Thirdieware
>>
>>107081611
Blazingly fast and gets shit done, eat shit nigger.
>>
>>107081615
>doesn't even deny being a thirdie
grim, at least use elixir with phoenix or some shit
>>
>>107072248
svelte is shitty and lack other stuff, you cant think out of the box with svelte
>>
>>107081461
>I don't know what a luxurious position you have or if you making shit up.
I was lucky to get hired in a software house that focuses on greenfield projects and given my specific circumstances, I pretty much only do that.

>And honestly? Almost every large React project I’ve encountered has been a horror show, especially in the B2B, banking, insurance, or government sectors. No fun meme side-projects, just enterprise-grade chaos with many forms and features.
And I can imagine that being the case. But this is not React or webdev specific problem, any 100k+ LoC project can become unmaintainable if it's badly designed. But if you know what you are doing you can avoid these problems before it's too late. That's why in my projects, no change get merged without my final approval. According to feedback I got teammates do complain a lot about how rigorous my reviews are, but I accept no compromises. And that's why the other kind of feedback I get is that when I'm in the team people can be sure there won't be any big fuck ups.
>>
>>107081719
I don't have to deny something that is inherently false.
>>
>>107081567
>PHPjeet
>utterly confused by simple functional style features
Like pottery
>>
>>107081776
It can be PHP or C or C++ or Rust or whatever the fuck you want, PHP is not the point you fucking shit-brained jeet.
>>
>>107081590
UI code is not simple as possible in any environment. Non-webdev UI code can often be way more spaghetti than anything you see in React.
>>
>>107081782
UI is literally "push button -> something happens"
>>
>>107081782
I did some webdev in Rust. I had to spent ~10x more time and effort to get same results as my nodejs server with no measurable advantage and much less flexible code.
And I say that as fairly experienced Rust developer who has been using it regularly for 5 years or so.
>>
>>107071222
all web frameworks are actually sandpaper, got it
>>
>>107068755
React is cool. And preact with htm is also very cool.
>>
>>107081763
The claim you make about PRs review etc. Is the same every software team makes.
And while they seem to be pendantic about linebreaks and spacings and variable naming and all that superficial stuff.
Core and architecual decisions are not properly reviewed but presented with retard POCs. Also the whole meme of microfronends is beyond retarded and a mess to proper configure webpack.

I hope for you that you are not making up stuff. Because react in the case of minor wrong "fork in the road" decisions will lead to technical spaghetti code type of dept. While that is true for all frameworks, REACT is the worst contender.
Even angular which was a nightmare transition between angularJS to Angular2, does not produce that type of depressing spaghetti code. (Except some CTO or Lead makes the dumb decisions to use redux/ngRx/Zustand)

As long as you don't use redux or zustand or any of the alleged "state management libraries" which are actually state imolementation obfuscation libraries. Then you might be in a sane place.

Otherwise you are one of the delusional react devs which only have the feeling of "it's actually maintainable" because it's their "baby" which is producing some insane version of habitual blindness for architecual smells.
>>
>>107080682
>lighthouse meme
>>
>>107081282
That page was created in 2023, which is 5 years after hooks were released. The early messaging around hooks was a lot different.
>>
>>107083150
>And while they seem to be pendantic about linebreaks and spacings and variable naming and all that superficial stuff.
Nah it's the other way around. Some people complain that I do not use some "industry standard" preset like Airbnb or whatever but I find them unnecessary pedantic and opinionated. I just have hand crafted linter config that catches real potential problems and mistakes while being more lenient in terms of how to format your code or whenever you choose loop over method chain(shit like this should never be part of a linter!). What I focus on is actual code practices like when to memoize, how to deal with state, etc and architectural stuff.

>mess to proper configure webpack.
Well, I wrote all the webpack configurations myself. It's not easy for sure, but it's a powerful tool if you know how to use it.

>While that is true for all frameworks, REACT is the worst contender.
With great flexibility comes great potential to fuck things up.

>As long as you don't use redux or zustand or any of the alleged "state management libraries" which are actually state imolementation obfuscation libraries. Then you might be in a sane place
Yeah, redux is overrated and leads to over engineering. I used redux in one(1) project. And it was justified because it had a lot of global state that could be expressed as a complex state machine. But for 99% of cases, you do not need it, useReducer and context is more than enough in general.
>>
>>107083011
stay away from preact. it's literally doing
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED as internals,
} from "react";
>>
File: .png (480 KB, 1172x1430)
480 KB
480 KB PNG
>>107081791
let's compare different JS frameworks and reason what happens after you push a button
>>
I just had codex build me react from vanilla
Everything i need with none of the bloat
>>
>>107086220
??
we can tree-shake react since forever.
>>
>>107086239
I said none of the bloat
>>
>>107086110
Surely Vue is objectively correct?
>>
File: .png (193 KB, 2274x1172)
193 KB
193 KB PNG
>>107086247
tree-shaking is the opposite of bloat. your clone that can't be tree-shaked is bloated.
>>
>>107086305
React is bloat
>>
>>107086220
why do you need ai slop to write
https://gist.github.com/faustinoaq/b19da758fc45155a0b3b10d9f578c5ce#file-myreact-html
>>
>>107086220
Here's a cenile trying React for the first time thinking it was all bullshit then finally realising why it exists: https://www.youtube.com/watch?v=XAGCULPO_DE
Protip: working with bare JS and HTML for complex front-end projects is a pain in the arse. Of course your personal blog talking about pedo hentai is not a complex front-end project.
>>
>>107086305
tree shaking never works
>>
>>107086598
If you have a habit of writing overly complex code, you would still be writing overly complex code with react.
>>
>>107086110
Webdevs reinventing undefined behavior
>>
>>107086955
NTA, but there exist complex problems that can't be solved in simple way. When you encounter them, it's either using a framework or writing a framework yourself.
>>
>>107068755
>Not HTMX
I slep
>>
>>107087188
That's true, but that's not the point I'm making. I'm not saying that a framework isn't useful, but if what you're making is more complex than not using a framework, then you're not really using the framework in a beneficial way. You're just reinforcing your bad habits.
>>
>>107086598
>working with bare JS and HTML for complex front-end projects is a pain in the arse.
That's codex's problem, not mine
>>
>>107087225
htmx literally says not to use it for spa:
https://htmx.org/essays/when-to-use-hypermedia/
use react for a spa.
>>
>>107087325
And JavaScript shouldn't be used on the backend but here the fuck we are. I will continue to use HTMX to replace SPA frameworks because targeting the class 'page-body' is kino
>>
>>107087188
Like what? Anything you mention I’ll be able to imagine a vanilla way to structure and build it. And if I can’t then that’s an opportunity to learn about something fundamental. I don’t want to be separated from that
>>
File: Ev5D79uWEAEHQlw.jpg (149 KB, 1874x937)
149 KB
149 KB JPG
React did win. It won the moment LLMs loaded Github into memory. Look at modern "Frontend Devs" they only know frameworks. You combine the current state of front end devs with the bias llm's have to doing React and you get an infinite season of React. We'll literally never get off it because modern dev's CANNOT write frontend without LLMs and LLMs can ONLY produce React. Think I'm crazy? Look at Java. We'll never get off that shit either.
>>
>>107084111
>I wrote all the webpack configurations myself.
I smell...

>And it was justified because it had a lot of global state that could be expressed as a complex state machine
I smell LARP.

>>107081216
>I have always been the team lead and I enforced practices that I think are good for making react websites.
Holy LARP.

>>107081763
>According to feedback I got teammates do complain a lot about how rigorous my reviews are, but I accept no compromises
HOLY FUCKING HUBLEBRAGGING LARP.

>>107081461
>or if you making shit up.
Shit's made up.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.