4 ms·

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphi

by jiofih 6y ago

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.

andrewingram 6y ago
But you can also apply JIT to learning as well. Depending on your work, you may come across a situation that needs these things anywhere on the continuum from often to never. As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker. But similarly, he might well know these things to an above-average level, and just think that he doesn't.
- lwigo 6y ago
  Or just grinds LeetCode really well (or had a referral).
- ErikAugust 6y ago
  "As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker." In a practical sense that should be fine, given the level of specialization that a company like Facebook can have given its size and scope. But I wonder if Dan would make it through the average Facebook engineer interview without his Redux cred however. He is also the rare person who is very honest about this kind of thing which is refreshing. For example he claims he only vaguely understands time complexity ("nested loops are bad"). I don't know exactly what point I'm making here, besides there can be a disconnect between a developer interview process and what people actually contribute. I think engineers should strive to be solid at the fundamentals, but at the same time there are very productive people who just learn as they go. Also, it takes a village so to speak, and over-optimizing for Comp Sci majors who drill LeetCode may not be the best long term choice for building teams either.
  - kyawzazaw 6y ago
    Now you got me wondering how people who got more well known creating open source projects go through hiring process at these big tech cos. I know creator of Homebrew still had to go through typical google interview. I am talking about people like Jon Gjengset who got hired to work on Rust at AWS.
  - andrewingram 6y ago
    He was hired at the same conference at which he showcased Redux for the first time (as a byproduct of the content of his actual talk, which was time-travel debugging), so it's unlikely it directly gave him the cred necessary to get hired, since he was already in the hiring pipeline.
idkat 6y ago
Well it makes perfect sense to me why React keeps reinventing the wheel every other version and why it's a hot mess. This video makes more sense now as to why they don't seem to have any direction https://www.youtube.com/watch?v=iRo18pUs61Q https://www.youtube.com/watch?v=iRo18pUs61Q. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.
- arcturus17 6y ago
  I have absolutely no clue what you're rambling about, but if frontend dev shouldn't consume braincells, you go on and code a complex frontend in vanilla JS and then serve that plate of hot spaghetti to the devs coming after you.
- richeyryan 6y ago
  That video is quite poor in my opinion. He comes so close to a bunch of very interesting questions like how can state management and effect management be done in a good, scalable way that maybe isn't tied to our view libraries? He then admits he has close to no opinion on the matter and suggests web components which is about a step above the jQuery scenario he described in the beginning. The way I see it the advent of React was basically a rejection of the imperative MVC model that was prevalent with the likes of Backbone in favor of a more functional one. The first prototype of React was written in Standard ML. The evolution over the years with flux, redux and hooks was basically answering the questions that were arguably solved in MVC already but coming from the angle of declarative, immutable approaches. Where does state live? How do I handle asynchronous effects? How do I abstract that behavior from my views? I don't think the community has answered those questions definitively yet and a lot of the interest seems to be in refining the view mechanics with the likes of Svelte rather than really getting to grips with how to best handle long lived application state and the effects that operate on it. One thing I could see being the case in a couple of years, and in some ways the video does reach this conclusion, is that the reactive, stateful layer will be abstracted from the view and how you render your data will be almost like choosing a templating engine on the server. It could be React, Vue, Svele, Marko, Web Components, whatever. Those libraries and components will handle your dropdowns opening and closing and your tooltips showing but your real application state that distinguishes your product from another will live somewhere else and will be less subject to churn.
colmvp 6y ago
I don't think you're a gatekeeper, I just don't see the relevance to the author. He's a library designer and is working with a team maintaining and updating one of the most popular Javascript libraries in the world. He has a very deep background in that language which is one of the most important skills for his role. I don't blame him for not knowing some of those things you listed more deeply. There's only so many hours a day to dig deep into a wide range of material. You still have to spend time going into other material that might be more relevant to the day to day including testing, managing people, communication with team members, planning, etc. Yeah sure I'd love to be more knowledgeable about CORS or networking, but I also want to be much stronger in Javascript, the JS library I'm working on, design patterns, deployment, etc. Lastly, I'd rather be in Abramov's shoes where my work profoundly influenced web development than be all over the place with my 'expertise' and not actually be all that impactful with my time.
- clashmeifyoucan 6y ago
  Seconded, also reading the list, it's likely he just delved deep enough to solve the issue at hand and then back to work. I can relate to that a bit, especially CORS since I never bothered to see what was up with that at a deep level either. Honestly just used a module for Flask when needed to get it working there and set up a CORS proxy on a cloudflare worker for a different project and called it a day. Maybe that's how it went with him too. I'd call this something like "Laze Driven Development"—learning just enough to solve the problem (like my experiences with bash scripts).
yladiz 6y ago
If your speciality is frontend JS engineering, why are deployment, platforms, and networking (unless you simply mean how to use fetch/XMLHttpRequest) large holes? I'd even question graphics APIs beyond very basic knowledge, because in my experience I've never needed to know anything about those beyond the basics. These things sound more like full stack, rather than frontend.
- jiofih 6y ago
  Yes, networking as in fetch/XHR, web sockets, HTTP, REST, protocols, performance and so on. How your frontend code runs. All I mentioned are strictly frontend skills, not anywhere near full-stack.
johnfn 6y ago
I mean, this is Dan Abramov we’re talking about. Ya know, the guy who created a good chunk of React. I’d say he built actual products for the web just fine.
- jiofih 6y ago
  He is not one of the React authors, common misconception (his bio says “I didn’t make react” as a nod to that). He wrote the Redux library. Not that I would care either way - this is about skill sets and not personalities.
  - yreg 6y ago
    Abramov is the #1 contributor[0]. I guess by authors you mean only the innitial people who came up with React? [0] - https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors
  - skinnymuch 6y ago
    He did create a big chunk of React. Half of the Github issues I see for React have him involved. He might not be a founder of React, but he sure is a major React author.
names_are_hard 6y ago
I think the point is that frontend engineering is a broad field, and everyone had gaps in their knowledge, especially specialists who focus on specific parts of the stack. It's possible to provide a ton of value on very complex frontends without doing much in the way of CSS, for example. I've been part of projects where the UI layer was handled in a dedicated library, and unless you wanted to be part of that team, you didn't have to understand much more than which React components to use when. Graphics are a specific subfield of frontend that isn't relevant to most apps, and it's possible to go very far without being exposed to these.
burade 6y ago
That's nonsense. The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.
ogre_codes 6y ago
> you’ll most definitely need those when building actual products for the web. You should take a good look at who posted the article. Fundamentally, who he is and what he's done in the community is the context of the blog. Without understanding that, you miss the entire point.
- jiofih 6y ago
  I know exactly who posted the article, thank you. I simply disagree that you can be a frontend engineer in the usual meaning it has without some level of those skills. Doesn’t mean anyone is less capable, deserving or cannot make a living that way.
  - ericmcer 6y ago
    But he is literally one of the most successful front end engineers of all time and lacks those skills. Your takeaway from the article is it’s antithesis.
    - jodrellblank 6y ago
      I simply don't believe he lacks those skills. He says "Python. I feel bad about this one — I have worked with Python for several years at some point and I’ve never bothered to actually learn it." He's skilled at JavaScript and C# and worked with Python for years, what's the betting he's as good as any typical Python developer, if not better? Pretty good, I'd think. > "I struggle to read either LISP-inspired (like Clojure), Haskell-inspired (like Elm), or ML-inspired (like OCaml) code" How many people don't know Haskell but can successfully struggle through reading it instead of having their eyes glaze over and completely refuse to try? > "CORS. I dread these errors! I know I need to set up some headers to fix them but I’ve wasted hours here in the past." "I don't know it - but I've also worked on it and know how to fix it and done so" - hmmmm. I suspect he is more capable than he's making out; politely talking himself down.
      - ogre_codes 6y ago
        > I suspect he is more capable than he's making out; politely talking himself down. Why? If you are heads down working on core Javascript technologies, why do you step over and dig into learning more than the basics of Python? Likewise most of these languages/ skills.

by jiofih 6y ago

andrewingram 6y ago

But you can also apply JIT to learning as well. Depending on your work, you may come across a situation that needs these things anywhere on the continuum from often to never. As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker. But similarly, he might well know these things to an above-average level, and just think that he doesn't.

lwigo 6y ago
Or just grinds LeetCode really well (or had a referral).
ErikAugust 6y ago
"As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker." In a practical sense that should be fine, given the level of specialization that a company like Facebook can have given its size and scope. But I wonder if Dan would make it through the average Facebook engineer interview without his Redux cred however. He is also the rare person who is very honest about this kind of thing which is refreshing. For example he claims he only vaguely understands time complexity ("nested loops are bad"). I don't know exactly what point I'm making here, besides there can be a disconnect between a developer interview process and what people actually contribute. I think engineers should strive to be solid at the fundamentals, but at the same time there are very productive people who just learn as they go. Also, it takes a village so to speak, and over-optimizing for Comp Sci majors who drill LeetCode may not be the best long term choice for building teams either.
- kyawzazaw 6y ago
  Now you got me wondering how people who got more well known creating open source projects go through hiring process at these big tech cos. I know creator of Homebrew still had to go through typical google interview. I am talking about people like Jon Gjengset who got hired to work on Rust at AWS.
- andrewingram 6y ago
  He was hired at the same conference at which he showcased Redux for the first time (as a byproduct of the content of his actual talk, which was time-travel debugging), so it's unlikely it directly gave him the cred necessary to get hired, since he was already in the hiring pipeline.

idkat 6y ago

Well it makes perfect sense to me why React keeps reinventing the wheel every other version and why it's a hot mess. This video makes more sense now as to why they don't seem to have any direction https://www.youtube.com/watch?v=iRo18pUs61Q https://www.youtube.com/watch?v=iRo18pUs61Q. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.

arcturus17 6y ago
I have absolutely no clue what you're rambling about, but if frontend dev shouldn't consume braincells, you go on and code a complex frontend in vanilla JS and then serve that plate of hot spaghetti to the devs coming after you.
richeyryan 6y ago
That video is quite poor in my opinion. He comes so close to a bunch of very interesting questions like how can state management and effect management be done in a good, scalable way that maybe isn't tied to our view libraries? He then admits he has close to no opinion on the matter and suggests web components which is about a step above the jQuery scenario he described in the beginning. The way I see it the advent of React was basically a rejection of the imperative MVC model that was prevalent with the likes of Backbone in favor of a more functional one. The first prototype of React was written in Standard ML. The evolution over the years with flux, redux and hooks was basically answering the questions that were arguably solved in MVC already but coming from the angle of declarative, immutable approaches. Where does state live? How do I handle asynchronous effects? How do I abstract that behavior from my views? I don't think the community has answered those questions definitively yet and a lot of the interest seems to be in refining the view mechanics with the likes of Svelte rather than really getting to grips with how to best handle long lived application state and the effects that operate on it. One thing I could see being the case in a couple of years, and in some ways the video does reach this conclusion, is that the reactive, stateful layer will be abstracted from the view and how you render your data will be almost like choosing a templating engine on the server. It could be React, Vue, Svele, Marko, Web Components, whatever. Those libraries and components will handle your dropdowns opening and closing and your tooltips showing but your real application state that distinguishes your product from another will live somewhere else and will be less subject to churn.

colmvp 6y ago

I don't think you're a gatekeeper, I just don't see the relevance to the author. He's a library designer and is working with a team maintaining and updating one of the most popular Javascript libraries in the world. He has a very deep background in that language which is one of the most important skills for his role. I don't blame him for not knowing some of those things you listed more deeply. There's only so many hours a day to dig deep into a wide range of material. You still have to spend time going into other material that might be more relevant to the day to day including testing, managing people, communication with team members, planning, etc. Yeah sure I'd love to be more knowledgeable about CORS or networking, but I also want to be much stronger in Javascript, the JS library I'm working on, design patterns, deployment, etc. Lastly, I'd rather be in Abramov's shoes where my work profoundly influenced web development than be all over the place with my 'expertise' and not actually be all that impactful with my time.

clashmeifyoucan 6y ago
Seconded, also reading the list, it's likely he just delved deep enough to solve the issue at hand and then back to work. I can relate to that a bit, especially CORS since I never bothered to see what was up with that at a deep level either. Honestly just used a module for Flask when needed to get it working there and set up a CORS proxy on a cloudflare worker for a different project and called it a day. Maybe that's how it went with him too. I'd call this something like "Laze Driven Development"—learning just enough to solve the problem (like my experiences with bash scripts).

yladiz 6y ago

If your speciality is frontend JS engineering, why are deployment, platforms, and networking (unless you simply mean how to use fetch/XMLHttpRequest) large holes? I'd even question graphics APIs beyond very basic knowledge, because in my experience I've never needed to know anything about those beyond the basics. These things sound more like full stack, rather than frontend.

jiofih 6y ago
Yes, networking as in fetch/XHR, web sockets, HTTP, REST, protocols, performance and so on. How your frontend code runs. All I mentioned are strictly frontend skills, not anywhere near full-stack.

johnfn 6y ago

I mean, this is Dan Abramov we’re talking about. Ya know, the guy who created a good chunk of React. I’d say he built actual products for the web just fine.

jiofih 6y ago
He is not one of the React authors, common misconception (his bio says “I didn’t make react” as a nod to that). He wrote the Redux library. Not that I would care either way - this is about skill sets and not personalities.
- yreg 6y ago
  Abramov is the #1 contributor[0]. I guess by authors you mean only the innitial people who came up with React? [0] - https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors
- skinnymuch 6y ago
  He did create a big chunk of React. Half of the Github issues I see for React have him involved. He might not be a founder of React, but he sure is a major React author.

names_are_hard 6y ago

I think the point is that frontend engineering is a broad field, and everyone had gaps in their knowledge, especially specialists who focus on specific parts of the stack. It's possible to provide a ton of value on very complex frontends without doing much in the way of CSS, for example. I've been part of projects where the UI layer was handled in a dedicated library, and unless you wanted to be part of that team, you didn't have to understand much more than which React components to use when. Graphics are a specific subfield of frontend that isn't relevant to most apps, and it's possible to go very far without being exposed to these.

burade 6y ago

That's nonsense. The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.

ogre_codes 6y ago

> you’ll most definitely need those when building actual products for the web. You should take a good look at who posted the article. Fundamentally, who he is and what he's done in the community is the context of the blog. Without understanding that, you miss the entire point.

jiofih 6y ago
I know exactly who posted the article, thank you. I simply disagree that you can be a frontend engineer in the usual meaning it has without some level of those skills. Doesn’t mean anyone is less capable, deserving or cannot make a living that way.
- ericmcer 6y ago
  But he is literally one of the most successful front end engineers of all time and lacks those skills. Your takeaway from the article is it’s antithesis.
  - jodrellblank 6y ago
    I simply don't believe he lacks those skills. He says "Python. I feel bad about this one — I have worked with Python for several years at some point and I’ve never bothered to actually learn it." He's skilled at JavaScript and C# and worked with Python for years, what's the betting he's as good as any typical Python developer, if not better? Pretty good, I'd think. > "I struggle to read either LISP-inspired (like Clojure), Haskell-inspired (like Elm), or ML-inspired (like OCaml) code" How many people don't know Haskell but can successfully struggle through reading it instead of having their eyes glaze over and completely refuse to try? > "CORS. I dread these errors! I know I need to set up some headers to fix them but I’ve wasted hours here in the past." "I don't know it - but I've also worked on it and know how to fix it and done so" - hmmmm. I suspect he is more capable than he's making out; politely talking himself down.
    - ogre_codes 6y ago
      > I suspect he is more capable than he's making out; politely talking himself down. Why? If you are heads down working on core Javascript technologies, why do you step over and dig into learning more than the basics of Python? Likewise most of these languages/ skills.