Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

Post reply on HN
Print view View original

41–50 of 299 posts

Re: A Modern JavaScript Tutorial

#41

Post by postalrat »

golergka wrote: post #15
nailer wrote: post #5

The default way promises are used is now async/await. `.then()` should not be introduced as anything more than 'you may find this in older codebases'.

async/await is excellent syntax when you want things to happen one after another. That's the usual case, and that's what I find myself using 95% of the time. However, when you want a more fine-grained concurrent execution of different asynchronous things, then() still could be very useful.

Can you give an example of more fine grained control with then?

Re: A Modern JavaScript Tutorial

#42

Post by kaycebasques »

This is not a tutorial [1]. It's more like a guide [2].

[1]: https://documentation.divio.com/tutorials/

[2]: https://documentation.divio.com/how-to-guides/

Edit: I don't mention this to be nitpicky. I mention it because I wish that we would collectively start standardizing those terms. I think it would be helpful if, whenever we saw "… guide" or "… tutorial" we had a general idea about the structure and purpose of the contents. The Divio links above do a great job at explaining each doc type. I'm simply sharing this idea for people who have never considered being more careful about how they label their docs and would like to start following general technical writing community practices. As a practicing technical writer I can tell you that the TW community mostly agrees upon what each doc type entails ("tutorials" and "references" have strong consensus; "guides" less so).

Re: A Modern JavaScript Tutorial

#44

Post by postalrat »

nailer wrote: post #5

The default way promises are used is now async/await. `.then()` should not be introduced as anything more than 'you may find this in older codebases'.

  (async () => { set(await get()); })();
 
  get().then(r => set(r));
Ignoring error handling I'll often choose the second option.

Re: A Modern JavaScript Tutorial

#47

Post by wsc981 »

alfonsodev wrote: post #4

The ninja code section is pure sarcasm, right? I'm not sure now which sections are and aren't.

The Ninja code section seem to have been largely based on this classic article, which I personally found more humorous to read: https://github.com/Droogans/unmaintainable-code?fbclid=IwAR1...

Re: A Modern JavaScript Tutorial

#48

Post by speedgoose »

Philip-J-Fry wrote: post #33
speedgoose wrote: post #22

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 and j are very understandle.

I did browse the go code randomly and for example t, s, and b are terrible variable names in my opinion in this example : https://github.com/golang/go/blob/3ce865d7a0b88714cc433454ae...

You can find a lot of code like this.

Re: A Modern JavaScript Tutorial

#49

Post by kaycebasques »

corytheboyd wrote: post #36
cosmotic wrote: post #30

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

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 standardized across docs sites.

Re: A Modern JavaScript Tutorial

#50

Post by emmanueloga_ »

Looks really nice, although ...

For as good as the TOC and layout is, there's always something I miss when I read books from a website. I miss the spatial context: how much material I already covered? How much is left?

I like the linearity of regular books (that includes PDFs). If the book is a website the next best thing for me is when the whole thing is just a single page. Worst thing are epubs :-p (hate the way the layout works with those and how slow epub readers tend to be).

ps. I saw I can buy a PDF of this site, but just commenting in general.

Post reply on HN