4 ms·

One of the goofiest things about JavaScript is how some of its most important and basic features and properties—say, prototypal inheritance and functions-are-ob

One of the goofiest things about JavaScript is how some of its most important and basic features and properties—say, prototypal inheritance and functions-are-objects—fall in the "you should probably never use these in any way that actually leverages their notable capabilities in JS, and if you think you need to, think again, and please... don't" category. The result is that practically no-one wants to write in whatever a "JS native" paradigm might look like. Everyone wants to write it like C, or like Java, or like OCaml, or whatever. Mind, I don't think it's a bad thing people avoid writing "JS native" style, because I certainly don't want to be handed a codebase in which anyone's done anything remotely interesting with prototypal inheritance—it's just something I find interesting about the community of such a popular language.

throw1234651234 6y ago
This. Though pretentious "experts" push it as "a must know for senior JS developers". Same with closures. Sure, it's nice to know when you create a closure by accident, but using it on purpose? Come on. It's all hacks for implementing "private" modules.
- neurotrace 6y ago
  Closures are handy for a number of things. Many event listeners are closures const [username, setUsername] = useState('') const onChange = event => setUsername(event.target.value) const onSave = () => dispatch(saveUsername(username)) return ( <div> <input value={username} onChange={onChange} /> <button onClick={onSave}>Save</button> </div> ) This code contains two closures
  - throw1234651234 6y ago
    1. React is a confusing mess of UI/logic mixing. 2. Where are the closures and what's the necessity to use them?
    - klodolph 6y ago
      1. UI and logic are inherently mixed. It takes a lot of effort and design sense to partially separate them, and trying to completely separate them is ill-advised. If this is confusing, it’s due to the fact that making a modern UI is an inherently complicated problem (and not something that is just made more complicated by frameworks). 2. onChange and onSave are both closures. It isn’t technically necessary to use closures, but you need to find the correct setUsername from onChange, and since setUsername isn’t a global variable, closures are the natural and easy way to do it.
    - spanhandler 6y ago
      > 1. React is a confusing mess of UI/logic mixing. Hooks have shown that Super Serious programming can also be comedy, which is pretty cool.
      - doteka 6y ago
        Don’t think I get how React hooks are comedy. Can you elaborate?
        spanhandler 6y ago
        They're low-level interfaces to a custom property and method lookup table in a language that already has that built-in. I guess it might just be me but I get a little chuckle every time I read/read-praise-about/use them. I dunno, the functions-or-bust crowd happily doing and championing manual OO machinery fiddling amuses me.
        SketchySeaBeast 6y ago
        Does that built-in method lookup table contain all the re-rendering and general state management work that React does with its hook?
        spanhandler 6y ago
        Nah, but that could have been build on traditional methods and properties just as well, without having to re-implement those first. It's not like every component doesn't resolve to an instance of an object anyway. [EDIT] what they couldn't have done, probably, would have been cleanly implementing that on top of class-based components without then having to tell their large and influential functions-are-the-only-way constituency that they'd need to write a lot more classes in the future. I suspect aversion to having to deliver that message is part of why we ended up with hooks as the solution, and classes left behind instead.
  - gabrielsroka 6y ago
    That's not JavaScript. Is it JSX?
    - neurotrace 6y ago
      JSX is just an extension of JavaScript. I wrote React-like code because that's very common right now but this would also be true for more traditional JS. const todoItems = [] addTodoItem.addEventListener(event => { todoItems.push(event.target.value) renderTodoItems() })

throw1234651234 6y ago

This. Though pretentious "experts" push it as "a must know for senior JS developers". Same with closures. Sure, it's nice to know when you create a closure by accident, but using it on purpose? Come on. It's all hacks for implementing "private" modules.

neurotrace 6y ago
Closures are handy for a number of things. Many event listeners are closures const [username, setUsername] = useState('') const onChange = event => setUsername(event.target.value) const onSave = () => dispatch(saveUsername(username)) return ( <div> <input value={username} onChange={onChange} /> <button onClick={onSave}>Save</button> </div> ) This code contains two closures
- throw1234651234 6y ago
  1. React is a confusing mess of UI/logic mixing. 2. Where are the closures and what's the necessity to use them?
  - klodolph 6y ago
    1. UI and logic are inherently mixed. It takes a lot of effort and design sense to partially separate them, and trying to completely separate them is ill-advised. If this is confusing, it’s due to the fact that making a modern UI is an inherently complicated problem (and not something that is just made more complicated by frameworks). 2. onChange and onSave are both closures. It isn’t technically necessary to use closures, but you need to find the correct setUsername from onChange, and since setUsername isn’t a global variable, closures are the natural and easy way to do it.
  - spanhandler 6y ago
    > 1. React is a confusing mess of UI/logic mixing. Hooks have shown that Super Serious programming can also be comedy, which is pretty cool.
    - doteka 6y ago
      Don’t think I get how React hooks are comedy. Can you elaborate?
      - spanhandler 6y ago
        They're low-level interfaces to a custom property and method lookup table in a language that already has that built-in. I guess it might just be me but I get a little chuckle every time I read/read-praise-about/use them. I dunno, the functions-or-bust crowd happily doing and championing manual OO machinery fiddling amuses me.
        SketchySeaBeast 6y ago
        Does that built-in method lookup table contain all the re-rendering and general state management work that React does with its hook?
        spanhandler 6y ago
        Nah, but that could have been build on traditional methods and properties just as well, without having to re-implement those first. It's not like every component doesn't resolve to an instance of an object anyway. [EDIT] what they couldn't have done, probably, would have been cleanly implementing that on top of class-based components without then having to tell their large and influential functions-are-the-only-way constituency that they'd need to write a lot more classes in the future. I suspect aversion to having to deliver that message is part of why we ended up with hooks as the solution, and classes left behind instead.
- gabrielsroka 6y ago
  That's not JavaScript. Is it JSX?
  - neurotrace 6y ago
    JSX is just an extension of JavaScript. I wrote React-like code because that's very common right now but this would also be true for more traditional JS. const todoItems = [] addTodoItem.addEventListener(event => { todoItems.push(event.target.value) renderTodoItems() })