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

191–200 of 299 posts

Re: A Modern JavaScript Tutorial

#191

Post by reificator »

brundolf wrote: post #190
reificator wrote: post #182

Earlier quoted context omitted.

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

I was worried that leading with `attachEvent` would get a response about only `attachEvent`.

The `with` statement is described on page 75 of the ES3 standard[0]. It does not work in an ES Module or in a strict mode context. This is a breaking change.

[0]: https://www-archive.mozilla.org/js/language/E262-3.pdf

Re: A Modern JavaScript Tutorial

#192

Post by hn_throwaway_99 »

DrScientist wrote: post #104
hn_throwaway_99 wrote: post #94

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

I understand the power of types - I just wonder why the heck you are writing so much JS/TS code? Are you doing server stuff with it? You could argue here there are much better languages and platforms for that.

Yes, in my current tech stack our entire backend is in Node with TypeScript, and the front end is React with TypeScript.

> You could argue here there are much better languages and platforms for that.

You could, but I think you'd be wrong. I come from a background of using Java on the backend for over a decade, then some time with various backend languages including Python and Ruby. This is the first time in my career when everything (front end and back end) are essentially on the same stack, and there are huge, gigantic productivity improvements to that. Most of it stems from it being easy for developers to switch between front end and back end code. E.g. it's very easy for front end developers to dig in and debug something that's not right on the back end, and usually to fix it themselves. Same thing goes for backend devs investigating how APIs are used by the front end. In all my previous jobs it was relatively rare (certainly not never but not that common) for devs to cross that divide, mainly because setting up the environment in a totally different stack was time consuming and annoying, and mentally context switching into a different language was difficult, if all you wanted to do was dig in on one particular endpoint, for example.

But even discounting that, I am much more productive in TS than I ever was with Java, primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java. Sure, there are some cases (mainly WRT scalability) where Java may be a better choice, but the idea that TS/Node is not an awesome choice for the server is outdated IMO.

Re: A Modern JavaScript Tutorial

#193

Post by useragent86 »

kaycebasques wrote: post #42

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

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.

Re: A Modern JavaScript Tutorial

#194

Post by brundolf »

reificator wrote: post #191
brundolf wrote: post #190

Earlier quoted context omitted.

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.

I was worried that leading with `attachEvent` would get a response about only `attachEvent`. The `with` statement is described on page 75 of the ES3 standard[0]. It does not work in an ES Module or in a strict mode context. This is a breaking change. [0]: https://www-archive.mozilla.org/js/language/E262-3.pdf

Strict mode was invented as a way of introducing a handful of "breaking" changes without them actually being breaking, since it's opt-in. JavaScript had some egregious design issues from the beginning and strict mode is a remedy to some of them.

But when most people say "breaking changes" they mean things that suddenly cause legacy code to stop working, and non-strict mode will almost certainly be supported ad infinitum, so I don't really count that. It's also almost certainly never going to happen again.

Re: A Modern JavaScript Tutorial

#195

Post by forgotmypw17 »

markdown wrote: post #144
forgotmypw17 wrote: post #130

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

alert("Reached here #23");

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(

:)

Re: A Modern JavaScript Tutorial

#196

Post by pault »

eyelidlessness wrote: post #175
DrScientist wrote: post #75

Earlier quoted context omitted.

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

Hardly just another one, and hardly fragmenting. It’s absorbed the vast majority of effort previously dedicated to Flow (the fragment in its own target space), and has continually gained in the JS community proper. It’s not just (or intended to be) a “compile to JS” language, it’s (almost) just annotated JS where the annotations provide additional tooling value. The resistance in the JS community isn’t to “yet anothe…

Front end library type definitions are a nightmare because they are usually retrofitted onto code that uses JavaScript idioms that take heavy advantage of metaprogramming and it's dynamic nature. It's also compounded (in my opinion) by developers that insist on making everything inferable instead of just putting a few generic parameters here and there and saving an enormous amount of complexities. Native typescript libraries are generally extremely easy to work with, however.

Re: A Modern JavaScript Tutorial

#197

Post by resu_nimda »

pwdisswordfish4 wrote: post #186
resu_nimda wrote: post #151

Earlier quoted context omitted.

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.

You could add that "I'm asking because the process of typing an off-topic comment on a forum and waiting for replies strikes me as an inefficient way to get an answer to this question, and I'm genuinely trying to understand that thought process."

I highly doubt it would have performed worse than your strategy, which at best resulted in a derail about tone, and at worst scared off the person you were asking and others who may have otherwise taken time to give the deep and thoughtful answer you were looking for.

It seems clear that you find niceties and pleasantries to be not genuine or unnecessary, and I can sympathize, but they go a long way in terms of making people feel comfortable and opening up to you.

Re: A Modern JavaScript Tutorial

#198

Post by fogetti »

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

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

Re: A Modern JavaScript Tutorial

#200

Post by fogetti »

names_are_hard wrote: post #154
vorpalhex wrote: post #86

Earlier quoted context omitted.

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.

In our case: 1) slow and long transpilation times, 2) although not that common these days but missing typings used to cause some head scratch 3) overly permissive/overly restrictive type definitions 4) wrongly configured sourcemaps 5) unreadable type definitions/declarations... The list is long but these are off the top of my head
Post reply on HN