Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

131–140 of 299 posts

Re: A Modern JavaScript Tutorial

#131
post #84

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.

You mean you didn't love Coffeescript?

(I'm joking)

Re: A Modern JavaScript Tutorial

#132

Earlier quoted context omitted.

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 strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?

Sure, what bothers me is how inconsistent it is. Function parameter of type Template is `t` but local variable of type Template is `tmpl`.

Re: A Modern JavaScript Tutorial

#133

Earlier quoted context omitted.

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

I mean, I read it, and assumed the rest of the guide was also tongue in cheek.

Every single example on that page was clear bunk -- showing the worst habits of some developers, and making clear why they are terrible.

I think if you've gotten as far as that chapter, it would be pretty impossible not to realize it was tongue in cheek.

At the top of the page is a big warning triangle that says "Irony detected."

No other chapter includes such a prominent warning. I think it's pretty clear that the "gag" is specific to that chapter.

Re: A Modern JavaScript Tutorial

#134
post #71

Earlier quoted context omitted.

I, as a JS dev of 10+ years, wouldn't consider this "modern". I didn't see - for in loop - for of loop as a couple examples, and those have been around for at least a few years now. There's probably more missing too. To what the above person said. The usage of "modern" or "latest" or similar is going to fall behind and make for bad searching.

> - for in loop - for of loop It's 2020 and you still use loops? ;-) source: https://github.com/buildo/eslint-plugin-no-loops

for/of is an iterator. It consumes the Symbol.iterator interface and is totally different from the for(i++) statement.

That eslint rule is a good example of a cargo cult. The second link in its rationalization argues for using underscore over touching a dangerous loop yourself.

Re: A Modern JavaScript Tutorial

#135

Earlier quoted context omitted.

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.

try/catch introduces new block scopes and interrupt control flow. I find this example very readable, but expanding it into try/catches would make it rather long winded and harder to see the pattern at work as you extend the sequence:

    get()
        .then(handleResult)
        .catch(useFallbackResult)
        .then(updateState)
I prefer concision and functional expressiveness because it reduces the surface area for writing buggy code. Much like how using map instead writing a for loop can eliminate out of range index bugs, chaining promises brings useful guarantees about how the code I do write can be interpreted.

Re: A Modern JavaScript Tutorial

#136
post #81

Earlier quoted context omitted.

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.

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

Every type checked language I've used, from Haskell to Java to Idris to C++ to Rust has ways to override the type checker (and either do the type checking at runtime, or, as C++ is often want to do, just YOLO it). It's not just the language but the codebase and the norms it and its dependencies use.

Some TypeScript codebases, the types are usually accurate, but not enough to rely on them, so you still need to do runtime checks in many places. In others, if something says (string|null) then you know with confidence that it is either a string or the null value, nothing more and nothing less.

Re: A Modern JavaScript Tutorial

#137
Still fantastic!

When I teach Javascript to students, javascript.info is one of the main sources I use besides MDN.

PS My copy of JS the good parts is getting a bit dusty somewhere in the garage...

Re: A Modern JavaScript Tutorial

#138
post #112

Earlier quoted context omitted.

> 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,…

What text editor did you use before? I think the biggest advantage is an IDE, not the language itself.

As a daily user of IntelliJ IDEA—which, IME, has the best autocomplete and code suggestions of any IDE for dynamically typed languages—there is a world of a difference between the quality of suggestions for a codebase using TypeScript and one written in vanilla JS. Without concrete types, the IDE often has to guess the possible type(s) that a value can have, whereas with TS, there is (generally) no such ambiguity.

Re: A Modern JavaScript Tutorial

#140

> According to your browser language headers, you know Chinese. Please help to translate the tutorial into your language! Thank you! I'm curious. How are my language preferences exposed through HTTP headers? I think this was a charming way to request volunteers for translation, but I was a bit taken aback.

Is your next thought after having your curiosity piqued not, "I should look at what headers my browser is sending", or "I should type 'browser language headers' into a search engine"? I'm trying to understand what sort of things lead people instead to think, "I should type a question about 'browser language headers' into a comment box on an off-topic thread, wait for a response, and then go back and check what the re…

I've done this more than a few times because this is a good community to get direct answers from when it comes to questions like the OP's.
Post reply on HN