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.
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.
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.
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
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.
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
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.
@@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.
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.
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
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.
@@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.
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.
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.
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.
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.
@@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.
@@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).
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.
@@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.
@@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).
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.
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."
@@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.
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
@@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.
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.
@@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.
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.
@@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.
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
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.
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.
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.
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.
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.
For migrating a WPF application to web tech while maintaining the same developer team Angular is an obvious choice and I would have made the customer give me in writing that he doesn't want to use Angular despite my recommendation.
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 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.
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
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.
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.
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.
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
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.
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.
@@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.
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. 🤦♂️🤦♂️🤦♂️
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?
@@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.
@@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.
@@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.
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 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.
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 ;)
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.
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.
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.
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!
@@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.
@@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, ....).
What possesses you to highlight everything _except_ the first and last characters of the thing you're trying to draw attention to? Can't be a skill issue because you do it consistently, every time, and don't miss. So what's the purpose?
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
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.
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.
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
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?".
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.
@@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
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
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
My team also switched from Webpack to Vite for our React project. The difference in build time was night and day. Vite has a lot of pre-configured optimizations out-of-the-box that have to be manually applied in Webpack.
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?
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😂
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.
@@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.
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.
@@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.
@@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
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.
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
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.
@@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.
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?"
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
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.
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
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
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.
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).
for the roadblock 1 : well he is sure is a nice man when he talked to the .NET team me however i'll be yelling : - i dont give a damn what you think about my stack or my fonctional style programming your team is the one who built a .NET app that we're trying to migrate away, there for your opinion is invalid - just google "how the F can i open a npm style project in Visual studio" is not that hard - well if you think you could do it better with all of those suggestions and you seem ALL knowing why do you need me for ? i'm sorry but that conversation triggered some PTSD in me , i know he is wrong in choosing React for this project but he should stand up for him self and act in the benifit of the project even if the CTO dosn't agree at least you could say "i TOLD YOU SO"
While getting fired might be extreme, this guy did make a junior dev mistake. He didn’t choose a stack that was established in the organization. A senior dev abandons their own preferences, starts from the established stack then drives it forward. A senior dev does not develop in a vacuum (ie. Cowboy)
Angular is nigh impossible to customise. If you are you looking at doing anything more complex than your typical material-styled CRUD forms, you should go React or maybe Svelte,
@@merodach566 Angular is just a tool for reactivity on top of the standard web apis like any other frontend frameworks. Angular itself has nothing to do with Material UI. Don't spread rumors.
TBF to the author and their team those build perf issues are just classic React webpack + SASS build hell. That combo was notoriously bad on large projects and what was eating the heap. Vite and dumping SASS for PostCSS with polyfills has been a game changer.
Retired COBOL programmer. Worst coding mistake, back in 1981, first year out of college was writing a new payroll system for the local school district. Ran the payroll process and all the checks had wrong amounts. Bad. VERY bad. Stayed up all night at the computer center fixing it so that everyone had their proper checks the next day.
What's most concerning to me is that some people have the misconception that you need to use a gazillion dependencies in an 'enterprise project' when it's really the opposite. The more a company is concerned about stability and security the fewer dependencies it wants. I recently had an interview with a bank for a Java dev position and they're not even using Spring, not to mention any of these JS frameworks and their bloated ecosystems.
I feel the same, when learning in bootcamp, i was in charge to made a functionality using react and redux , after fighting a week I made it work. the problem… not me, not my student team, nor the instructor were able to understand why it was working, so was bad code. but was funny as student.
That's what happens when you choose a library that gets used as a framework...messy project, no structure, it's far west baby! And as it has been stated, react doesn't work on its own (because it's a library) so it needs other 200 libraries to cover specific things and as it also has been stated again, you can't pass knowledge from one project to another, each project using react is completely different
Please tell my employer. I want to post this video on teams but I'll be shouted down by a few React Cultists, and management won't understand any of the debate.
The CTO is wrong for hiring a JS dev to be team lead for a .NET centered project. Js has no standards besides the ones they have adopted from the outside. Too many JS fanboys out there that dont possess enterprise skillsets. Facts sucks, but no one would be using React if not for FB who barely uses it itself. Too many shat on Java but nvr used it and constantly crap on C# but nvr worked on enterprise apps. Alot of lip service from those that really only work for the web instead of being a real engineer.
"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."
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.
Hmm... jQuery is terrible now? Wow... so glad I never went beyond tinkering with it. What... Angular is terrible now? Wow... so glad I never wasted time learning it. Umm... React is terrible now? Wow... so glad I never went through that React bootcamp I was gonna do. So... htmx is great now? Hey... I'm never gonna get any skills if I keep waiting for the perfect thing.
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.
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
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.
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.
@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.
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.
@@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.
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!
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.
OF COURSE there's a name for it, how could there not be? The irony is that he managed to perfectly recreate the chart (albeit inverted) without ever knowing what the median voter theorem is (AFAIK).
@@cristianbiluno, Angular is pretty decent choice for a big enterprise app, The standard way of doing things is a great feature when working with a big team.
@@cristianbiludisagree on rxjs. On a project I worked on it made everything harder. Strange bugs no one (except me) was able to debug. No one understood it really.
What is it with JavaScript developers, especially React developers and being really good at making everything way more complicated Bro it's just a bunch of forms
Prime says he hates "React" yet his name is "Prime Reacts", Curious
2024 ThePrime Svelte?
ThePrimeVues he doesn't React
ThePrimeVuesSvelteVideosAndHasAngularOpinionsOnThem
Sus 😮
@@mauro--1521😂
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.
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.
eqv? and equal? Is the only distinction required.
@@MrAntice Don't ever ask a Lisper about eq, eql, equal and equalp.
@@MrAntice just don't use ==, bro
@@majorhumbert676 That's what I always say too when anyone asks why there are only ==='s in my code.
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.
This is the problem with weak leadership.
To many cooks, resistance and to much planning without working on a minimal viable product.
@@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."
@@cariyaputta personally I think you can do allot of the planning building a mvp or prototype and this can also help convince people.
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
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.
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
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.
@@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.
sometimes fetch() and promises can be quite a footgun so sometimes i use axios for that @@DEVDerr
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.
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
whole problem was .Net had nothing to make a SPA website for many years.
Blazor is great
Or use Angular. It is structured such that traditional Backend folks with OOP feel right at home
Blazor sucks IMHO, it's great until it's not and when it's not there's nothing documented about it.
Blazor sucks too much.
27:36 At risk of starting a flame war... I've never seen a Javascript problem that is fixed by more Javascript.
Yeah it's usually fixed using the bash command "npm install ..."
There should be a law that goes something like "You cannot fix the wrong abstraction by using that wrong abstraction."
@@hypergraphicyeah, it's called "two wrongs don't make a right, they just get you going backwards. Three lefts _will_ make a right, though."
you fix it by including jquery actually
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
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.
@@IvanKleshnin Agreed, such sheep culture. Can't think for themselves
React Devs has no brain they are connected in one network
Yeah, because both are libraries 🫣
@@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.
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.
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.
Not only did they reinvent html, but the dom was too slow, so they made a new dom in JavaScript.
now we have slow javascript
React will reinvent Javascript soon enough
@@Kunal70006 reactscript?
@@Kunal70006 Isn't that JSX already?
@@Mr_Yeah nah jsx is more like a template not a language
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.
If you are in NA or Europe then it is low. If get paid that much while working in India I am rich.
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.
@@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.
@@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).
I get 25$ an hour in UK, so yeah 40$ sounds great
We don't want to reinvent the wheel, so let's decide which tools that reinvent the wheel to base our entire project on
😂😂😂
That's the whole point of not reinventing the wheel... It takes time, time you 9/10 times don't have.
This is the way
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.
Exactly
That whole “teams are unable to make a decision” is a mood. It’s why I left my last job
its real man. it hurts so much
Accountability without Authority = Bureaucracy
Authority without Accountability = Totalitarianism
Need the balance of both.
They now can make decisions
@@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.
@@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).
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.
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."
Yes, better to call it barebones, or "no batteries included".
@@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.
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
@@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.
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.
wpf is for desktop apps i think, they wanted to create a web app.
I remember WPF, it was actually pretty awesome to learn and to use.
WPF is great, but it is exclusively desktop and only works on Windows.
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.
@@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.
The only problem with 'OOP' is everyone forgets to add the 'S' at the end (OOPS)
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.
🤓 🤡
Another web dev opinion. Be an engineer and utilize concepts that make you understand what your getting into.
The only people that do OOPS are those who can't organize their code.
@@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.
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
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.
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)
Svelte❤
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.
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.
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.
Consider the basic idea that there are shit developers out there
He didn’t get nearly fired for react, he got nearly fired for letting his team write OOP inside React
why not ?
that is just one of the many problems there
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.
@@scvnthorpe__ not sure if I agree; I’d love to hear more
You shouldn’t use class based components, OOP is fine.
For migrating a WPF application to web tech while maintaining the same developer team Angular is an obvious choice and I would have made the customer give me in writing that he doesn't want to use Angular despite my recommendation.
Create a paper trail. That’s really good advice. When it blows up later you pull out the receipts.
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.
What does OTP mean?
@robolist2277 one-trick pony, I think
@@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.
@@braxpark Obviously The Poser
@@erifetimone tiny penis
27:50 "I have only one rule: New is always better." ~ Barney Stinson
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
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.
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.
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.
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
"...at $40/ hour. Man you got some cheap developers there."
Me making $28.85/hour: 😭
me, with 3 years experience, making 10USD/hour....
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.
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.
@@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.
@@mornwind318 it really isn't anything easy. Check out the issue Integrating React components #1970
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. 🤦♂️🤦♂️🤦♂️
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?
@@buc991 Web dev is reinventing the wheel every year...
@@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.
@@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.
@@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.
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.
You forgot /s
Love Angular. The seperation of concerns is implemented nicely - meaning view templates, script and styles are loosely coupled.
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.
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.
@@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.
I’ve been needing this man’s commentary in my career, like a mentor ❤
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 ;)
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.
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.
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.
you don't need apollo, you can just make post requests for graphql
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!
@@Salantor ez, unistall redux-saga. Use RQ (2 dep) or SWR (2 dep).
@@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.
@@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, ....).
I'm slowly descending into this hell at my own workplace. Definitely feel for the dude
What possesses you to highlight everything _except_ the first and last characters of the thing you're trying to draw attention to? Can't be a skill issue because you do it consistently, every time, and don't miss. So what's the purpose?
Probably trash ai in the highlighting feature. It’s even worse in vscode
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
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.
It may require more dev time but once done it is future proof because there is no dependency.
These errors should be cough in the tests anyway. Since when you expect to catch serious errors building an interpreted language without static types
24:22 600MB of dependencies?!? And I thought my 70MB Java web application was too big.
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.
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
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?".
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.
@@tylerbrown1457 I obviously mean "regularly changing" and "regularly deprecating" stuff in relation to other web technologies.
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.
@@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
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
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
My team also switched from Webpack to Vite for our React project. The difference in build time was night and day. Vite has a lot of pre-configured optimizations out-of-the-box that have to be manually applied in Webpack.
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?
It's not cool enough, I use Angular for apps, and use Vue or Astro for static websites.
Angular is fine. AngularJS being deprecated destroyed lot of trust on people who boarded that train early
@@mma93067 I just googled when that was. 8 years ago. Between version 1 and 2 of something that is at version 16 now.
@@sivuyilemagutywa5286 What a based statement! I applaud you sir.
@@mma93067 same thing happened with Vue 3. They stopped supporting Class API and half the community left.
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😂
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.
@@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.
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.
@@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.
@@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
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.
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
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.
@@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.
@@HyuLilium that's not entirely true IMHO, what is wrong is the complete abuse some devs does with OOP
@@NikPiermafrost OOP sucks, just admit it. Have an opinion for god's sake
@@majorhumbert676web dev tier opinion
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
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?"
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
I gotta say as a Javascript dev I feel the same when I have run-ins with Java. I despise it
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.
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
As a java developer, i hate having to touch that pajeetlang, not that JS is any good, both suck
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
I'm so happy to take on the features that either don't or barely hit the front end react
How do you produce so much content - have a full time job - and a family???
Asking the real questions here, lol. Who cares about that React crap?
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.
Teams of people making decisions, nothing will happen... yep too many chefs in the kitchen.
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).
How many left pad dependencies in that 600 MB?
I am building a no code platform based on Angular to use for exactly these type of enterprise applications. Very interesting!
for the roadblock 1 : well he is sure is a nice man when he talked to the .NET team me however i'll be yelling :
- i dont give a damn what you think about my stack or my fonctional style programming your team is the one who built a .NET app that we're trying to migrate away, there for your opinion is invalid
- just google "how the F can i open a npm style project in Visual studio" is not that hard
- well if you think you could do it better with all of those suggestions and you seem ALL knowing why do you need me for ?
i'm sorry but that conversation triggered some PTSD in me , i know he is wrong in choosing React for this project but he should stand up for him self and act in the benifit of the project even if the CTO dosn't agree at least you could say "i TOLD YOU SO"
While getting fired might be extreme, this guy did make a junior dev mistake. He didn’t choose a stack that was established in the organization. A senior dev abandons their own preferences, starts from the established stack then drives it forward. A senior dev does not develop in a vacuum (ie. Cowboy)
What’s wrong with angular? I’m a java developer backend and I’m thinking about switching to angular instead of react
Angular is nigh impossible to customise. If you are you looking at doing anything more complex than your typical material-styled CRUD forms, you should go React or maybe Svelte,
@@merodach566Good advice, but 99% of enterprise work is some sort of business process CRUDdy service.
@@merodach566 Angular is just a tool for reactivity on top of the standard web apis like any other frontend frameworks. Angular itself has nothing to do with Material UI. Don't spread rumors.
Damn, as I watched this video I felt the pain of this guy... I think Angular indeed would have been better for his case
TBF to the author and their team those build perf issues are just classic React webpack + SASS build hell. That combo was notoriously bad on large projects and what was eating the heap.
Vite and dumping SASS for PostCSS with polyfills has been a game changer.
They just had devs that didn't know the tech stack
Retired COBOL programmer. Worst coding mistake, back in 1981, first year out of college was writing a new payroll system for the local school district. Ran the payroll process and all the checks had wrong amounts. Bad. VERY bad. Stayed up all night at the computer center fixing it so that everyone had their proper checks the next day.
What's most concerning to me is that some people have the misconception that you need to use a gazillion dependencies in an 'enterprise project' when it's really the opposite. The more a company is concerned about stability and security the fewer dependencies it wants. I recently had an interview with a bank for a Java dev position and they're not even using Spring, not to mention any of these JS frameworks and their bloated ecosystems.
i think this is the root of the problem.
There's a whole book about the "no-good-zone", it's called "The Simplicity Cycle".
It sounds like power bi
A 5000 line function would suck the life out of anyone, regardless of language/framework/library
Why is React a bad choice when it comes to displaying large amounts of data?
It doesn't handle table transformations efficiently due to a lack of optimization resulting from it's architecture(i.e. use of Virtual DOM, etc.).
@@hughmcateer3369 Have you heard of react-virtualized? Presumably it hands that issue. Is it good?
Such a good commentary. Dude, this is therapy :D
Hot take, vanilla JS is really powerful and easy to work with these days and there is rarely a need for any framework. Change my mind.
I feel the same, when learning in bootcamp, i was in charge to made a functionality using react and redux , after fighting a week I made it work. the problem… not me, not my student team, nor the instructor were able to understand why it was working, so was bad code. but was funny as student.
"Isn't it fun to solve HTTP in javascript?" GOTTEM!
That's what happens when you choose a library that gets used as a framework...messy project, no structure, it's far west baby! And as it has been stated, react doesn't work on its own (because it's a library) so it needs other 200 libraries to cover specific things and as it also has been stated again, you can't pass knowledge from one project to another, each project using react is completely different
Please tell my employer. I want to post this video on teams but I'll be shouted down by a few React Cultists, and management won't understand any of the debate.
@@Daijyobanai You haven't mentioned which cult you ascribe to, for some inexplicable reason.
It takes me close to double the time finish a video here as I pause and rewind to read the chats
The CTO is wrong for hiring a JS dev to be team lead for a .NET centered project. Js has no standards besides the ones they have adopted from the outside. Too many JS fanboys out there that dont possess enterprise skillsets. Facts sucks, but no one would be using React if not for FB who barely uses it itself. Too many shat on Java but nvr used it and constantly crap on C# but nvr worked on enterprise apps. Alot of lip service from those that really only work for the web instead of being a real engineer.
"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."
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.
What took place in this article happens every day in every small to medium sized company.
Hmm... jQuery is terrible now? Wow... so glad I never went beyond tinkering with it.
What... Angular is terrible now? Wow... so glad I never wasted time learning it.
Umm... React is terrible now? Wow... so glad I never went through that React bootcamp I was gonna do.
So... htmx is great now? Hey... I'm never gonna get any skills if I keep waiting for the perfect thing.
After getting fed up with the slow speed of next, I tried nuxt and entered a very fast and pleasant development experience in the new world.
Could you elaborate
Here's an anecdote for you: Most things in JS are just complicated classes
Nothing in JS is classes. Just functions and closures
Classes are syntactic sugar in JS
@@MichaelKire JS function is an object
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.
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
Now hate react also 😂
i come here to get motivated, i walk away in awe of how absurdly insanely knowledgable this dude is
Blazor probably would have been the best choice for this company.
I don’t know if that was true 5 years ago.
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.
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.
@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.
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.
@@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.
Classic "Xyz-agen reads a article".
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!
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.
Make sense. React is legacy at this point.
I didn’t expect a Prime video explaining the Median Voter Theorem 😂😂😂
OF COURSE there's a name for it, how could there not be? The irony is that he managed to perfectly recreate the chart (albeit inverted) without ever knowing what the median voter theorem is (AFAIK).
skill issue
14:12 When everyone has a hand on the wheel you're going to crash.
Angular is pretty good
Pretty good at overcomplicating everything. The only good things about it are typescript and rxjs
work at a corpo and you'll know why its good @@cristianbilu
@@cristianbilu and who is saying that? A React dev? :D
@@cristianbiluno, Angular is pretty decent choice for a big enterprise app, The standard way of doing things is a great feature when working with a big team.
@@cristianbiludisagree on rxjs. On a project I worked on it made everything harder. Strange bugs no one (except me) was able to debug. No one understood it really.
“Not every method needs a namespace”. Oh boy the C# is gonna pull out their pitchforks on this one
I started out on frontend.
Then I needed to learn React.
I ran screaming to backend and never looked back...
I never want to work with React again and this helped convince me even more. Svelte is life now
What is it with JavaScript developers, especially React developers and being really good at making everything way more complicated
Bro it's just a bunch of forms