@jesterxl thank you so much for your answer! Incredibly helpful. I never thought about all the different meanings behind web development.
I had a quick follow up question, if you have some time to answer.
We're a startup and mostly have worked on the back-end of our software. We're basically looking to change our tech stack. Do you think it would be good to include in the job posting something about us being open to the candidates recommending and persuading us on a tech stack. Or, should we just pick our own?
I write code, front-end and back-end, and like deploying it on AWS. Software Developer for 20 years, and still love it. Amateur Powerlifter & Parkourist.
Hell yeah, dream come true for a lot of us who "want to use X tech with Y build system deployed to Z back-end using A language there". Green field is fun, no matter your experience level. It's also a competitive advantage for startups. Meaning, I can't go use Elm/ReScript/Roc/Haskell/Elixir at at bank, but a startup is all like "Dude, we don't care, nor do our users, just make our users happy so we can have a successful product". That means you'll get people who want to build vs. people who just want a paycheck. For example, a Senior Director I worked with at Capital One left to go work at a startup because he could control the tech stack; like the whole thing, not just the CSS framework. An individual contributor at his level, that type of opportunity is far and between so when you see it, people us will POUNCE.
I'd cite the startup angle too as many who are experienced "get" that you'll wear many more hats there vs. "just a front-end person"; meaning they may have to get their hands dirty building a CICD pipeline, debug some back-end stuff, do more CSS than normal (oh gawd... no... NOOOOOoOoO), and have a way more healthy relationship with Business/Product. Some love that level of ownership and responsibility. I'll ignore all the negatives because they know what they're signing up for.
For example, saying "Angular" will attract people passionate in Angular. You want passion, sure. However, what if there was a React dev and she had a bad experience with Angular... but could totally crush any problem you threw at her? Maybe allowing her to use React is better? There's no right answer there because maybe y'all dig Angular and are like "look, if you know React, we can teach you Angular". Again, some don't have loyalty, where others, like me, treat UI frameworks like Sports Teams and will die on completely ridiculous philosophical hills "because my favorite toy!".
Same goes for programming languages, AWS vs. Azure, blah blah blah. For some it's honey, others it's ... whatever is the opposite of honey in the metaphor. Sometimes the opened endedness is an attraction to the role (like me having an agenda to help define it) and others who are bored and don't really care and just want to code more and manage less and don't really care about the tech stack.
"pick your own" That's your call. There are extremes, sure. Let's do the Benjamin Franklin sales technique; list all the pros and cons, whichever has more pro's, do it.
Pros? Everyone knows React. TypeScript is easily learned if you know JavaScript or any typed language like Java/C#. Your hiring pool is extremely large, React is still popular, and the community library/framework support is huge, with Facebook still continuing to be a consistent supporter of open source in React. Express.js, same, with tons of plugins to fix functionality and cyber needs. ECS on AWS means you can "scale with the money" to extremely high Transactions Per Second. Material Design has good documentation on UX from Google, and the components are pretty good for React. What's not to love here?
Cons? Some only like React "with their state management philosophy" like Redux, or Easy Peasy or MobX or Context only, blah blah blah. Some still are die hard class fans. Some may be awesome Angular people any startup would be lucky to get and you're negating them because of their framework choice. Some like me who like others will see "React" in the job posting and stop reading. Maybe you don't even need a Single Page App? Maybe you actually need a website, and it'd be better using Wordpress, a SSR /Jamstack style site using Netlify. Maybe a hybrid of the two, and what you need is more of a CMS style developer who's familiar with Drupal/Wordpress/Salesforce and gets that things like SEO and page speed can help in those scenarios. React people are super diverse too, and there are many camps of "SSR only" or "UI only because state on the client is best for user" and "Do both using REMIX yay!". What diversity are we losing here by making a hard claim on React? Now... Express.js, sure, but it's a monolith. Do you really need that huge TPS ability before you've even gotten to market? What really is your new user base? Do you really need ECS? Maybe just a few serverless Lambda's + API Gateway, maybe a simple Amplify stack is good enough to get to market? How does that all work using Github when AWS has more appropriate things like Terraform/CloudFormation/SAM/CDK/Serverless?
Here's the opposite angle using the REGAL stack:
ReScript + Elm + GraphQL + AWS Amplify/AppSync + Lambda
Pro's? Deterministic code where 90% of your bugs will be in the microservice layer (Elm + ReScript + GraphQL types ensure all your bugs are logic bugs, not runtime exceptions). Serverless, so easier to twist some knobs and scale based on price vs. the insane Unix level know how of scaling Node.js/Go/Elixir horizontally on an EC2 you'd do in ECS. Same for security; your libraries are your problem, sure, but Node.js/Python/whatever is managed by AWS; same for up time. GraphQL ensures your UI and API types are the same and the architecture can be mostly reactive, in a monorepo, but still deployed like microservices.
Con's? Elm is super fringe. ReScript is even more fringe. Functional Programming is a minority despite the slow rise of borrowed ideas in languages. Who are you going to hire if your main dev quits? Who in this large pool would actually either know that Hipster Tech Stack OR be willing to learn it? The "hit by a bus" scenario is more scary here, but maybe that's a trade off your willing to make because your a startup and will take anyone willing to have passion behind your business idea? GraphQL is super complex because it's all about the types and resolving to those shapes. REST is super old, why not just a library like fetch and POST your JSON directly in the body? Simpler, eh? We don't about strong types early because our design changes so often, right?
Those are extremes, but you can see the nuance I hope.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@jesterxl thank you so much for your answer! Incredibly helpful. I never thought about all the different meanings behind web development.
I had a quick follow up question, if you have some time to answer.
We're a startup and mostly have worked on the back-end of our software. We're basically looking to change our tech stack. Do you think it would be good to include in the job posting something about us being open to the candidates recommending and persuading us on a tech stack. Or, should we just pick our own?
Hell yeah, dream come true for a lot of us who "want to use X tech with Y build system deployed to Z back-end using A language there". Green field is fun, no matter your experience level. It's also a competitive advantage for startups. Meaning, I can't go use Elm/ReScript/Roc/Haskell/Elixir at at bank, but a startup is all like "Dude, we don't care, nor do our users, just make our users happy so we can have a successful product". That means you'll get people who want to build vs. people who just want a paycheck. For example, a Senior Director I worked with at Capital One left to go work at a startup because he could control the tech stack; like the whole thing, not just the CSS framework. An individual contributor at his level, that type of opportunity is far and between so when you see it, people us will POUNCE.
I'd cite the startup angle too as many who are experienced "get" that you'll wear many more hats there vs. "just a front-end person"; meaning they may have to get their hands dirty building a CICD pipeline, debug some back-end stuff, do more CSS than normal (oh gawd... no... NOOOOOoOoO), and have a way more healthy relationship with Business/Product. Some love that level of ownership and responsibility. I'll ignore all the negatives because they know what they're signing up for.
For example, saying "Angular" will attract people passionate in Angular. You want passion, sure. However, what if there was a React dev and she had a bad experience with Angular... but could totally crush any problem you threw at her? Maybe allowing her to use React is better? There's no right answer there because maybe y'all dig Angular and are like "look, if you know React, we can teach you Angular". Again, some don't have loyalty, where others, like me, treat UI frameworks like Sports Teams and will die on completely ridiculous philosophical hills "because my favorite toy!".
Same goes for programming languages, AWS vs. Azure, blah blah blah. For some it's honey, others it's ... whatever is the opposite of honey in the metaphor. Sometimes the opened endedness is an attraction to the role (like me having an agenda to help define it) and others who are bored and don't really care and just want to code more and manage less and don't really care about the tech stack.
"pick your own" That's your call. There are extremes, sure. Let's do the Benjamin Franklin sales technique; list all the pros and cons, whichever has more pro's, do it.
Choosing React + TypeScript + Express.js + ECS + Material Design UI + Github
Pros? Everyone knows React. TypeScript is easily learned if you know JavaScript or any typed language like Java/C#. Your hiring pool is extremely large, React is still popular, and the community library/framework support is huge, with Facebook still continuing to be a consistent supporter of open source in React. Express.js, same, with tons of plugins to fix functionality and cyber needs. ECS on AWS means you can "scale with the money" to extremely high Transactions Per Second. Material Design has good documentation on UX from Google, and the components are pretty good for React. What's not to love here?
Cons? Some only like React "with their state management philosophy" like Redux, or Easy Peasy or MobX or Context only, blah blah blah. Some still are die hard class fans. Some may be awesome Angular people any startup would be lucky to get and you're negating them because of their framework choice. Some like me who like others will see "React" in the job posting and stop reading. Maybe you don't even need a Single Page App? Maybe you actually need a website, and it'd be better using Wordpress, a SSR /Jamstack style site using Netlify. Maybe a hybrid of the two, and what you need is more of a CMS style developer who's familiar with Drupal/Wordpress/Salesforce and gets that things like SEO and page speed can help in those scenarios. React people are super diverse too, and there are many camps of "SSR only" or "UI only because state on the client is best for user" and "Do both using REMIX yay!". What diversity are we losing here by making a hard claim on React? Now... Express.js, sure, but it's a monolith. Do you really need that huge TPS ability before you've even gotten to market? What really is your new user base? Do you really need ECS? Maybe just a few serverless Lambda's + API Gateway, maybe a simple Amplify stack is good enough to get to market? How does that all work using Github when AWS has more appropriate things like Terraform/CloudFormation/SAM/CDK/Serverless?
Here's the opposite angle using the REGAL stack:
ReScript + Elm + GraphQL + AWS Amplify/AppSync + Lambda
Pro's? Deterministic code where 90% of your bugs will be in the microservice layer (Elm + ReScript + GraphQL types ensure all your bugs are logic bugs, not runtime exceptions). Serverless, so easier to twist some knobs and scale based on price vs. the insane Unix level know how of scaling Node.js/Go/Elixir horizontally on an EC2 you'd do in ECS. Same for security; your libraries are your problem, sure, but Node.js/Python/whatever is managed by AWS; same for up time. GraphQL ensures your UI and API types are the same and the architecture can be mostly reactive, in a monorepo, but still deployed like microservices.
Con's? Elm is super fringe. ReScript is even more fringe. Functional Programming is a minority despite the slow rise of borrowed ideas in languages. Who are you going to hire if your main dev quits? Who in this large pool would actually either know that Hipster Tech Stack OR be willing to learn it? The "hit by a bus" scenario is more scary here, but maybe that's a trade off your willing to make because your a startup and will take anyone willing to have passion behind your business idea? GraphQL is super complex because it's all about the types and resolving to those shapes. REST is super old, why not just a library like
fetchand POST your JSON directly in the body? Simpler, eh? We don't about strong types early because our design changes so often, right?Those are extremes, but you can see the nuance I hope.