A Modern JavaScript Tutorial

https://javascript.info/

by ivanche • 6 years ago

893 274 6 years ago

javascript.info

viviansolide• 6 years ago

Thanks for sharing. I found this quote very appropriated:

In older scripts, you may also find another keyword: var instead of let

Rumudiez3• 6 years ago

True for reading legacy JS. For newer code, you can still identify noobies (and "experts") by the conspicuous usage of let instead of const.

reificator3• 6 years ago

While I certainly prefer immutability there are many who do not, and that preference does not make you better or more experienced than them.

jsnk• 6 years ago

Excellent resources. Is there one like this for Java?

alfonsodev• 6 years ago

The ninja code section is pure sarcasm, right?

I'm not sure now which sections are and aren't.

jeffmcmahan• 6 years ago

It has an alert at the top that says, "Irony Detected".

Zhyl• 6 years ago

That page has an 'irony warning' so just watch out for those on other pages!

It might just be my sense of humour (I'm the sort of person that doesn't need an '/s' tag and feels that it shouldn't be necessary if you told the joke properly), but it was pretty obvious to me even without the irony warning that the page was intended as a joke.

It looks like it was heavily inspired by the classic 'Tao of Programming' [0]. It uses a very similar style and even quotes the actual Tao Te Ching.

[0] http://www.mit.edu/~xela/tao.html

hutzlibu5• 6 years ago

I am with you on not wanting or needing to see /s ... but on a tutorial, where people actually struggle to understand anything at first read, using unmarked irony is maybe not the most helpful for them.

Oh and a second thought on /s. For some time I only got my news through satire sites like the onion. And after I switched back to "real news" sites, I could not believe it was not satire. I mean come on, the world and the internet was always full of dumb people, but when even very high ranking people and institution say really out of the world things in all seriousness - I came to the conclusion, marking irony as irony is sadly sometimes important, in those interesting times we live ...

colmvp• 6 years ago

The section is clearly dripping with irony. They even have an "Irony detected" box at the very top which acts as the sarcasm/satire tag so many people seem to use to bang over our heads that it's not serious.

speedgoose4• 6 years ago

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.

Philip-J-Fry• 6 years ago

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 then it should be called "index" not "i".

Method receivers are usually always kept short because they're pretty self explanatory and the first thing you look at in a function.

vsareto• 6 years ago

I kind of agree with their reasoning, the exception being when you can have a lot of complicated looping/control flow breaks or transient variables close to their usage. Seeing 'array[i][j][k]' is never fun.

flixic• 6 years ago

It is hilarious. Lao Tzu quotes make it simply perfect.

earthboundkid6• 6 years ago

It is funnier to me because the quotes are actual historical quotes (to be fair, there probably was no "Laozi" historically), whereas you see fake quotes for Laozi/Confucius/Buddha all over the internet.

wsc981• 6 years ago

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

nailer11• 6 years ago

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

jedimastert2• 6 years ago

Can you point to anything other than saying "this is obvious"?

nailer11• 6 years ago

No, just experience with a lot of codebases.

Here's a simple question to ask yourself: what if non-IO operations allowed you to use the .then() syntax? If you have the choice to use:

   1 + 1.then(function(result) { ... }

   const result = 1 + 1

Which would you choose?

ericwood• 6 years ago

Maybe some codebases mandate it, but it's very common to use either style when it makes the most sense. The classic syntax is by no means deprecated or superseded by async/await.

golergka2• 6 years ago

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.

postalrat6• 6 years ago

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

verisimilidude• 6 years ago

That’s probably good general advice.

One problem. I’m increasingly coming across devs who’ve never used Promises directly, only async/await. They’re introducing all kinds of problems into code because they don’t have that foundational understanding of Promises. I think it’s essential to know how Promises work, even if we generally recommend async/await.

Also, Promise interface can do things that async/await cannot, such as Promise.all, and other unusual async execution scenarios. It’s important to have those tools in your belt.

nailer11• 6 years ago

100%, people should definitely understand Promise.all() and Promise.any().

nailer11• 6 years ago

Promise interface can do things that async/await cannot, such as Promise.all

PS I should clarify await and Promise.all/any work fine:

    await Promise.all(items)

throw_m2393393• 6 years ago

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

No, because you might have to write explicit promises in the browser with async API that are callback based.

You need to understand how promises work to use async/await at first place anyway.

Just like it's better to understand how prototypal inheritance works in JS BEFORE even using a single class declaration.

hutzlibu5• 6 years ago

"Just like it's better to understand how prototypal inheritance works in JS BEFORE even using a single class declaration. "

About that, does JS class inheritance now work like classes in java for example? Or is it still just syntactic sugar for the prototype inheritance? By your wording, I assume the later?

nailer11• 6 years ago

Yes because you can and should promisify old libraries.

postalrat6• 6 years ago

  (async () => { set(await get()); })();
 
  get().then(r => set(r));

Ignoring error handling I'll often choose the second option.

Rumudiez3• 6 years ago

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.

nailer11• 6 years ago

OK. I'll do:

  const result = await get()
  set(result)

But you do you.

Current node and console have top level await BTW.

ddoolin• 6 years ago

I've had this site's Regex section bookmarked for awhile and it's been a great tutorial and reference. I can't speak to the other content but if it's similar, it would be of good quality.

robofanatic• 6 years ago

Excellent. Wish all documentation\tutorial sites were this clean.

kaycebasques3• 6 years ago

When you say "clean" are you referring to the formatting of the page?

realyashnag• 6 years ago

and structuring of the content, i believe.

madeofpalk2• 6 years ago

Not sure what OP was referring to, but I find both the formatting and the tone of voice to be exceptionally clean and mature. I am incredibly jealous of the writer's skill to write like this.

forest_dweller• 6 years ago

This site is a great resource. The event delegation section is something I have bookmarked as when entering a new contract I typically don't have access to my own code to use as a reference.

boberoni• 6 years ago

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.

lights0123• 6 years ago

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

jmt_• 6 years ago

The Accept-Language HTTP request header is my guess

croisillon• 6 years ago

I get the same question (after a while) here: https://www.wpf-tutorial.com/

smarx007• 6 years ago

I have figured it out experimentally (Chrome & Ukrainian): if you visit a website in language X and click Never Translate, Chrome silently adds language X to the end of the list (Accept-Language that is). I have not found a way to forcibly turn it off.

Edit: check out chrome://translate-internals/ if you are interested

sequoia• 6 years ago

This was probably set at the operating system level, i.e. you selected "zh_ZH"/Chinese at some point during setup. Upon installing a browser, it reads your OS language preference & then passes that through to websites via the accept-language header.

cosmotic2• 6 years ago

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

corytheboyd2• 6 years ago

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.

kaycebasques3• 6 years ago

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.

willio58• 6 years ago

I think it’s precisely the fact that js is constantly changing that they’ve branded this as “modern”.

simonw2• 6 years ago

Disagree. I've been writing JavaScript for twenty years, and I'm very aware that there's a lot of "new" stuff that I need to brush up on. When I saw it call itself "modern" I instantly assumed that it would be covering the kind of information I need to know.

joshxyz2• 6 years ago

i think it's great on how it brushed on forms and web api's, but in your case it seems exploringjs.com would be a fit (grouped by ecmascript versions).

OTOH out of scope are server-side JS (NodeJS), transpilers like babel, bundlers like webpack, and of course package managers like npm and yarn

wolfadex• 6 years ago

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.

root_axis• 6 years ago

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

jonnycomputer3• 6 years ago

just say es6, though, i guess?

mixmastamyk• 6 years ago

Make a merge request.

0df8dkdf• 6 years ago

to be fair. anything after 'use strict' can be consider 'modern'. However with the rate ES7 - 10 is going. Yeah this wouldn't be modern.

brundolf5• 6 years ago

Nothing will become inaccurate, because JS never introduces breaking changes.

The guide might come to lack some newer things over time, but I doubt those will include any major paradigm shifts, because the past ~10 years have likely been the most dynamic that JS will ever see in terms of idioms and best-practices. JS made a radical shift into a mature language, and now it is mostly on the other side of that transition. So writing a "modern" (post-transition) tutorial makes perfect sense to me, and I don't think it will become irrelevant any time soon.

reificator3• 6 years ago

Nothing will become inaccurate, because JS never introduces breaking changes.

Can you help me debug why `document.createElement('button').attachEvent('onclick', e=>alert('attachEvent!'))` isn't working then?

You might object that DOM APIs aren't part of JS proper and that's true, but this guide covers `addEventListener` on this page: https://javascript.info/introduction-browser-events

Sticking only to JS language features, I assume you can help track down why my `with()` statement doesn't work. Or why `function testing() { console.log(this.location.href); } testing();` throws an error but only if I package my code as an ES Module instead of an AMD bundle.

I agree that breaking changes like this are increasingly unlikely to happen, and I think the changes that have been made are easily net positive. But the claim that they never happen is simply not true.

cosmotic2• 6 years ago

JS (the language) may never introduce breaking changes, but JS (the ecosystem) sure does. With a quite normal react app, breaking changes are a constant battle. Clone the repo, oops, one package was upgraded that broke another; upgrade that one, oops, it breaks another. The package manager is supposed to deal with that, but it (effectively) doesn't.

kaycebasques3• 6 years ago

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

dboreham• 6 years ago

'And thirdly, the code is more what you'd call "guidelines" than actual rules.'

useragent86• 6 years ago

I looked at those links. Here's what I got from them:

1. Tutorials "are lessons that take the reader by the hand through a series of steps." They "are oriented towards learning how."

2. How-to guides "take the reader through steps."

3. "How-to guides are wholly distinct from tutorials."

If I found a "community" around a topic, do I then get to decide what words mean? By consensus, of course.

xixixao• 6 years ago

You can see a good breakdown of what they mean by each label in this table:

https://documentation.divio.com/introduction/#the-secret

It's certainly a valuable take, even if you disagree with the claim that all 4 functions are required for good documentation.

quietbritishjim2• 6 years ago

This is a tutorial. It almost fits the definition of "tutorial" at the link you posted, but not quite, but that's because the definition at the link you posted is a bit flawed. It definitely is not a how-to guide, and the links you posted strongly support that.

How-to guides take the reader through the steps required to solve a real-world problem.

That is from the linked article on how-to guide. By "real-world problem" it means something specific you might want to do to a real code base, like "switch to a different database engine" or "add user authenticaion". That's why it includes the qualification "real-world". The original article definitely does not fall into that category.

* A tutorial is what you decide a beginner needs to know.
* A how-to guide is an answer to a question that only a user with some experience could even formulate.

That was some extra clarification from the linked article on the difference between tutorial and how-to guide. That makes it even more clear that the article is more like a tutorial than a how-to guide.

Tutorials are lessons that take the reader by the hand through a series of steps to complete a project of some kind.

That's from the page about tutorials. The article introduces a reader to a substantial new topic from scratch and guides them through it, but it doesn't do so by making them complete a specific project, so it doesn't fit this definition.

But that doesn't stop it from being a "tutorial". The requirement that tutorials have to involve completing a sample project is invented by the author of that page and not part of the usual definition of that word.

This final point is pure conjecture, but I suspect the author of that page was just trying to strongly encourage people to base tutorials around sample projects. It's fair to encourage that, because often tutorials are improved by basing them around a single unifying project (but not always). But putting it in their definition of the word was a mistake, because that's not what that word means, and it's only created confusion.

ethanfinni• 6 years ago

Do you have a good JS tutorial for beginners that meets the definitions you are proposing to compare and contrast?

simonw2• 6 years ago

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

mekoka2• 6 years ago

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.

codetrotter• 6 years ago

I think time of day, novelty, luck, and whether any mods notice the post and decide to give it a second wind.

By novelty I mean something that is easily recognized as new and important. It doesn’t help that something is new if no one catches the point of reading about it. Could be a bad title or a bad article. Or bad luck.

In terms of good luck I mean a couple of specific things especially:

- If a few people see it that are excited about it, either from hearing about it the first time or from knowing it in the past, and these people write positive comments about it, then others who come across the post may be encouraged to check it out and to upvote it too.

- “Micro zeitgeist”. If it’s about a topic that recently hit the front page and it adds something new about that, it could luck out. Why luck in this case? Because you probably don’t know ahead of submitting that people will care to read even more about some topic even if it was popular the day before. Perhaps instead people are tired of the topic.

- The other things submitted the same day did not gain enough traction to push this thing away.

- Evergreen topics that have not gotten traction in a while but that people care about.

- Topics that people in university and college are currently learning about so it catches their attention. I dunno how big the amount of people currently in university is versus people that are in jobs. But I remember that I learned about HN from some other students in a student union I was in back then. And I don’t know how students HN reading habits are compared to people in jobs either. I remember reading HN a lot when at the university. But I still read HN a lot. These days I read HN in the morning, the evening and at night though, not when I am working. But even if you have a job you might read HN in the lunch break, or perhaps you have some downtime where you are waiting for something at work and you read HN for a while.

There are other possible factors too that I have thought about in the past but these are the ones I can think of right now.

Please note that all of what I am saying here is only my thoughts based on my own habits and from what I’ve heard other people say and what I’ve seen.

emmanueloga_• 6 years ago

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.

joshxyz2• 6 years ago

I think comparing gaps with exploringjs.com (separated by ecmascript versions) would be worth a shot.

OpuRahman• 6 years ago

Needs to be updated on a regular basis.

stasgavrylov• 6 years ago

It's open source and they're actively looking for contributors.

priyatham_• 6 years ago

This site is absolutely awesome and I would suggest this to new comers and experienced folks alike. It covers all things related to javascript, explains the concepts really well in a practical day to day application point of view.

I might be sounding like a promoter for it, but it really added a lot of value for me personally, so just wanted to spread the good word.

arebhaibhai• 6 years ago

I just wish it didn't have Disqus :(

seddin• 6 years ago

The addon Privacy Badger blocks it by default.

nerdponx• 6 years ago

What's wrong with Disqus? Seems relatively benign among things that people might be tempted to force upon the people who use their site.

29athrowaway• 6 years ago

It is a nice tour of JS features.

Some things missing: Typed arrays, template literals, Internationalization API (Intl).

Date will be replaced with TC39 Temporal soon.

cercatrova2• 6 years ago

Note that the Russian version of the site has more information than the English version, you can translate the page into English to read it (or just learn Russian)

polywock• 6 years ago

sighs and opens Russian learning book

Avtomatk• 6 years ago

The Russian version simply adds a CSS section for JS developers and an extra page at the end of the first section, I don't know if the content of the chapters differs from the English version.

cercatrova2• 6 years ago

You're right, the English version is now updated, it used to not be as up to date as the Russian version.

cgrealy• 6 years ago

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

halfmatthalfcat3• 6 years ago

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

DrScientist9• 6 years ago

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, more supported ones, isn't it just another one?

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

auganov• 6 years ago

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.

vorpalhex2• 6 years ago

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.

_greim_2• 6 years ago

I've been thinking a lot about why this is, and I think one reason is because TS adds mental overhead to the language, while simultaneously removing other mental overhead.

However, for JS programmers, worrying about types is habitual. Offloading that task to a robot is great, but it doesn't mean the habit will just disappear. Thus to them, TS seems to mainly add overhead.

tambourine_man• 6 years ago

Hi there.

tenaciousDaniel• 6 years ago

I've spent enough time converting nearly illegible coffee script back to JS that I didn't want to do it again. I believe TS has its has benefits, I just don't care.

heavyset_go4• 6 years ago

I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.

jedimastert2• 6 years ago

I'm not against the idea of typescript as I'd just rather not have a compile step.

brundolf5• 6 years ago

For real projects, but for someone just getting started I think it makes a lot of sense to start with core language fundamentals (I notice that, at least from the table of contents, there was no mention of build systems or frameworks either). Lots of newly-minted JS devs today know relatively little about what it means to use plain JS, which means they don't have as much perspective on what their TypeScript and JSX actually turn into, which has a meaningful effect on informing decisions.

jerrygoyal• 6 years ago

and step 2: install prettier, step 3: eslint plugins.

bob1029• 6 years ago

I was half expecting the first page to explain what nodejs is and how to install it. Pleasantly surprised by most of this.

jonnycomputer3• 6 years ago

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.

weaksauce• 6 years ago

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

jonnycomputer3• 6 years ago

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

z3t47• 6 years ago

Then it will always be truthly if it returns an object, or 0 means success? :)

The proper way is callback convention err. Then you can write if(!err) ...

lxe• 6 years ago

https://javascript.info/ninja-code hah this is a great read :)

throwawaysea• 6 years ago

Is there a good tutorial that covers all the various frameworks that are in use? Modern Javascript has become very complicated due to the proliferation of these frameworks more so than the programming language.

icebr9• 6 years ago

Tbh if you know JavaScript well all these frameworks work like js. I build couple websites using vanilla js and when using any framework I can tell what it is doing behind the curtains because I have done it myself dozen or times in multiple lines of normal js

msie• 6 years ago

Remember when some people advocated not using semicolons to end statements? Good times...

https://javascript.info/structure

pknopf• 6 years ago

Yeah...

There was a big push for that a while back. The JavaScript community can be silly.

stingraycharles• 6 years ago

https://news.ycombinator.com/item?id=2024328

Here’s an example great bike shed discussion from ~10y ago about whether or not to use semicolons with JavaScript.

“If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.”

Those were the fun days! :)

wwweston• 6 years ago

Something I always thought was interesting about that argument is how a similar line of reasoning could apply to the `==` and `===` comparison operators.

Just about anyone who's ever written JS probably knows about the heavy lean towards "always use `===`". And it's not without good reason, because there are more than handful of not-entirely-intuitive implicit coercions/comparison corners associated with `==`. Personally, I think it's OK to use it, but I understand that it requires knowing the rules associated with use and most of all comes with the overhead of keeping them in mind when you do so. Most of the time it will be OK if you know even most of the rules. Sometimes it will not be OK. More often the overhead will cost you attention to other things. Some people have made the call "wouldn't it be simpler if we just did strict comparison and saved our attention for other things?" and while it's not my first choice, I can understand and respect it.

The statement termination thing strikes me as pretty much the same. Sure, if you know the rules, you can do it freely. But it takes something explicit that you don't have to think about and turns it into something implicit that you do. It isn't going to be a problem most of the time, but sometimes it will not be OK. A little more often the overhead will cost you attention to other things. Following the rule that semicolons terminate statements hasn't ever cost me anything.

The weird thing in my experience was the frequent overlap between antisemicolonists and always===ists. My theory is that mostly these people came from Ruby and Python, liked less punctuation for subjective aesthetic reasons, and didn't actually know the coercion rules well or particularly like JS, but that's speculation.

dagw2• 6 years ago

Reminds me of a CS teacher for our intro Haskell course at university who would dock points for unnecessary use of parentheses, since he considered that it showed we didn't understand order of operations or how our program was parsed.

weeksie• 6 years ago

I've run into that in a few places and it always baffles me that people would intentionally choose to add even more gotchas to javascript. Don't get me wrong, I think aesthetics in code are important but not to the point of deliberately increasing the chance of hard to find bugs.

gtsop2• 6 years ago

I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotcha" out of omitting semicolons.

If for any reason you absolutelly can't have these in place, better be safe and use semicolons.

Edit: for the "gotcha" explained in the link, prettier will automatically insert a semicolon before the array.

ux-app• 6 years ago

I have yet to encounter a single "gotcha" out of omitting semicolons.

keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case.

I honestly don't see the logic.

madeofpalk2• 6 years ago

"It doesn't matter" really is the perfect summation of this.

We have tooling that can solve this to prevent pointless bike shedding.

JoBrad• 6 years ago

Exactly. I almost always use TS instead of JS, for example, which flags gotcha scenarios (which I usually rewrite to avoid) and inserts semicolons for me in the final code. It’s just noise in my source.

simplify• 6 years ago

I still don't use them :)

sneak• 6 years ago

I don't know whether I use them or not, to be honest (and I just finished a project in js). My code looks like whatever the almost-default (tab-width: 4) output of prettier is.

It's nice to not waste a single braincycle on these things anymore.

Jowsey• 6 years ago

This. I just use an auto-formatter for the Standard style. If the Standard linter says it looks ok, it looks ok to me, and I move on with my day.

austincheney2• 6 years ago

So what changed this? This was a hill that people were willing to die on.

flippinburgers• 6 years ago

Debate over one character whose presence in code has no downside other than that a subset of programmers get to feel less arrogant. Sometimes I cannot stand this industry.

forgotmypw172• 6 years ago

I prefer post-modern javascript, the kind that works universally across all browsers starting with Netscape 2.0

markdown• 6 years ago

alert("Reached here #23");

forgotmypw172• 6 years ago

More like:

//alert('DEBUG: SomeFunction: condition is TRUE');

Then, depending on what browser I'm debugging in, the post-processor changes that to either console.log, document.title=, or alert(

austincheney2• 6 years ago

Aside from newer methods the only syntax gotchas in my code are template strings and let/const. That makes the code really quick and simple to convert to an old IE friendly application.

sireat• 6 years ago

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

longnow• 6 years ago

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 misunderstanding, then I can’t possibly recommend this book).

mcgingras• 6 years ago

yes, it's a whole chapter written ironically. I too find this to be misleading.

hanoz• 6 years ago

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.

ehutch79• 6 years ago

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

lucideer• 6 years ago

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.

mekoka2• 6 years ago

I think that page would benefit to first more clearly define what a JavaScript Ninja is and why it's good for you to become one. Something along the lines:

"A JavaScript Ninja writes code that is brilliantly mysterious. When people read such code it should induce confusion and if at all possible, fear. Clarity is for the feeble. Obviousness is overrated. Obfuscation and secrecy: that is the way of the Ninja. So, how do you become a Ninja?"

abhishekjha• 6 years ago

This reminded me of a brilliant and hilarious presentation on microservices : https://youtu.be/X0tjziAQfNQ

strogonoff• 6 years ago

There is a chapter called ‘ninja code’, which is full of terrible advice.

How someone interprets a tongue-in-cheek chapter could be a good litmus test of their reading comprehension, grasp on the fundamentals, and (last, but not the least) basic sense of humour. I’d hate to see it removed.

If someone takes this section literally, I would be immensely curious how they reconciled in their mind that advice with what they (supposedly) read in preceding sections.

dmje• 6 years ago

Never rely on Americans to spot irony

ZoomZoomZoom• 6 years ago

Suppose I've been living under a rock this whole time and my knowledge of JS is something along `it's a language you use when you want a message box to appear and annoy your visitors`, i.e. completely out of touch.

How could you explain me, strictly from the language design point, not practicality/how widespread it is/how easy is to find a job/etc, why JS? What are the strong points which make it a better language than lua/python/lisp/tcl/ruby? Thanks.

OkGoDoIt• 6 years ago

Well for client side code running on a website, it’s your only option. I guess nowadays many client support web assembly, but for all practical purposes you need to use JavaScript to do any client side web programming.

On the server the advantage is much less clear-cut, but a lot of it boils down to “we want to use the same language for the front end and the backend“. Although in my experience this is actually a horrible idea, and tends to result in very messy code and lots of work arounds in practice.

Anyway for me personally I continue to use JavaScript because of a combination of wanting to build lightly-interactive webpages and because that really is what the job market demands. So many companies are dead-set on hiring someone with node, react, and whatever other JavaScript experience. I tried taking it off my resume at one point because I kind of hate it, but if you’re at all involved in full stack web development it’ll really hurt your career if you don’t do JavaScript.

meow_mix• 6 years ago

I swear this tutorial comes out fresh every other month

yudlejoza• 6 years ago

... how it's done now

Intro section has no context, especially how this relates to Crockford's "the good parts".

Is it inspired by it, in conflict with it, a superset, a subset? How did newer standards affect it? how is 'modern' defined? How is 'now' defined?

dfilppi• 6 years ago

The Ninja section is priceless.

z3t47• 6 years ago

JavaScript has some really nice features that this tutorial does not mention 1) First class functions 2) Prototype 3) Function scope 4) What async means and how to master it Those I think is essential in order to understand JavaScript.

fogetti2• 6 years ago

What are you talking about? Did you even take a look at the table of contents?

rfrey2• 6 years ago

I didn’t downvote, but calling people out for not reading the article — even if it seems blindingly true — is against HN rules and always gets downvoted.

SPBS• 6 years ago

This website covers every nitty gritty detail of javascript, even DOM specific aspects like https://javascript.info/bubbling-and-capturing (just look at how well it is written). I would be highly surprised if it did not even mention those javascript basics. A brief look at its table of contents shows that indeed it mentions those, and I am baffled why the other commentor is getting downvoted for calling you out.

z3t47• 6 years ago

For example the article about callbacks basically says "use Promises" which is even more complicated then first class functions.

Helpful resource: http://callbackhell.com/

vmurthy• 6 years ago

Lot of upvotes for the site so please do support the author(s) by buying the book[0].

All parts together is $18 (epub + pdf). I am not a front-end developer so not much use for me personally but spreading the good word :)

https://javascript.info/ebook

ianstormtaylor• 6 years ago

Wow, this is really well put together! Anyone know an equally good guide for Python?

lenkite• 6 years ago

The site is awesome, but I wish they had an all-in-ONE-page option. Navigating through X sections and links is a chore.

qwerty456127• 6 years ago

So glad people still make things like this despite so many tutorials and books already being available. This means people still care to make something purely for sake of making it better - obviously nobody would be interested if it wasn't. Crafting tutorials should be considered an art.

pachico• 6 years ago

I feel I need this so badly. The last time I wrote something in JavaScript was around 10 years ago and I want to get up to date. One of the chapters is named "the old 'var'". I didn't know it was old, which proves the need to learn.

stevenjgarner• 6 years ago

Looks like a great resource. There does not seem to be anything on database connections (e.g. MySQL, PostgreSQL etc) and related topics (e.g. building a CRUD framework). Are database connections only considered in a client/server context (e.g. through Node.js)? What am I missing? How does the IndexedDB section relate to these considerations?

x14km2d• 6 years ago

The website is really very good. I started to learn JavaScript last week and worked through the JavaScript Wikibook. Unfortunately it is not as complex as the website linked above. I can continue working with it really well. I also like the structure and design, which makes the tutorials really easy to read. A great project.

MaxBarraclough• 6 years ago

Looks well written, but it seems undecided on whether it's targeting experienced programmers or newcomers. I have to disagree with priyatham_'s position that it effectively targets both.

The Loops section gives a very brief description of what loops are. This doesn't introduce anything of value to an experienced programmer, and it's nowhere near enough of an explanation for teaching imperative programming to a beginner.

Personally I'd suggest targeting experienced programmers. I only learnt JavaScript relatively recently, and I found it very frustrating that every JavaScript tutorial I could find was aimed at beginners (and that isn't an exaggeration).

bovermyer• 6 years ago

This is great. However, it gives the example of copying a variable by assigning another variable to it. This doesn't copy a variable's contents - it makes the new variable a pointer to the original variable.

As someone who doesn't use Javascript much... is there a way to force it to copy the current state of the original variable to the new variable, without it being a reference and without having to use something like lodash?

lighthazard• 6 years ago

You will need to clone the object somehow. The simplest solution is to go through each of the object properties and create a new object with those same properties (_.clone). Alternatively, recursively go through each property in the object and then keep going deeper through each property that is an object until you get a copy of everything to assign to a new object (_.deepClone)

rhengles• 6 years ago

I think the only reasonable thing that js can do here is what it does - copy the reference. Also, there is a simple way to copy all properties from a object: const copy = { ...object }; Of course, if these properties are themselves objects, then changes in one of them will appear in the other.

One way to have a deep copy which shares nothing is const copy = JSON.parse(JSON.stringify(object)); but that may not always work. In short, copying a arbitrarily large object will probably waste memory, so it should be a little hard so you don't do it unless it's really necessary.

ianjsikes• 6 years ago

The cheaty way is `let copy = JSON.parse(JSON.stringify(val))`. Doesn't work for functions or cyclic structures though.

derivagral• 6 years ago

In addition to the cloning stuff, I've seen use of an immutables library [0] to make this stuff a little more explicit and simple. Not sure if that's still fashionable though.

[0] e.g. https://immutable-js.github.io/immutable-js/

cphoover• 6 years ago

Hmmm there are a lot of language footguns or advanced features that don't have any disclaimers for beginners. I don't think a beginner should be told to use Proxy object handlers before learning the basics of JS, async and functional programming.

ngcc_hk• 6 years ago

Like the email based one more. But this seems more complete.

A Modern JavaScript Tutorial

Related Stories