5 ms·

Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes

Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect

ljm 6y ago
React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.
- brundolf 6y ago
  In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generalized understanding. What you describe here is extremely true; I've seen it in practice: > any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself I've talked with otherwise very capable JS devs who have built impressive things with multiple frameworks, but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax (they may have only ever used one), how Promises behave outside of a narrow subset of situations, what NodeJS actually is (despite having used it), or even the difference between passing by reference vs value. Many of these frameworks create such a narrow lens into the language itself, add what are effectively (sometimes literally) their own DSLs on top, sprinkle in some magical behavior, and when all is said and done you hardly end up using JS at all. Obviously there's a benefit from doing things this way or it wouldn't have happened. But I can't help but think the technologies that work well for industry are having a detrimental effect on a generation of new programmers.
  - searchableguy 6y ago
    > even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.
    - brundolf 6y ago
      When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference. And this applies to comparisons too: when comparing objects or arrays you are comparing by reference, not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade-offs. I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.
      - Scarbutt 6y ago
        but with objects and arrays you can only pass by reference. It's still pass by value, you are passing the reference of the object as a value.
        brundolf 6y ago
        I'm not sure I agree with your framing of the precise terminology ("passing a reference to an object, by value" vs "passing an object by reference"), but it also isn't important. What's important is this: let a = { foo: "bar" } let b = { foo: "bar" } console.log(a === b) // false and this: let a = { foo: "bar" } let b = a b.foo = "blah" console.log(a.foo) // "blah" This is the kind of misunderstanding that causes insidious bugs.
        slibhb 6y ago
- michaelpb 6y ago
  Very true, while I appreciated React Hooks for making React easier for beginners by avoiding the giant can of worms that is OOP mechanics in JavaScript, they are also very magical and even more framework-specific. That said, vanilla JS can be hard like this as well, especially as "solved" legacy issues still regularly crop up in tutorials and code-bases. Many times I remember helping newer folks with challenges they found online that seemed to them like they were testing hard computer science problems, but were more just trivia to navigate some bad design decisions of JS (eg gotcha problems on "this" / binding, IFFE, hoisting, async/promises/callbacks, to name a few)
- nsonha 6y ago
  I decided that react was going down since the introduction of hooks. Before that I was using higher order component (hoc) perfectly fine and there was even libraries like recompose/recompact that made HOCs more convenient. They're really just functions (no magic, not like quote unquote) and they don't invite devs to convert everything into them and break portability/separation of concerns like hooks do. They're also highly composable (there are no such thing as rules of HOCs), you can pass HOCs as params or put them in conditional code branch or whatever you feel like.
hombre_fatal 6y ago
Meh, beginners are going to spin their wheels when they get to the point where they're trying to build anything, especially using a web/mobile/desktop client framework, because that's 99% of what software development is. Don't feel to bad for them, that's our entire craft. `while(true)` and sorting algorithms are not.
- michaelpb 6y ago
  To clarify, I guess what I'm saying is it's often mistaken that this complexity is somehow intrinsic or unavoidable to the craft, when in fact it's completely avoidable. Bad (but popular) tooling isn't new --- I remember learning PHP4 was like an encyclopedia of gotchas and defensive programming --- but I feel that even a disaster like PHP4 was a lot more approachable for new coders than the state of the art now, and that the skills learned overcoming these things were more portable outside of the framework / language. All of this definitely makes my job more secure, but, I dunno, still feels like a real shame.
littlecranky67 6y ago
The mistake those beginner make is listening to some evagelists that will tell them they need everything, from React, TypeScript to Redux, routers, thunks/sagas etc. As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction. A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value. The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.

ljm 6y ago

React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.

brundolf 6y ago
In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generalized understanding. What you describe here is extremely true; I've seen it in practice: > any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself I've talked with otherwise very capable JS devs who have built impressive things with multiple frameworks, but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax (they may have only ever used one), how Promises behave outside of a narrow subset of situations, what NodeJS actually is (despite having used it), or even the difference between passing by reference vs value. Many of these frameworks create such a narrow lens into the language itself, add what are effectively (sometimes literally) their own DSLs on top, sprinkle in some magical behavior, and when all is said and done you hardly end up using JS at all. Obviously there's a benefit from doing things this way or it wouldn't have happened. But I can't help but think the technologies that work well for industry are having a detrimental effect on a generation of new programmers.
- searchableguy 6y ago
  > even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.
  - brundolf 6y ago
    When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference. And this applies to comparisons too: when comparing objects or arrays you are comparing by reference, not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade-offs. I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.
    - Scarbutt 6y ago
      but with objects and arrays you can only pass by reference. It's still pass by value, you are passing the reference of the object as a value.
      - brundolf 6y ago
        I'm not sure I agree with your framing of the precise terminology ("passing a reference to an object, by value" vs "passing an object by reference"), but it also isn't important. What's important is this: let a = { foo: "bar" } let b = { foo: "bar" } console.log(a === b) // false and this: let a = { foo: "bar" } let b = a b.foo = "blah" console.log(a.foo) // "blah" This is the kind of misunderstanding that causes insidious bugs.
        slibhb 6y ago
michaelpb 6y ago
Very true, while I appreciated React Hooks for making React easier for beginners by avoiding the giant can of worms that is OOP mechanics in JavaScript, they are also very magical and even more framework-specific. That said, vanilla JS can be hard like this as well, especially as "solved" legacy issues still regularly crop up in tutorials and code-bases. Many times I remember helping newer folks with challenges they found online that seemed to them like they were testing hard computer science problems, but were more just trivia to navigate some bad design decisions of JS (eg gotcha problems on "this" / binding, IFFE, hoisting, async/promises/callbacks, to name a few)
nsonha 6y ago
I decided that react was going down since the introduction of hooks. Before that I was using higher order component (hoc) perfectly fine and there was even libraries like recompose/recompact that made HOCs more convenient. They're really just functions (no magic, not like quote unquote) and they don't invite devs to convert everything into them and break portability/separation of concerns like hooks do. They're also highly composable (there are no such thing as rules of HOCs), you can pass HOCs as params or put them in conditional code branch or whatever you feel like.

hombre_fatal 6y ago

Meh, beginners are going to spin their wheels when they get to the point where they're trying to build anything, especially using a web/mobile/desktop client framework, because that's 99% of what software development is. Don't feel to bad for them, that's our entire craft. `while(true)` and sorting algorithms are not.

michaelpb 6y ago
To clarify, I guess what I'm saying is it's often mistaken that this complexity is somehow intrinsic or unavoidable to the craft, when in fact it's completely avoidable. Bad (but popular) tooling isn't new --- I remember learning PHP4 was like an encyclopedia of gotchas and defensive programming --- but I feel that even a disaster like PHP4 was a lot more approachable for new coders than the state of the art now, and that the skills learned overcoming these things were more portable outside of the framework / language. All of this definitely makes my job more secure, but, I dunno, still feels like a real shame.

littlecranky67 6y ago

The mistake those beginner make is listening to some evagelists that will tell them they need everything, from React, TypeScript to Redux, routers, thunks/sagas etc. As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction. A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value. The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.