Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

171–180 of 299 posts

Re: A Modern JavaScript Tutorial

#171
post #128

Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure

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.

Re: A Modern JavaScript Tutorial

#172

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…

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

Re: A Modern JavaScript Tutorial

#174

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)

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.

Re: A Modern JavaScript Tutorial

#175

Earlier quoted context omitted.

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

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 another language”, it’s to the perceived complexity of TS strictness/appeasing the compiler. I’m saying this not based on polling so obviously take it with a grain of salt, but I routinely search Twitter, GitHub and rando blogs for TS content and that sentiment represents nearly 100% of the anti-TS content I encounter.

And largely I find that in React-focused communities. Which having spent the last several years using TS on Node in production, and the last couple months working on a web project in React, it’s not remotely surprising. React and many libraries built on it have ridiculously complex types. That’s not because of TS but interacting with and satisfying those types at compile time is extremely frustrating even to me as a seasoned TS dev who has built libraries that take advantage of many advanced features in the type system (I just don’t expose that complexity to the API consumer).

Re: A Modern JavaScript Tutorial

#176

Thanks for sharing. I found this quote very appropriated: In older scripts, you may also find another keyword: var instead of let

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

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

Re: A Modern JavaScript Tutorial

#177

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)

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.

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

Re: A Modern JavaScript Tutorial

#178

Earlier quoted context omitted.

I don't really experience this issue and I use Web storm which is basically the same thing. I find that the dynamic type hinting plus the combination of using JS Doc formatted comments rarely leaves me with any ambiguity when writing vanilla JavaScript.

Are you using types in your JS Doc comments? If so, that's not vanilla JavaScript.

JS Doc is just comments. (But the typechecker can still read them.)

Re: A Modern JavaScript Tutorial

#179

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.

Getting a configuration together that consumes all your dependencies and generates code without crapping a ton of meaningless warnings about duplicate type definitions in its own type mappings for runtime types is non-trivial and requires setting more than a few non-default compiler options, none of which are named anything that means anything.

I still don't know how it's possible to safely, cleanly make a library that other projects can consume comfortably with just TypeScript.

Re: A Modern JavaScript Tutorial

#180

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…

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