Comment by michaelpb | Hacker News Reader

Comment by michaelpb | Hacker News Reader

Parent Full thread

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

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.

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.

> 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.

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.

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.

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.

> 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")

The distinction is that, if JS truly was pass-by-reference for objects, you could change what the reference was pointing to. But you can't.

I agree with you that objects/references are a stumbling block for new programmers in JS. You have to understand how these things work but there's no explicit concept of a reference, which means it can be tricky to learn.

> you could change what the reference was pointing to

That's only true if you're passing the pointer by reference. That's different from passing the object itself by reference.

I did just look up the C++ semantics and learned something: technically reference-arguments don't have to be implemented by the compiler as pointers, though in practice they mostly are. So in that sense it's technically more correct to say that JS works with object pointers and not references. But we're really getting quite deep into the weeds at that point.

https://stackoverflow.com/questions/5893873/pass-by-referenc...

This is the kind of misunderstanding that causes insidious bugs.

That's how all mainstream languages with a GC work, Java, C#, Ruby and Python, it's not particular to JS. And this why why languages like Clojure are nice to work with.

but it also isn't important

It's important if you really want to know why your examples work they way they do.

I have been very curious about clojure. What do you feel is the most attractive part about it?

> it's not particular to JS

We're specifically talking about new programmers who haven't used any of those languages, and who are being reared in the JavaScript ecosystem where certain patterns reign that obscure this language behavior. That's what the original discussion was about.

> It's important if you really want to know why your examples work they way they do.

It's really not. Pass-by-reference and pass-a-pointer-by-value are subtly different concepts even in the C++ world, and using terminology that involves the word "pointer" opens up a whole other can of stuff that needs explaining.

> When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference.

A variable stores reference to the original object and when you pass it to a function, it passes the actual reference as the value.

I think the last part you mentioned is actually confusing in js because lack of clear guidance.

isXyz, Xyz.isXyz, Object.is, and other ways are used in practice to do the same thing but they all have different behavior which trips people.

Everything in JavaScript is passed the same way, whether primitive values or objects. Trying to graft a distinction between pass-by-value and pass-by-reference on top of this single passing method is unlikely to do anything other than confuse people learning JavaScript.

You're talking about the call site; I'm talking about the semantics. There is undeniably a crucial semantic distinction, whatever terminology you want to use to talk about it.

You don't pass by reference in JS. You pass references by value.

Passing by reference has a well defined meaning in computer language terminology. It means passing something that references the variable outside the function. Something you can't do in JavaScript

    void someFunc(ref int v) {
      v = 456;
    }

    var foo = 123;
    someFunc(foo);
    write(foo);  // output 456

Above we are not passing 123 (the value of foo) into someFumc, we are passing a reference to foo. This is what pass by reference means.

same if foo was reference to an object

    void someFunc(ref Object v) {
      v = someOtherObject;
    }

    var foo = someObject;
    someFunc(foo);
    // foo now refers to someOtherObject

In this impossible in JavaScript. It does not have the concept of pass by reference. It only has pass by value

    function someFunc(v) {
      v = someOtherObject;
    }

    var foo = someObject;
    someFunc(foo);
    // foo still refers to someObject

Above the value of foo, which is a reference to someObject, that value is assigned to v in someFunc. v's value is set to reference someOtherObject. foo's value is still someObject as there is no way to "pass by reference" in JavaScript

Great explanation of something that has caught me out multiple times (I occasionally dabble in JS).

Having spent my career in languages with pass by reference it feels unnatural not to have it. I suspect if I started with JS this wouldn't be such a problem.

I would argue that Javascript is a hybrid of pass by reference because of the case below though.

    function someFunc(v) {
      v.myvar = 456;
      v = someOtherObject;
    }

    var foo = someObject;
    foo.myvar = 123;
    someFunc(foo);
    // foo still refers to someObject
    // foo.myvar is 456

Banning our team from passing objects around except in specific, discussed, cases got rid of lots of difficult to track down bugs.

You'd be wrong. Again "Pass by reference" is "well defined" in computer languages.

Passing a reference to an object is not "pass by reference". Your example works the same in Java and C# and probably Swift and many other languages. But you aren't "passing by reference". "pass by reference" specifically means passing a reference to the variable, not the variable's value. Javascript always passes the value of the variable, it has no ability to pass a variable by reference.

I definitely think the tendencies you’re describing are maximized in the JS ecosystem, but it isn’t clear to me if it’s something about the specific language or culture/tooling... or if it’s just where so much of the industry grunt work is getting done.

And so much of the industry everywhere is about “do X to get Y result” and any further reflection is kindof a luxury. How does your package manager work? Part of the point is not to know, which works until it doesn’t. So we all get trained into basically a culture of issuing commands in a manner not too different from the machines we ask to do the work, and developing a model of what’s going on is either bonus study or earned by running your hands over the sharp edges when you’re bucked onto the unhappy path.

Which definitely happens outside of JS. I suspect it happens more inside because JS functions as maybe the biggest funnel into the field.

> but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax

There is more than 2 now. :)

You have the keyword function, you have

const myFunc = (param) => { //body }

and then you have the various types that can occur within a class, which can have a little bit different behavior based on which syntax you use.

Fun times!

And remember, arrow functions within a class have a this, but arrow functions outside of a class don't have a this!

> And remember, arrow functions within a class have a this, but arrow functions outside of a class don't have a this!

This is not correct. Arrow functions have the `this` value of the outer context.

I recommend this article to understand `this`: https://web.dev/javascript-this/

> This is not correct. Arrow functions have the `this` value of the outer context.

You are correct, I wasn't clear. I was describing the end effect of free floating arrow functions VS an arrow function declared within a class.

When free floating, trying to access 'this' can (will) result in unexpected behavior, when inside a class arrow functions operate exactly as people expect a class member function to operate in other languages. (In contrast to having to otherwise bind JS functions to 'this')

In both cases the arrow function is acting the same way, but most intro to JS lessons don't explain it.

Indeed the way it was originally explained to me is that "arrow functions in classes auto bind to this" which is hilariously inaccurate, but the end effect is as if that was happening.

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)

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.

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.

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.

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.

Reply on news.ycombinator.com