7 ms·

A few more items added to the kitchen sink that is JavaScript. JavaScript's multi-paradigm approach is one of its strengths, but, in my opinion, a weakness at

by adamkl 6y ago

A few more items added to the kitchen sink that is JavaScript. JavaScript's multi-paradigm approach is one of its strengths, but, in my opinion, a weakness at the same time. It allows people to write JavaScript following whatever approach suits them, which is fine for individual developers and small teams, but expand beyond that and it becomes a big ask for every developer to be up to speed with every feature JavaScript supports. I use and teach JavaScript/TypeScript every day, and its possible to be very productive with it, but I prefer the approaches of Go and Clojure better. Limited languages that support a single paradigm, and support it well.

spanhandler 6y ago
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?
throw1234651234 6y ago
Nobody uses OOP in JavaScript imo (because otherwise, just use TypeScript) except when making games.
brlewis 6y ago
> It allows people to write JavaScript following whatever approach suits them This comment really looks like it's a reply to some article other than this one. Realistically, do you think JS programmers are going to form two camps? x ** y Math.pow(x, y) I don't think so. I think people will just stop using Math.pow. Nor do I foresee a big problem with some numeric constants being written with separators and others not. In the unlikely event there's a problem with either addition, prettier can be enhanced to make it so developers don't need to be up to speed on them.
- adamkl 6y ago
  That's fair. My comment is probably off-base when it comes to the particular contents of this article. I guess I was speaking more to a general fatigue with every new feature that is added to JavaScript/TypeScript. What was so wrong with Math.pow(x, y) that we needed a new operator for it? I think this is a question that could be asked of many additions to JavaScript/TypeScript over the years, and I think every (well-intentioned) addition has contributed to the language's current kitchen sink. New additions don't mean the old capabilities will go away (without breaking backwards compatibility). So yes, some developers will use the new power operator in net-new code, but all existing usages of Math.pow() will remain, and every new developer that learns JavaScript will now need to know both.
  - brlewis 6y ago
    Ideally, JS would have been based on S expressions and consistency would naturally flow from the syntax. But that ship has sailed, and occasionally it makes sense to add a new infix operator for succinctness. https://github.com/tc39/proposal-exponentiation-operator#informative https://github.com/tc39/proposal-exponentiation-operator#inf... With prettier, one can make an old style go away.
  - Silhouette 6y ago
    New additions don't mean the old capabilities will go away (without breaking backwards compatibility). This is something any popular programming language has to wrestle with. There is a lot of merit in Python's philosophy of having one, and preferably only one, obvious way to do something. Otherwise, even if each different way is perfectly good in its own right, you still have more for anyone learning the language to know, and you get different representations of the same idea appearing in the same code base for no particular reason. I do think JavaScript has more of a problem with this than most languages because of its rapid changes and ambiguous standardisation (the de jure of annual ES standards vs. the realities of what is supported in real time in each browser, or Node version, or Babel preset). Does anyone really have time to check whether some new function on Array's prototype or some new syntax like the examples in this article is available in every target they need to support yet? I'm guessing most of us still use Babel in our build process for front-end code, even if the relatively new parts of JS we're using are supported natively everywhere we need them by now. But then you get things like modules and imports, and you still find Node's story with these is a muddle. Things we've taken for granted for years now on the front end don't always work out of the box as you might expect on the back end, and there are at least two competing styles. And this is arguably the most important and fundamental tool a programming language needs for building larger applications!
pansa2 6y ago
> Limited languages that support a single paradigm, and support it well. Yeah, Python got this right when it said "There should be one obvious way to do it". It's a shame the language seems to have disregarded that part of the "Zen of Python" recently.

by adamkl 6y ago

spanhandler 6y ago

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?

throw1234651234 6y ago

Nobody uses OOP in JavaScript imo (because otherwise, just use TypeScript) except when making games.

brlewis 6y ago

> It allows people to write JavaScript following whatever approach suits them This comment really looks like it's a reply to some article other than this one. Realistically, do you think JS programmers are going to form two camps? x ** y Math.pow(x, y) I don't think so. I think people will just stop using Math.pow. Nor do I foresee a big problem with some numeric constants being written with separators and others not. In the unlikely event there's a problem with either addition, prettier can be enhanced to make it so developers don't need to be up to speed on them.

adamkl 6y ago
That's fair. My comment is probably off-base when it comes to the particular contents of this article. I guess I was speaking more to a general fatigue with every new feature that is added to JavaScript/TypeScript. What was so wrong with Math.pow(x, y) that we needed a new operator for it? I think this is a question that could be asked of many additions to JavaScript/TypeScript over the years, and I think every (well-intentioned) addition has contributed to the language's current kitchen sink. New additions don't mean the old capabilities will go away (without breaking backwards compatibility). So yes, some developers will use the new power operator in net-new code, but all existing usages of Math.pow() will remain, and every new developer that learns JavaScript will now need to know both.
- brlewis 6y ago
  Ideally, JS would have been based on S expressions and consistency would naturally flow from the syntax. But that ship has sailed, and occasionally it makes sense to add a new infix operator for succinctness. https://github.com/tc39/proposal-exponentiation-operator#informative https://github.com/tc39/proposal-exponentiation-operator#inf... With prettier, one can make an old style go away.
- Silhouette 6y ago
  New additions don't mean the old capabilities will go away (without breaking backwards compatibility). This is something any popular programming language has to wrestle with. There is a lot of merit in Python's philosophy of having one, and preferably only one, obvious way to do something. Otherwise, even if each different way is perfectly good in its own right, you still have more for anyone learning the language to know, and you get different representations of the same idea appearing in the same code base for no particular reason. I do think JavaScript has more of a problem with this than most languages because of its rapid changes and ambiguous standardisation (the de jure of annual ES standards vs. the realities of what is supported in real time in each browser, or Node version, or Babel preset). Does anyone really have time to check whether some new function on Array's prototype or some new syntax like the examples in this article is available in every target they need to support yet? I'm guessing most of us still use Babel in our build process for front-end code, even if the relatively new parts of JS we're using are supported natively everywhere we need them by now. But then you get things like modules and imports, and you still find Node's story with these is a muddle. Things we've taken for granted for years now on the front end don't always work out of the box as you might expect on the back end, and there are at least two competing styles. And this is arguably the most important and fundamental tool a programming language needs for building larger applications!

pansa2 6y ago

> Limited languages that support a single paradigm, and support it well. Yeah, Python got this right when it said "There should be one obvious way to do it". It's a shame the language seems to have disregarded that part of the "Zen of Python" recently.