EDIT: the article's title and content has been updated to "full-stack" and is no longer "front-end full-stack". What I've written below applies to front-end web more specifically.
This is very subjective -- it'll depend on who you ask, but what Brandin noted is correct -- most people's interpretations are that there isn't a such a thing as full-stack front-end dev, although, one could argue that there is front-end "leaning" full-stack suggesting that maybe the majority of the time is spent on client-side web (browsers).
The minimum will certainly vary by region. Honestly, anyone can be a dev, the minimum is equal to the minimum one can convince someone else that they can do the work or pay them for it. LOL.
But if we're talking about generally or falling across the board, my non-exhaustive list:
HTML/CSS
understand what a RESTful API looks like - because it's easy to understand how to obtain resources in some serialized format back if it's performed following general patterns outlined
JavaScript (at least ES5) and TypeScript and knowing the various styles -- pseudo-classical (classes even though they're syntatic sugar) and prototypal
3a. more JS and its semantics in relation to its asynchronous programming model - promises (old), async/await (new), and also generators, and generally the difference between blocking and non-blocking (async)
strength in at least one of the major ecosystems -- Angular, React, Vue and history with older ones, like Backbone, Ember, etc are a plus
understanding browser compatibility and how to address them (e.g. polyfills)
basic data structures and algorithms -- at least trees, both binary and n-ary (DOM). Have I ever had to use this? Yes, when writing a client-library or SDK for a brand new API or beta API, traversing/navigating JSON structures and nested fields is a recursive operation. Even if you're not writing a library, you're gonna be writing code that makes a request, parses it, and sometimes navigating it even if only for internal use
basic security - what is XSS and how it can be prevented
difference between authentication and authorization and the different ways authentication can be done
Thank you for sharing and for mentioning the title change (I was thinking about a front end dev trying to go full stack and I ended up writing front end full-stack). Your list seems very comprehensive. What language would you recommend for the back-end (besides JS, since I am already using it)?
I'd probably stick with what you know. If you were doing Ruby, I would've heavily recommended Ruby on Rails -- although a ton of people talk down on it being "opinionated", I think those opinions are within reason -- having been vetted by a LARGE open-source community of very experienced developers. I think it puts a person starting out on solid ground from which to start crafting their own viewpoints about what seemed difficult and what seemed hard and why it differs in other frameworks or paradigms. The NodeJS community unfortunately is immensely fragmented and difficult to wade through when it comes to writing software on the back-end or full-stack.
I always urge first principles and literally search for "what is X?" whenever you don't know something and follow it up with, "why is X done this way?" or "why does X exist?". There's no way to go down every rabbit hole, but it this allows you to start crafting branches of knowledge for future leaves to hang on.
The thing that I implicitly use everyday is design principles and general algorithmic thinking -- mostly running time analysis. When I say design principles, I'm kind of alluding to "clean code". This is a popular repository for JS and non-JS people alike: github.com/ryanmcdermott/clean-cod.... I would star it and use it as a reference. It does put into perspective some things -- like why some things are called what they are. The back-end of things is "everything". One of the most invaluable books I've read across my career in software thus far is, "Designing Data Intensive Applications" by Martin Kleppmann. I think it's a good starting point for setting up branches even if upon first read, half the things are questions marks do you. It's best to have at least covered some basic algorithms and data structures, though
Yes, Ruby is not very used in Europe so I can't say anything about it. Thank you for the repository recommendation, I started working in the filed a bit over 7 months ago and I tried from the beginning to build good habits when it comes to writing code. I will definitely check it out. Algorithms are still of a puzzle for me (at the moment).
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.
EDIT: the article's title and content has been updated to "full-stack" and is no longer "front-end full-stack". What I've written below applies to front-end web more specifically.
This is very subjective -- it'll depend on who you ask, but what Brandin noted is correct -- most people's interpretations are that there isn't a such a thing as full-stack front-end dev, although, one could argue that there is front-end "leaning" full-stack suggesting that maybe the majority of the time is spent on client-side web (browsers).
The minimum will certainly vary by region. Honestly, anyone can be a dev, the minimum is equal to the minimum one can convince someone else that they can do the work or pay them for it. LOL.
But if we're talking about generally or falling across the board, my non-exhaustive list:
That looks like a frontend dev job posting to me.
You're right -- the title of the piece and article has been edited
Sorry, I didn't know that. No wonder I wondered why there're so many comments of frontend tech stacks here :)
Thank you for sharing and for mentioning the title change (I was thinking about a front end dev trying to go full stack and I ended up writing
front end full-stack). Your list seems very comprehensive. What language would you recommend for the back-end (besides JS, since I am already using it)?I'd probably stick with what you know. If you were doing Ruby, I would've heavily recommended Ruby on Rails -- although a ton of people talk down on it being "opinionated", I think those opinions are within reason -- having been vetted by a LARGE open-source community of very experienced developers. I think it puts a person starting out on solid ground from which to start crafting their own viewpoints about what seemed difficult and what seemed hard and why it differs in other frameworks or paradigms. The NodeJS community unfortunately is immensely fragmented and difficult to wade through when it comes to writing software on the back-end or full-stack.
I always urge first principles and literally search for "what is X?" whenever you don't know something and follow it up with, "why is X done this way?" or "why does X exist?". There's no way to go down every rabbit hole, but it this allows you to start crafting branches of knowledge for future leaves to hang on.
The thing that I implicitly use everyday is design principles and general algorithmic thinking -- mostly running time analysis. When I say design principles, I'm kind of alluding to "clean code". This is a popular repository for JS and non-JS people alike: github.com/ryanmcdermott/clean-cod.... I would star it and use it as a reference. It does put into perspective some things -- like why some things are called what they are. The back-end of things is "everything". One of the most invaluable books I've read across my career in software thus far is, "Designing Data Intensive Applications" by Martin Kleppmann. I think it's a good starting point for setting up branches even if upon first read, half the things are questions marks do you. It's best to have at least covered some basic algorithms and data structures, though
Yes, Ruby is not very used in Europe so I can't say anything about it. Thank you for the repository recommendation, I started working in the filed a bit over 7 months ago and I tried from the beginning to build good habits when it comes to writing code. I will definitely check it out. Algorithms are still of a puzzle for me (at the moment).