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
A Modern JavaScript Tutorial
181–190 of 299 posts
Re: A Modern JavaScript Tutorial
#182Oh 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…
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
#183Isn’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.
Re: A Modern JavaScript Tutorial
#184Earlier 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.
Disagree strongly on "contributes very little to the discussion".
Re: A Modern JavaScript Tutorial
#185Earlier 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…
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
#186Earlier 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-…
Re: A Modern JavaScript Tutorial
#187Earlier 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.
Re: A Modern JavaScript Tutorial
#188Re: A Modern JavaScript Tutorial
#189Earlier 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.
Couldn't the same be said for COBOL programmes and GOTOs?
Re: A Modern JavaScript Tutorial
#190Earlier 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'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.