Live data from Hacker News

A Modern JavaScript Tutorial

javascript.info

101–110 of 299 posts

Re: A Modern JavaScript Tutorial

#101

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…

I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web.

Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without.

However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites.

It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.

Re: A Modern JavaScript Tutorial

#102

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…

I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web. Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type…

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?

Re: A Modern JavaScript Tutorial

#103
post #69

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

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.

Re: A Modern JavaScript Tutorial

#104

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…

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

Re: A Modern JavaScript Tutorial

#105

Earlier quoted context omitted.

I never understood that. Is it really that hard to spell out full variable names? It’s so much more legible, there is autocomplete on virtually any editor (even the ones that aren’t IDEs), and you write code once but read it hundreds of times. Why even try to save 8 bytes at the expense of readability?

Short variable names make code more readable in some scenarios, not less. fooBarBazThings.each(t => t.DoThing()) for (int i = 0; i Some local code patterns are seen so often you understand it in one go. Something like fooBarBazThings.each(fooBarBazThing => fooBarBazThing.DoThing()) for (int thingIndex = 0; thingIndex Just clutters things up.

I disagree. I always use descriptive variable names. I have no idea what ‘t’ is. ‘thing’ is 4 bytes more. Not the end of the world, but much more readable. Same for ‘i’ vs ‘index’.

Re: A Modern JavaScript Tutorial

#106

Earlier quoted context omitted.

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

i and j are very understandle. I did browse the go code randomly and for example t, s, and b are terrible variable names in my opinion in this example : https://github.com/golang/go/blob/3ce865d7a0b88714cc433454ae... You can find a lot of code like this.

That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?

Re: A Modern JavaScript Tutorial

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

Re: A Modern JavaScript Tutorial

#108

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.

Have you seen the size of frontend codebases? Even modest SPAs reach into the tens of thousands of lines. Or the size of large Express.js driven backends? A huge portion of the web is driven by JS/TS.

Re: A Modern JavaScript Tutorial

#110

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.

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

Post reply on HN