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

91–100 of 299 posts

Re: A Modern JavaScript Tutorial

#91

Post by sundarurfriend »

auganov wrote: post #84
halfmatthalfcat wrote: post #72

Earlier quoted context omitted.

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.

This is pretty much how I feel about Javascript itself.

Re: A Modern JavaScript Tutorial

#93

Post by yarosv »

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

Earlier quoted context omitted.

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.

That's easy. `b` stands for file

Re: A Modern JavaScript Tutorial

#94

Post by hn_throwaway_99 »

DrScientist wrote: post #75
halfmatthalfcat wrote: post #72

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…

> Surely in the end it just adds complexity and fragmentation of the ecosystem?

Lol. I switched to TS from pure JS a couple years ago and could never imagine going back. I am so much more productive in TS than JS:

1. Typeahead is crucial, and even when just working on my own projects it makes me much faster.

2. Refactoring is a scary nightmare in pure JS, but so much easier with TS.

3. I have yet to see any sizable, multi-person pure JS project not become an incomprehensible nightmare after a couple years. TS makes large codebases much easier to maintain.

There are other reasons.

If anything, the consolidation onto TS from previous competing type systems for JS (e.g. I think Flow is dead for all intents and purposes, and I've seen a number of projects migrate onto TS from Flow) results in less fragmentation.

Re: A Modern JavaScript Tutorial

#95

Post by postalrat »

golergka wrote: post #57
postalrat wrote: post #41

Earlier quoted context omitted.

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

const [result1, result3] = await Promise.all([task1(), task2.then(res => task3(res))])

Could that be written

  const task2then3 = async () => task3(await task2());
  const [result1, result3] = await Promise.all([task1(), task2then3()])

Re: A Modern JavaScript Tutorial

#96

Post by postalrat »

Rumudiez wrote: post #78
postalrat wrote: post #44

Earlier quoted context omitted.

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

Much cleaner. You can go even further by using point-free style: get().then(set) It's the try/catch blocks that make async/await truly worse than native promises. I use them sparingly because so often the .then syntax is both clearer and terser.

What don't you like about try/catch? I find the opposite true, the .then/.catch is more confusing.

Re: A Modern JavaScript Tutorial

#97

Post by weaksauce »

jonnycomputer wrote: post #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.

It was tongue in cheek though... the summary tells you as much.

Re: A Modern JavaScript Tutorial

#98

Post by DrScientist »

rictic wrote: post #81
DrScientist wrote: post #75

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…

As I said, it's not a bad attempt, and it's presence has probably given renewed impetus to js lang improvements.

Though the attempts at close compatibility mean it's not properly type safe despite it's name.

In the end, it's still a 'splitter' to quote Monty Python.

Re: A Modern JavaScript Tutorial

#100

Post by kinjba11 »

ornornor wrote: post #82
Philip-J-Fry wrote: post #33

Earlier quoted context omitted.

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?

Short variable names make code more readable in some scenarios, not less.

  fooBarBazThings.each(t => t.DoThing())
  for (int i = 0; i
Some local code patterns are seen so often you understand it in one go. Something like

  fooBarBazThings.each(fooBarBazThing => fooBarBazThing.DoThing())
  for (int thingIndex = 0; thingIndex
Just clutters things up.
Post reply on HN