FIRED For Using React?? | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Article: betterprogramming.pub/i-almos...
Author: Razvan Dragomir | / drazvan91
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@Sledgeattack]

Prime says he hates "React" yet his name is "Prime Reacts", Curious

[@mauro--1521]

2024 ThePrime Svelte?

[@atikenny]

ThePrimeVues he doesn't React

[@OzzyTheGiant]

ThePrimeVuesSvelteVideosAndHasAngularOpinionsOnThem

[@crazypato1217]

Sus 😮

[@kullbetdah]

​@@mauro--1521😂

[@DeusGladiorum]

It’s insane that we live in a world where express is considered a framework and react has the nerve to call itself a library

[@IvanKleshnin]

React kiddies attack and "correct" everyone who dares to mislabel their precious. They dont care that React is the only "library" in history that is fullstack, they dont care that Vue is a framework being a React closest alternative. If tomorrow Meta acknowledges its a framework the same kiddies will instantly change their minds, accordingly.

[@OzzyTheGiant]

@@IvanKleshnin Agreed, such sheep culture. Can't think for themselves

[@mac.ignacio]

React Devs has no brain they are connected in one network

[@sapkra]

Yeah, because both are libraries 🫣

[@pyrocentury]

@@IvanKleshnin I use React at work and I can care less about what it is labelled as. It's a tool to do a job. If you're surrounding yourself with people--online or otherwise--that care about this, then you should find better company.

[@sealsharp]

I'm a C# dev and that compromise to make c# devs feel better was bullshit. If a java programmer joined my projects and started replacing properties with getter and setters i would tell him to stop it, no matter how "at home" that feels. And in exchange i will use any === or ==== or ===== in JS or whatever is required to get the behaviour that is == in any civilized language.

[@MrAntice]

Javascript. one of the few languages in history where you need 2 types of comparisons, in case you accidentally compare "1" with 1 and getting true when it shoudl be false.

[@georgerogers1166]

eqv? and equal? Is the only distinction required.

[@freesoftwareextremist8119]

@@MrAntice Don't ever ask a Lisper about eq, eql, equal and equalp.

[@majorhumbert676]

​@@MrAntice just don't use ==, bro

[@MrAntice]

@@majorhumbert676 That's what I always say too when anyone asks why there are only ==='s in my code.

[@doc8527]

After reading the story, I have a weird feeling that no matter what the author chose from the beginning, it will always end up to the same place. It seems like there was a internal battle between different developers and the author actually didn't have the power to do anything, it just seems like he had the choice but in fact he never. CTO is being a weird position that only watched thing happened and blame if something didn't work.

[@edwardcullen1739]

This is the problem with weak leadership.

[@joegaffney8006]

To many cooks, resistance and to much planning without working on a minimal viable product.

[@cariyaputta]

​@@joegaffney8006yeah true, whenever I'm in charge of a codebase I always go with "let's just build some shits and see what'll happen."

[@joegaffney8006]

@@cariyaputta personally I think you can do allot of the planning building a mvp or prototype and this can also help convince people.

[@russtran]

I agree. They need to change the way their team work. Their CTO should be the one that leads the crew, yet I don't see any of his action to contribute into the project. All I can see is he's creating unnecessary tension between team members, he doesn't even know who's the expert of the project and let some .NET devs involved with the project flow. I feel sorry for the author tbh

[@FabulousFadz]

7:28 I also find it strange that people are so ready to add a project level dependency for the most simple things. Just the other day a friend asked me for help in figuring out how a library he had added could be configured to work they way he wanted. I told him I hadn't heard of the library but it was a simple problem to solve and would be easy to code in about 20 minutes. He shut me down saying he didn't want to spend any more time on it because he had been fiddling with the library for a whole day and had to make a decision on whether to stick with the library or choose another within an hour. I mean... 20 min < 1 hour. He chose to work with the library and the next day came asking how to write that code after finding the overhead the library came with was not worth the benefits.

[@DEVDerr]

Right? I can't count amount of times where people asked me to install axios (before showing them how to write simple fetch couple of minutes later) Even making tiny good abstraction around fetch() takes like 5 minutes to write, so it's extremely weird that I had to justify my decision of not installing yet another library that gives 90% of overhead and 10% of actual simplification of the problem

[@Euphorya]

I've also noticed way more resistance to writing our own code over using a library. I think it comes down to liability, if something breaks you can blame the library. If you roll your own solution and it breaks it's on you. I catch a lot of flack for being the "minimize new dependencies" guy.

[@doc8527]

@@DEVDerr your example could be quickly invalid while working with others, if the thing is simple and straight forward. then go ahead, do the fetch(), when you need a consistent implementation for the entire project with typescript support, error handling format. Either you single handed the entire fetch abstraction structure so everyone was enforced by your choice, or just use axios and called it a day. I once have project that went with your fetch approach, it's a little nightmare to handle, because the fetch handling structure slowly changed over time by different devs, so many inconsistency and api handling, guess what, it's a worse reimplementation of axios abstraction. I think axios is not a good example here as the lib itself has some history context. The more appropriate example I think it's installed some helper libs (hook libs or lodash) and only use one of them for the entire project, and that part of code is only few lines inside the original lib, which you can just directly copy and paste. Even worse, they realized the helper functions they used didn't fit their needs, instead of creating the own one. They create some weird abstractions or fixes on top of that wrong choice of functions. Then the nightmare starts. I also felt this is one of the core issues of the article inside the video failed to mentioned. The amount of dependency is bizarre. I can feel the codebase has tons of reimplementation on top of the wrong choice, that would justify the tons of deps.

[@faridguzman91]

sometimes fetch() and promises can be quite a footgun so sometimes i use axios for that @@DEVDerr

[@doc8527]

I also see some simple React/Svelte app to be extremely slow during the dev and prod. the 600mb node_modules folder is never the issue, the problem is always end up being the worse reimplementation of existing libs on top of the wrong choice of some libs. As long as you get rid of those fking reimplementation, the whole app runs as fast as fk. 🥲I'm just being the unfortune one who need to clean those debts. Being a framework developer imo is totally fine as long as you know it well, the hard reality is that tons of "framework developers" have no clue of the framework itself. They are not even qualified for the industry, you can call me gate-keeping. The market is being high-saturated and damaged because of them and we have to clean their terrible left-over.

[@FabulousFadz]

27:36 At risk of starting a flame war... I've never seen a Javascript problem that is fixed by more Javascript.

[@ShadoFXPerino]

Yeah it's usually fixed using the bash command "npm install ..."

[@hypergraphic]

There should be a law that goes something like "You cannot fix the wrong abstraction by using that wrong abstraction."

[@mage3690]

​@@hypergraphicyeah, it's called "two wrongs don't make a right, they just get you going backwards. Three lefts _will_ make a right, though."

[@MuhammadSaied]

you fix it by including jquery actually

[@bike4aday]

We don't want to reinvent the wheel, so let's decide which tools that reinvent the wheel to base our entire project on

[@daumienebi]

😂😂😂

[@asdqwe4427]

The bigger issue (to me) is that they didn’t pick a framework that fit the team. But, to be fair, this is easier now than 5 years ago. If I had C# developers today, I’d honestly consider Blazor

[@440766tg]

whole problem was .Net had nothing to make a SPA website for many years.

[@tyrellnelson]

The only problem with 'OOP' is everyone forgets to add the 'S' at the end (OOPS)

[@robertluong3024]

OOP is good for a lot of things. At the same time, there's a lot of pitfalls and the over-prescription of classes and inheritance make for a messy and complex structure. Also, I like IoC at times, but I mean you don't need to bring it everywhere. I hated it in AngularJS. I worked for a bay area company and they used DI for NodeJS stuff and I couldn't figure out how things worked. We had devs completely stalled because we couldn't figure it out. I'm also a .NET dev and I've read Mark Seemann's Dependency Injection in .NET so I'm not foreign to the topic at all and I had trouble figuring out they did it.

[@zahash1045]

🤓 🤡

[@adrianspikes6454]

Another web dev opinion. Be an engineer and utilize concepts that make you understand what your getting into.

[@OzzyTheGiant]

The only people that do OOPS are those who can't organize their code.

[@mage3690]

​@@adrianspikes6454the web is literally defined by OOP, top to bottom. The DOM is all but written into law, and the only languages used in the browser are OOP to their core. If "OOP bad" is a webdev take, I'd listen. They're the ones who have to live the OOP life, day in and day out.

[@lawrencejob]

He didn’t get nearly fired for react, he got nearly fired for letting his team write OOP inside React

[@radvilardian740]

why not ?

[@VuTuanIT]

that is just one of the many problems there

[@scvnthorpe__]

The greatest trick the devil ever pulled was getting developers to define graphical interfaces using OOP (the two have a closely linked history) and calling it functional programming.

[@lawrencejob]

@@scvnthorpe__ not sure if I agree; I’d love to hear more

[@johnjackson6262]

You shouldn’t use class based components, OOP is fine.

[@d1ngd0]

Not only did they reinvent html, but the dom was too slow, so they made a new dom in JavaScript.

[@ThePrimeTimeagen]

now we have slow javascript

[@Kunal70006]

React will reinvent Javascript soon enough

[@reeeeedmil]

@@Kunal70006 reactscript?

[@Mr_Yeah]

@@Kunal70006 Isn't that JSX already?

[@Kunal70006]

@@Mr_Yeah nah jsx is more like a template not a language

[@darkdudironaji]

"...at $40/ hour. Man you got some cheap developers there." Me making $28.85/hour: 😭

[@timothyvandyke9511]

That whole “teams are unable to make a decision” is a mood. It’s why I left my last job

[@ThePrimeTimeagen]

its real man. it hurts so much

[@MichaelPohoreski]

Accountability without Authority = Bureaucracy Authority without Accountability = Totalitarianism Need the balance of both.

[@Necessarius]

They now can make decisions

[@TehKarmalizer]

@@MichaelPohoreski disagree. There is no accountability for bureaucracy. They are unelected officials. Though I suppose there is no accountability for elected officials, either, so maybe I just need to rethink that.

[@hungrymusicwolf]

@@TehKarmalizerAccountability for major institutions and the people working within is a bit of a problem in general nowadays. Elected, unelected, shouldn't have authority in said institution at all but do anyways because of cronyism (not exactly but you get the point).

[@ankurdutta3277]

I do my personal projects in Svelte but for any serious project that involves a team I always root for Angular. Though creating wrappers is also a problem in Angular. The code base stays consistent and Angular takes care of all my basic needs. All I have to do is focus is on solving the problem.

[@Daijyobanai]

Consistency is a real problem with React. I see a lot of consultants creating new work but after a year or two they move on, never to touch that code-base again. They just start something new far way from this project that used X-router, X-state-manager, X-this and that. Then some poor guy is hired to "bugfix and make improvements" and everyone is angry after that.

[@mornwind318]

You don't really need react-something to use something in React. You just need to learn React instead of copypasting code from NPM. Most people writing React, or Vue, or Angular, never learn JavaScript itself, and never notice that they're using a library that produces HTML, written in JavaScript, that can use anything else written in JavaScript. It's the unfortunate reality of an industry chock-full of newbies out of bootcamps. Btw, hilariously enough, Svelte needs dedicated libraries because it's more of a compiled thing. You can ref any library into React any day. Refs are the escape hatch out of React. You don't need dumb wrappers.

[@sivuyilemagutywa5286]

Let's be honest: you're unlikely to write an app using just vanilla JavaScript; you'll probably end up creating a new JavaScript framework instead. I can relate to this because I initially learned JavaScript through a framework. My background includes experience in Java, as well as basic knowledge of C#, C, C++, and PHP. Although I'm familiar enough with vanilla JavaScript to build a website without a framework, I would never choose to do so again when I have the option to use something like Astro or Vue.

[@mornwind318]

@@HyuLilium you most definitely can. You only need to handle the state yourself by wiring it up to callbacks and such if you want to cross boundaries between Grape and React. React doesn't really care what's in your element, or even web component as long as you don't give it any reason to interfere.

[@HyuLilium]

@@mornwind318 it really isn't anything easy. Check out the issue Integrating React components #1970

[@diegolikescode]

btw, the $40/hour is actually a pretty good pay, I'm a brazillian developer and the best offers that I get from US companies is like $1800/month, which translate to like $10/hour. Yeah, it sucks big time.

[@vaibhavnayak909]

If you are in NA or Europe then it is low. If get paid that much while working in India I am rich.

[@redpillsatori3020]

What are taxes like in Brazil? With the USA tax code I probably don't make much more than you do, and I bet the cost of living there is a fraction what it is in the States--especially rent.

[@youtubeviewer5990]

​​​@@redpillsatori3020up to 27% income tax + ~60% tax in everything you buy (gas, food, etc...) + property tax + vehicle tax (and we have a 80% tax for imported products too) And company taxes to receive the money.

[@Smogne]

@@redpillsatori3020 In simple terms, the highest tax bracket is 27.5%; you get there once you hit a little more than BRL 4.6k - which is a little less than USD 1K. Taxes here are ridiculously high (I mean, sure, the part that falls on the lower bracket is taxed on that bracket, but once you star receiving more than 4.6k, you pay in taxes around 38.5% of every BRL 1 that you make - the extra that makes it around 38.5% is the national well fare system, that in theory will allow you to retire gaining an equivalent amount to your contributions, so if you make more money you pay more money but do retire making more later - most people retire from it (every one that is low income have it as their only retirement plan, so it is a import institution here), but I have my doubts about it's sustainability until I retire). You can get by a decent single life for about BRL 2.5~3K if you have rent and so on (small apartment rent). You can live better with that on a small town. Much better in some cases tbh. If you have a family with small kids, you expenses get a lot higher (it's like that on the US too, so nothing new for you I imagine).

[@koool56]

I get 25$ an hour in UK, so yeah 40$ sounds great

[@lukasmolcic5143]

when people say React is an unopinionated library, what they want to say it's different from something like Angular which provides you with all of the building block to create the entire app, while React only gives you the base lifecycle and reactivity modal on top of which you are free to build anything with anything in whatever way that you want. The reason why the phrase doesn't really hold water is because that part that React provides shapes absolutely everything you build on top of it which definitely bounds your work to a frame shaped by Reacts opinions of how HTML and js should interact.

[@mage3690]

I think almost any language or tool is opinionated. As they say, when you have a hammer and all that. But the statement works equally well with any other tool: when you have a screwdriver, every problem looks like a screw; when you have a wrench, every problem needs a bolt; when you have a welder, every problem could be welded; when you have duct tape, all you need is an awful lot of duct tape. The real problem is when people think that their particular favorite tool _isn't_ opinionated. I love assumptions. Assumptions are fast, usually accurate, and easily modified--unless I think they're not assumptions. Then they're slow, more wrong than trying to use a stopped clock to fix a boiler, and damn near impossible to change. Unless, of course, your tool is just bad. If I had a flathead screwdriver, every problem would need a bolt. If I had Scotch tape, every problem would need rope. But even there, you can see the assumptions that aren't assumptions anymore shining though: it's "I don't like flathead screwdrivers, therefore I need another tool that looks just like it but is easier to use," rather than "I'm trying to weld wood, therefore I really need to consider using glue."

[@ZelenoJabko]

Yes, better to call it barebones, or "no batteries included".

[@dan-bz7dz]

@@mage3690 "I think almost any language or tool is opinionated". RoR is opiniated. That way when you start a new project, you don't have to make these library decisions as everyone basically use the same. You don't have that in the JS world.

[@jhonyhndoea]

Its unopinionated because you can use it for just a single element, you don't have to code the whole website with react. people are just doing it wrong, it was never meant to be used for SPA

[@ra2enjoyer708]

@@jhonyhndoea You have to have a root component pretty high in the markup in order to render anything at all. And react itself is not a lightweight dependency (not to mention it requires a build pipeline), so using it for just one component is a colossal waste.

[@_starhelix]

I’ve been needing this man’s commentary in my career, like a mentor ❤

[@michaelhart8928]

The informed captain sounds a lot like the surgical team structure from The Mythical Man-Month. It's a great book. Casey references some of the same concepts from the book in his videos.

[@mage3690]

It also sounds exactly like the military rank structures used by every decent military since Napoleon. Fast decisions favor top-down decision making, but top-down structures are inherently unstable and ironically slow to react to change. The Marines especially embody the ideal of "informed captain": at the end of every meeting, the top dog gets up and asks everyone in the room for feedback, starting with the lowest ranking person. And because it's ultimately the top dog's decision, he really can't blame the youngest guy in the room for bad advice.

[@Gornius]

That's exactly what happens when you're OTP of a language/framework. You can't solve problems, you just apply solutions without knowing the underlying issue.

[@robolist2277]

What does OTP mean?

[@braxpark]

​@robolist2277 one-trick pony, I think

[@Gornius]

@@robolist2277 One Trick Pony - mostly used in gaming communities, usually meaning you play only one class/role/strategy etc, so technically you should be very good at the one thing you were doing your whole "career", but no experience in other aspects of the game mean you cannot fully grasp what's happening and ironically it makes you worse at the game. Same thing with programming and other aspects of life tbh.

[@erifetim]

@@braxpark Obviously The Poser

[@JeyPeyy]

​@@erifetimone tiny penis

[@Gornius]

28:45 - I have not been aware of THESE implications of how svelte handles reactivity. Like obviously it's easier and faster to write, but this is that one thing that at this moment made me really try Svelte out.

[@DEVDerr]

It's just obviously better in all things Even in things that React devs claim that React is better at than Svelte (which is false)

[@kelvintakyi-bobi3155]

Svelte❤

[@salvatoreshiggerino6810]

I'm not familiar with WPF, but from what I can read that sounds like it was the right tool for the job the whole time.

[@distant6606]

wpf is for desktop apps i think, they wanted to create a web app.

[@therealscifi]

I remember WPF, it was actually pretty awesome to learn and to use.

[@shimadabr]

WPF is great, but it is exclusively desktop and only works on Windows.

[@disguysn]

If I remember correctly WPF is technically available on multiple platforms thanks to C# cross platform shenanigans and possibly third party libraries. It's been a few years since I cared about it though.

[@lucass8119]

@@disguysn WPF is, unfortunately, not cross platform. Microsoft really messed up the .NET framework to Core transition. While .NET is fully cross platform going on, many old libraries will never be made cross platform. Instead, they are left in the dust to be replaced by new .NET Core libraries. For example, .NET MAUI succeeds WPF. You can technically mayyyyybe run WPF through Wine, but that's always been the case for Windows applications and is hardly considered cross platform. On one hand this sucks a bit for those who committed huge time and code to quickly obsolescing .NET technologies, but on the other hand a rebirth of .NET libraries will provide a clearer path in the future and reinforce .NET's position as a modern cross-platform framework.

[@getflourish]

Such a good commentary. Dude, this is therapy :D

[@ivanmaglica264]

This is one example where I think server side MVC would make a lot more sense. Especially since quite a bit of C# could have been reused. Also the outsource team would have been on-boarded sooner.

[@AH-wk1id]

Exactly

[@JohnDavidDunlap]

But then you don't have to update your frontend dependencies!

[@joejazdzewski]

I had a similar story of having a project where I had C# devs and chose Angular because it was in Typescript(this was when Typescript wasn't popular yet) and maintenance would be easier even if I left the project

[@returncode0000]

Thats the most funniest episode I‘ve seen so far on this channel 😂 Already a classic! I‘m working in a big Angular project with hundrets of sites, all he wrote does sound like Angular has been the right decison for this project.

[@alexander_234]

27:50 "I have only one rule: New is always better." ~ Barney Stinson

[@edwardcullen1739]

The whole JavaScript ecosystem is insane. Every project I've worked on seems to download the entire Internet. There was even one library that needed Python to build it. 🤦‍♂️🤦‍♂️🤦‍♂️

[@buc991]

same python, ruby and whatnot, why hate only js, all scripting languages like this, or you want to reinvent wheel for every little thing, but you have limited time for tasks on a job, or no?

[@Salantor]

@@buc991 Web dev is reinventing the wheel every year...

[@edwardcullen1739]

@@buc991 Because JS isn't a programming language. More to the point, JS programmers do not take responsibility for the shit they use. The ecosystem for other languages are not nearly as bad. The fact that "no one uses NPM anymore", because they all use something else that tries to manage the dependency hell, says it all.

[@ra2enjoyer708]

@@edwardcullen1739 All these "not NPM" alternatives either died out or caved in to becoming a strict (and worse) subset of NodeJS + NPM module resolution. Also "other languages are not nearly as bad" is a complete lie, since dependency management in turing-complete environments is a non-trivial task and is a problem in all languages.

[@edwardcullen1739]

@@ra2enjoyer708 Given this is what I do, I'm going to vehemently disagree. It is not the tool that is the problem, per se (though NPM solves the wrong problems), but the entire ecosystem and how it is used/managed. Python (pip) ecosystem is not even close to being as bad, though, the influx of data scientists and AI researchers in recent years has degraded quality overall. Turing Completeness is nothing to do with this problem - I question whether you actually know what you're talking about.

[@adambickford8720]

Been there. We had a team of 3 doing a PoC that was entirely non-blocking in java; `WebFlux` and 100% functional/reactive programming. We were crushing it by any metric. Then a couple people left, and the new custodians despised everything about it and did their best to fight it every step of the way. Productivity tanked and bugs thrived even with the same tech/code base.

[@WolfrostWasTaken]

Consider the basic idea that there are shit developers out there

[@airjuri]

Yeah, i learned coding since '87. So i think i know something or two about developing. Nowadays you do what you're paid for. If there is some crazy framework and you go with it without asking... you don't solo things or you're out. I'm just glad that i know how to program assembler for 6502, waiting for job opportunities with that ;)

[@Slashx92]

10:14 people are so used to angular's opinions as where files go, how things are called, etc. That we forget that is not the only opinions that exist. Opinions like "everything in you app must be done the react way or else is dogshit" is a very strong opinion. The *framweork* not having directory structure doesn't make it unopinionated You know what is not opinionated? something like lit templates

[@matteoveraldi.musica]

I see that hating React is the new trend. All the other frameworks/libraries are already hated (angular, svelte, you name it). I guess we're all going to downgrade to vanilla JS again.

[@SXsoft99]

As a PHP developer I had the opportunity to work on a vue app with a java team that wrote the project from scratch, they mamaged to shoot vue in the foot

[@aflah7572]

I can so relate to the description at 17:05 In my first internship at a pretty good company I was supposed to work on React and spent my first week learning it while also looking at their codebase on the side and trying out minor changes to make sense of it. There were behemoths of functional component just hundreds of lines long having tons of useEffects and state changes which made it essentially unreadable to anyone but the original developer

[@CFXTBogard]

When you are genuinely the only guy on the team to stand and take decisions that can help everyone, there will be that **special developer** that doesn't want to adhere to the norms and start to make the weirdest shit you will see in Merge Request. If not corrected on time, the ship is quickly become unmaintainable or ready to sink. That is why I believe that if you are in position of leadership and show receipts to your devs, and devs understand the risks of doing shitty things, applications will be maintainable and easy to ship.

[@spik330]

This reminds me of the "good old days" where everything had to be done with a packaged lib, and writing code in your project was considered cliche. If you wanted to write you a system or anything larger than a few lines, well you need to write it then package it up as a lib so they could add it as a dependency to the project. It was soo ducking stupid.

[@nryle]

I'm so happy to take on the features that either don't or barely hit the front end react

[@richardrodriguez8342]

Been there. Not in an enterprise situation, but a personal one. Was truly on board with Electron and NodeJS. The dependencies of using any NodeJS package, is that it brings in others, which brings in others, etc. It was ok for a while, but whenever I would put down the project and come back, things have changed forcing me to add code to compensate for the changes I didn't make. As some competition to Electron came out, I tried it out, but it required me to dump NodeJS and code I wrote for it. What a nightmare, I thought, but I was wrong. Moving away from NodeJS and Electron completely stabilized things and was the right decision to keep the project moving at my own pace, which was on and off.

[@wraith3108]

Awesome video. A quick question, does Netflix use nextjs framework now?

[@Bourn77]

Angular, Vue or Blazor is the right answer here, especially since C# Dev's are involved, React is a big no no, it's coming from a C# dev.

[@cowabunga2597]

You forgot /s

[@manaslovesbirds]

Love Angular. The seperation of concerns is implemented nicely - meaning view templates, script and styles are loosely coupled.

[@adrianspikes6454]

Right on. But as usual JS devs don't really know any other way. While C# engineers have to know other ways of getting jobs. Blazor was a total game changer for .NET and Angular would really be the only other option for a .NET team not React.

[@blubblurb]

Vue yes, Angular no. Angular is overengineerd bloatware. Never tried blazor unfortunately. But Iˋm happy with Vue so no reason to try blazor atm.

[@OzzyTheGiant]

@@blubblurb Really? well god forbid you ever work with a basic Android/iOS project. OOP principles help organize code really well, just gotta learn those design patterns. On the other hand, ngModules are overkill, but thankfully, Angular 16 is doing away with that, as well as supporting new template syntax (Svelte style), Jest, signals, etc. that it's worth taking another look.

[@gFamWeb]

Having personally ported a WPF application to Electron, and separately worked on a project with a Canadian company that chose to migrate an app to React (Native), this story seems particularly relevant. EDIT: InversifyJS, oh fuck! There's something I have experience with too.

[@NikPiermafrost]

My fucking god my solution architect has the exact same mentality: "C# does it like this so everything must be like this" in an Angular project and the result when i got back into the project after one year was one of the ugliest mess i ever seen in my life. C# is a pretty good and performant language but my god it has the biggest number of Acolytes

[@OzzyTheGiant]

I feel like people are missing the point of the video. While you're not wrong, it show cases that OOP is a paradigm that is transferable to most other languages and frameworks, whereas React is the opinionated one here.

[@HyuLilium]

​@@OzzyTheGiant OOP doesn't belong in frontend code and the fact that syntactic sugar classes were added is just a mistake. Seeing OOP shilling makes me want to pick up Haskell and then Rust faster.

[@NikPiermafrost]

@@HyuLilium that's not entirely true IMHO, what is wrong is the complete abuse some devs does with OOP

[@majorhumbert676]

@@NikPiermafrost OOP sucks, just admit it. Have an opinion for god's sake

[@theshermantanker7043]

​@@majorhumbert676web dev tier opinion

[@dipereira0123]

14:50 that part about the no-Good Zone is something that I 100% support being taught in both tech and business schools. and its usually ignored... it also reinforce the importance of documentation hence later you have to justify the drawbacks of your choice

[@thngzys]

I'm slowly descending into this hell at my own workplace. Definitely feel for the dude

[@mauriceb2037]

As a Java developper, i always HATE when i have to touch anything javascript related. So i understand how c# his teammates would have felt, and yes i would resent having to work with react

[@EvilTim1911]

I gotta say as a Javascript dev I feel the same when I have run-ins with Java. I despise it

[@manaslovesbirds]

Java dev here. When I get bored of Java I start learning JS...and immediately start loving Java because of how terrible the JS ecosystem is. Javascript as a language is terrible as well. JS devs make fun of JSP but love React syntax where HTML is mixed with script elements..makes me laugh.

[@buc991]

all i hear is as a java developer, i'm scared to learn new things, language is just a tool, and there are no better tool than js/ts for web frontend development atm

[@vitorguidorizzzi7538]

As a java developer, i hate having to touch that pajeetlang, not that JS is any good, both suck

[@avsync-live]

4:49 I agree it feels so fundamentally wrong. But it does make sense on some level. Of course the machine can handle code splitting and minification faster than if you wrote everything by hand. If you do no build js I think you are creating more work for yourself in a large project. Not sure if wasm is coming to the rescue because it has overhead and takes a build step too

[@animelafuerza]

I feel the problem here was not react, was the hugungus quantity of libraries used in the project. I don't mind a charting library (or two) or some library for maps... but hundreds? the standard libraries I use are: react-icons, apollo, graphql-code-generator (doesn't get transpiled) and tailwind. Maybe some projects require an specific lib (like charting, or maps, ....), IMHO having a library for everything and anything is just lazy programing. Also, I would never recommend stand-alone react for an enterprise solution to anyone, I would recommend NextJS. I do thing NextJS is the future of react for anything that isn't a hello-world or TODO app.

[@SandraWantsCoke]

you don't need apollo, you can just make post requests for graphql

[@Salantor]

But here is the thing: that was not the number of libraries. That was the number of dependencies. They picked just a handful of npm packages, and the rest came along. Redux-saga has one dependency, but that one requires 8 more, and those require 6 more. You already have 16 packages just to use Saga. And that is only one big package on the list!

[@oscarljimenez5717]

@@Salantor ez, unistall redux-saga. Use RQ (2 dep) or SWR (2 dep).

[@animelafuerza]

@@SandraWantsCoke Technically yes, actually no. While it is possible to just do a POST request, I combine apollo with GraphQL Code Generator, that way I can have the same schema I have in EF and I don't have the need for any casting. The moment I do something like useMyNamedQuery(params: { whateverINeed }) I have the object ready. I know I can define my schema manually and that I can create those functions, but, having a single .graphql file which generates my query functions is excellent for quick development.

[@animelafuerza]

@@Salantor and this is why you want as fewer dependencies as you can get away with (and also use a framework like NextJS). While it is true that a single package can have 10s or even 100s of dependencies, having a ton of dependencies is just calling for trouble, this is true for any programing language (like 100s of pip libraries, Nuget packages, dlls, ....).

[@Martinit0]

What's the name of that Yahoo i18n library?

[@PoeticLogic]

Angular was built for enterprise applications and addresses/fixes all the problems he experienced. They literally shot and killed their golden goose right off the start because they thought it was going to be deprecated 😆

[@paulholsters7932]

I am building a no code platform based on Angular to use for exactly these type of enterprise applications. Very interesting!

[@hungrymusicwolf]

16:25 Compromising is terrible practice for cooperative choices. You hear everyone out to find BETTER ideas, not give up the good ones because the other guy doesn't like it. It's why you don't vote on half a law in a parliament because one guy didn't like the other half. You vote on the whole law and if it's good enough you pass it. Minor amendments can also be voted on, but you don't "compromise" on half the law. At that point you might as well remove the damn thing. (The requirement to not compromising is of course that it isn't horribly a stupid law in the first place. In that case it's just politicking to get as much of it out of there to minimize damage, but that's more just power plays in democracies than the actual democratic process in a team).

[@Slashx92]

7:25 the "lets load a library" for everything is very "we are backend/.NET/etc engineers and for the web we just load kbs of js for anything". Literally inexpert people thinking they are experts because they have a zillion years doing WPF. But ask them about anything web related and they implode

[@codepluggg2875]

How do you produce so much content - have a full time job - and a family???

[@angryanonymous4082]

Asking the real questions here, lol. Who cares about that React crap?

[@TheMrChugger]

I love your takes, because you're a similar age as me, and I get the whole 'I've seen all this shit before, and it's just funny to me now' vibe you have

[@Matt23488]

Building JavaScript is a GOOD thing... Yeah it technically slows down development on the surface, but a build step means you get errors, which would otherwise happen at runtime. Even though technically it's not needed, it improves the experience greatly.

[@genechristiansomoza4931]

It may require more dev time but once done it is future proof because there is no dependency.

[@eduardofcgo]

These errors should be cough in the tests anyway. Since when you expect to catch serious errors building an interpreted language without static types

[@kuhluhOG]

So, this seemed to me like he wanted to use a "library" which is known for regularly changing how it does stuff and regularly deprecates and even removes stuff in what seems like an industry application (I am using "industry" here as a sign that it's a subset of enterprise applications). So, he made one crucial mistake: He did not take into account stability. In industry applications your dependencies should have an API (and possibly ABI if it's a concern for your language) stability promise of at least 10 years. If you go with less, stuff like this happens. They just move way too slowly. When choosing a library, you must ask yourself "Is it likely, that I can theoretically go in 10 years and update the dependency from the version I have today to the one in 10 years without touching my codebase without anything breaking?".

[@tylerbrown1457]

I mean, web based technologies in general change and evolve rapidly… there aren’t many web based tools out there that could achieve this, you’d have to go straight vanilla HTML, CSS, and JS and forego all the benefits of modern web technologies. Do correct me if I’m wrong. Just seems like it would apply more to like the far back backend/infrastructure that wouldn’t be user facing.

[@kuhluhOG]

@@tylerbrown1457 I obviously mean "regularly changing" and "regularly deprecating" stuff in relation to other web technologies.

[@ra2enjoyer708]

10 years ago was 2013, aka IE11/Java 8 times, hope you'll enjoy having to work with a java 8 web server in the current year.

[@kuhluhOG]

@@ra2enjoyer708 sure, it's not nice, but it's something your customers excpect heck, in some industries they expect even more and if you don't provide that, guess what, they won't be your customers in the future

[@michaelschmid2311]

i usually just try to adapt to coding styles from what i see in the existing codebases, only using new features of libraries when i am still at the start of a project and then sticking with that.Ofc updating libraries for security reasons but its just way easier to maintain this way. unless it gets unsafe but then we will have to rewrite all components. or if there is actually a huge advantage to using the new features. But ive never worked in projects with more than 10 contributors before sooo...

[@stuvius]

I never want to work with React again and this helped convince me even more. Svelte is life now

[@lukewu7637]

To be fair, this seems more like a problem of Builder/Bundling setup than framework choice. Encounter similar issues with HMR and bundling with Webpack. Migrated to Vite + React architecture and it becomes blazingly fast. But these will always stay true to any situation More lines of code to write (less libraries) = Faster bundling Less lines of code to write (using libraries) = Slower bundling

[@rocketpig1914]

Yeah I don't feel anyone has really put their finger on exactly what went wrong. i can imagine any js project becomes a dependency nightmare if you use enough npm libraries

[@billyhart3299]

The Marine corps does the informed captain thing too. It's the duty of the NCO corps to give their officer the most informed picture they can for the officer to make a decision with. As a corporal leading a small unit, you actually get the picture of the situation from your privates and lance corporals and make a decision.

[@lizard450]

I'm a c# dev primarily. I can do react. I did write my own DI framework for react when I was using classes, but abandoned it when hooks came in.

[@TheKlopka]

Polly in C# is amazing, and I'm assuming PollyJs is the same. It takes 100 or more lines of code to write a good fully functional decorrelated jitter back-off in my retry policy. OR I can use Polly and do it in 20 characters, and it probably is way more efficient.

[@alexgoncharov6430]

“Hooks are just complicated classes” - yes, exactly. It’s also much worse than classes, you now have to do something like memoization for a problem that didn’t previously exist

[@grimm_gen]

I feel like OOP people are really closed minded😂 I was doing alot of OOP when I started to code, and when I tried Elixir, my brain could not brain anymore, but after a couple of days it all made sense😂

[@OzzyTheGiant]

I can say the same thing about FP fanboys. They're all close minded. I use both, but when it comes to UI, which uses event systems a lot of the times, OOP solves the problem far better than a giant bird-shaped component tree of providers.

[@oscarljimenez5717]

@@OzzyTheGiant actully is the oposite. OOP people are the closed minded. Every FP person know OOP, but only few OOP people know FP. In my point of view, both are pretty nice, the problem i found is people trying to choose only one and doing in an extreme way. For example, Java o C# guys doing only OOP forever and ever.

[@MrAntice]

I currently work 100% in the javascript world nowadays, but have this hangup of never using stuff like lodash for doing object copying and parsing etc. Every time someone asks why I aparently hate lodash so much that I remove it whenever i encounter it, I just answer. Elixir thaught me recursion. Why would i use a big ass library to do something I can do myself in 5 to 10 lines of code? It's not hard to write recursive functions damnit. even if it's in javascript.

[@lucass8119]

@@oscarljimenez5717 Its a hard pill to swallow but OOP is the right tool for some jobs. React, for one, can't seem to acknowledge that. OOP lends itself SO WELL to UI construction its spooky. There is a reason every notable UI framework for the past 30 years uses OOP heavily. It just makes sense. I mean, for fucks sake, GTK is written in C, not C++ or Java, and they extended C with OOP concepts just so their framework design made more sense. They went out of their way to design an OOP type system and runtime called GObjects just to tack it on to C, of all languages. OOP has its place.

[@WHYUNODYLAN]

​@@oscarljimenez5717 yeah, I've heard some joke about how FP guys never actually talk about why they like FP, just why they hate OOP. Honestly kind of true lol

[@ragequilt_]

I understand the criticisms around C# but I wish Typescript would be more like C#. For large code bases I feel I don't have to rely on the devs to do the right thing.

[@mihaiungureanu3370]

Loved the decision / compromise discussion. Software Engineering is not politics

[@LostFelix]

At my first job, only ever app i programmed, was setup on a foundation of react and redux. I am happy that was the only app customers in 6 years.

[@homelessrobot]

Personally I think most usecases of closures in OOP are a code smell. Closures make the most sense when things that are already defined don't change. When this is true, the state of all of the variables reachable from the closure is constant for the life of the code associated with the closure, so you don't get spooky action at a distance. Otherwise, its probably best to be explicit about lexical dependencies as actual properties in a data structure, and not properties in an inscrutable external data structure known as a stack frame. A closure is pretty much entirely JUST a name space. Just one that isn't generally well specified. Most FP type patterns are better off NOT expressed as higher order functions either in OOP. Things get a whole lot clearer and easy to reverse engineer when you don't have to consider every variable reference as a dependency, and rather just the fields in an actual well defined and parsable data structure. You can of course still blow all of your limbs off with explicit closures, but you at least have the option of being explicit about dependencies.

[@aprilmintacpineda2713]

He literally just blamed technology for his poor decisions. He probably has made these same decisions in the past and those projects are probably shit-show today, I'm sure he will make the same poor choices in the future because he never actually learned even after taking a ton of time contemplating for him to write this blog post.

[@LaLoses]

"You have to fight for what is going to help you in the future... ...If you don't fight for the future, the future already is going to happen and it's gonna suck a whole bunch."

[@KangoV]

As a Java dev, I never really think about this. I've just pulled in a java lib that is 12 years old. It just built and ran fine. I really feel for JS devs.

[@petarkolev6928]

Prime, first of all - I LOVE YOUR VIDEOS!!!!! AMAZING JOB!!!!! I have a question not only to you but to all of my fellow developers - how can be become proficient at many languages when I have two kids which are participating in 5 different types of practices, etc.? I am writing React for more than 7 years and I barely find time to read something new before bed and I am the living dead because my energy levels are almost equal to 0. Which makes me feel really bad because I do really love programming and I don't want to be so narrow proficient. I hear you talk all the time how one should strive to learn as many as possible. How? What's your suggestion, guys? Thanks in advance!

[@tempo5366]

Personally, I don’t think programming is any different to learning an instrument or doing sports or any other hobby. For me it has to start with a goal of archiving a certain thing and learning the stuff while trying to do that. For example: depending on the interests and age of your kids you could build something with them together, like Arduino, which is a very nice approach to learning C.

[@seeker4430]

It takes me close to double the time finish a video here as I pause and rewind to read the chats

[@jeremiedubuis5058]

Also to be honest, I have recently migrated very complex components from classes to function components, and to avoid performance issues you need to jump through a lot of hoops. When you need control over the event delegation function components kind of become a mess. When you start having to focus on performance refs are necessary and they are so much less straightforward than writing class properties.

[@tylerbrown1457]

Can I trouble you to expand a lil bit on this, if you have a moment? I’ve only been working with React for 3 years, I got onboard the React train right when functional components and hooks took over so they’re what I know best and I haven’t had any issues. Would be good to hear about it from someone more experienced with class based components. As I understand it, there are additional lifecycle methods with class components, but hooks cover the majority of use cases and you still have class based to use when you need tighter control.

[@jeremiedubuis5058]

​ @tylerbrown1457 you can get everything done with function components, and yes class components are still viable. It isn't about control but about the way some optimizations are just easier in class components. To give a simple example: in a function component if I need control over the event delegation I will add a listener in the useEffect hook and unregister it in the return fucntion. However if that listener depends on props or any type of external state I will need to add a dependency to the useEffect or useCallback, effectively redeclaring the listener function everytime the required props change and unassigning the listener and reassigning it. Working around this is tedious in function components. In class components I don't specify any dependencies, I just register on mount. The listener is a class method referencing class properties. If these properties change nothing happens but if the event is fired the state it references will be up to date. You can handle these issues in function components but it is way less straightforward. Most of the time you don't need to and function components are great but having fine control over the diff checking and rerenders is just harder with function components.

[@ra2enjoyer708]

What are you smoking? React delegates events by default, you don't need to write your own delegator logic for that. And if you think that passing callbacks is annoying, relying on indirect string references for your logic is even worse.

[@jeremiedubuis5058]

@@ra2enjoyer708 if you never needed control over your event delegation I'm happy for you. Yes in most cases the default event delegation is fine but if you ever need to work with drag and drop/drag selection distinct windowed lists (frequent updates across multiple components, with events affecting each other) you will probably need more control or juste create horrible performance. When elaborating any complex behaviour involving a large number of elements immutability will become a performance bottleneck. It seems like you barely read me and jumped to a conclusion. I chose to migrate to function components because I find them better in most cases but there are these specific complex cases where adhering to the encapsulation and immutability of function components will render performance optimizations tedious. If you don't see the benefits of statefulness and mutability don't use them but they do exist and implementing them with hooks is sometimes way more comvoluted than with class components.

[@basdfgwe]

Seriously, I don't understand the hate of Angular and everyone praising React. We had a similar situation and the choice was between React and Angular, but we didn't have an opinionated CTO. We ran a red team and blue team to a POC between React and Angular, react ended up having 5 devs for some reason and Angular had 2-3 (started with 2 and ended the poc with 3). The react team spent a lot of time trying to decide things and quite a lot of disagreement and rework, and angular team finished the poc with added features while they waited for the react team to finish their poc. The choice was really straight forward - it was angular. The CTO having an issue with Angular because of AngularJS being deprecated seems like the CTO should not be in tech.

[@piyushgandhi7959]

9:25 CTO should've backed facts and data, and not the team. The only source of truth should be data and nothing else, specially in the C Suite

[@Martinit0]

It wasn't even his own team, it was an outside dev shop. I was like "How about you get the devs suitable for the task instead of making the task suitable to OUTSIDE devs?"

[@Myiyk]

In React is almost impossible to setup nextjs with styled components and SSR together. After few years of programming in React i found it's incredible hard to create good components. With good api/props, and good compostable model to merge features together. Sometimes I just remember to old times programming with PHP and AJAX, how everything was easier.

[@Iscream4j0y]

We had a new hire try to pitch us react, after we told him we already did that and it literally could not scale and was not a fit for our project Laravel with blade templates and htmx while passsing off memory intensive tasks to Rust is a great way to go Stimulus JS for any special functionality, Tailwind CSS for styling

[@eyehear10]

I can't believe all of this technology was chosen to display essentially text in a grid/table format. CHOOSE BORING TECHNOLOGY PEOPLE!

[@jfftck]

How many left pad dependencies in that 600 MB?

[@cherubin7th]

React/JS just annoyed me, because when I changed the state, it secretly changed the props that initialized that state in useState. Turns out that both props and the state basically &mut to the same data. I miss Rust's ownership system here.

[@hi_im_julian_kirsch]

Somehow I completely missed the hatetrain for Angular. What exactly is wrong with it, especially in an enterprise environment? While I prefer using stores over services (i.e. Redux, Jotai and especially Pinia) and Vue over Angular, I believe the opinionated architecture of Angular removes the guess work, your faced with, when working with e.g. React. Everything has it's definitive place and it seems to be battle tested. The onboarding as a dev is easier, if you don't have to relearn a new architecture, that someone pulled out of his ass, when the application was initially two views and five buttons. So, what am I missing here?

[@sivuyilemagutywa5286]

It's not cool enough, I use Angular for apps, and use Vue or Astro for static websites.

[@mma93067]

Angular is fine. AngularJS being deprecated destroyed lot of trust on people who boarded that train early

[@sealsharp]

@@mma93067 I just googled when that was. 8 years ago. Between version 1 and 2 of something that is at version 16 now.

[@OzzyTheGiant]

@@sivuyilemagutywa5286 What a based statement! I applaud you sir.

[@OzzyTheGiant]

@@mma93067 same thing happened with Vue 3. They stopped supporting Class API and half the community left.

[@Tony-dp1rl]

I worry for an application or team that hasn't yet worked out what Business Logic is. Which it sounds like they haven't, if they think UI validations are.

[@firemyst9064]

Your point on teams making a decision reminds me of Parks and Rec when they make a painting together. One guy makes a comment about a camel being a horse designed by committee, i assume too much input and not enough direction.

[@nerdobject5351]

What took place in this article happens every day in every small to medium sized company.

[@Mattipedersen]

7:28 I think part of the problem is that you many new programmers who will start learning JavaScript Fundamentals using Libraries, such as jQuery, etc. This is exactly why I decided early on to stay away from JS Libraries altogether, if it could be done in Vanilla JavaScript and that methodology has served me well, as I am not entirely dependent on one library after another. Of course, there were some difficult times, being that the introduction of JS Libraries essentially poisoned the Search Engines in regard to standard JavaScript content. As a result, you now have to sift through a bunch of Articles that may reference JavaScript in the Header, but ultimately the code consists of jQuery or some other JS Library. It's quite obnoxious, to be honest.

[@getdown03]

There's a whole book about the "no-good-zone", it's called "The Simplicity Cycle".

[@luke-gamedevlearning]

7:00 - "WTF?" - While coding a scripting class in C# for fun. - I have observed that people who start as scripting and Scripting Languages cannot grasp Programming Languages or their solid and robust and strict-for-good-reasons syntax. I love how in your previously watched-by-me video you mentioned that anybody who programs in C++ is automatically sophisticated. That's a perfect polar opposite to all the scrubs today who keep thinking they are "programmers" because they code in languages like Python, etc. - P.S. The worst online post I ever saw was, I quote, "Who really knows if HTML and CSS are programming languages or not?" He didn't even include JavaScript with them. We need another ice age.

[@peterrowley2428]

A 5000 line function would suck the life out of anyone, regardless of language/framework/library

[@JohnDavidDunlap]

I've worked on perl functions which were bigger than that.

[@Fleebee.]

In vscode, if you hold command and click your function name you go to its source

[@tobiasvdp]

Redux is great for non transient data. However developers really overstate what is non transient. A list of items fetched from the api, that is prone to change should in no way ever be stored in state stores.

[@YuichiTKD]

Damn finally someone that knows how to use a store! But i still feel bad about using redux know for the kind o state that i use right now, context should suffice, but i would need some "dead time" to focus on the refactor

[@AD-wg8ik]

This channel really has changed the way I think about programming.

[@magfal]

You can make a perfomant grid in a react app, just outsource it to ag-grid

[@rankala]

I'm littlebit confused, 1200 dependencies and only 600mb? my node_module with like 50 direct deps is regualarly 800/900mb.

[@WillDelish]

I think frameworks being able to add more features vs having 10 different community libraries to choose from would be most ideal.

[@McFrax]

The moment some people get into completely different environment and they insist on bringing patters they are familiar with, instead of leaning into the new thing with curiosity, it can't end well. He was screwed from the get-go. I saw that first question about dependency and my reaction was basically "this is the moment to let go, these people won't allow you to make sensible decisions". And they didn't.

[@a.m.4154]

Glad to see someone finally credit Deitel & Deitel.

[@Apoxtle]

newbie question> what is the safest framework for enterprise web apps?

[@jvanderberg]

I built highly performant React applications that were dense with data, including data tables with tens of thousands of rows. We used Redux. The only performance issues we had were related to poor design (large, blocking, client side computations - bad, don't do this). React isn't slow. Are there other frameworks that are faster? Sure. Does it matter to most users? No. React is more than fast enough.

[@komicproductions3887]

Damn, as I watched this video I felt the pain of this guy... I think Angular indeed would have been better for his case