[HN Gopher] A Modern JavaScript Tutorial
___________________________________________________________________
A Modern JavaScript Tutorial
Author : ivanche
Score : 393 points
Date : 2020-12-07 15:56 UTC (7 hours ago)
(HTM) web link (javascript.info)
(TXT) w3m dump (javascript.info)
| ZoomZoomZoom wrote:
| Suppose I've been living under a rock this whole time and my
| knowledge of JS is something along `it's a language you use when
| you want a message box to appear and annoy your visitors`, i.e.
| completely out of touch.
|
| How could you explain me, strictly from the language design
| point, not practicality/how widespread it is/how easy is to find
| a job/etc, why JS? What are the strong points which make it a
| better language than lua/python/lisp/tcl/ruby? Thanks.
| OkGoDoIt wrote:
| Well for client side code running on a website, it's your only
| option. I guess nowadays many client support web assembly, but
| for all practical purposes you need to use JavaScript to do any
| client side web programming.
|
| On the server the advantage is much less clear-cut, but a lot
| of it boils down to "we want to use the same language for the
| front end and the backend". Although in my experience this is
| actually a horrible idea, and tends to result in very messy
| code and lots of work arounds in practice.
|
| Anyway for me personally I continue to use JavaScript because
| of a combination of wanting to build lightly-interactive
| webpages and because that really is what the job market
| demands. So many companies are dead-set on hiring someone with
| node, react, and whatever other JavaScript experience. I tried
| taking it off my resume at one point because I kind of hate it,
| but if you're at all involved in full stack web development
| it'll really hurt your career if you don't do JavaScript.
| viviansolide wrote:
| Thanks for sharing. I found this quote very appropriated:
|
| In older scripts, you may also find another keyword: var instead
| of let
| Rumudiez wrote:
| True for reading legacy JS. For newer code, you can still
| identify noobies (and "experts") by the conspicuous usage of
| let instead of const.
| msie wrote:
| Remember when some people advocated not using semicolons to end
| statements? Good times...
|
| https://javascript.info/structure
| pknopf wrote:
| Yeah...
|
| There was a big push for that a while back. The JavaScript
| community can be silly.
| weeksie wrote:
| I've run into that in a few places and it always baffles me
| that people would intentionally choose to add even _more_
| gotchas to _javascript_. Don 't get me wrong, I think
| aesthetics in code are important but not to the point of
| deliberately increasing the chance of hard to find bugs.
| stingraycharles wrote:
| https://news.ycombinator.com/item?id=2024328
|
| Here's an example great bike shed discussion from ~10y ago
| about whether or not to use semicolons with JavaScript.
|
| "If you don't understand how statements in JavaScript are
| terminated, then you just don't know JavaScript very well, and
| shouldn't write JavaScript programs professionally without
| supervision, and you definitely should not tell anyone else how
| to write their JavaScript programs."
|
| Those were the fun days! :)
| boberoni wrote:
| > According to your browser language headers, you know Chinese.
| Please help to translate the tutorial into your language! Thank
| you!
|
| I'm curious. How are my language preferences exposed through HTTP
| headers?
|
| I think this was a charming way to request volunteers for
| translation, but I was a bit taken aback.
| lights0123 wrote:
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...
| smarx007 wrote:
| I have figured it out experimentally (Chrome & Ukrainian): if
| you visit a website in language X and click Never Translate,
| Chrome silently adds language X to the end of the list (Accept-
| Language that is). I have not found a way to forcibly turn it
| off.
|
| Edit: check out chrome://translate-internals/ if you are
| interested
| jmt_ wrote:
| The Accept-Language HTTP request header is my guess
| croisillon wrote:
| I get the same question (after a while) here: https://www.wpf-
| tutorial.com/
| sequoia wrote:
| This was probably set at the operating system level, i.e. you
| selected "zh_ZH"/Chinese at some point during setup. Upon
| installing a browser, it reads your OS language preference &
| then passes that through to websites via the accept-language
| header.
| pwdisswordfish4 wrote:
| 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
| replies say."
| dhruvarora013 wrote:
| I think this is a little harsh. The comment does point out a
| feature on the topic site. I'm personally glad that they
| brought it up because as an English speaker I didn't see this
| feature exposed. Internationalisation is a complex yet
| required feature for large websites these days, and a clever
| feature like this to find translations is great!
| pwdisswordfish4 wrote:
| > 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 tolerable (it
| got flagged) but the other commenter's is fine?
| resu_nimda wrote:
| 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-quotes" is very
| easily construed as mocking or belittling, even if you
| were just trying to be precise about your meaning.
|
| A better way to ask might have been: "I'm curious, and I
| don't mean to be rude, but what caused you to post this
| comment here instead of searching for the answer?"
| scpedicini wrote:
| 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.
| djeiasbsbo wrote:
| Maybe he did fo that but wanted to inform the OP that this
| was surprising to him. Given that the OP is looking for
| translators it is valuable feedback imo.
| heavyset_go wrote:
| 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.
| bryanrasmussen wrote:
| maybe: since I'm already here I'll ask the question because
| on this particular site somebody knows the answer and can
| probably give me a better starting point for learning about
| the subject than the average search engine!
|
| Also it will serve as a notice to people that not everybody
| knows these things and might be put out by this sort of
| question.
| OpuRahman wrote:
| Needs to be updated on a regular basis.
| stasgavrylov wrote:
| It's open source and they're actively looking for contributors.
| jsnk wrote:
| Excellent resources. Is there one like this for Java?
| forgotmypw17 wrote:
| I prefer post-modern javascript, the kind that works universally
| across all browsers starting with Netscape 2.0
| markdown wrote:
| alert("Reached here #23");
| kaycebasques wrote:
| 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 the contents. The Divio links above do a great job at
| explaining each doc type. I'm simply sharing this idea for people
| who have never considered being more careful about how they label
| their docs and would like to start following general technical
| writing community practices. As a practicing technical writer I
| can tell you that the TW community mostly agrees upon what each
| doc type entails ("tutorials" and "references" have strong
| consensus; "guides" less so).
| simonw wrote:
| I'm surprised I haven't seen this before - it's been under very
| active development since 2015 and has 11,000+ stars on GitHub:
| https://github.com/javascript-tutorial/en.javascript.info/gr...
| mekoka wrote:
| Even more surprising, it's been submitted umpteen times before:
|
| https://news.ycombinator.com/from?site=javascript.info
|
| I sometimes wonder what are the dynamics that trigger the
| snowball on HN.
| codetrotter wrote:
| I think time of day, novelty, luck, and whether any mods
| notice the post and decide to give it a second wind.
|
| By novelty I mean something that is easily recognized as new
| and important. It doesn't help that something is new if no
| one catches the point of reading about it. Could be a bad
| title or a bad article. Or bad luck.
|
| In terms of good luck I mean a couple of specific things
| especially:
|
| - If a few people see it that are excited about it, either
| from hearing about it the first time or from knowing it in
| the past, and these people write positive comments about it,
| then others who come across the post may be encouraged to
| check it out and to upvote it too.
|
| - "Micro zeitgeist". If it's about a topic that recently hit
| the front page and it adds something new about that, it could
| luck out. Why luck in this case? Because you probably don't
| know ahead of submitting that people will care to read even
| more about some topic even if it was popular the day before.
| Perhaps instead people are tired of the topic.
|
| - The other things submitted the same day did not gain enough
| traction to push this thing away.
|
| - Evergreen topics that have not gotten traction in a while
| but that people care about.
|
| - Topics that people in university and college are currently
| learning about so it catches their attention. I dunno how big
| the amount of people currently in university is versus people
| that are in jobs. But I remember that I learned about HN from
| some other students in a student union I was in back then.
| And I don't know how students HN reading habits are compared
| to people in jobs either. I remember reading HN a lot when at
| the university. But I still read HN a lot. These days I read
| HN in the morning, the evening and at night though, not when
| I am working. But even if you have a job you might read HN in
| the lunch break, or perhaps you have some downtime where you
| are waiting for something at work and you read HN for a
| while.
|
| There are other possible factors too that I have thought
| about in the past but these are the ones I can think of right
| now.
|
| Please note that all of what I am saying here is only my
| thoughts based on my own habits and from what I've heard
| other people say and what I've seen.
| meow_mix wrote:
| I swear this tutorial comes out fresh every other month
| alfonsodev wrote:
| The ninja code section is pure sarcasm, right?
|
| I'm not sure now which sections are and aren't.
| speedgoose wrote:
| Interestingly Golang encourages one letter variable names and
| it's not sarcasm this time :
| https://github.com/golang/go/wiki/CodeReviewComments#variabl...
|
| Golang's landscape is full of one letter variables and
| abbreviations and it's not great.
| Philip-J-Fry wrote:
| 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 then it should be called "index" not "i".
|
| Method receivers are usually always kept short because
| they're pretty self explanatory and the first thing you look
| at in a function.
| ornornor wrote:
| 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?
| kinjba11 wrote:
| Short variable names make code more readable in some
| scenarios, not less.
| fooBarBazThings.each(t => t.DoThing()) for (int i =
| 0; i < len(things); i++) { // i used here }
|
| 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 < lengthOfThings; thingIndex += 1) { //
| thingIndex used here }
|
| Just clutters things up.
| ornornor wrote:
| 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'.
| drran wrote:
| Modified obfuscator can make your code even more
| readable. It can simplify functions in addition to
| variables. Also, it improves job security, which is
| important in times of covid.
| twic wrote:
| This is a bit of a false dichotomy, because the names
| don't have to be that long.
| fooBarBazThings.each(thing => thing.DoThing())
|
| It's more useful when the receiver of the method doesn't
| tell you as much, eg:
| getRecentPurchases().values().forEach(price ->
| priceStats.accept(price));
| speedgoose wrote:
| 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/3ce865d7a0b88714cc43345
| 4ae...
|
| You can find a lot of code like this.
| yarosv wrote:
| That's easy. `b` stands for file
| earthboundkid wrote:
| That strikes me as perfectly readable. t for template, b
| for bytes, and s for string. What else would you call
| them?
| drran wrote:
| template, file, text
| earthboundkid wrote:
| Is file a file object? A file path?
|
| All three are "the template". So, they use polish-ish
| notation: the template as []byte, template as string, and
| template as *template.Template.
| yarosv wrote:
| Sure, what bothers me is how inconsistent it is. Function
| parameter of type Template is `t` but local variable of
| type Template is `tmpl`.
| speedgoose wrote:
| template, bytes, string.
| earthboundkid wrote:
| `bytes` is the name of a stdlib package. `string` is the
| name of a built in type. `template` is technically
| available, but only because it's the name of this
| package, so it can't refer to itself.
| vsareto wrote:
| I kind of agree with their reasoning, the exception being
| when you can have a lot of complicated looping/control flow
| breaks or transient variables close to their usage. Seeing
| 'array[i][j][k]' is never fun.
| flixic wrote:
| It is hilarious. Lao Tzu quotes make it simply perfect.
| earthboundkid wrote:
| It is funnier to me because the quotes are actual historical
| quotes (to be fair, there probably was no "Laozi"
| historically), whereas you see fake quotes for
| Laozi/Confucius/Buddha all over the internet.
| jeffmcmahan wrote:
| It has an alert at the top that says, "Irony Detected".
| wsc981 wrote:
| The Ninja code section seem to have been largely based on this
| classic article, which I personally found more humorous to
| read: https://github.com/Droogans/unmaintainable-
| code?fbclid=IwAR1...
| Zhyl wrote:
| That page has an 'irony warning' so just watch out for those on
| other pages!
|
| It might just be my sense of humour (I'm the sort of person
| that doesn't need an '/s' tag and feels that it shouldn't be
| necessary _if you told the joke properly_ ), but it was pretty
| obvious to me even without the irony warning that the page was
| intended as a joke.
|
| It looks like it was heavily inspired by the classic 'Tao of
| Programming' [0]. It uses a very similar style and even quotes
| the actual Tao Te Ching.
|
| [0] http://www.mit.edu/~xela/tao.html
| hutzlibu wrote:
| I am with you on not wanting or needing to see /s ... but on
| a tutorial, where people actually struggle to understand
| anything at first read, using unmarked irony is maybe not the
| most helpful for them.
|
| Oh and a second thought on /s. For some time I only got my
| news through satire sites like the onion. And after I
| switched back to "real news" sites, I could not believe it
| was not satire. I mean come on, the world and the internet
| was always full of dumb people, but when even very high
| ranking people and institution say really out of the world
| things in all seriousness - I came to the conclusion, marking
| irony as irony is sadly sometimes important, in those
| interesting times we live ...
| Sohcahtoa82 wrote:
| Yeah, when we live in a world where people _legitimately_
| believe that Bill Gates is trying to use COVID vaccines to
| install microchips into people, you can 't always be sure
| that someone giving an insane opinion isn being ironic or
| sarcastic.
| hutzlibu wrote:
| I mean, we allways had flat earthers (even though I
| couldn't believe they were serious either, when I first
| stumbled upon them).
|
| But this new level is a bit unsettling.
| colmvp wrote:
| The section is clearly dripping with irony. They even have an
| "Irony detected" box at the very top which acts as the
| sarcasm/satire tag so many people seem to use to bang over our
| heads that it's not serious.
| priyatham_ wrote:
| This site is absolutely awesome and I would suggest this to new
| comers and experienced folks alike. It covers all things related
| to javascript, explains the concepts really well in a practical
| day to day application point of view.
|
| I might be sounding like a promoter for it, but it really added a
| lot of value for me personally, so just wanted to spread the good
| word.
| longnow wrote:
| 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 misunderstanding,
| then I can't possibly recommend this book).
| hanoz wrote:
| _> There is one small comment at the top of the chapter, which
| says 'Irony detected'._
|
| The whole chapter is littered with clearly tongue in cheek
| remarks.
| ehutch79 wrote:
| People will absolutely not get that and take the advice to
| heart.
| mekoka wrote:
| I think that page would benefit to first more clearly define
| what a JavaScript _Ninja_ is and why it 's good for you to
| become one. Something along the lines:
|
| _" A JavaScript Ninja writes code that is brilliantly
| mysterious. When people read such code it should induce
| confusion and if at all possible, fear. Clarity is for the
| feeble. Obviousness is overrated. Obfuscation and secrecy: that
| is the way of the Ninja. So, how do you become a Ninja?"_
| lucideer wrote:
| I understand that often subtleties of language, particularly
| when it comes to irony or sarcasm, can be lost in textual
| content (particularly supposedly-formal content like
| educational materials), and that generally this is something to
| be avoided.
|
| However, after reading that chapter, I really can't help
| thinking that you simply weren't paying any attention.
|
| It's not just written in sarcastic tone (something that yes,
| could be easy to miss for many), but it's also littered with
| active dissuasion and explicit explanations of the pitfalls of
| using this style.
|
| Examples:
|
| > _If you write like that, a developer who comes across this
| line and tries to understand what is the value of i is going to
| have a merry time. Then come to you, seeking for an answer._
|
| > _A quick read of such code becomes impossible. And when
| there's a typo... Ummm... We're stuck for long_
|
| > _A fellow programmer who wants to work with elem in the
| second half of the function will be surprised... Only during
| the debugging, after examining the code they will find out that
| they're working with a clone!_
|
| > _First, the code becomes longer and less readable, and the
| second, a fellow developer may spend a long time trying to
| figure out what the underscores mean._
|
| You can argue that the chapter is inappropriate, but I don't
| think you can reasonably argue that it's misleading.
| mcgingras wrote:
| yes, it's a whole chapter written ironically. I too find this
| to be misleading.
| nailer wrote:
| The default way promises are used is now async/await. `.then()`
| should not be introduced as anything more than 'you may find this
| in older codebases'.
| golergka wrote:
| async/await is excellent syntax when you want things to happen
| one after another. That's the usual case, and that's what I
| find myself using 95% of the time.
|
| However, when you want a more fine-grained concurrent execution
| of different asynchronous things, then() still could be very
| useful.
| postalrat wrote:
| Can you give an example of more fine grained control with
| then?
| golergka wrote:
| const [result1, result3] = await Promise.all([task1(),
| task2.then(res => task3(res))])
| postalrat wrote:
| Could that be written const task2then3 =
| async () => task3(await task2()); const [result1,
| result3] = await Promise.all([task1(), task2then3()])
| wa1987 wrote:
| Often times operations are order-independent. Specifying
| those as sequential `await`-s does not make a lot of sense
| in those situations. I guess less fine grained control is
| desirable under such circumstances :-)
|
| There's also other useful utilities such as Promise.all(),
| Promise.any() and Promise.race().
| postalrat wrote:
| (async () => { set(await get()); })(); get().then(r
| => set(r));
|
| Ignoring error handling I'll often choose the second option.
| Rumudiez wrote:
| Much cleaner. You can go even further by using point-free
| style: get().then(set)
|
| It's the try/catch blocks that make async/await truly worse
| than native promises. I use them sparingly because so often
| the .then syntax is both clearer and terser.
| postalrat wrote:
| What don't you like about try/catch? I find the opposite
| true, the .then/.catch is more confusing.
| Rumudiez wrote:
| try/catch introduces new block scopes and interrupt
| control flow. I find this example very readable, but
| expanding it into try/catches would make it rather long
| winded and harder to see the pattern at work as you
| extend the sequence: get()
| .then(handleResult) .catch(useFallbackResult)
| .then(updateState)
|
| I prefer concision and functional expressiveness because
| it reduces the surface area for writing buggy code. Much
| like how using map instead writing a for loop can
| eliminate out of range index bugs, chaining promises
| brings useful guarantees about how the code I do write
| can be interpreted.
| jedimastert wrote:
| Can you point to anything other than saying "this is obvious"?
| nailer wrote:
| No, just experience with a lot of codebases.
|
| Here's a simple question to ask yourself: what if non-IO
| operations allowed you to use the .then() syntax? If you have
| the choice to use: 1 +
| 1.then(function(result) { ... }
|
| vs const result = 1 + 1
|
| Which would you choose?
| pavlov wrote:
| Using then() doesn't pause execution of the callsite
| function, while await does. Surely that's a relevant
| difference here?
|
| It doesn't seem unreasonable to use then() to express: "Run
| this anonymous function whenever the async thing completes.
| Meanwhile let's do this other stuff right now."
| nailer wrote:
| Both codebases can't do anything until `result` has a
| value.
| verisimilidude wrote:
| That's probably good general advice.
|
| One problem. I'm increasingly coming across devs who've never
| used Promises directly, only async/await. They're introducing
| all kinds of problems into code because they don't have that
| foundational understanding of Promises. I think it's essential
| to know how Promises work, even if we generally recommend
| async/await.
|
| Also, Promise interface can do things that async/await cannot,
| such as Promise.all, and other unusual async execution
| scenarios. It's important to have those tools in your belt.
| nailer wrote:
| 100%, people should definitely understand Promise.all() and
| Promise.any().
| ericwood wrote:
| Maybe some codebases mandate it, but it's very common to use
| either style when it makes the most sense. The classic syntax
| is by no means deprecated or superseded by async/await.
| [deleted]
| throw_m239339 wrote:
| > The default way promises are used is now async/await.
| `.then()` should not be introduced as anything more than 'you
| may find this in older codebases'.
|
| No, because you might have to write explicit promises in the
| browser with async API that are callback based.
|
| You need to understand how promises work to use async/await at
| first place anyway.
|
| Just like it's better to understand how prototypal inheritance
| works in JS BEFORE even using a single class declaration.
| hutzlibu wrote:
| "Just like it's better to understand how prototypal
| inheritance works in JS BEFORE even using a single class
| declaration. "
|
| About that, does JS class inheritance now work like classes
| in java for example? Or is it still just syntactic sugar for
| the prototype inheritance? By your wording, I assume the
| later?
| [deleted]
| wa1987 wrote:
| Well, it's complicated :-)
|
| https://stackoverflow.com/questions/36419713/are-
| es6-classes...
| hutzlibu wrote:
| Wow. I was hoping, at some point things would improve a
| bit.
| wa1987 wrote:
| Agreed. I find myself using a pretty small subset of the
| language which definitely doesn't include the class
| keyword. Doubt I'll ever find it useful.
| hutzlibu wrote:
| Yeah, like many people, I ended up making my own
| inheritance routines. Then when class came out, I was
| half rejoicing, half regretting to put up the work. But
| well, no thanks. I rather keep using my own far from
| perfect way of things.
| ragnese wrote:
| Correct. It's still prototype based. Thus making the class
| keyword actually MORE confusing for people from other
| languages, IMO.
| ddoolin wrote:
| I've had this site's Regex section bookmarked for awhile and it's
| been a great tutorial and reference. I can't speak to the other
| content but if it's similar, it would be of good quality.
| jonnycomputer wrote:
| 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.
| weaksauce wrote:
| It was tongue in cheek though... the summary tells you as much.
| jonnycomputer wrote:
| I mean, I read it, and assumed the rest of the guide was also
| tongue in cheek.
| SamBam wrote:
| Every single example on that page was clear bunk -- showing
| the worst habits of some developers, and making clear why
| they are terrible.
|
| I think if you've gotten as far as that chapter, it would
| be pretty impossible not to realize it was tongue in cheek.
|
| At the top of the page is a big warning triangle that says
| "Irony detected."
|
| No other chapter includes such a prominent warning. I think
| it's pretty clear that the "gag" is specific to that
| chapter.
| z3t4 wrote:
| 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) ...
| forest_dweller wrote:
| This site is a great resource. The event delegation section is
| something I have bookmarked as when entering a new contract I
| typically don't have access to my own code to use as a reference.
| cosmotic wrote:
| 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).
| willio58 wrote:
| I think it's precisely the fact that js is constantly changing
| that they've branded this as "modern".
| root_axis wrote:
| It's not pointless. In the context of JS 'modern' generally
| means es6+ or node as opposed to es5.
| jonnycomputer wrote:
| just say es6, though, i guess?
| simonw wrote:
| Disagree. I've been writing JavaScript for twenty years, and
| I'm very aware that there's a lot of "new" stuff that I need to
| brush up on. When I saw it call itself "modern" I instantly
| assumed that it would be covering the kind of information I
| need to know.
| wolfadex wrote:
| 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.
| wa1987 wrote:
| > - for in loop - for of loop
|
| It's 2020 and you still use loops? ;-)
|
| source: https://github.com/buildo/eslint-plugin-no-loops
| hombre_fatal wrote:
| for/of is an iterator. It consumes the Symbol.iterator
| interface and is totally different from the for(i++)
| statement.
|
| That eslint rule is a good example of a cargo cult. The
| second link in its rationalization argues for using
| underscore over touching a dangerous loop yourself.
| joshxyz wrote:
| i think it's great on how it brushed on forms and web api's,
| but in your case it seems exploringjs.com would be a fit
| (grouped by ecmascript versions).
|
| OTOH out of scope are server-side JS (NodeJS), transpilers
| like babel, bundlers like webpack, and of course package
| managers like npm and yarn
| 0df8dkdf wrote:
| to be fair. anything after 'use strict' can be consider
| 'modern'. However with the rate ES7 - 10 is going. Yeah this
| wouldn't be modern.
| mixmastamyk wrote:
| Make a merge request.
| corytheboyd wrote:
| Honestly, it's fine if documentation goes out of date,
| otherwise what's the point of writing anything at all? The onus
| is on the reader to check the publish date of what they are
| reading, and to cross reference it with other sources to ensure
| accuracy.
| kaycebasques wrote:
| I'd be careful about relying on "updated" dates too heavily.
| As a professional technical writer, I've seen that some
| people bump the "updated" timestamp for any update, no matter
| how small. At other times it's bumped automatically by the
| build system. I think the best practice is to only bump the
| timestamp for substantial updates, or to use an explicit
| changelog at the bottom of the doc. But that practice isn't
| standardized across docs sites.
| corytheboyd wrote:
| That's a good point to call out, thanks! There is so much
| involved in being a "defensive reader" heh
| olnluis wrote:
| I encounter this "article update" problem a lot with Java
| blogs... Baeldung instantly comes to mind. Every article I
| find there was last updated on 2020, but don't seem to have
| actually changed.
| brundolf wrote:
| 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 transition. So writing a "modern"
| (post-transition) tutorial makes perfect sense to me, and I
| don't think it will become irrelevant any time soon.
| [deleted]
| cercatrova wrote:
| 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)
| polywock wrote:
| _sighs and opens Russian learning book_
| lxe wrote:
| https://javascript.info/ninja-code hah this is a great read :)
| cgrealy wrote:
| Isn't step 1 of "modern JavaScript" to install TypeScript? :)
| brundolf wrote:
| 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.
| bob1029 wrote:
| I was half expecting the first page to explain what nodejs is
| and how to install it. Pleasantly surprised by most of this.
| jerrygoyal wrote:
| and step 2: install prettier, step 3: eslint plugins.
| halfmatthalfcat wrote:
| Amazing how many JS devs I meet (or work with) that are against
| the very idea of Typescript.
| tambourine_man wrote:
| Hi there.
| DrScientist wrote:
| 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, more supported
| ones, isn't it just another one?
|
| Surely in the end it just adds complexity and fragmentation
| of the ecosystem?
| Ankintol wrote:
| 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.
| DrScientist wrote:
| 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?
| SamBam wrote:
| Because applications on the web are increasingly that --
| full applications.
|
| I create scientific models and simulations for use in
| schools. Whether it's simulating a hurricane, or
| continental drift, electronics, or molecular
| interactions, the simulations themselves need to run on
| the browser, and all the UI that provides the users with
| all the affordances to interact with the model needs to
| also be written in JS/TS.
|
| I think your questions are just revealing a failure of
| imagination/experience for what kinds of applications run
| on the web these days.
| Ankintol wrote:
| 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 to deliver on real
| time performance requirements and to keep server costs
| manageable (certain inputs will get even high end CPUs
| humming).
|
| If breaking this SPA up is possible, it's not apparent
| even to engineers with >10 years of experience developing
| highly complex applications.
|
| Other similarly complex applications run on the web, even
| if it's unusual.
| jefftk wrote:
| Do you think the Zoom web client should have fewer than
| 10k lines? Or be broken up? What about Google Docs?
| LoathsLights wrote:
| In before someone comments: "But chances are you are not
| the person who needs something as complicated as TS
| therefore it's useless." and "If your code is more than a
| thousand lines then you're doing it wrong, all code
| should be <1000 lines that you throw out immediately and
| replace with new code".
| rictic wrote:
| Unlike other languages, typescript adds zero runtime
| overhead, and the APIs that one writes in TS are trivially
| consumable from JS. Consuming JS from TS is also made as
| easy as possible, including the option to set types aside
| entirely for some parts of your code using the "any" type,
| which means "don't type check this, just trust me that it
| works".
|
| TS really is different from other compile-to-js languages
| in this respect.
| DrScientist wrote:
| As I said, it's not a bad attempt, and it's presence has
| probably given renewed impetus to js lang improvements.
|
| Though the attempts at close compatibility mean it's not
| properly type safe despite it's name.
|
| In the end, it's still a 'splitter' to quote Monty
| Python.
| rictic wrote:
| > Though the attempts at close compatibility mean it's
| not properly type safe despite its name.
|
| Every type checked language I've used, from Haskell to
| Java to Idris to C++ to Rust has ways to override the
| type checker (and either do the type checking at runtime,
| or, as C++ is often want to do, just YOLO it). It's not
| just the language but the codebase and the norms it and
| its dependencies use.
|
| Some TypeScript codebases, the types are usually
| accurate, but not enough to rely on them, so you still
| need to do runtime checks in many places. In others, if
| something says (string|null) then you know with
| confidence that it is either a string or the null value,
| nothing more and nothing less.
| vorpalhex wrote:
| It adds in developer overhead and for someone writing in
| JS that is often what you are trying to minimize.
| the_af wrote:
| Doesn't plain JS add developer overhead in the form of
| bugs and code the team doesn't understand a few weeks or
| months later?
| com2kid wrote:
| It adds overhead on initial write, saves massive overhead
| every day after that.
|
| There is JS code I deal with once a month where the
| manipulation of types is so complex I probably burn ~30
| minutes every time I have to touch it. If that was was
| transformed into TS (which is going to happen eventually)
| that'd be 30 minutes saved per month, on this one
| particular flow of data.
|
| I've done refactorings that were only possible because TS
| existed.
|
| A lot of JS unit tests consist of "ensure these fields
| exist on this object after it has been called by these
| functions."
|
| Typescript removes the need for those tests.
|
| And it removes the need to update those tests every time
| the code changes (just change the declarations
| appropriately!). And it removes the need to run those
| tests on every commit.
|
| That said, the overall code/compile/run time savings is
| possibly not in TS's favor due to how slow the compiler
| is. :/
| hn_throwaway_99 wrote:
| > 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, multi-person pure JS
| project _not_ become an incomprehensible nightmare after a
| couple years. TS makes large codebases much easier to
| maintain.
|
| There are other reasons.
|
| If anything, the consolidation onto TS from previous
| competing type systems for JS (e.g. I think Flow is dead
| for all intents and purposes, and I've seen a number of
| projects migrate onto TS from Flow) results in less
| fragmentation.
| z3t4 wrote:
| What text editor did you use before? I think the biggest
| advantage is an IDE, not the language itself.
| RussianCow wrote:
| As a daily user of IntelliJ IDEA--which, IME, has the
| best autocomplete and code suggestions of any IDE for
| dynamically typed languages--there is a _world_ of a
| difference between the quality of suggestions for a
| codebase using TypeScript and one written in vanilla JS.
| Without concrete types, the IDE often has to guess the
| possible type(s) that a value can have, whereas with TS,
| there is (generally) no such ambiguity.
| scpedicini wrote:
| 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.
| DrScientist wrote:
| 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.
| halfmatthalfcat wrote:
| 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.
| at-fates-hands wrote:
| >> Even modest SPAs reach into the tens of thousands of
| lines.
|
| I still don't get how we got from fifty lines of code for
| a form with simple client side validation to a
| React/Vue/Angular/Next version that needs 100 different
| modules and a thousand lines of code to replicate. Why do
| people see this as a huge advancement in front-end
| development?
| halfmatthalfcat wrote:
| Those libraries are providing a lot more than just simple
| validation though. Bunch of advanced validation rules,
| masking, etc. I'm sure if you dive into any of those
| modules you'd be able to see why. Not saying there isn't
| dependency bloat but it's not like people are creating
| these for the sake of it.
| jrockway wrote:
| Because people are writing applications, not forms. As
| software engineering has gotten easier, customers have
| demanded more complicated applications.
|
| Modest SPAs do have a lot of code. So does a C++ Win32
| application that calls into some central datastore. The
| complexity is not a byproduct of languages or libraries,
| but rather the customer's complicated needs.
| auganov wrote:
| Pretty annoyed with Typescript too. Mostly because of its
| popularity.
|
| Before Typescript most compile-to-js languages existed in
| their own world. You might have not liked them. But you'd
| never have to deal with them.
|
| Typescript has become so popular that many top javascript
| libraries use it too. Whatever you think of it, sooner or
| later you'll be working with Typescript code.
| DenverCode wrote:
| You mean you didn't love Coffeescript?
|
| (I'm joking)
| sundarurfriend wrote:
| This is pretty much how I feel about Javascript itself.
| vorpalhex wrote:
| 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.
| names_are_hard wrote:
| 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.
| [deleted]
| _greim_ wrote:
| 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.
| robofanatic wrote:
| Excellent. Wish all documentation\tutorial sites were this clean.
| kaycebasques wrote:
| When you say "clean" are you referring to the formatting of the
| page?
| realyashnag wrote:
| and structuring of the content, i believe.
| [deleted]
| emmanueloga_ wrote:
| Looks really nice, although ...
|
| For as good as the TOC and layout is, there's always something I
| miss when I read books from a website. I miss the spatial
| context: how much material I already covered? How much is left?
|
| I like the linearity of regular books (that includes PDFs). If
| the book is a website the next best thing for me is when the
| whole thing is just a single page. Worst thing are epubs :-p
| (hate the way the layout works with those and how slow epub
| readers tend to be).
|
| ps. I saw I can buy a PDF of this site, but just commenting in
| general.
| joshxyz wrote:
| I think comparing gaps with exploringjs.com (separated by
| ecmascript versions) would be worth a shot.
| dmje wrote:
| Never rely on Americans to spot irony
| 29athrowaway wrote:
| It is a nice tour of JS features.
|
| Some things missing: Typed arrays, template literals,
| Internationalization API (Intl).
|
| Date will be replaced with TC39 Temporal soon.
| sireat wrote:
| Still fantastic!
|
| When I teach Javascript to students, javascript.info is one of
| the main sources I use besides MDN.
|
| PS My copy of JS the good parts is getting a bit dusty somewhere
| in the garage...
| throwawaysea wrote:
| Is there a good tutorial that covers all the various frameworks
| that are in use? Modern Javascript has become very complicated
| due to the proliferation of these frameworks more so than the
| programming language.
| icebr9 wrote:
| Tbh if you know JavaScript well all these frameworks work like
| js. I build couple websites using vanilla js and when using any
| framework I can tell what it is doing behind the curtains
| because I have done it myself dozen or times in multiple lines
| of normal js
___________________________________________________________________
(page generated 2020-12-07 23:00 UTC)