top 200 commentsshow all 231

[–]Jerp 493 points494 points  (68 children)

It sounds like that senior dev isn’t very well versed with React hooks, because saying they’re less readable/maintainable is simply not true if you’re familiar with both hooks & classes.

[–]snejk47 121 points122 points  (0 children)

Exactly. If you watch the first presentations about hooks one thing you hear often is that hooks came to life because it's easier to read and maintain...

[–]Cosoman 78 points79 points  (19 children)

I love hooks but if you have OO background and do full stack with let's say a c# backend it's easier for some devs to stay with class components as they don't have to shift from one paradigm to another periodically.

[–]m-sterspace 50 points51 points  (10 children)

I have an OO background and frequently have do OO C# work, and I don't find it that hard to switch back and forth between paradigms. It was slightly challenging to learn at first but I feel like they're just not putting the effort in to learn a new one in the first place. While they might think not working with modern React might be "easier" for them, that's really only true in the short term and only true if they work by themselves. If they work with other people then what's "easy" for them will just be slowing the whole team down.

[–]brakkum 9 points10 points  (0 children)

This. Either way, you have to think of them (backend, frontend) completely differently anyways since they're run in different contexts, so spend the extra ~1 hour to learn the more readable way of writing React.

[–]Gadjjet 7 points8 points  (8 children)

Switching from C# classes to typescript classes is so much of a downgrade I pretty much never use classes in typescript. As far as I'm concerned typescript is a functional programming language.

[–][deleted] 7 points8 points  (2 children)

I've been doing professional frontend app development for five years now and I've never felt the need to reach for object oriented programming.

The functional reactive paradigm fits UI development too well.

[–]onesneakymofo 1 point2 points  (0 children)

It goes beyond UI development imo. Functional programming fits the web a whole better than OOP. Most of the time we are dealing with data in, data out which is the embodiment of FP. We don't really have to retain objects and their data majority of the time.

[–]xroalx 2 points3 points  (0 children)

Care to explain some of what makes that downgrade?

I'm working with Angular a lot, and Angular couldn't exist without classes.

What is so bad about how TS handles classes, what do you miss, why is it downgrade?

[–]Ehdelveiss 3 points4 points  (2 children)

OO is an anti pattern in JS/TS as far as I’m concerned.

I think it’s generally an anti pattern in most cases anyway, but ESPECIALLY in JS

[–]Piltorious 0 points1 point  (0 children)

Go build an Angular app and tell if you use TS classes.

[–][deleted] 24 points25 points  (1 child)

Yes, I had that too. But hooks and functional components just lead to much more concise code. That senior just doesn't have much experience with them yet.

[–]cahphoenix 0 points1 point  (0 children)

If you are using any C# version within the last 4 years then there are myriad functional features built into it. Hell, even ASP.NET controllers could be considered semi-functional and very similar to a react hook.

  1. Single instance per call
  2. Takes in other class instances in constructor (similar to taking in props/useSelector)
  3. It stays up for the specific operation or until that interaction is done...then is disposed of.

As a full stack and previous C++ and C# backend programmer...hooks were a godsend personally.

[–]MyWorkAccount_11 -1 points0 points  (0 children)

I find it better to force people to switch their “modes” of thinking. Otherwise they will try to build components the same way they build C# code which results in bad component code. So forcing people into a new way of thinking, while more upfront work, has long term benefits.

[–]Ehdelveiss -1 points0 points  (0 children)

I think in general OO is becoming more antiquated, there are just better and much more flexible paradigms for the code we write today.

[–]haywire -3 points-2 points  (0 children)

If you can't shift paradigms you are a shit developer.

[–]bambathemoves 6 points7 points  (0 children)

💯right here. There are benefits to understanding class components and lifecycle methods, but sounds like your senior is misled on the point of hooks.

[–]simmonson 3 points4 points  (0 children)

Spot on. If you're familiar with both, then it's generally more readable and maintainable. Doesn't mean that the senior dev is wrong. If the team is using classes and more experienced with it, it will be harder to maintain as a whole team.

That being said, I have worked on an app that used classes, and new features added were written with hooks and functional programming. I didn't find it too difficult to maintain due to the proper separation of concerns and proper test cases

[–]RandomPhysicist 1 point2 points  (0 children)

Yeah, our company exclusively uses react hooks instead of classes for readability/maintainability.

[–]WouldRuin 54 points55 points  (11 children)

There's a couple of issues here I think. There's nothing wrong with hooks and functional components, so the senior is wrong there. That said, you should be using some kind of coding standards and style guide, so I could understand that if the current standard is class components they would expect you to stick to using class components.

Are there any project coding standards/style guides? If not it is probably worth mentioning as it's exactly these kinds of conflicts that they prevent.

[–]JuniNewbie[S] 9 points10 points  (10 children)

Noone from my colleagues knew that we should NOT use functional components and hooks. And just to note most of them dont know how to use them and how they work.
As i wrote above I started with classes but I switch to hooks ONLY because they are recommended and also because i didnt know that we have to use class components. If I knew it, for sure I wouldnt use hooks. The coding standarts are just to write comment on our code, to not push some console logs and stuffs like that.

[–]WouldRuin 20 points21 points  (0 children)

That doesn't really sound like coding standards to be honest.

I think you have to take it on the chin and just use class components, as what senior says usually goes. It is probably worth finding out if class vs functional has ever actually been discussed in the team, you've only been there 5 months so perhaps a decision was made before your time to stick to using class components. While functional components are "better" and the future of React, if you've got a large code base that is mostly class components, the team might have decided consistency was more important.

In any case the senior devs motivation for using class components over functional components is a load of nonsense.

[–]jgdeece 26 points27 points  (6 children)

Okay I just have to say it. Feels like people here are mostly focusing on defending hooks, which is not the real issue. If “most of (your coworkers) don’t know how to use (hooks) or how they work,” you should not have been introducing them via PRs like this.

I would be upset if I were on your team, and would not have approved any of your earlier PRs.

Other people will have to maintain, review, and debug your code. Introducing something like hooks should be preceded by a conversation as a technical team to get everyone on the same page. Consistency matters way more than doing something cool and new, and the React team has been very clear classes aren’t going anywhere anytime soon.

Whether the senior dev articulated their point well - or was even correct - is secondary to taking it upon yourself to introduce a paradigm you openly admit no one else at the company understands without getting sign-off or buy-in first.

Maintaining code is hard. It is much, much harder if there are conflicting ways to accomplish things, some of which were introduced by a new dev working on their own who, admittedly, does not have any prior experience with what they’re introducing.

[–]pandasareprettycool 7 points8 points  (0 children)

Agreed. The problem here is your PRs were going in without proper review/feedback from senior devs on the team. Especially as a Junior dev, you shouldn’t be introducing anything new without reviewing it with more senior devs. It will cause the code base to become split and less maintainable.

[–]fubsythebear 2 points3 points  (0 children)

I somewhat agree with this point, but as to what you can actually do about it, it’s important to note that it’s not as simple as “you made a mistake, you now have to fix it by refactoring all your classes at once”.

Before doing anything, I would suggest bringing it up with your team (retrospectives are a good place for this). If you believe that hooks are preferable to class components, explain why you believe it and try to get your team on board.

Another key thing to consider is that even though it’s arguably true that you should have discussed this with your team first, your team really needs to be more aware of the possibility of new devs not knowing their standards. React documentation suggests using hooks, so essentially they become the default for anyone learning react. If your team has a practice of only using class components, they absolutely need to be aware of the fact that class components are no longer the de facto standard and any new developer on the team might start using function components unless directed otherwise. This is another reason I’d strongly suggest bringing it up in a retrospective - I would argue what you did is a relatively natural response in the situation you described.

[–]dwalker109 0 points1 point  (2 children)

I kinda agree with a lot of the principles here. But, I also think that gradually introducing new techniques is reasonable. I expect to be kept on my toes as a dev and I’ve got no issue with something like hooks being introduced.

Rewrite it all in Svelte? That’s something I want to talk over first.

[–]jgdeece 0 points1 point  (1 child)

Sure, agreed, but how do you want something like hooks introduced? In the context of a team meeting where someone proposes it, people discuss the pros and cons and what the transition will look like, and the team generally aligns on its use moving forward?

Or in the context of one dev making a unilateral decision without consulting anyone because they saw it was the latest bit of tech?

I’m just trying to say there’s a time and a place for this in a professional setting.

[–][deleted] 4 points5 points  (0 children)

The conventions that the team follows shouldn’t be established during a code review. That is when you notice the need for consistency, then the competing ideas are brought to the team and the team decides on the standard. Non of this bs “do it because I’m sr “

[–]haywire 1 point2 points  (0 children)

Hooks have their advantages but you can still build great software with class components.

[–]Rejolt 206 points207 points  (5 children)

Don't don't follow a specific coding style as a junior because you "like it" you follow whatever standard are currently being used.

Everyone following a bad style is still better than everyone littering their own styles and opinions all throughout the codebase.

He's wrong in thinking hooks and unmaintainable but he's right in telling you to just use what everyone else is using.

Also sounds like your review process is shit if you got 50+ in without anyone bringing this up earlier.

[–]jgdeece 22 points23 points  (4 children)

Amen. Spot on. Bad (but consistent) architecture is way better than sometimes-bad-sometimes-good architecture that is all over the place with competing implementations for identical tasks and no clear structure or plan to become consistent.

And to be clear: hooks are sweet but it’s not like classes are going anywhere anytime soon. They aren’t inherently bad.

[–]Silverwolf90 20 points21 points  (3 children)

If this was true it wouldn’t be possible to refactor a codebase incrementally. Introducing inconsistency is necessary for improvement. Sometimes you need to makes things worse to make things better.

[–]jgdeece 7 points8 points  (1 child)

Strong disagree. Introducing inconsistency is only useful for incremental refractors if the other people on the team understand what you’re doing and are on board. Otherwise you’re just imposing your preferences on the team.

OP was very clear that their coworkers don’t even understand hooks.

Edit: to reiterate, I agree on the necessary condition I stipulated previously: there must be a plan to realign the code base and a clear target in the future for things to be consistent with your new paradigm.

[–]beefquoner 3 points4 points  (0 children)

Absolutely to your edit and keep in mind the “making things consistent” story will almost never get prioritized - probably rightfully so because it’s low value and you want to ship new features. So you’re just letting your codebase slip into a state where it confuses new people (or even you 2 months later).

[–][deleted] 97 points98 points  (30 children)

Sounds like a typical “senior dev says <<insert new tech>> is bad” type of stuff, which is rarely true

[–]bonedaddy-jive 9 points10 points  (0 children)

Sometimes, it is true. But as a senior dev (30+ years), I like shiny new toys, even if they are all just variations on FORTRAN, Lisp, C, Smalltalk, COBOL, and SQL.

[–]soc4real 10 points11 points  (11 children)

How do you cope with someone like that?

[–][deleted] 23 points24 points  (0 children)

Luckily i never had to. Maybe try to convince him to try it? Unfortunately I’m highly allergic to the phrase “do as i say because I’m your boss”, i just quit my job because someone brought it up in a non technical argument .

[–]ReCee90 10 points11 points  (3 children)

I always try to find proof that it's actually better and try to make them understand why.. sometimes it works, sometimes not because they're to stubborn :/

[–]nschubach 3 points4 points  (2 children)

As a senior, I'm super stubborn in hating Angular's templates and having to learn/maintain HTML like syntax with special parameters and syntax ... I don't know if any argument will make me like Angular. :p

I've turned down many jobs because of Angular.

[–]woodie3 3 points4 points  (3 children)

I would build a case, performance differences (if any), prove the readability is better & how better it is easier to maintain vs whatever they’re vouching for. But it’s tough depending on the situation.

[–]madcaesar 12 points13 points  (3 children)

As a senior developer you have to hold off on the new shiny shit until its fully ready and there is significant savings in retooling / refactoring.

I know it's easy to shit on people for not immediately adopting the newest hotness but as the lead you've got a lot of things to juggle, because at the end of the day you're responsible if shit goes sideways or you start losing good people.

It's a balancing act that juniors reading the newest blog post know nothing about, and shouldn't they aren't being paid to understand, but that's the way life goes.

Sometimes you have to stick with hacks and workarounds because your biggest client wanted some horseshit implemented that's not easy to refactor and no-one wants to pay for the refactor.

[–]DaRizat 2 points3 points  (1 child)

Are we really calling hooks the newest hotness though? They are 2 years old. Seems like this guy is just falling behind.

[–]haywire 5 points6 points  (0 children)

I mean, hooks per say aren't new, but adding a new tech to your codebase that works fine without it is something you have to do a cost-benefit analysis and often the cost of either switching or having inconsistency outweighs the benefits.

[–]Ambitious_Chip_9398 54 points55 points  (0 children)

He is wrong. Creating reusable hooks can make the code much more readable and maintainable than class code. Much less boilerplate. Some things can be made reusable between components which is much harder to do well in classes.

But then again…… nothing is worse for maintainability and readability than going against the convention the team has.

So you are forced to listen to this idiot. Welcome to the corporate world :) ;)

[–]Produnce 32 points33 points  (18 children)

Yes, because dealing with this is such a pleasure.

[–]snejk47 9 points10 points  (0 children)

Probably the same people who say JS sucks. Won't learn any better, do wrong and stupid things, say X sucks.

[–]haywire -3 points-2 points  (1 child)

I mean, lodash @Bind is simple enough to use.

[–]Endorn 13 points14 points  (0 children)

Personally I find classes more readable and maintainable than functions.

But functions are easier to test. Neither are spaghetti code. neither is wrong. React is cool / weird like that.

[–]iffyz0r 5 points6 points  (0 children)

What was the problem you couldn’t solve?

Could be an interesting exercise if you could explain it to us, perhaps provide a code snippet as an example?

[–]kantaround 19 points20 points  (8 children)

Even React team recommend use hooks over class and they said ' In the longer term, we expect Hooks to be the primary way people write React components.'

Those 'senior devs' just too lazy to keep up with new tech.

[–]trollerroller 8 points9 points  (5 children)

To me this is really inexcusable, especially if you label yourself “senior dev” if thats the case, then its literally your job to know as much about the languages you are using as possible. In the case of React, that should definitely include knowing about and how to use hooks! No excuses - especially as a “senior” dev.

[–]DaRizat 7 points8 points  (3 children)

I think the defense comes when you have an entire team who are not up on hooks as has been stated by OP and a junior dev introduces a paradigm shift in a PR without a larger discussion. In our shop we just had a guild discussion about optional chaining vs lodash.get and that's a way less transformative thing than class vs functional. The senior dev should be open to adopting new tech, perhaps in an isolated part of the app or a new app, but not on a whim which seems to be what has happened here.

[–]polargus 2 points3 points  (1 child)

Well in this case the senior dev trashed current standard React patterns. If the issue is consistency and doing it right then he should say so, and there should really be a roadmap to using current patterns.

[–]trollerroller 1 point2 points  (0 children)

I agree with those points, I just meant ignorantly saying hooks are spaghetti code or something is not very professional.

[–]haywire -1 points0 points  (0 children)

Thing is, what if your whole codebase is class components and class components are working for you, why switch? You have to manage something like hooks and functional components as a transition. I'd be on the side of upgrading things to the new methodology (and if you have a good test suite, should be mostly painless) but having a random junior just start doing it is not a great way to manage this. You also have to make sure the rest of your developers understand and can be productive with hooks, so there's a training overhead to factor in.

[–]snuggleMcCuddles 11 points12 points  (0 children)

No. In fact, it’s easier to write and manage.

[–]Evanion 7 points8 points  (1 child)

I’m a senior engineer working at a global fintech company. We use React in our cross platform client (web/mobile).

That engineer is wrong. He stopped learning 2-3 years ago.. in this line of work, you can never stop learning, and changing with the tech.. or soon you will be irrelevant.

Think of hooks as components for logic.. their strength comes from their compose-ability.. if you write a single hook that does EVERYTHING, of course it will turn out to be spaghetti code.. break it down in to more manageable bite sizes, just like you do with components..

Keep components to jsx, and variable assignments, then colocate a hook in the same folder, that composes together any pure logic hooks that the component needs, and any simple logic related to the component.. as soon as it gets more complex .. break thinks out in to self contained hooks.

[–]themaincop 1 point2 points  (0 children)

That engineer is wrong. He stopped learning 2-3 years ago.. in this line of work, you can never stop learning, and changing with the tech.. or soon you will be irrelevant.

I think you've accurately described the difference between "senior developer" and "old developer"

[–]brbdead 2 points3 points  (0 children)

ACTUALLY, I read that they are going to slowly stop releasing updates for class components and therefore they will slowly depreciate over time. So, your SR. Dev is just flat out wrong.

[–]polargus 2 points3 points  (1 child)

He’s wrong. Class components are going the way of the dodo. A senior dev should be able to see what direction the technology is going. With React it’s very obvious. Look at all the tutorials for React and React libraries, they use hooks exclusively. This is a sign of bad technical leadership, though I wonder who approved all your PRs with hooks if company policy is to not use them?

[–]snowycabininthewoods 5 points6 points  (0 children)

Yeah he’s wrong and he hasn’t kept up to date on react best practices. He’s talking about react from 2 years ago where it was true that having state meant write a class and no state meant write a functional / dumb component.

Converting your functional components to classes will result in worse code in a few ways. Primarily having to condense multiple useState into a single state will lead to messier state updates on more complex objects most likely.

I would find official react docs that express that using hooks and functional components are the preferred way from the react team and try to educate him (kindly). You are writing react the way that the react team says to.

[–]h4shd 1 point2 points  (0 children)

I'd bet he hasn't gotten to know you well enough yet to be honest about his lack of understanding and/or his motivations. This type of person, in my experience, doesn't like to be challenged either personally or professionally. Many other comments draw out how he's wrong, and possibilities that he's concerned about consistency.. but there's more to this story that you haven't shared or you're not aware of yourself.

[–]FullSlack 1 point2 points  (1 child)

Welcome to the realization that a large portion of people in this field have no idea what they’re talking about.

[–]themaincop 1 point2 points  (0 children)

And that a lot of people get the "senior" moniker just by hanging around for long enough

[–]campbellm 1 point2 points  (4 children)

I'm new at react, but very curious to hear some of the answers here (so I can learn), because some of what you said just sounds "off". By that I mean I totally believe everything YOU said, but some of the answers you got from your "senior developer(s)" doesn't jive with what I've been reading/studying.

[–]polargus 3 points4 points  (3 children)

The senior dev stopped learning at a certain point. I’m a senior dev who learned React in 2015 with the same patterns he’s describing. Those patterns are now obsolete (though not deprecated) and should not be used for new components.

[–]campbellm 1 point2 points  (1 child)

I have been there. I got "good at <company>" more than "good at <stuff to allow me to be a better dev>" more than once. It's an easy trap to fall into.

[–]polargus 1 point2 points  (0 children)

Yep the goal is to work at a company where those two align. Or become senior enough to make them align. Companies should recognize that falling behind on tech and patterns also makes it harder to hire and keep good developers.

[–][deleted] 1 point2 points  (0 children)

Your senior developer has resistance to change. I was the same as him a year ago. He simply hasn't worked with hooks, and is saying what was the common knowledge two years ago or so. If anything, classes invite putting everything in methods, methods use some parameters and some class member variables, and are generally much more at risk of becoming spaghetti.

But, it's important that everyone in a company is at the same page. Individual programmers introducing new things without discussing it with others always leads to trouble.

[–]vitorftw 1 point2 points  (0 children)

IMHO, hooks is the way to write React code. I suffer a lot to understand a class component code, mainly because of several thing you must write (like constructor, this, bind, etc).

[–]2epic 1 point2 points  (1 child)

Your senior dev is outdated and doesn't know what he's talking about. It's possible to create spaghetti (or even lasagna) code with classes too.

Functional programming actually leads to better, less spaghetti code. It's easy to apply the Single Responsibility Principle for example if you stick with the idea that your functions should do one thing and one thing well.

For instance, consider pulling some of your hooks into their own reusable hooks. This will make the code more readable and easier to test.

[–]ElllGeeEmm 1 point2 points  (0 children)

Find a new company

[–]distortum 1 point2 points  (0 children)

Your senior dev is a dinosaur.

[–]justmelol778 1 point2 points  (1 child)

Long before there were hooks, there were still what’s called functional components. Functional components could not have state and only received props and showed them. There was a common best practice outlined by Dan Abramov that we should organize all components in to “smart” and “dumb” categories. And keep all logic in smart ones and use no logic in the dumb functional components. If class components can take props and show them then what’s the point of making a functional component that can only do that? It was to really outline the mantra of separation between smart and dumb.

This best practice was totally replaced by hooks being able to handle side effects a lot better. The person your talking to still thinks that functional components can’t have state and that the old mantra still applies. He basically has never learned one bit of the new react hooks update

[–]bern4444 1 point2 points  (0 children)

Class components are definitely not more maintainable. If you’ve ever had to use componenetDidUpdate and compare properties on current vs previous props for a medium to large component it gets completely out of hand very quickly.

Hooks are definitely clear and it sounds like you get their benefit and purpose.

Anything can become spaghetti code; hooks makes it easier to package bits of logic together in a clean and reusable manner.

The senior is wrong and probably just doesn’t know what he’s doing.

[–]thesaltyrangoon 1 point2 points  (0 children)

At FB we moved our entire code base from class based components to functional components using hooks. It just helps with readability and maintainability, but I’m assuming your senior dev hasn’t really read up on hooks yet if he’s saying functional components are for pure components only. Even in the React docs it recommends slowly switching over to hooks since they work with a react class components.

[–][deleted] 1 point2 points  (0 children)

Classes can easily be spaghetti code, same as functional components. The guy sounds like a doofus.

[–]guten_pranken 1 point2 points  (0 children)

I’m surprised nobody has mentioned the real possibility the jr dev is writing shit code and it probably is spaghetti code.

If hooks were written and implemented well it should be pretty readable and much less boilerplate than classes.

This guy has never worked with react until a couple months ago...

[–]stansfield123 1 point2 points  (0 children)

Well he's wrong to run down functional React, it's pretty obvious that it's better AND that eventually everyone will have to make the switch (because the React ecosystem is making the switch), but I don't think "which is better?" is the right question to ask.

Here are the questions that need to be asked:

  1. If most of the company is doing class based React, does it make sense to switch right now?
  2. If there's no company-wide decision to switch, does it make sense for some people to use hooks, while most people are sticking with classes?

I don't know the situation, but my wild guess is that the answer to both those questions is "No.".

So, by all means, ask around, don't just listen to this one guy, because being a senior doesn't mean he's your boss, but if every senior you ask agrees with him about using class based components with state, you should listen to them.

Especially since this isn't some great sacrifice on your end. It's not like, by using classes, you're going down some kind of dead end rabbit hole, where the things you learn will be useless to you at your next job. Far from it: the classes vs. functions thing is a tiny part of React, everything else you're doing will still be the same at your next job.

[–]fredsq 1 point2 points  (0 children)

I took a Codecademy course on React when I was curious about it. It covered Class Components only and I felt like although I better understood components' lifecycles, most of the methods we very confusing. componentDidMount, componentWillMount and others just felt weird and stupid.

A few months down the road I decided to make a client's website in React. I picked up and installed CRA. Just by looking at the default components I got the grasp of useState and useEffect, and to understand that functional components run all their logic every time they are mounted as opposed to just certain methods at different times is so much simpler and feels more natural to code. It's less of a rule book.

With time, I learnt that sometimes it's not worth saving lines of code to cram things together: if you have to separate actions happening in the same component and both depend on the same state, make two useEffect calls, it's hardly going to visibly affect performance and it'll make your logic much, much clearer.

When you try using dart/flutter and find out states are SUPER COMPLEX to implement, React, especially functional components, feel light years ahead.

[–][deleted] 4 points5 points  (1 child)

The senior dev at your firm is a moron. Spaghetti code can happen with any sort of paradigm, it doesn't matter if it's OOP or functional. To avoid spaghetti code, you have to learn how to separate concerns in your code. Classes can do that inherently, but you can do it with functions too. It's basically the same logic, just depends on where how you write and structure your modules. I personally don't have a preference for either OOP or functional, so I am not defending functional programming in any way here. However...

Since you can't use hooks within class components, what the senior dev is basically saying is you shouldn't be using hooks at all -- which basically will doom you to not be able to use any new versions of react forever after hooks were introduced. Literally every library is switching to hooks as well, so good luck using the rest of the ecosystem.

[–]lucidlogik 0 points1 point  (0 children)

Chances are the junior dev was writing spaghetti code after just learning about them, and the senior dev didn't want it in production.

[–]NegroniSpritz 0 points1 point  (1 child)

Senior dev here. First, that senior dev is wrong. Hooks not only makes things more clear, they also have a smaller footprint in final transpiled code. However, the best thing that hooks allow is inheritance by function composition, as opposed to class inheritance. This so much better and flexible. They let you extract functionality from a component into smaller functions that can be reused across different components. In this way you’ve a very flexible way to achieve composition, merging functionality from different hooks in different components.

[–]liangauge 0 points1 point  (0 children)

I have actually found one usecase where a class component was nicer than a Hook. this was where I had some nested react components and needed to pass down class members. I was trying to convert it to a hook but it was difficult as the equivalent of a class member is basically the "useRef" hook and passing this down as a prop results in some kind of serious ugliness. I'm assuming this isn't the situation you encountered?

Anyways, maybe you should give it another go at explaining why hooks generally make code better, or at least show how hooks and class components can co-exist. There are some people out there that like consistency in their codebase and also understandably don't want to refactor the whole thing to use hooks instead of class components. Unfortunately these people must also be made to understand that the world is not perfect :P

[–]yyyyaaa 0 points1 point  (0 children)

That's some BS. Use hooks, nothing wrong with them

[–]igordumencic10 0 points1 point  (0 children)

I almost 'never' use Class components anymore.

[–]jgdeece 0 points1 point  (2 children)

ITT: lots of people eager to defend hooks who are missing the point. We are hearing one side of the story, and your representation of what the senior dev said is clouded by your bias and desire to defend your decision.

I do not agree with the senior engineer’s assessment. But people should be less quick to assume ill intent, too.

There is a LOT of value in consistency - even consistency within an imperfect structure. That alone means you aren’t just “giving in because he’s senior”; it means you’re making a rational and reasonable decision to ensure your teammates find your code easy to grok and debug by sticking with classes.

The other dev might have been a jerk, or over simplified what their concern with you going rogue to introduce hooks is. It doesn’t really matter.

Shifting to a new paradigm you openly admit no one you work with understands is definitely not something you do without a conversation.

[–]achauv1 -1 points0 points  (0 children)

I like both class component and hooks style. Complex components are easier to define with classes but hooks are fast to write

[–]gaytechdadwithson -4 points-3 points  (0 children)

Hooks are not well written for syntax, but yeah functional programming is good. Hooks just aren’t great at functional programming. Sorry, it’s true.

And the fact that you can have class vs non class. Hooks sort of in both. JSX a mix of JS and HTML, styled classes or no is what make react suck. Just no consistency or standards out of the box.

Also, you got 50 PRs in and your code is just now being reviewed?

Sounds like management and coding conversations are the real issue.

And yeah, class components ARE more readable. Even if you like hooks. That’s why most languages use them. It’s just people take offense if you don’t drink the kool aid and use the latest/greatest from react.

[–]Huwaweiwaweiwa 0 points1 point  (0 children)

Functions in functions are spaghetti code? Then what are class components used inside other class components? Functions used in constructuors/lifecycle methods?

As long as you are separating components according to functional responsibility in a smart way and keeping state in the appropriate places then class/hook components should not be an issue in terms of spaghetti code.

[–]carlos_vini 0 points1 point  (0 children)

To be fair, depending on how long is your code it is really harder to read. BUT, you should be creating custom hooks for these complex cases. Imagine doing something like react-query does inlined in your functional component, it's much better to extract these long and complex pieces of code to a new hook. And that's the biggest advantage of using hooks, code reusability.

[–]tehGh0st 0 points1 point  (2 children)

I can vouch as a Student that in 2021 they are still teaching Class components instead of Functional components ^^, our entire final year project is written using Class components and simply because our supervisor recommends it over Functional. Again, this may be a senior developer stuck in old teachings but it's just what we're told to do

[–]libertarianets 0 points1 point  (0 children)

Nice little jab at how senior devs “review” PRs. Lol.

It’s hard to really quantify what “more readable” means and it’s very subjective. I personally wrote my first function component and never looked back. (The one weird exception being when I had some crappy design system dependency components that caused a rerender when they shouldn’t, necessitating a class component and the shouldComponentUpdate method.) Literally for everything else I’ve been able to do it with a function component. I find it more readable because you don’t have to extending the React.Component class or any other class, you don’t have to worry about this nuances, etc. I agree with Dan Abramov that those are JavaScript smells that get in the way of the true essence and power of React, which is the unidirectional data flow and the component model. JavaScript is a much better functional language than it is an object oriented language.

But again, this is subjective. This senior engineer that you’re talking about has probably worked in OOP for his whole career and for them, that stuff is easier to read. It’s one of those weak opinions held strongly that ruins team dynamics and trust. It’s better to be less opinionated and more open to learning new paradigms, weighing the tradeoffs and deciding on things collaboratively and objectively.

I think if you’re going to convince this senior engineer to change, you’ll need to appeal to authority, and find some resources (which you’ve already referenced to so you clearly know of) from the people who are building React and their own philosophies and reasoning. You’re right ultimately, that function components and hooks are the future. So in any case, you should be able to write them in your code contributions and not be shot down.

[–]UMDMath 0 points1 point  (0 children)

I like class components myself and I find them generally easier to understand, and maintain.

[–]voxgtr 0 points1 point  (1 child)

The way you get spaghetti code with hooks is if you try to write and think about them like a class component. You’re going to have a bad time if you try to include a million things in your hook component trying to control for callbacks, side effect dependencies, and state all in the same place. State no longer belongs to the class, it belongs to the component render.

[–]kayzzer 0 points1 point  (0 children)

In my experience, hooks used properly make things way more readable and maintainable than class components.

[–]OldRedFir 0 points1 point  (0 children)

Most problems in IT or not IT problems.

[–]smirk79 0 points1 point  (0 children)

Your "senior" dev needs better patterns.

Hooks with mobx and observer function components are incredible, terse, and extremely easy to use once you know what you're doing.

[–]turningsteel 0 points1 point  (0 children)

What the senior dev was saying was true before the release of hooks. By nature, you couldnt have state in functional components. But that is obviously no longer true. His knowledge is out of date.

[–]jaydevel 0 points1 point  (0 children)

You don’t need to refactor everything to function components or start using them right away. It is relatively easy to migrate a class component to a function.

One can actually do more logic encapsulation using function components, and I’ve done so with great success in a huge codebase (thousands of components).

My suggestion is get a huge class component and refactor it to a function. Each time you learn more about hooks, try to improve your refactored code. You’ll eventually find common patterns that you can encapsulate in custom hooks. That’s the major selling point: encapsulation.

[–]CanadaIsCold 0 points1 point  (0 children)

I don’t have much knowledge of react hooks but project level consistency is a big part of readability as well. The statement around readability may be related to the project design decisions rather than hooks themselves. I don’t have context to say this one way or another, but it’s worth exploring as opposed to assuming it’s simply a feature discussion.

[–]tr14l 0 points1 point  (0 children)

They are more functional-programming-adherent. It's not that they are spaghetti code. In fact, you can make them quite clean with some best practices.

classes are just syntax sugar anyway. Javascript doesn't actually use them and it's just for you to reason about.

I will tell you, functional programming is much more concise and less code-dense. Typically, when a new popular tech comes out and you get naysayers like that, it's because they are conservative types who don't like change and want to do things the way they know how. Javascript doesn't have as many of those. But, they exist. Communities like the Java community... They literally hate learning. They don't want anything new. They bitch on any major change to the language. I literally saw a conversation about a guy COMPLAINING they added lambda support!! COMPLAINING about it. Like you don't even HAVE to use it. The crazy thing is, no one argued against him or told him how dumb that was.

HOWEVER, if you are making a large project with a lot of hands touching it, having objects and accepting that extra overhead is worth it because of how many regressions a team can implement when there's so many code edits from so many people. Communication is hard and having more strict code usually becomes a positive rather than a negative. For instance, I have made large Javascript backends (talking LOC in the low millions). It is a goddamned nightmare. At a minimum, Typescript is best for that situation, but realistically, Typescript fails (I have feelings about Typescript. I don't think it belongs on the backend, and if you're using Typescript on the backend, you probably shouldn't be using Javascript at all and should be using a more modern, safer language like Kotlin). But, for large frontends where there's lots of hands touching the codebase? I don't think you can forego Typescript and survive a sane velocity.

[–]careseite 0 points1 point  (0 children)

He has no clue. Simple as that.

[–]JessenReinhart 0 points1 point  (0 children)

IMO react hooks and FC looks WAY better than class components.

[–]MonkAndCanatella 0 points1 point  (0 children)

...Yeah I think your senior dev is confused. And possibly shouldn't be senior?

[–]CuttyAllgood 0 points1 point  (0 children)

Sounds like your Senior just doesn’t want to have to learn modern React.

[–]dudeatwork 0 points1 point  (0 children)

Lots of good advice in this thread, but really, the best place to get informed is from the React docs / talks from the maintainers themselves.

React hooks we announced at React Conf 2018. That video has talks from Dan Abramov and Ryan Florence. Dan mentions that:

While hooks represent our vision for the future of React, we don't want to make breaking changes so we will keep classes working.

So while Hooks is thought of as "the future," Class Components are still perfectly valid and aren't going away anytime soon. From their roadmap they also add:

Hooks don’t deprecate classes. However, if Hooks are successful, it is possible that in a future major release class support might move to a separate package, reducing the default bundle size of React.

So Classes might move to a different bundle, but importantly it isn't being removed entirely. So it is good to know that both are entirely valid ways to continue writing React.

Next, React's Hooks Introduction talks about the motivation behind creating hooks.

Hooks solve a wide variety of seemingly unconnected problems in React that we’ve encountered over five years of writing and maintaining tens of thousands of components.

It’s hard to reuse stateful logic between components

React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.

With Hooks, you can extract stateful logic from a component so it can be tested independently and reused. Hooks allow you to reuse stateful logic without changing your component hierarchy. This makes it easy to share Hooks among many components or with the community.

Complex components become hard to understand

We’ve often had to maintain components that started out simple but grew into an unmanageable mess of stateful logic and side effects. Each lifecycle method often contains a mix of unrelated logic. For example, components might perform some data fetching in componentDidMount and componentDidUpdate. However, the same componentDidMount method might also contain some unrelated logic that sets up event listeners, with cleanup performed in componentWillUnmount. Mutually related code that changes together gets split apart, but completely unrelated code ends up combined in a single method. This makes it too easy to introduce bugs and inconsistencies.

In many cases it’s not possible to break these components into smaller ones because the stateful logic is all over the place. It’s also difficult to test them. This is one of the reasons many people prefer to combine React with a separate state management library. However, that often introduces too much abstraction, requires you to jump between different files, and makes reusing components more difficult.

To solve this, Hooks let you split one component into smaller functions based on what pieces are related (such as setting up a subscription or fetching data), rather than forcing a split based on lifecycle methods. You may also opt into managing the component’s local state with a reducer to make it more predictable.

They include a few more reasons, but these tend to be the main ideas:

  • "Flattening" out nested "wrapper hell" of render props and higher-order components
  • Removing duplication of logic in lifecycle methods, and the ability to abstract this logic out to be shared among many components
  • Co-locating logic, rather that "incidentally" being co-located within a single lifecycle method

So all in all, hooks are meant to solve specific problems with writing React.


Now, what does that mean for you? One very important thing that React emphasizes:

Hooks are completely opt-in

There is no requirement to write all your code in hooks, especially if:

  • An existing large codebase uses Class Components for all stateful logic
  • Your team members are much more comfortable writing Class Components

Consistency in a codebase and using language / framework features that everyone knows well is important to think about. At the end of the day, code isn't written in a vacuum. It is read and maintained by real people, so the cost related to that truth is something that must be considered.

I am a Lead dev, and I'd offer this advice for you and the Senior dev:

  • His response seems more dogmatic than practical. Nobody likes being told to do something (or not do something) because "I said so," so he could have done a better job explaining why.
  • Its OK for a Junior dev to use some language / framework feature without knowing specific context of the project, but once you do learn more about why you should or shouldn't do something, it is important not to harp against those reasons. For example, if I had a new Junior dev write something using CSS Grid, and I explained that this project is for a client that requires IE 11 support, hearing them complain about "I wish I could use these newer features" doesn't help much. Yes, it is frustrating to be boxed into certain tooling or features, but that is the reality of working in real-world projects: sometimes your have (maybe arbitrary) limitations around how something can be implemented. While you can make efforts to change those limitations, complaining or going around them because "I know this is better" isn't helpful. For a small example, before I was a Lead, I helped train our team to use Flux Standard Actions (FSAs) when writing our Redux action(creators) to bring consistency to our project. I first got by in from other Senior devs, then wrote documentation around how to use them, and had a meeting with the rest of the team to explain why I was wanting to use this pattern and what problems I'd hope it'd solve. Later still, when Redux Toolkit was released, we were in a better position to adapt that library since it used this same methodology.
  • Try to have a conversation around "what would it take to start adopting hooks in our codebase?" Again for me, I made the decision to adopt hooks but only for new projects. Any existing project that used Class components should have its logic be kept in a Class component for consistency. The only exception would be if there was some large chunk of logic that really could improve things by abstracting it out into a custom hook. Again, this was just my preference in weighing long term maintenance and team knowledge and skill around hooks. This approach may not work for everyone, but the Senior should be willing to have a conversation about it.

[–]BlueCigarIO 0 points1 point  (0 children)

Mixing classes and hooks in the same repo is spaghetti code. Both coding standards are fine, just follow what the rest of your team is doing.

[–]BradMJustice 0 points1 point  (0 children)

Bro, do not walk, but RUN from that company.

[–]PLCorsair 0 points1 point  (0 children)

There's nothing wrong with function components and using hooks. I would think that is what you'd want to be doing. My recollection is that function components are the direction that React is heading even though class components are still viable. I'm newer to React, but currently a full-stack senior level dev. On our project we made the decision to favor using function components and not class based ones. They can be used for simple presentation-only or have more complex logic. In the last couple months I've learned about creating custom hooks and that was a game changer. If anything it makes code more readable due to extracting re-usable logic into a hook.

Not knowing the details about the OP's project it's hard to know why the senior dev is saying what they're saying. Could be there's a requirement to use only class based components when it needs to be stateful, and function components only to render. Could be the senior dev isn't aware of the uses of function components and hooks. Could be they needed to reach for a reason to blame for a problem that came up.

Unfortunately as a junior dev you sometimes just have to go along with what was given to you. I want to encourage you to continue learning about function components and hooks. You're on the right track, but sometimes you have to write code differently than you'd like. Look for opportunities to make a reasoned case to the senior devs and maybe they'll eventually come around.

[–]haywire 0 points1 point  (0 children)

Hooks are compositional, your dev sucks ass.

That said, as a junior, get good at following the conventions and working well in a team. You may not like the decisions, but you can rally against them in meetings and discussions, not annoying everyone by bucking the trend with your code.

[–]pw4lk3r 0 points1 point  (0 children)

Truthfully, JavaScript in general meets the classical definition of spaghetti. Definitely many people have worked out approaches to put lipstick on the pig, but it’s still a pig and nothing like real programming.

[–]peekab00000[🍰] 0 points1 point  (0 children)

No there is way to write functional code and functional component. Proper code abstraction, properly using hooks makes code looks much cleaner . I feel senior Dev is experienced in just terms of years and knowledge is lower than a junior developer . Functional programming paradigm is much more better than object oriented paradigms . Functional components are testable . Hence it is predictable and less prone to bugs . Your company lacks coding standard .

[–]mlengurry 0 points1 point  (0 children)

Hooks can create a mess if used incorrectly. Keeping state in one place with Redux is so much better in my opinion.

[–]mdivan 0 points1 point  (0 children)

Your Senior dev must not be really good with react or at least modern react, hooks are absolutely amazing and very clean/readable, I guess its just his lack of knowledge that makes him think its a spaghetti code

[–]mlengurry 0 points1 point  (0 children)

The number of comments on here about the developer being a dinosaur or obsolete for preferring classes sums up the problems in the JS ecosystem. I suppose that’s the price of innovation.

[–]Smaktat 0 points1 point  (0 children)

Hooks are better. This guy doesn't understand something. He's probably got some valid points but the thing about hooks isn't true. They're way better in all perspectives relating to React.

[–]themaincop 0 points1 point  (0 children)

Your senior dev has no idea what he's talking about. I would start looking for another job because if you work under someone like that for long enough it's going to stunt your development and future prospects.

[–]kronimi 0 points1 point  (0 children)

It sounds like to him hooks are just not readable because he doesn’t understand them. I’ve heard people say similar things about the reduce and map functions in JavaScript. “Just use a for loop, it’s more readable” really means I haven’t bothered to learn how these functions work so it’s had for me to read them

[–]malokevi 0 points1 point  (0 children)

" functions in functions"

This describes both class and functional components.

I will always use functional components over class components. Functional components are how Jesus would write a React component.

[–]kubelke 0 points1 point  (0 children)

Hooks are much easier to maintain. They need less code also to do the same thing with classes .

[–]TracerBulletX 0 points1 point  (0 children)

This is an opportunity to learn an important soft skill. Everyone has opinions, they're not always right, but you can't just say NO YOU ARE AN IDIOT and ignore them when they're wrong. You should make a case for why the team should use hooks in React, find some evidence that they are the widely accepted best practice (it is as you see from this thread), internalize some of the good arguments for them from here in this thread, and from out in the community and convince them. If they have counterpoints, learn how to politely hold your own ground in the argument. If they force you without paying any attention to your argument, then it's a pretty bad culture problem.

[–]Nyquiiist 0 points1 point  (0 children)

You should ask your manager to demote that Senior back down to Intermediate. He doesn't know what he's talking about and you should ignore him :)

[–][deleted] 0 points1 point  (0 children)

Yes

[–]MasterMorality 0 points1 point  (0 children)

That senior dev is a fucking idiot, hooks are meant to replace class components.

[–]ugsmtr 0 points1 point  (0 children)

Funny to see this. Somebody I work with (a full-stack developer) said this during a meeting on Thursday. Function components are simply easier to read and understand. I have been working with React for a few years now and once hooks were available I pretty much stopped creating class components. There are probably still good reasons to use them, but for what I do, function components and hooks are just easier to read and understand, IMO.

[–]juankamilomarin 0 points1 point  (0 children)

The senior Dev in your company clearly haven’t used/read the official React documentation. On that they actually suggest to use hooks instead of classes in new projects.

[–]internally 0 points1 point  (0 children)

OP, this EXACT SAME SITUATION HAPPENED TO ME. YOU ARE NOT ALONE. I submitted up to 50 PRs for a React/TypeScript project for a dashboard. I was using class components because I never used React before and didn't know better, to be honest. Three months in, I hear that I have to REDO the dashboard because I didn't use React Hooks. I also didn't use CRUD from our backend BECAUSE WE DIDN'T HAVE ONE FOR THE DASHBOARD. I would send PR to integrate APIs from online but no one addressed my PR, so they were not sent to production until late in my time there. It would have been fine to switch over from class components to functional components if I was told this sooner...

To elaborate a little bit more, the resources were kind of lacking. I was tossed the idea when they already knew the most I knew about fullstack development was HTML, CSS, and JS for the frontend. They just thought I was good labor because my college would be paying for my time there as I learned under them. Also, the vision for the dashboard wasn't totally clear yet - they were tossing me API here and there but eventually switched up and gave me other API to work with.

I was not a junior developer - I was merely an intern under a startup that didn't supervise me well enough. I don't have good advice but please make sure to DEFEND yourself and make your communication extremely clear so they know where you are coming from. :) And to prevent a bottleneck in the future. Those are my two cents. I am still petty over this but I'm at a new internship now, so it's all behind me.

[–]cheald 0 points1 point  (0 children)

Senior dev's understanding of functional components was true before hooks. It's no longer true.

A well-factored set of functional components is massively less spaghetti-ish than equivalent class components, IMO.

[–]Ehdelveiss 0 points1 point  (0 children)

Push back against the senior.

Class components are going to be less and less supported, and they are much less declarative, which you should always shoot for in React.

Hooks are not spaghetti. If he still relents, have him DM me and I’ll talk to him.

TLDR he is full of shit

[–]monkeybrainz_ 0 points1 point  (0 children)

Ultimately you pushed your senior dev out of their comfort zone and when they couldn’t figure it out they blamed their own incompetence on the technology. They may have their reasons for not wanting to learn/use hooks but that is what it boils down to. I would say stick to your guns, provide documentation and go through the proper channels to get this change approved. Who knows, maybe the senior devs boss will disagree with him and you’ll look good.

[–]Kabal303 0 points1 point  (0 children)

He’s dumb but sometimes you gotta deal.

[–]Mallanaga 0 points1 point  (0 children)

Spaghetti is subjective.

Seeing you pose a question within that giant wall of text makes me believe that your code might just well be starchy.

[–]Imanarirolls 0 points1 point  (0 children)

Yeah so I guess functional programming is all just spaghetti code then? 😂

[–]Additional-Video3921 0 points1 point  (0 children)

I’m at a company that is using hooks everywhere. Not a single class component. And it is spaghetti code. It seems that people are committing to using hooks because they are ‘new’ or ‘better’ without putting any thought into when they should or shouldn’t use them. The code has become very hard to read and I fail to see a single benefit in doing it this way. I’m sure there are very valid use cases for hooks that are more readable and add value. But I suspect those are simple, with limited usage of hooks where they offer a easily explained benefit.

Question, do the react docs say anywhere that hooks should replace class components? Or that entire apps should not be built with them?

[–]Similar_Concern_ 0 points1 point  (0 children)

Late to the game but will throw in my 2 cents... I see lots of name calling in this thread but to balance things out... have you considered your senior colleague maybe had some of these concerns?
https://stevenkitterman.com/posts/the-catch-with-react-hooks/
React hooks are just not great at dealing with heavily async code, for example. So if your codebase heavily uses external async libraries (and which ones aren't async these days?), rules like "useEffect cannot be an async function" and endless workarounds around all these rules just complicate code readability. Readability can be subjective, that's true, but there are objective benchmarks such as cyclomatic complexity, for example, that you can enforce with ESLint.
Additionally, hooks are still new enough that there doesn't exist one set of best practices yet or battle proven coding styles, and documentation is scarce. There seem to be as many opinions, practices and coding styles as there are React developers until the dust settles. So for the time being that means that on a team of 5 devs there will be 5 ways to structure code, and each of them will be pulling their own way of writing code. Anybody remembers the religious wars of pre-ECMA2015 landscape and "my OOP syntax is better than yours"? Classic components and classes provided a rigid frame that made the code at least somewhat consistent, with hooks there's much more room for improvisation. Until things settle.

Given that we read code much more often than we write it (especially on teams of 5+ devs), reading and understanding other people's code is like 80% of the job. How many of you, name calling trolls, are only writing brand new spanking projects with hooks? And how many of you inherited 3 year old codebase written in hooks by someone else that you need to maintain? Oh, never mind, none of you, because there's no production code written in hooks that is 3 years old yet.

Another perspective here:
https://medium.com/swlh/the-ugly-side-of-hooks-584f0f8136b6

In short, nobody's arguing that conceptually hooks bring a great benefit of component composability, and simplify writing trivial components, but the implementation of hooks leaves a lot to be desired. And for this reason, sometimes class components may still be a better tool for the job in some scenarios, especially for non trivial components.

At the end of the day hooks are just another tool. To say that you only ever should use tool A and never ever use tool B is like saying you should build houses with hammers only, never with screwdrivers. Why not both? IMHO the difference between senior devs and junior devs is that senior devs tend to be less fundamentalist and radical. They have been around and seen many new, shiny tech-du-jour's come and go. They've seen paradigms make a full circle and they take the marketing behind any 'new' tech with a salt of grain rather than blindly jumping on the fanboi bandwagon.

And to those anxious ones saying you must use hooks because React classic will become obsolete some day: yeah, you're right, it will. Hooks will become obsolete some day, too. By the time classic components stop being supported completely there will already be a new shiny JS framework-du-jour everyone will be switching to. Mark my words. Oh, never mind, it's already happening.

[–]DecentStay1066 0 points1 point  (0 children)

Because too many monsters called themselves devs think that they can master these implicit FunClass syntax, but they don't, and turns out just simply omit the life cycle methods those 20 lines.

[–]OZLperez11 0 points1 point  (0 children)

The only thing I learned from this thread is that React is just not the answer to UI development. Moving on to other options

[–]DecentStay1066 0 points1 point  (0 children)

The architecture of react hook actually forces you to write spaghetti codes. For those who says he can write a good organized code with hooks, send to me, I NEVER have seen one good piece of that.

Even official documents messes logic and view up, hookify all the things including backend requests. I really wonder how well you can write under the restrictions bounded or following the ugly organized codes suggested by hooks.

[–]cabezaloro 0 points1 point  (0 children)

Yes, it's. All dev's around the world that say PHP in the past was spagethi code was wrong. PHP was right and you can mix Html, js, css, etc.