While I use `const` for a lot of my variables that I don't want to change it feels super-super wrong.
What feels wrong about it?
You wouldn't declare your in-scope variables as `const` in C/C++/C#/Java wold you?
Making the Most of the JavaScript Language (2016)
31–40 of 47 posts
Re: Making the Most of the JavaScript Language (2016)
#32Earlier quoted context omitted.
What feels wrong about it?
You wouldn't declare your in-scope variables as `const` in C/C++/C#/Java wold you?
In C++ I always do, everything is 'const auto &' if it can be. C# const is different, it's more like C++ '#define'.
Why wouldn't you always go for the most immuatable declaration? Even in C++, where you can have 'const int f(const int y) const;' it's still worth using even though you have to type it a few times.
Re: Making the Most of the JavaScript Language (2016)
#33Earlier quoted context omitted.
Typescript with TsLint is a godsend on larger codebases. It makes JavaScript into a pretty solid language for big projects. Without it you frequently run into objects passed to you after going through 10k lines of code and it becomes a wicked game to figure out which properties the object actually has at that point. JavaScript, even ES6, is IMO crap for large codebases. Does this object have the property I'm looking…
The true source of your problems there are mutation, which in my opinion is the primary source of issues. Immutable data structures being the most benefit. I also believe dynamic language tooling has regressed.
> I also believe dynamic language tooling has regressed.
I'd truthfully love to hear more about that. Care to elaborate?
Re: Making the Most of the JavaScript Language (2016)
#34Earlier quoted context omitted.
The big deal of an arrow function, brevity aside, is that it inherits the value of 'this' from the scope that creates it. Regular functions do not, so to use them as first-class functions you often have to bind before passing, pass around thisObjs for rebinding, do a 'that = this' type trick, etc. Same goes for 'arguments', though that comes up less. Basically, they're much more representative of a simple lambda than…
What's wrong with explicitly binding the scope? I really like that in JavaScript you have to be explicit about that kind of thing.
The syntax of the arrow function does a great job of making this explicit too. On top of that it offers 1) brevity/ease of use, and 2) standardization.
From my experience at least, binding to the outer/creating scope is something I do very often, and as far as I know my use of JS is pretty idiomatic.
Concerning 1, being able to use terser, clearer syntax for something I do so often is a huge win, and in regards to 2, it's nice to see an arrow function and to immediately know what this means, and hella better than having to search for a .bind(), var self = this, var that = this, Car.method(), etc, all equally valid as an approach, and depending entirely on the whims of the programmer behind this code.
Re: Making the Most of the JavaScript Language (2016)
#35Earlier quoted context omitted.
Transpilation is wonderful but it does add a lot of complexity to the build chain. I'm with you the language features are worth it but it's just a quirk of developing for browsers that they don't move as fast as JS itself and that all of this extra machinery is necessary.
Not sure that's true anymore with TypeScript. They made a real focus on tooling and it's been widely adopted. In intellij it's as simple as turning on the option and creating a .ts file, the identically named js file is then dropped in the same directory (by default) and you just include that. It's about 2 minutes from start to finish to setup. Then it's a natural progression to using https://www.typescriptlang.org/d…
> Not sure that's true anymore with TypeScript.
Excellent point, and one of the less-advertised benefits of using TypeScript.
I tend to use Babel/Webpack in most of my projects, mostly because I have the time to waste on keeping up with the 'bleeding edge' and I kind of enjoy it (in perhaps a slightly masochistic way).
That said, more than once I picked TypeScript for some project not primarily because of its main purpose, but rather because it offered a simple way to transpile 'ESNext' to ES5. Despite the fact that a basic Babel/Webpack setup is second nature to me now, it still feels easier to just use TypeScript to do all of it at once, and get types as part of the deal!
Re: Making the Most of the JavaScript Language (2016)
#36Classical inheritance is useful in JS sometimes, but I agree with the sentiment of "don't use it unless you have a reason to".
Ya, that part I don't agree with. Especially since he also says to use ES6 features, which includes the new class syntax, making it a lot more straightforward to use classes + inheritance (even if it's still prototypical under the hood).
I suppose it could be considered more 'general' programming advice, not specific to JS. At least here on HN there seems to be a consensus that classical inheritance more than 1 layer deep is a bad idea (correct me if I'm wrong though, dear HN readers and writers!).
Personally I'm a huge functional programming weenie for no reason I can coherently defend, so I prefer to avoid ES6 classes. But quite often they end up being the most reasonable solution to my problem, and having syntax for it is great. I just avoid them by default.
Re: Making the Most of the JavaScript Language (2016)
#37Earlier quoted context omitted.
Not sure that's true anymore with TypeScript. They made a real focus on tooling and it's been widely adopted. In intellij it's as simple as turning on the option and creating a .ts file, the identically named js file is then dropped in the same directory (by default) and you just include that. It's about 2 minutes from start to finish to setup. Then it's a natural progression to using https://www.typescriptlang.org/d…
> Not sure that's true anymore with TypeScript. Excellent point, and one of the less-advertised benefits of using TypeScript. I tend to use Babel/Webpack in most of my projects, mostly because I have the time to waste on keeping up with the 'bleeding edge' and I kind of enjoy it (in perhaps a slightly masochistic way). That said, more than once I picked TypeScript for some project not primarily because of its main pu…
Yep and TS makes it trivial to target old JS versions and in 2.4 you can use the type inference on normal JS as well.
Its all a win.
Re: Making the Most of the JavaScript Language (2016)
#38Earlier quoted context omitted.
Typescript with TsLint is a godsend on larger codebases. It makes JavaScript into a pretty solid language for big projects. Without it you frequently run into objects passed to you after going through 10k lines of code and it becomes a wicked game to figure out which properties the object actually has at that point. JavaScript, even ES6, is IMO crap for large codebases. Does this object have the property I'm looking…
Typescript is essential for large codebases / many devs. > My company has abandoned JavaScript wholesale with great relief. If it was a physical object we would have tossed it off the balcony. I would like to do the same with our gigantic SPA-ghetti.
There's no time like the present to start! Typescript's allowJS compiler option and comment-based approach lets you start with the spaghetti you have and slowly transition to Typescript.
(Though I'm still fan of the "rip off the Band-Aid" approach I used in a few projects back in the day: rename every .js to .ts and then fix compiler errors until things compile. allowJS is a great option now.)
Re: Making the Most of the JavaScript Language (2016)
#39I disagree on "avoiding classical inheritance", though I didn't drink the functional programming kool-aid so what do I know. That aside, I like the article, JS is my second favorite language and I'v never gotten the hate for it. I'm glad it's improving so much.
Re: Making the Most of the JavaScript Language (2016)
#40Earlier quoted context omitted.
What feels wrong about it?
It's an incredibly verbose way to do what you'd prefer to be the default. val or con would have been better.
Going way back to ancient Lisps `let` has been the const declaration in a lot of programming languages. It's too bad ES2015 decided to use `let` for `var`/`val`, because `let` should have been const.
That said, I've come to terms with const, even if I find I accidentally use let sometimes from time spent in Lisp and F#.