Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

181–190 of 299 posts

Re: A Modern JavaScript Tutorial

#181
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

Disallowing for..of iterators is the reason I cannot use or recommend the Airbnb lint preset. A very nice example of an anno 2014-2017 cargo cult that clearly hasn't held up. https://github.com/airbnb/javascript/issues/1271

Re: A Modern JavaScript Tutorial

#182

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

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

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

Re: A Modern JavaScript Tutorial

#183
post #69

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

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

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.

Re: A Modern JavaScript Tutorial

#184

Earlier quoted context omitted.

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

Because your question reads as a relatively transparent thinly veiled insult, like you're questioning his ability to be curious about the world, and contributes very little to the discussion.

You haven't given me anything actionable. Read the question I asked, understand against your instincts that it is a question and not the insult you assumed it to be, and then tell me a way to ask that question that doesn't make you feel the way you do right now. Is there one?

Disagree strongly on "contributes very little to the discussion".

Re: A Modern JavaScript Tutorial

#185

Earlier quoted context omitted.

I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?

The fact you ask this question gets at my point I think. For several years I've been writing a large computer algebra system(CAS) that runs on a webpage. Every time the user puts some input into a text box the CAS runs. Depending on the input it may run as many as ~40k lines of code. There are no coherent lines upon which to split the CAS as far as anyone developing it can tell. The CAS must run on the browser both t…

The trick is to not break it up. Adding more lose ends will just make the ball of twine more complicated. What you can break out though is independent code that is the same for many apps, that code can be made into a module and reused across apps. Pure mathematical functions can be turned into a library.

But what could probably help keep your sanity for a CAS is to add a test case for every change to make sure the same input produce the same output in the future. As well as performance tests to avoid performance regressions.

Re: A Modern JavaScript Tutorial

#186

Earlier quoted context omitted.

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

That recommendation strikes me as much closer to an attempt to make a statement with a rhetorical question than the question I actually asked. Even the most charitable assumption of good faith would most likely yield a response lacking detail and devoid of any insights that I was after.

Re: A Modern JavaScript Tutorial

#187

Earlier quoted context omitted.

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.

I don't understand.

Re: A Modern JavaScript Tutorial

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

Re: A Modern JavaScript Tutorial

#189

Earlier quoted context omitted.

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

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.

> for JS programmers, worrying about types is habitual

Couldn't the same be said for COBOL programmes and GOTOs?

Re: A Modern JavaScript Tutorial

#190

Earlier quoted context omitted.

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

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

I do include the DOM API in my statement, but I do not include non-standardized browser APIs, which attachEvent seems to be.

I'll refine my statement to "The JS standard never introduces breaking changes".

attachEvent never was part of any standard, and is therefore subject to breakage. Non-standard APIs should never be part of a comprehensive guide to the language in the first place.

Post reply on HN