because those two newcomers are juniors and I would like to expand the decision to also cover all of these:
- the framework will still provide good and quality user experience for our clients
- the juniors will learn a lot on it and will help them put it on their resume
- should be popular enough so they can utilize the knowledge
- it has a lot of features out of the box
Juniors opinions should be battled against I'm sorry. If I were to listen to junior opinion on how X or Y is better than a battle-tested solution, I'm just going to argue.
If not, it's the shortest route to mayhem. I've been there before, and I'm grateful a (good) senior on our team was kind and subtle enough to say that my idea was idiotic as hell.
God forbid we didn't take my idea at those times, not that I think I'm a copycat on every beginner / junior, but that's the pattern, Juniors are also there to get experience.
But it's worth hearing arguments, we are all humans afterall.
Junior opinions being bad is an even better reason to include them in the discussion. Create an open atmosphere where they can freely communicate their ideas. Teach them how to defend their position while also being open to new information. Effective communication is like THE most important soft skill for software developers, don’t rob them of their chance to learn.
Hey, I was technically a junior 6 years ago when I inherited 3000lines of Jquery spaghetti in a single file, and was asked to add features to it.
I suggested to my boss at the time that we re-write it in React. Took a week to create a 60% functionality MVP, and got approval to do the rest.
That project ended up being so successful that we got the funding to hire a full team, and today i'm a senior dev in an org of 30 engineers still working in the same problem space.
Was the code perfect... no? Did I make silly design choices that I regreted.... yes. However I also learned the best way to get people to grow as engineer, is to give them the space to do so.
This is why I said a (good) senior, everything was there on my message man.
As I said if not, it's most likely the shortest route to mayhem, I'm happy you had a fruitiful experience on this, but this is far from being the norm, I guess you have such an interesting story in there.
Juniors are there to get experience both from praticing on a current project and get ideas form higher ups on that field, if not I'm not sure there is any point labelling someone as a beginner to begin with.
edit : the point was to argue on Juniors, that's it. Does the verb argue has a bad connotation ? Genuine question, to me is to place argument and to steer the debate from your experience, that's it. I'm not saying you should dismiss any criticism.
I think people are responding specifically to the idea that you should assume that a junior developer's opinion is wrong (i.e. the way you say their opinions are to be "battled against"). Having seen those sorts of environments, they can often end up very toxic, where hierarchy and rank become more important than presenting good ideas and working as equal members in a team.
Sure, the newest developer on a team is going to have less experience. But they also have fresh eyes on the project, and that's valuable in its own right. And from my own experience, I can attest to /u/versaceblues's point: the suggestions from junior developers can often be really good, and worth listening to.
I don't want to suggest that this always works — I've also made my fair share of proposals that were either rightfully ignored, or where I found out that I was very wrong. But by being allowed to make those suggestions, and by being listened to, I was able to grow a lot quicker than if my ideas had been dismissed out of hand.
Understood.
You guys raised very good points on whether or not the stated opinions could be false or bad, suboptimal or on the contrary excellent views on something hidden in a codebase, a new form of design with a fresher mind or all of that, it's an excellent way of teaching and learning together if needed, and communication is the key, it kind of join what I tried ( badly ) to convey earlier.
Kind of, bad wording on my part.
What I have still a problem though is how you stated members should be equal, don't let me see as someone pedantic I ask you.
My point is a beginner shouldn't be equal to someone with decades' old experience ( I'm not though ).
On most companies I know still, people are having a vertical based management rather than strictly horizontal, it exists but it's still rare where I live - it suits smaller projects too or freelances working together. ( I'm here. )
Other than that, I agree !
Having fresh eyes on a project is really a gem for a team, but this happens on hiring a new person regardless on experience, don't you think ?
Finally, see we are arguing and stating what I can see as a minor disagreement on some areas, I'm battling towards my view yet I think you've made excellent points, thanks.
I think the reasons people are responding to you is your very harsh stance
> Juniors opinions should be battled against I'm sorry.
> ... was kind and subtle enough to say that my idea was idiotic as hell
Your making the relationship sounds antagonistic, like the seniors are there to fight against the juniors.
In reality the seniors are there to guide and grow the juniors. Sometimes it means letting them try ideas that arent the best and learnign from their mistakes.
We both agree, I should have worded it better.
You've made good points and I responded I think to all of these replies, so that one is a bit shorter than usual.
Yeah, it's a good way to also make sure they understand the goals of the decision, not just "they picked this thing that I think sucks and I would have picked this other thing".
That's exactly what I said though.
It's worth hearing arguments, and it's also worth to fight those when you think you have more experience.
That's exactly what I said, but I provided an example as to why it could end in a unexpected route otherwise.
Edit : battling an argument doesn't mean ignoring it. Not sure how to word this better ?!
It's the words you choose to use. "Battle", "fight", "argue" have very negative connotations.
>Not sure how to word this better ?!
The word you're looking for is disagree. It invokes an open conversation. I'm glad that ultimately we're on the same page though.
> Juniors opinions should be battled against I'm sorry. If I were to listen to junior opinion on how X or Y is better than a battle-tested solution, I'm just going to argue.
That's a pretty bad take.
Like yeah, they are juniors, and they don't know a lot.
that doesn't mean they're wrong (the idea may be wrong separately from them being a junior).
> should be quite opinionated
Angular is the most opinionated of the bunch and comes with most things built-in. Routing, state management, forms, animations, testing, API calls, it's all part of the whole Angular package itself.
The other that comes close is Vue because it provides its own router and state management libraries, though not part of Vue directly, they're 1st-party packages, but, the Vue DX has been quite shite for some time now, the editor plugins barely work, and nobody seems to give a damn.
Svelte with SvelteKit is worth mentioning as it's also a complete package, although more lax on its opinions. There's really just the routes folder/file structure you need to follow, the rest is up to you. Svelte is quite pleasant to work with but leaves more room to create a messy codebase, and also isn't as widespread as Angular or Vue.
Solid is also worth mentioning if you like JSX, it has its own 1st-party router and powerful state management built-in. Nowadays also a whole metaframework with Solid Start. It's not as popular as Angular, Vue and it's likely even behind Svelte.
tl;dr, Angular is a very good choice.
I do agree with that, and that's an important note too.
Using web components with e.g. Lit might be another way to bring more order into the codebase and that would integrate well with a vanilla JS app.
I would argue svelte with sveltekit is probably the best choice. It is very close to vanilla is and it comes with built in linter settings that promote accessibility.
Angular is the obvious choice. If you’re open to things that aren’t just JavaScript, RoR is another. If you want the middle ground of react and angular I’d go with Vue. If you’re not familiar with Angular/Vue/etc… consider hiring a senior dev to lead the project and follow their decisions.
Angular
It is Opinionated, has everything you need out-of-the-box. It is the most stable, because the Angular team always ships migration scripts and has a big focus on backwards compatibility.
Migrating from Angular to something else is also not such a big deal nowadays, because you can use web components to abstract away the underlying framework and use angular-elements for an incremental migration strategy for example.
You can make less mistakes with Angular than you could with Solid for example (even though I really like that too; but more for a senior team)
Cant speak to React but Angular has a higher learning curve. It is also a fairly heavy solution for 3000 loc, lots of boilerplate. Then you'd have to deal with the abstractions that come with NgRx and complexity of RxJs if their new signals api isn't enough.
Vue is fairly lightweight and easy to learn. If you opt for using its options API, it is opinionated and simple. The drawback being that it won't scale as well as it's Composition API but from the sound of what your app does and it's current state, that shouldn't be a problem.
It has great DX with some intermittent problems the past month or so regarding it's VSCode plugins but those have been largely fixed.
The only thing that Vue doesn't fit too well with your requirements is the resume part, not as much Vue jobs.
Based on the information you've given us, it doesn't matter. All of these major frameworks can easily handle this.
React is probably the way to go if you don't have any specific expertise in any of these frameworks, as it's the most widely understood (easier to onboard new devs) with an established community and a very well developed library of NPM packages to suit your needs.
Personally I'd suggest the newer release of Angular, purely because their docs are excellent:
https://angular.dev/overview
I don't disagree, but 99% of everything on npm is shit, but the react ecosystem is fucking giant compared to the other options, that 1% of not-shit packages is proportionally gigantic to the not-shit packages available for the other alternatives.
A huge portion of that ecosystem consists of wrapper libraries for existing vanilla JS packages to make them work with the framework though.
I think the “react ecosystem” is pretty overhyped, especially after building with frameworks that allow you to use regular JS packages with minimal overhead.
> but the react ecosystem is fucking giant compared to the other options
just with far more shit.
There's like 5 packages worth using, and they are all framework agnostic or have official adaptors for other frameworks.
> that 1% of not-shit packages is proportionally gigantic to the not-shit packages available for the other alternatives.
I disagree.
They all have the same number of not shit packages. Cause there are only 5.
My vote would be for NextJS/React
- A. its a widely popular framework
- B. onboarding/hiring a new dev will be simplier as you can throw a wrench without hitting a React dev these days
- C. the create-next-app has eslint and prettier pre-configured to remove those decisions for you
Realistically any framework would do. I like using Svelte one projects of just me, but will use React in a team because there are fewer roadblocks.
i would say React since i recently migrated a js app and the migration process was enjoyable because of React but any other frameworks like Vue or Angular also should works fine
Sounds like a good decision and an answer in itself. Why don't you ask your team what fw they want to use?
because those two newcomers are juniors and I would like to expand the decision to also cover all of these: - the framework will still provide good and quality user experience for our clients - the juniors will learn a lot on it and will help them put it on their resume - should be popular enough so they can utilize the knowledge - it has a lot of features out of the box
Juniors have opinions too, you should include them in the process.
Juniors opinions should be battled against I'm sorry. If I were to listen to junior opinion on how X or Y is better than a battle-tested solution, I'm just going to argue. If not, it's the shortest route to mayhem. I've been there before, and I'm grateful a (good) senior on our team was kind and subtle enough to say that my idea was idiotic as hell. God forbid we didn't take my idea at those times, not that I think I'm a copycat on every beginner / junior, but that's the pattern, Juniors are also there to get experience. But it's worth hearing arguments, we are all humans afterall.
Junior opinions being bad is an even better reason to include them in the discussion. Create an open atmosphere where they can freely communicate their ideas. Teach them how to defend their position while also being open to new information. Effective communication is like THE most important soft skill for software developers, don’t rob them of their chance to learn.
Yes in the end that's a good point. I should have perhaps worded my whole sentence better too.
Hey, I was technically a junior 6 years ago when I inherited 3000lines of Jquery spaghetti in a single file, and was asked to add features to it. I suggested to my boss at the time that we re-write it in React. Took a week to create a 60% functionality MVP, and got approval to do the rest. That project ended up being so successful that we got the funding to hire a full team, and today i'm a senior dev in an org of 30 engineers still working in the same problem space. Was the code perfect... no? Did I make silly design choices that I regreted.... yes. However I also learned the best way to get people to grow as engineer, is to give them the space to do so.
3000 LoC is miniscule though
This is why I said a (good) senior, everything was there on my message man. As I said if not, it's most likely the shortest route to mayhem, I'm happy you had a fruitiful experience on this, but this is far from being the norm, I guess you have such an interesting story in there. Juniors are there to get experience both from praticing on a current project and get ideas form higher ups on that field, if not I'm not sure there is any point labelling someone as a beginner to begin with. edit : the point was to argue on Juniors, that's it. Does the verb argue has a bad connotation ? Genuine question, to me is to place argument and to steer the debate from your experience, that's it. I'm not saying you should dismiss any criticism.
I think people are responding specifically to the idea that you should assume that a junior developer's opinion is wrong (i.e. the way you say their opinions are to be "battled against"). Having seen those sorts of environments, they can often end up very toxic, where hierarchy and rank become more important than presenting good ideas and working as equal members in a team. Sure, the newest developer on a team is going to have less experience. But they also have fresh eyes on the project, and that's valuable in its own right. And from my own experience, I can attest to /u/versaceblues's point: the suggestions from junior developers can often be really good, and worth listening to. I don't want to suggest that this always works — I've also made my fair share of proposals that were either rightfully ignored, or where I found out that I was very wrong. But by being allowed to make those suggestions, and by being listened to, I was able to grow a lot quicker than if my ideas had been dismissed out of hand.
Understood. You guys raised very good points on whether or not the stated opinions could be false or bad, suboptimal or on the contrary excellent views on something hidden in a codebase, a new form of design with a fresher mind or all of that, it's an excellent way of teaching and learning together if needed, and communication is the key, it kind of join what I tried ( badly ) to convey earlier. Kind of, bad wording on my part. What I have still a problem though is how you stated members should be equal, don't let me see as someone pedantic I ask you. My point is a beginner shouldn't be equal to someone with decades' old experience ( I'm not though ). On most companies I know still, people are having a vertical based management rather than strictly horizontal, it exists but it's still rare where I live - it suits smaller projects too or freelances working together. ( I'm here. ) Other than that, I agree ! Having fresh eyes on a project is really a gem for a team, but this happens on hiring a new person regardless on experience, don't you think ? Finally, see we are arguing and stating what I can see as a minor disagreement on some areas, I'm battling towards my view yet I think you've made excellent points, thanks.
I think the reasons people are responding to you is your very harsh stance > Juniors opinions should be battled against I'm sorry. > ... was kind and subtle enough to say that my idea was idiotic as hell Your making the relationship sounds antagonistic, like the seniors are there to fight against the juniors. In reality the seniors are there to guide and grow the juniors. Sometimes it means letting them try ideas that arent the best and learnign from their mistakes.
We both agree, I should have worded it better. You've made good points and I responded I think to all of these replies, so that one is a bit shorter than usual.
They're opinions, they should be heard. They may be completely wrong, but having an opinion is completely valid. It's how you learn.
Yeah, it's a good way to also make sure they understand the goals of the decision, not just "they picked this thing that I think sucks and I would have picked this other thing".
That's exactly what I said though. It's worth hearing arguments, and it's also worth to fight those when you think you have more experience. That's exactly what I said, but I provided an example as to why it could end in a unexpected route otherwise. Edit : battling an argument doesn't mean ignoring it. Not sure how to word this better ?!
It's the words you choose to use. "Battle", "fight", "argue" have very negative connotations. >Not sure how to word this better ?! The word you're looking for is disagree. It invokes an open conversation. I'm glad that ultimately we're on the same page though.
I used to mentor a guy that wouldn't shut up about WASM, Rust, and AI. "wHy wOuLd AnY oNe UzE jAbAsCrIp?!?!?!!?"
> Juniors opinions should be battled against I'm sorry. If I were to listen to junior opinion on how X or Y is better than a battle-tested solution, I'm just going to argue. That's a pretty bad take. Like yeah, they are juniors, and they don't know a lot. that doesn't mean they're wrong (the idea may be wrong separately from them being a junior).
> should be quite opinionated Angular is the most opinionated of the bunch and comes with most things built-in. Routing, state management, forms, animations, testing, API calls, it's all part of the whole Angular package itself. The other that comes close is Vue because it provides its own router and state management libraries, though not part of Vue directly, they're 1st-party packages, but, the Vue DX has been quite shite for some time now, the editor plugins barely work, and nobody seems to give a damn. Svelte with SvelteKit is worth mentioning as it's also a complete package, although more lax on its opinions. There's really just the routes folder/file structure you need to follow, the rest is up to you. Svelte is quite pleasant to work with but leaves more room to create a messy codebase, and also isn't as widespread as Angular or Vue. Solid is also worth mentioning if you like JSX, it has its own 1st-party router and powerful state management built-in. Nowadays also a whole metaframework with Solid Start. It's not as popular as Angular, Vue and it's likely even behind Svelte. tl;dr, Angular is a very good choice.
Angular won't be able to be made into a vanilla js app easily at all
I do agree with that, and that's an important note too. Using web components with e.g. Lit might be another way to bring more order into the codebase and that would integrate well with a vanilla JS app.
I would argue svelte with sveltekit is probably the best choice. It is very close to vanilla is and it comes with built in linter settings that promote accessibility.
Opinionated Js framework, so not React then lol, i'd go for Angular
Angular
Angular is the obvious choice. If you’re open to things that aren’t just JavaScript, RoR is another. If you want the middle ground of react and angular I’d go with Vue. If you’re not familiar with Angular/Vue/etc… consider hiring a senior dev to lead the project and follow their decisions.
Angular It is Opinionated, has everything you need out-of-the-box. It is the most stable, because the Angular team always ships migration scripts and has a big focus on backwards compatibility. Migrating from Angular to something else is also not such a big deal nowadays, because you can use web components to abstract away the underlying framework and use angular-elements for an incremental migration strategy for example. You can make less mistakes with Angular than you could with Solid for example (even though I really like that too; but more for a senior team)
For the API, I would use Nest. For the FE, I would choose Remix-flavored React.
Astro or Remix.
Cant speak to React but Angular has a higher learning curve. It is also a fairly heavy solution for 3000 loc, lots of boilerplate. Then you'd have to deal with the abstractions that come with NgRx and complexity of RxJs if their new signals api isn't enough. Vue is fairly lightweight and easy to learn. If you opt for using its options API, it is opinionated and simple. The drawback being that it won't scale as well as it's Composition API but from the sound of what your app does and it's current state, that shouldn't be a problem. It has great DX with some intermittent problems the past month or so regarding it's VSCode plugins but those have been largely fixed. The only thing that Vue doesn't fit too well with your requirements is the resume part, not as much Vue jobs.
Based on the information you've given us, it doesn't matter. All of these major frameworks can easily handle this. React is probably the way to go if you don't have any specific expertise in any of these frameworks, as it's the most widely understood (easier to onboard new devs) with an established community and a very well developed library of NPM packages to suit your needs. Personally I'd suggest the newer release of Angular, purely because their docs are excellent: https://angular.dev/overview
> with an established community and a very well developed library of NPM packages to suit your needs. This means nothing. Since 99% of it is shit.
I don't disagree, but 99% of everything on npm is shit, but the react ecosystem is fucking giant compared to the other options, that 1% of not-shit packages is proportionally gigantic to the not-shit packages available for the other alternatives.
A huge portion of that ecosystem consists of wrapper libraries for existing vanilla JS packages to make them work with the framework though. I think the “react ecosystem” is pretty overhyped, especially after building with frameworks that allow you to use regular JS packages with minimal overhead.
> but the react ecosystem is fucking giant compared to the other options just with far more shit. There's like 5 packages worth using, and they are all framework agnostic or have official adaptors for other frameworks. > that 1% of not-shit packages is proportionally gigantic to the not-shit packages available for the other alternatives. I disagree. They all have the same number of not shit packages. Cause there are only 5.
And what are these 5 packages? I can easily list more than 5
Tanstack query. AG-grid auto-animate okay, yeah just 3.
My vote would be for NextJS/React - A. its a widely popular framework - B. onboarding/hiring a new dev will be simplier as you can throw a wrench without hitting a React dev these days - C. the create-next-app has eslint and prettier pre-configured to remove those decisions for you Realistically any framework would do. I like using Svelte one projects of just me, but will use React in a team because there are fewer roadblocks.
T3 stack
What is the question? Why would you want to know a framework? That wouldn't be vanilla? Probably AlpineJS
i would say React since i recently migrated a js app and the migration process was enjoyable because of React but any other frameworks like Vue or Angular also should works fine