React / Angela vs Jquery

Joined
Mar 11, 2013
Messages
5,542
Reaction score
9,844
What makes sense for you in these docs: https://react.dev/reference/react-dom/components
??

Nothing if you don't read it for weeks and months. And that's updated version that came up recently.

The previous version was such a disaster I felt like eating bricks.

Now if you go here: https://api.jquery.com/

It's very clear and you know what each thing does without some extra vocabulary. It's as clear as javascript docs from Mozilla.

So next project, you know what to do.

images
Key Features of React
Components - you will never need it
Virtual DOM - you will never need it
JSX - you will never need it.
One-way Data Binding - kinda easy to implement on your own.
Performance - you will never need it.
Component life cycles - you will never need it.
State management - simple to implement without it.
Server side rendering - ain't nobody gonna SEO behind paywall thing, man.

Apart from that, what would you rather have.

Extra useless corporate framework / library knowledge or...

Be able to scrape some cool websites and then plug into some APIs that would let you scale to the limit.



Stop complicating by subscribing to corporate nonsense from your home 1 person team...

And if you hire a team, you're just increasing costs of development.

Seriously, they don't tell you that. BUt shit is so hard to work with and easy to get lost in, you don't want that.

If they introduce some new library based on React, it's gonna be wicked. Each library based on React is another layer of wicked stuff.

Source code of those libraries is like some voodoo.

I haven't found it to be the case with javascript plain.

Don't learn it. Don't worry about it. You're never gonna specialize in it cause doing front-end isn't your goal. Your goal is to make a lot of money.
If you want to make some money, do some databases operations, build some storages, backends, automations proxies, servers etc. Not front-end, unless it's just javascript / jquery that doesn't require node.js to run. It's too much if you need node.js to run frontend.
 
Last edited:
Felt good to get that off your chest huh .. =)
Not really, I'm even more angry now. I'm on a rampage.

My mother said "no meat cause it's night".

So I tell the truth on the internet.

React won't make it to my business in 2025. :)

Even if lucky.sparks or some other player tries to convince me.

NEVER!!

We all have enemies. And Meta React is my fcking enemy.

Edit: it's existential crisis today. I posted already in the lounge about my 9-5. BUt I'm going harder trying to fix my development work environment and go to heavens.

MY WAY or MY WAY. No someone's way. =)

In crisis you got to positively filter and change as much for the better and kick out the crap. Then embrace new life.
Why? Because in crisis you're extremely critical as you can see.

If I go to prison, I won't waste my time studying front-end. Instead I'll jump into mathematics and study real engineering there.
 
Last edited:
I would use jQuery if I need to do small things, like a few changesets, nothing more. Now that there are so many advanced client-side libs and vanilla js is kinda advanced I would even say the need for jQuery is going out.

For building something more serious, for lets say user profile pages or dynamic content check vue or svelte, the learning curve isn't as crazy as for react, they are lightweight, easy to understand, and powerful.
 
I would use jQuery if I need to do small things, like a few changesets, nothing more. Now that there are so many advanced client-side libs and vanilla js is kinda advanced I would even say the need for jQuery is going out.

For building something more serious, for lets say user profile pages or dynamic content check vue or svelte, the learning curve isn't as crazy as for react, they are lightweight, easy to understand, and powerful.
Or Livewire like I posted 3 years ago when I came back to the Blackhatworld.

Svelte syntax looks so similar to blade templates in Laravel.

It looks like a mix of Vue and Blade.

Vue looks like a cousin of React.

Everything is tied to these "frameworks". That's the biggest hurdle.

Instead of saying "is this available for js", they ask "is this available for Vue".

I'm gonna have some water from Svelte. And spill it on my target...

The problem is I can't really fully understand what's happening behind. It's too many layers. I feel confused by it. I put these "bind" to my component but I don't understand why it really works and what it does... docs suck.
 

Attachments

  • ehh.png
    ehh.png
    14.7 KB · Views: 99
In react I end up using only useEffect and useState I keep it as simple as possible don't see benefits on moving.

Aside from that with this new theme this looks as an old post from 2010 or so that also looks boring to read :weep: Hate this feel
 
pls no


anyways having and keeping your frontend separate from backend has many advantages, you can easily build/test/distribute multiple design and frontend variations, build mobile UI based on same API endpoints and so on.

livewire is just PHP fanatics attempting(and succeeding) to (again) do things in PHP that they shouldn't.

you know.. only because you can it doesn't mean you should..
 
In react I end up using only useEffect and useState I keep it as simple as possible don't see benefits on moving.

Aside from that with this new theme this looks as an old post from 2010 or so that also looks boring to read :weep: Hate this feel
Suddenly wild youtubers appear and spam me with Redux, React Query and multiple other things.

Let's say I think: "I want to do this", so I google "how to do this in React". I'm bombarded with libraries and zero solutions with plain React.

And suddenly I have to understand wicked ways of doing something. That feels like reverse engineering car's engine to start the car... what's the point!

pls no


anyways having and keeping your frontend separate from backend has many advantages, you can easily build/test/distribute multiple design and frontend variations, build mobile UI based on same API endpoints and so on.

livewire is just PHP fanatics attempting(and succeeding) to (again) do things in PHP that they shouldn't.

you know.. only because you can it doesn't mean you should..
Because you can use React or Svelte or you can use dynamic pages or SPA, doesn't mean you should. :D

BHW still runs without any of that. ANY.

Look up their numbers... they focus on business.

I want to have only most important thoughts in my head. Zero distraction by tech I don't have to understand.
 
Another thing that I need to fix is my back position.

I feel like my back is rounded and not straight when I sit on my computer contributing to my overall discomfort that made me say that I hate computers and all that stuff.

But React? It will make me forget about my back position and I'll feel like crap again.

Only with proper positions I can get full strength of my head going through neck to all the muscles. React won't allow me to do that.
React is a piece of garbage
Nothing more needs to be said. Anyone who tried other options, will agree.

Angular shines in comparison. But it's again forcing a lot of stuff in its own way which is gonna slow down development.
 
Only with proper positions I can get full strength of my head going through neck to all the muscles. React won't allow me to do that.
Lololololol

I like to keep my feet elevated with a foot rest under my desk, helps me stay leaned back into the chair support.
 
CRYPTIC names.

Example Svelte.
First we read that it's "cybernetically enhanced web apps".

First time ever I heard that something is cybernetically enhanced.

First page we read "2. Assignments are 'reactive'"

And reactive isn't defined, so... we don't really know what they mean and have to figure that out.

Well, it can mean anything... ask the founder.

"3. $: marks a statement as reactive"

Man, what the hell is that syntax. Is this a trial of new language invention?

store = { subscribe: (subscription: (value: any) => void) => (() => void), set?: (value: any) => void }

This is crazy syntax. What the fck is this...

Why even mix HTML and JS together like this:

<button on:click={() => x++}> Increment X </button>

Overall I went through 5 things on ONE page and it all feels like complete insanity.

So again, it's another stupid invention where we need to figure out what cryptic corporate devs meant.

I know 99% of people using Svelte are poor React developers already, so they think it's intuitive.

No, it's not.

I used JavaScript for couple years. Going to PHP was easy. Going to Python was easy. Going to C# wasn't much of a problem.

But to React or something? Hell no.

The closest to ideal is Angular for me. The syntax resembles PHP, c#, typescript.

Good luck living with knowing i'm Angular fan. :)

It feels like Angular was developed by more serious people who actually think their product makes sense??? I think creators of React and Vue and Svelte don't think their product is worth anything?

Don't tell me Vue is better alternative to React. I couldn't find my shit in that mess without standards.

Why pick such a framework if you have to figure out everything yourself anyways... just in this "odd way" that is non-intuitive.

I remember using React Query it took me 4 days to write a simple fetch request. Wtf

And with Vue the situation wasn't much better. One view layout took me a week to develop.

That shit gave so many options and it was complicated to choose proper tools from all those useless tools that god knows what are for.

1715203478054.png


None of that speaks for itself.

Believe it or not, I'll be faster with SCSS / Less + JQuery / Plain JS.

Why it's so hard to have my own opinion? I'm too young.

"What really matters for you?" - this is important question to ask when making a choice or buying a product / service.

Maybe I'm just biased toward how Google engineers think. I like YouTube and Google a lot better than Facebook. It's easier for me to make money using Google products. And it seems easier to use their development tools as well.

Weird?

Facebook and their CEO was always considered somehow Alien.

1715203847411.png


Google answered my questions right off the bat when I visited Angular docs.

Hydration is the process that restores the server side rendered application on the client. This includes things like reusing the server rendered DOM structures, persisting the application state, transferring application data that was retrieved already by the server, and other processes.

Reactive forms provide a model-driven approach to handling form inputs whose values change over time. This guide shows you how to create and update a basic form control, progress to using multiple controls in a group, validate form values, and create dynamic forms where you can add or remove controls at run time.

Well done. Now I'm an Angular developer!

Another reason to choose Google is they're forward thinking which means Typescript is something in the default package.

You see that quote on "hydration" and "reactive forms"? I bet these definitions wouldn't be the same for React and Vue. ;)

Pessimistic vision.

"*ngIf"

xD

What the fck.

Benji?

Maybe there's some subset of Angular / tweaked version that doesn't mix HTML with js.

1715204689984.png


I'm gonna smoke a pipe... of programming crack. Pipes...
 
Last edited:
have you checked out htmx? i too hate React and all the frontend framework hell. htmx kinda changed the game for me
 
have you checked out htmx? i too hate React and all the frontend framework hell. htmx kinda changed the game for me
It looks very complicated when I checked it now.

I will try to modify Angular. :p Fork Angular?


I'm still wondering how refreshing websites became so complicated. That's complete clusterfuck.

When we looks closely https://htmx.org/docs/

The syntax is mostly JS and HTML. It doesn't provide some voodoo here.

Praise the God!

1715205579010.png


All people who I knew and went bankrupt doing web apps used React and React Native.

Coincidence?

Doing React feels like doing exercises with bad form. xD

It's not really fast like they claim. You need to optimize it in a cryptic way still. So it'll not be really fast without your efforts.

React is a perfect example of a nice 9-5 tool. It'll make your life suck and make you feel sorry that you were born. :P
 
Last edited:
So my list of candidates now is:

1. htmx
2. AlpineJS
3. Angular
...
Hell___
4422. Vue
...
10592. React
 
When we looks closely https://htmx.org/docs/

The syntax is mostly JS and HTML. It doesn't provide some voodoo here.

Exactly. It basically allows you to solve common front end problems by using html attributes instead of JS clusterfuck.

For me this is awesome because i'm mostly a back end developer (slowly migrating from Flask to Axum (Rust) as web framework) and this puts the work back into the server-side of things! I've been experimenting with Axum + Askama + Htmx stack these past few months and i'm having a blast.
 
Using React or Angular for me is like picking a bunch of stuff outside of big companies and putting it into a small business. This is not going to work. This would force me to learn something for the sake of just knowing how that tool works. And the benefit to something like a front-end web framework is really small. At first you feel like you're stepping up in your front-end game, but you don't really care about front-end, so why do that? Because it's a trendy style of doing things and maybe someone told you this is what the future looks like? Probably you think these companies like FaceBook and Google have good enough arguments to convince anyone that they're bosses. Their authoritativeness and people's bigotry towards using things of "the big guys" makes them feel special. It's like with gym, everyone who goes there hears about steroids. So everyone wants to shoot them cause they think steroids are what gives you gains. No, it actually discourages you to do things the right way. And it's exactly the situation with frameworks and libraries that do too much stuff for you. They're trying to solve every single problem for you, just like steroids, but those who sell it don't tell you about consequences and side effects.

So the consequence of picking thing A, B or C because we've heard about them in our environment is sometimes brutal. One thing we'd notice with things like React, Angular or any other web front-end framework is that it changes all the time. It's like a kid with an ADHD that you can never catch. There's always something new to learn. When you go to back-end, study procedural or object oriented programming, things there are always the same and the only difference is your approach to how you style all of the stuff. You of course need to be a lot more consistent in your work when you don't use framework and much more aware of what's happening. This would be only possible if you keep consistency, strict rules and have your own style written on paper. That usually isn't the case with front-end frameworks where people put a ton of stuff that could be as well skipped.

So we always need to ask ourselves what are we doing and what we really need in our processes. We don't ask "what is the current industry standard" because we're not hiring people to work in a large code base who need to have some "common ground" which a front-end framework can be. It can help organize some stuff when people in teams change, but it just doesn't happen in marketing automation. Once you code that tool to automate marketing, it's good. It doesn't need anything else. And if it's good enough, it can be connected to anything else using just simple modules that are held by a single procedure or a class.

What could be something that would help automate websites?

https://pugjs.org/api/getting-started.html

Not really, but it's something that was on my mind. Something that basically takes data whether it's some file in some human readable format like markdown or yaml or json or pug. Front-end frameworks are mixing OOP with HTML and also functional. This is very complicated to operate in such a landscape. HTML with CSS are more like procedural code. There's not much you can mess up in there and I think PUG or a tool that you code yourself with just switch cases and conditionals will get the job done to get 1000 sites published every week on the internet, then connect it to your own, proprietary analytics, so you are comfortable with it.

It's probably the only thing I would ever ask for. Nothing more and nothing else.
You're not bound with it to any "framework / library paradigm". Yes, front-end frameworks are like limited, narrow worlds where everything works differently than in a normal program. If someone ever saw how assembly code looks like, this is what this can be. It can be simple, easy to understand and just logical. You don't need heavy amounts of documentation with that. You can edit anything and do anything as long as you can press F12 a couple times.
 
Using React or Angular for me is like picking a bunch of stuff outside of big companies and putting it into a small business. This is not going to work. This would force me to learn something for the sake of just knowing how that tool works. And the benefit to something like a front-end web framework is really small. At first you feel like you're stepping up in your front-end game, but you don't really care about front-end, so why do that? Because it's a trendy style of doing things and maybe someone told you this is what the future looks like? Probably you think these companies like FaceBook and Google have good enough arguments to convince anyone that they're bosses. Their authoritativeness and people's bigotry towards using things of "the big guys" makes them feel special. It's like with gym, everyone who goes there hears about steroids. So everyone wants to shoot them cause they think steroids are what gives you gains. No, it actually discourages you to do things the right way. And it's exactly the situation with frameworks and libraries that do too much stuff for you. They're trying to solve every single problem for you, just like steroids, but those who sell it don't tell you about consequences and side effects.

So the consequence of picking thing A, B or C because we've heard about them in our environment is sometimes brutal. One thing we'd notice with things like React, Angular or any other web front-end framework is that it changes all the time. It's like a kid with an ADHD that you can never catch. There's always something new to learn. When you go to back-end, study procedural or object oriented programming, things there are always the same and the only difference is your approach to how you style all of the stuff. You of course need to be a lot more consistent in your work when you don't use framework and much more aware of what's happening. This would be only possible if you keep consistency, strict rules and have your own style written on paper. That usually isn't the case with front-end frameworks where people put a ton of stuff that could be as well skipped.
100% agreed. One MUST NOT be tied to a framework by any means. Especially if you're working by/for yourself and not as an employee of a large company that forces that framework down your throat. For solo developers the trick lies in knowing very well the differences between the possible solutions (frameworks, languages, etc.) and be able to choose the one that fits our project criteria/domain. ARCHITECTURE FIRST FRAMEWORKS/DRIVERS LATER!
 
Back
Top