Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

81–90 of 299 posts

Re: A Modern JavaScript Tutorial

#81

Earlier quoted context omitted.

Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.

Because it fails to meet the 'it's the platform stupid' maxim. ie languages aren't nearly quite so important as the platform. Stuff wasn't written in js because early js was a brilliant language - it was because the platform - the web - was brilliant. Many have written 'better' languages that compile to js - https://github.com/jashkenas/coffeescript/wiki/List-of-langu... and while typescript is one of the better, mor…

Unlike other languages, typescript adds zero runtime overhead, and the APIs that one writes in TS are trivially consumable from JS. Consuming JS from TS is also made as easy as possible, including the option to set types aside entirely for some parts of your code using the "any" type, which means "don't type check this, just trust me that it works".

TS really is different from other compile-to-js languages in this respect.

Re: A Modern JavaScript Tutorial

#82

Earlier quoted context omitted.

Interestingly Golang encourages one letter variable names and it's not sarcasm this time : https://github.com/golang/go/wiki/CodeReviewComments#variabl... Golang's landscape is full of one letter variables and abbreviations and it's not great.

It's only encouraged within certain contexts. Like it says, short lived stuff can be named "x" or "i". We already do this in almost every language. "c" for "count" or "i" for "index" isn't specific to Go, I've seen and done that in every language I've used. Stuff that isn't easily understood should be named appropriately but shortness is encouraged. If you're storing an index in a global variable or a struct field th…

I never understood that. Is it really that hard to spell out full variable names? It’s so much more legible, there is autocomplete on virtually any editor (even the ones that aren’t IDEs), and you write code once but read it hundreds of times. Why even try to save 8 bytes at the expense of readability?

Re: A Modern JavaScript Tutorial

#83
I looked at this page first and assumed that it was all a gag.

https://javascript.info/ninja-code

>Show your original thinking! Let the call of checkPermission return not true/false, but a complex object with the results of the check.

>Those developers who try to write if (checkPermission(..)), will wonder why it doesn’t work. Tell them: “Read the docs!”. And give this article.

Re: A Modern JavaScript Tutorial

#84
post #69

Isn’t step 1 of “modern JavaScript” to install TypeScript? :)

Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.

Pretty annoyed with Typescript too. Mostly because of its popularity.

Before Typescript most compile-to-js languages existed in their own world. You might have not liked them. But you'd never have to deal with them.

Typescript has become so popular that many top javascript libraries use it too. Whatever you think of it, sooner or later you'll be working with Typescript code.

Re: A Modern JavaScript Tutorial

#85
post #43

I'm surprised I haven't seen this before - it's been under very active development since 2015 and has 11,000+ stars on GitHub: https://github.com/javascript-tutorial/en.javascript.info/gr...

Even more surprising, it's been submitted umpteen times before:

https://news.ycombinator.com/from?site=javascript.info

I sometimes wonder what are the dynamics that trigger the snowball on HN.

Re: A Modern JavaScript Tutorial

#86
post #69

Isn’t step 1 of “modern JavaScript” to install TypeScript? :)

Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.

It's terrible. The amazing issues that TS can introduce to a codebase are terrifying, and TS has breaking releases on a regular cadence. As someone who has to do maintenance on a legacy TS platform it was miserable and literally involved flipping through TS versions to find one that worked.

My issues are not with strongly typed languages, they're specifically with TS.

Re: A Modern JavaScript Tutorial

#87

Earlier quoted context omitted.

Honestly, it’s fine if documentation goes out of date, otherwise what’s the point of writing anything at all? The onus is on the reader to check the publish date of what they are reading, and to cross reference it with other sources to ensure accuracy.

I'd be careful about relying on "updated" dates too heavily. As a professional technical writer, I've seen that some people bump the "updated" timestamp for any update, no matter how small. At other times it's bumped automatically by the build system. I think the best practice is to only bump the timestamp for substantial updates, or to use an explicit changelog at the bottom of the doc. But that practice isn't stand…

I encounter this "article update" problem a lot with Java blogs... Baeldung instantly comes to mind. Every article I find there was last updated on 2020, but don't seem to have actually changed.

Re: A Modern JavaScript Tutorial

#88

Oh no! It's already out of date! (That's a JS changes too fast joke) But seriously, calling it 'modern' is pointless. It's not adding anything valuable and its just going to become out of date (and thus wrong).

It's not pointless. In the context of JS 'modern' generally means es6+ or node as opposed to es5.

just say es6, though, i guess?

Re: A Modern JavaScript Tutorial

#90
post #81

Earlier quoted context omitted.

Because it fails to meet the 'it's the platform stupid' maxim. ie languages aren't nearly quite so important as the platform. Stuff wasn't written in js because early js was a brilliant language - it was because the platform - the web - was brilliant. Many have written 'better' languages that compile to js - https://github.com/jashkenas/coffeescript/wiki/List-of-langu... and while typescript is one of the better, mor…

Unlike other languages, typescript adds zero runtime overhead, and the APIs that one writes in TS are trivially consumable from JS. Consuming JS from TS is also made as easy as possible, including the option to set types aside entirely for some parts of your code using the "any" type, which means "don't type check this, just trust me that it works". TS really is different from other compile-to-js languages in this re…

It adds in developer overhead and for someone writing in JS that is often what you are trying to minimize.
Post reply on HN