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

151–160 of 299 posts

Re: A Modern JavaScript Tutorial

#151

Post by resu_nimda »

pwdisswordfish4 wrote: post #74
dhruvarora013 wrote: post #37

Earlier quoted context omitted.

I think this is a little harsh. The comment does point out a feature on the topic site. I'm personally glad that they brought it up because as an English speaker I didn't see this feature exposed. Internationalisation is a complex yet required feature for large websites these days, and a clever feature like this to find translations is great!

> I think this is a little harsh Only if you read the question and assume that it is something besides a question. How does a person ask the question that I asked and mark it unambiguously as a question, not a statement (and do it without unnecessary baggage)? How do I convince people to answer the question instead of reply the way you did, to something you received instead of what I asked? Is that question not toler…

It comes off as condescending. Generally, being incredulous of the way someone thinks isn't a respectful way to engage with them (I'm sure most of us are guilty of it at times, but usually in frustration with people that we have a personal relationship with). If you're going to ask someone something that might offend them, I would suggest starting with a show of goodwill. Also, extensive use of hypothetical "thought-quotes" is very easily construed as mocking or belittling, even if you were just trying to be precise about your meaning.

A better way to ask might have been: "I'm curious, and I don't mean to be rude, but what caused you to post this comment here instead of searching for the answer?"

Re: A Modern JavaScript Tutorial

#152

Post by hanoz »

longnow wrote: post #146

There is a chapter called ‘ninja code’, which is full of terrible advice. A small example. > The ideal name for a variable is data. Use it everywhere you can. There is one small comment at the top of the chapter, which says ‘Irony detected’. Is there really a whole chapter written Ironically? It would be very easy to read this and think it was real advice. (And if it is real advice, and I’m completely misunderstandin…

>There is one small comment at the top of the chapter, which says ‘Irony detected’.

The whole chapter is littered with clearly tongue in cheek remarks.

Re: A Modern JavaScript Tutorial

#154

Post by names_are_hard »

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

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.

What issues does TS introduce into a codebase that weren't already there? This sounds kinda like arguing that if we write fewer tests we'll have fewer bugs.

Re: A Modern JavaScript Tutorial

#155

Post by earthboundkid »

speedgoose wrote: post #121
earthboundkid wrote: post #106

Earlier quoted context omitted.

That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?

template, bytes, string.

`bytes` is the name of a stdlib package. `string` is the name of a built in type. `template` is technically available, but only because it’s the name of this package, so it can’t refer to itself.

Re: A Modern JavaScript Tutorial

#156

Post by ehutch79 »

hanoz wrote: post #152
longnow wrote: post #146

There is a chapter called ‘ninja code’, which is full of terrible advice. A small example. > The ideal name for a variable is data. Use it everywhere you can. There is one small comment at the top of the chapter, which says ‘Irony detected’. Is there really a whole chapter written Ironically? It would be very easy to read this and think it was real advice. (And if it is real advice, and I’m completely misunderstandin…

>There is one small comment at the top of the chapter, which says ‘Irony detected’. The whole chapter is littered with clearly tongue in cheek remarks.

People will absolutely not get that and take the advice to heart.

Re: A Modern JavaScript Tutorial

#157

Post by lucideer »

longnow wrote: post #146

There is a chapter called ‘ninja code’, which is full of terrible advice. A small example. > The ideal name for a variable is data. Use it everywhere you can. There is one small comment at the top of the chapter, which says ‘Irony detected’. Is there really a whole chapter written Ironically? It would be very easy to read this and think it was real advice. (And if it is real advice, and I’m completely misunderstandin…

I understand that often subtleties of language, particularly when it comes to irony or sarcasm, can be lost in textual content (particularly supposedly-formal content like educational materials), and that generally this is something to be avoided.

However, after reading that chapter, I really can't help thinking that you simply weren't paying any attention.

It's not just written in sarcastic tone (something that yes, could be easy to miss for many), but it's also littered with active dissuasion and explicit explanations of the pitfalls of using this style.

Examples:

> If you write like that, a developer who comes across this line and tries to understand what is the value of i is going to have a merry time. Then come to you, seeking for an answer.

> A quick read of such code becomes impossible. And when there’s a typo… Ummm… We’re stuck for long

> A fellow programmer who wants to work with elem in the second half of the function will be surprised… Only during the debugging, after examining the code they will find out that they’re working with a clone!

> First, the code becomes longer and less readable, and the second, a fellow developer may spend a long time trying to figure out what the underscores mean.

You can argue that the chapter is inappropriate, but I don't think you can reasonably argue that it's misleading.

Re: A Modern JavaScript Tutorial

#158

Post by earthboundkid »

drran wrote: post #127
earthboundkid wrote: post #106

Earlier quoted context omitted.

That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?

template, file, text

Is file a file object? A file path?

All three are “the template”. So, they use polish-ish notation: the template as []byte, template as string, and template as *template.Template.

Re: A Modern JavaScript Tutorial

#159

Post by com2kid »

vorpalhex wrote: post #90
rictic wrote: 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…

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

It adds overhead on initial write, saves massive overhead every day after that.

There is JS code I deal with once a month where the manipulation of types is so complex I probably burn ~30 minutes every time I have to touch it. If that was was transformed into TS (which is going to happen eventually) that'd be 30 minutes saved per month, on this one particular flow of data.

I've done refactorings that were only possible because TS existed.

A lot of JS unit tests consist of "ensure these fields exist on this object after it has been called by these functions."

Typescript removes the need for those tests.

And it removes the need to update those tests every time the code changes (just change the declarations appropriately!). And it removes the need to run those tests on every commit.

That said, the overall code/compile/run time savings is possibly not in TS's favor due to how slow the compiler is. :/

Post reply on HN