[HN Gopher] JavaScript for Impatient Programmers
___________________________________________________________________
JavaScript for Impatient Programmers
Author : arkj
Score : 144 points
Date : 2021-12-24 12:54 UTC (1 days ago)
(HTM) web link (exploringjs.com)
(TXT) w3m dump (exploringjs.com)
| armchairhacker wrote:
| My "real" advice for impatient programmers: just start
| programming, and every time you encounter a problem google it.
|
| Don't know how to setup node.js? Google should lead you to `npm
| init` or a starter. Getting some weird syntax error? Google it.
| Once you learn the basics, want to do X? Google it and determine
| a) how to do X, or b) if X can't be done / is bad practice.
|
| Just by diving head-first into whatever you're trying to
| accomplish (or a toy project if you just want to learn),
| eventually you'll start to get the hand of syntax, libraries, and
| general programming style. But read articles every once in a
| while on best practices so you aren't learning the "wrong" way to
| do things.
|
| The big drawback is that there are a _lot_ of Google results that
| are outdated, novice, or flat-out wrong. You have to really learn
| how to do research on the internet. But this is a skill you
| should learn because you can apply it to _anything_. My general
| advice: consult official docs whenever possible; Stack Overflow
| is reliable but check the answer 's comments to see if it's
| outdated; use Reddit to compare X vs. Y; try to avoid long wordy
| articles on bloated sites, generally the better the writer = the
| better the article and more likely it's accurate.
| divbzero wrote:
| Another great source for up-to-date info on getting started are
| tutorials from official docs. Most mature projects will on
| them.
| yummypaint wrote:
| I spent the last week doing exactly this after going over a
| decade without making a web page and having never done anything
| java related. The key thing for me was finding an existing
| website i liked that was hosted on github pages and used that
| as a template/example to see how things fit together. The
| learning curve at the very beginning was brutal, but once you
| get a few toeholds and can iterate things quickly start falling
| into place. The problem with the textbook approach is you don't
| know what you can skip until you already know it.
| 2muchcoffeeman wrote:
| The problem with this is that sometimes a good tutorial gives
| you insight on how they do things in the language/framework
| way.
|
| If I pick up something new and just try to piece things
| together using a sample project or whatever, I tend to think
| in ways from the most familiar language I work in.
|
| Also without familiarity, you can't judge if the sample you
| picked is super opinionated or does things in a weird way.
| pwdisswordfish9 wrote:
| Most stuff getting slung around, as the parent mentions, is
| rooted in the kind of development that relies on NPM-adjacent
| tooling. The two things you mention (Java and modern Web
| development, especially something modelled after another
| thing found on GitHub Pages) tend to be miles apart in this
| decade. Where does Java come in to it?
| yawaworht1978 wrote:
| How much time would you say is fast enough to build a full
| front end and back end login/authentication system in nodeJS
| with any db ? I mean including throttling, pwd reset, forgot
| email/pwd, 2fa, confirmation email etc? Most of the tutorials
| are notoriously outdated and won't work bc dependencies, but I
| have build one such app.
|
| For someone who knows the J's basics , I mean
| armchairhacker wrote:
| It depends on what exactly your app is because you might be
| able to use existing solutions.
|
| But my recommendation is Firebase or Supabase. These tools
| were basically designed for this type of webapp. I know a
| team of junior devs who created a production-app in a few
| weeks with Firebase. Firebase handles authentication, the
| database REST endpoint, and various other common webapp
| functionality, so that stuff is seriously achievable in
| hours. In Supabase "signup", "login", "login with provider",
| "send reset email" are all single JS functions.
| jbay808 wrote:
| Yeah, I tried this approach and got as far as authentication.
| At that point Google would only tell me what _not_ to do.
| rockbruno wrote:
| > every time you encounter a problem google it.
|
| One "patience" problem I have is that problems are usually much
| more complex than they appear. Node is giving you some random
| dependency error? It's because you need to install X. But to
| install X you need to install Y. But to install Y you need to
| install Z. But Z requires some specific node version. But that
| specific node version will break A, and to not break A you need
| to install B which requires you to disable your Mac's SIP so
| that it can work with X. If I sniff that I problem will lead me
| to a hole like this I get so annoyed that I start avoiding that
| specific platform as much as I can.
|
| Software is so fragmented nowadays that even setting up
| something simple requires you to handle tons of difference
| pieces for no good reason. Monopoly aside, this is one reason I
| like Apple having full control of iOS development.
| armchairhacker wrote:
| Yes, node.js and JavaScript transpile issues in particular
| are super annoying. But idk if any book would help you with
| this either.
|
| I recently discovered Vite (with pnpm) and so far I haven't
| had _any_ annoying JS /npm/engine issues, so that would be my
| recommendation. Generally to setup something I either a) run
| `<build-tool> init`, b) "create new project" in IntelliJ, or
| c) clone a medium-sized project on GitHub, then remove the
| code and leave the configuration files.
| dpweb wrote:
| I like Google, or better Stack overflow, when you're at your
| desk writing code. Books (preferably paper books), to browse in
| free moments when not working.
|
| I used to keep a paper copy of "JavaScript pocket reference" on
| me, and pull it out on the train, or just sitting around at
| night, to help get the concepts.
| tyingq wrote:
| I'm the type that likes to learn from some real, existing
| codebase. This is frustrating in the JS space, as you would
| have to have the right version of a bunch of stuff to do that,
| and how to use it. Libraries, packers, packagers, frameworks,
| minifiers, and so on.
|
| Other languages have some of that sprawl, but none quite to the
| same level, and none with the same pace of change.
|
| If you learn like me, my advice would be to have a list of
| potential candidate projects to learn from and move on to the
| next one when the tool and dependency hell proves too much.
| davidmurdoch wrote:
| I find that generally true of every other language except JS.
| You run `npm i` and all correct dependencies are installed.
| tyingq wrote:
| Was not my experience. The system npm was either too new or
| too old for the codebase I picked (can't remember). So
| uninstalled, installed a different one, then some unfixable
| issue with something called fsevents, other issues
| regarding "peer dependencies", etc. Similar issues with the
| second one I tried.
|
| The third project I went with went much better, though it
| was still difficult to learn things (even if they are
| working) as every project seems to choose different
| build/deploy tools.
| davidmurdoch wrote:
| Sometimes I forget about npm v7-8 (the latest versions).
| They're "backwards compatible" if you consider "breaks
| everything" a form of backwards compatibility.
|
| So maybe you're right. Perhaps everything is terrible
| everywhere.
| wruza wrote:
| I always found this way too clumsy, because you learn X but
| accidentally miss Y, and X becomes your tool of choice at
| places where it doesn't really fits best or at all.
|
| Javascript traditionally had NO good language guides, and this
| one looks pretty like the one you _should_ read in advance.
| Other resources are either more library reference-like, very
| situative or for unclear standard, not exhaustive, or just
| stupid and wrong. I've read a language guide A to Z for every
| PL I used in my life (a bunch), and can say by skimming through
| few rough /key topics that it is definitely a good one. No
| offense, but my advice is to not apply your advice _when_ there
| is a good guide. You'll save both your own time and the one's
| who will come after.
| Lamad123 wrote:
| Start with _Javascrip, the Good Parts_.
| jmnicolas wrote:
| The problem with this method is that you don't know what you
| don't know.
| DonHopkins wrote:
| Which is better than thinking you know what you don't know.
|
| The most important thing impatient programmers need to learn
| is TO NOT BE IMPATIENT, not how to learn a programming
| language in X minutes.
|
| Learning patience will help you in all aspects of life.
|
| Do you really want to share the road with somebody who
| learned to drive in 5 minutes, and doesn't have the patience
| not to speed, tailgate, run stop signs, red lights, and pass
| you on the right by driving on the sidewalk?
|
| More "real" advice: Read LOTS of other people's code.
|
| Need to use a library? Then first read the documentation,
| then read the source code, so you actually understand what it
| can do, how it does it, that it's not magic, what its
| limitations are, how to use it, and if you actually need it.
|
| I've been working on learning and reading the D3 data
| visualization library for several years, bit by bit. It's a
| wonderful library, there's a whole lot to it, the code is
| brilliant and expertly written, and I've learned a LOT about
| JavaScript programming in general by reading different parts
| of it again and again.
|
| https://github.com/d3/d3
|
| Mike Bostock: 10 Years of Open-Source Visualization: Did I
| learn anything from D3.js? Let's see...
|
| https://observablehq.com/@mbostock/10-years-of-open-
| source-v...
|
| >In honor of D3 1.0's tin anniversary, I thought I'd reflect
| on lessons learned. This isn't intended to be too
| comprehensive or serious -- just a handful of observations as
| I look ahead to the next ten years. But I hope a nugget or
| two will interest you, too.
|
| HN discussion:
|
| https://news.ycombinator.com/item?id=26240339
| post-it wrote:
| > Need to use a library? Then first read the documentation,
| then read the source code, so you actually understand what
| it can do, how it does it, that it's not magic, what its
| limitations are, how to use it, and if you actually need
| it.
|
| That's the opposite of thread OP's advice. If you need to
| use a library and you're impatient, find the closest
| example to what you want to do and then hack away at it
| until it does what you want.
| DonHopkins wrote:
| It's an elaboration of his advice, not the opposite.
| Please be patient enough to read all of the OP's advice:
|
| >But read articles every once in a while on best
| practices so you aren't learning the "wrong" way to do
| things.
|
| >The big drawback is that there are a lot of Google
| results that are outdated, novice, or flat-out wrong.
|
| >My general advice: consult official docs whenever
| possible
|
| After you read the official docs, and decide you actually
| want to use a library for something that's not trivial,
| one-off, or throw-away, it will benefit you to actually
| read the source code itself, which is by definition not
| out-of-date and incomplete, like so many of the articles
| about the library you can find by googling and reading
| stack overflow.
|
| In my book, hacking away at using a library until it does
| what you want involves reading the source code in the
| developer tools by setting breakpoints and browsing the
| call stack, function definitions, local variables, and
| data structures, while the code is alive and running.
|
| Once you've done that, it's a lot more interesting and
| easier to then read the entire source code on github
| front to back, to learn the library well, because you
| will have a lot more context about how it's actually used
| and fits together, its dynamic runtime behavior, and the
| shape and texture of its objects and data structures.
| vaiso wrote:
| Agreed, this is how you end up with people hard-coding
| hundreds of iterations because they don't know what arrays or
| loops are. I think it's better to learn top-down and bottom-
| up simultaneously, by building your own projects as well as
| taking a more structured fundamentals course.
| smoldesu wrote:
| I think this strategy works for just about every language _but_
| Javascript. Last week I was trying to learn JS with this method
| and it sucked, almost exclusively because there is so much
| content to sift through that it 's difficult to separate the
| wheat from the chaff. Reading the documentation, while not
| particularly glorious, is the most time-efficient method of
| learning a language in my experience.
| Lamad123 wrote:
| You cannot just google your way through it. There are times
| when you don't even know what to google. I remember as an early
| beginner being stuck with something that had to do with
| closures. I had no idea what was going on and didn't know what
| to google and when I asked questions on stackoverflow and
| reddit please started saying things about decorators and
| whatnot!!! It is only when I sat down and went through some
| kinds of structured tutorials that I knew what had stomped me.
| Sometimes, you ight just have to be aware of some problems even
| if you'd don't understand them properly but you are aware of
| their existence and what they are called.
| Waterluvian wrote:
| 100%
|
| And the most important advice, in my opinion, is to expect to
| write a LOT of garbage code that you replace almost
| immediately. It's not like pouring concrete. You're not wasting
| your time or code. It's a learning process and once you've
| written it, you've absorbed all the good and bad lessons from
| it.
|
| I struggled a lot with paralysis where I refused to even begin
| a project until I could see the "right way" to get to the
| finish line. But now I just do a tiny little bit of design (for
| toys and personal projects) and then dive in.
|
| There's no better way to deeply understand why a certain
| concept is important than doing it wrong and suffering the
| consequences.
| ryannevius wrote:
| A resource I commonly turn to when I'm feeling impatient is Learn
| X in Y Minutes: https://learnxinyminutes.com/
| DonHopkins wrote:
| That's a great resource, but not a miracle cure for ignorance
| or magic pill for knowledge and skill.
|
| If you're actually serious about learning to program, then it's
| going to take more than a few minutes of your life to learn.
|
| But if you can't stomach investing more than a few minutes in
| learning to program in JavaScript or any other programming
| language, then you should really find something else do to with
| your extremely limited time.
|
| Teach Yourself Programming in Ten Years, by Peter Norvig:
|
| https://norvig.com/21-days.html
|
| The last time I posted a link to this important essay,
| impatient people who weren't very serious about investing any
| time in learning or reading simply and immediately responded to
| the title, but didn't bother to actually follow the link or
| read and respond to any of Peter Norvig's brilliant essay (and
| probably didn't even know who he was), so here is an excerpt.
|
| >Researchers (Bloom (1985), Bryan & Harter (1899), Hayes
| (1989), Simmon & Chase (1973)) have shown it takes about ten
| years to develop expertise in any of a wide variety of areas,
| including chess playing, music composition, telegraph
| operation, painting, piano playing, swimming, tennis, and
| research in neuropsychology and topology. The key is
| deliberative practice: not just doing it again and again, but
| challenging yourself with a task that is just beyond your
| current ability, trying it, analyzing your performance while
| and after doing it, and correcting any mistakes. Then repeat.
| And repeat again. There appear to be no real shortcuts: even
| Mozart, who was a musical prodigy at age 4, took 13 more years
| before he began to produce world-class music. In another genre,
| the Beatles seemed to burst onto the scene with a string of #1
| hits and an appearance on the Ed Sullivan show in 1964. But
| they had been playing small clubs in Liverpool and Hamburg
| since 1957, and while they had mass appeal early on, their
| first great critical success, Sgt. Peppers, was released in
| 1967.
|
| This essay is a classic that's been discussed on HN numerous
| times:
|
| https://news.ycombinator.com/item?id=27411276
|
| https://news.ycombinator.com/item?id=20543495
|
| https://news.ycombinator.com/item?id=16574248
|
| https://news.ycombinator.com/item?id=5519158
|
| https://news.ycombinator.com/item?id=3439772
| ai_ia wrote:
| This essay, which has helped fixing my initial mindset a lot,
| is directed for complete beginners.
|
| The website OP mentions is for someone who already knows how
| to program well in one or more language and want to take a
| quick look at another language syntax.
| DonHopkins wrote:
| Titles like "Learn X in Y minutes" fool impatient people
| who don't take the time to follow links or read more than
| titles into believing the incorrect notion that it's
| possible to do what the title promises. They never get
| around to reading the actual articles or disclaimers that
| it actually takes a long time and a lot of practice to
| become proficient or even competent in a programming
| language.
|
| Then they think they can learn programming languages by
| reading Twitter instead of writing code, and claim on their
| resumes they know languages they've only read a few blog
| posts about.
|
| Those are the same people who complain that they hate Lisp
| by parroting tweets that it has "too many parenthesis",
| even though other languages have much more complex syntax,
| much less powerful and more limited and difficult to use
| macros and meta-programming facilities (like C macros and
| C++ templates), that force you to use an ugly mish-mash of
| even more inconsistent punctuation line noise like
| brackets, braces, escapes, quotes, backquotes, obscure
| operator precedence and ad-hoc parsing rules, and a myriad
| of other hard-to-learn punctuation that makes the code much
| less readable than Lisp, without realizing that there is
| actually a point to Lisp's clean simple parenthetical
| syntax.
|
| There's also a long sad history of impatient people not
| wanting to bother learning JavaScript, but believing that
| they can simply learn JQuery or React or some other popular
| "silver bullet" library instead:
|
| Can you get away with learning jQuery only instead of
| JavaScript?
|
| https://www.quora.com/Can-you-get-away-with-learning-
| jQuery-...
|
| Should I learn jQuery first or Javascript?
|
| https://www.quora.com/Should-I-learn-jQuery-first-or-
| Javascr...
|
| Is it necessary to learn JavaScript before learning jQuery?
| [duplicate]
|
| https://stackoverflow.com/questions/3183545/is-it-
| necessary-...
|
| Why You Should Learn jQuery Before JavaScript
|
| https://learn.onemonth.com/why-you-should-learn-jquery-
| befor...
|
| Why Beginners Should not Learn JavaScript through jQuery
|
| https://www.codementor.io/javascript/tutorial/learn-
| jquery-j...
|
| Do I need to know JavaScript in order to learn jQuery?
|
| https://www.quora.com/Do-I-need-to-know-JavaScript-in-
| order-...
|
| How is it possible to learn jQuery without first knowing
| JavaScript?
|
| https://www.quora.com/How-is-it-possible-to-learn-jQuery-
| wit...
|
| Can I learn React.js if I don't know JavaScript?
|
| https://oprearocks.medium.com/can-i-learn-react-js-if-i-
| dont...
|
| Do we need to fully know JavaScript to study React?
|
| https://www.quora.com/Do-we-need-to-fully-know-JavaScript-
| to...
| Lamad123 wrote:
| I bet even the patient wouldn't put up with that gigantic list..
| 45 "chapters" is kinda too much!
| justinpage wrote:
| Another resource to consider for Modern JavaScript:
| https://javascript.info/
| Juju_z wrote:
| I like how clean this guide is. Are there any similar guides for
| Python as a quick reference?
| giantrobot wrote:
| My biggest hurdle with JavaScript was getting things to happen in
| order. Functions can be unexpectedly colorful[0] and contortions
| and boilerplate is needed to deal with that. What was unintuitive
| to me was a lot of interactions with the DOM are asynchronous
| without being explicit about it. So you've got to chain a bunch
| of asynchronous calls together to make sure a sequence of events
| occur. Most other languages make this sort of asynchronous
| callback hell explicit.
|
| Once you understand this aspect of the language it's an annoying
| (to me) idiosyncrasy but manageable. Before you understand it
| there's a lot of pouring over poorly written tutorials that gloss
| over it like it should be obvious.
|
| [0] https://journal.stuffwithstuff.com/2015/02/01/what-color-
| is-...
| eckmLJE wrote:
| If you were developing in JS in 2015 this hurdle is
| understandable.
| simlevesque wrote:
| Do you have an example of a DOM operation that is async ?
| Madmallard wrote:
| >For impatient programmers >45 modules
| mrkentutbabi wrote:
| I really don't understand why people hate JS so much. I myself a
| primarily a JS dev, and now a TS dev. TS made the experience so
| much so much better. JS is like pretty much a programming
| language for average software engineer like me. Sure, JS build
| system is a pain. I am the go to build system guy for almost
| every company I've been with, I worked with Grunt, Gulp, Webpack
| 1,2,3,4 and etc and yes I hate it, but other than that it works
| really well. If you don't touch frontend you can pretty much
| forget build system entirely. npm init is so easy.
|
| Async is easy as well. I really don't understand the hate, what
| am I missing? Maybe I'm too dumb for other programming languages.
| I did try various languages from Java, Elixir, Haskell, Rust, Go,
| Ruby, Python and JS is simply the best in productivity,
| expressiveness, ease of use and performance balance.
|
| As long as you don't code in a clusterfuck way, it is so easy to
| write JS and compose JS functions. Just use functions everywhere,
| no need class. JS is very readable.
|
| Like, seriously, Python has Python2 vs Python3 package and
| build/deployment problem. Haskell is difficult and the tooling is
| abysmal. Rust is difficult and too much choices to just write
| this and that. Ruby has no tpe system and slower than JS. Python
| is also slower, no good async, and its type system is not
| expressive as TS. Go's type system isn't expressive enough. Java
| type system is too much and JVM is complicated. Scala is
| complicated.
|
| JS/TS is:
|
| - simple/easy to use
|
| - pays the bills (you can go anywhere and find jobs as JS/TS dev
| in almost every company in the world)
|
| - everywhere, like from IoT to robotics to game development to
| server to frontend to regular scripts
|
| - easy programming language to do Leetcode style interview as
| well
|
| - if you wanna do Option/Maybe style error handling like
| Haskell/Rust/Go you can do that with TS, just wrap try catch and
| return the error with neverthrow library. This makes TS
| programming bliss!!! I freaking love it
|
| If you don't want to care about setting up NodeJS + TS, now you
| have Deno, who's pretty much out of the box everything just
| works.
|
| JS/TS is such a super boring language it feels like cheating your
| way out of software engineering. It is a language made for dumb
| people like me, maybe that's why it has no appeal for hardcore
| programmers.
|
| I owe to JS/TS on changing my life and giving me a good living.
|
| Like, seriously I don't understand the hate...
| ratorx wrote:
| I don't like JS and try to avoid it wherever possible. I have
| written some, but I'm not an expert by any means.
|
| My problems with JS/TS:
|
| Simple to start, but hard to program robustly and defensively.
| Due to the lack of typing, a lot of the codebases I've seen end
| up with extensive input validation code, which often uses fancy
| tricks that are hard to parse (unless you already know them).
| Typescript helps with this, but it is not the same as a proper
| type system because it is optional. Usually I run into runtime
| problems due to type errors with library code which doesn't
| have types (or has the wrong ones).
|
| The core language is filled with weird edge cases in coercion.
| jsfuck.com and https://www.destroyallsoftware.com/talks/wat are
| examples. This doesn't affect my day-to-day code, but it's
| equivalent to C undefined behaviour for me. A bunch of hidden
| rules that I don't really want to extensively learn and
| understand, but which will bite me when writing anything
| moderately complex. '===' is good, but I think it's really easy
| to miss the extra equals, especially if you write code in other
| languages a lot.
|
| Lack of standard library (in Nodejs). For quick things, I find
| Python a lot better. The scant JS standard library has been
| widely criticised. This is a contributing factor to the
| absolute explosion in the dependency graph whenever you start
| pulling in a lot of the common dependencies. IMO, Go and Rust
| both do a better job despite having comparably easy package
| mangers.
|
| Although some JS code is easy to read, I've seen lots of
| examples of overuse of functional indirection. Maybe it's
| something I will start recognising the patterns once I've come
| across them more, I end up ragequitting JS codebases much more
| often than other languages. Despite its flaws, Go in a good
| editor is an absolute joy to understand new codebases.
|
| I've found a combination of Python, Go and Rust to be the ideal
| combination. Each has its flaws, but for any specific use case,
| I can pick one I'd rather use than JS.
| bigyikes wrote:
| I think a lot of JS haters haven't spent much time with modern
| JS. That's how it was for me, at least. I would laugh at JS
| wat-isms and think back to the old days of jQuery spaghetti.
| Python was my favorite language.
|
| Now I'm a full time JS/TS developer and I love the language.
| It's a dream to use. The syntax is concise and logical, the
| ecosystem is vibrant, and the barrier to entry is low. I wish
| there was more JS in the scientific, CV, and ML spaces --
| Python is still superior here, imo -- but otherwise JS is my go
| to. It's no wonder we see the rise of Electron apps - the
| developer experience is just so much better.
| dgdbebbd wrote:
| Right, you need some historical context to understand the
| situation. 10 years ago JS was a shitty language with a far
| worse ecosystem. It deserved the hate it got. Then ES6 came
| along 6 years ago or so and added tons of super valuable
| language features. Suddenly you don't have to deal with the
| hoisting semantics of var or worrying about what 'this' is
| all the time. It was so nice that people started using Babel
| to use the new features ASAP. Then a couple years later, once
| everyone has a transpiler in their build process without a
| second thought (this used to be controversial!), TypeScript
| comes along and provides another huge leap in how pleasant
| the language is to use.
|
| Now it's a pretty nice ecosystem, but it used to be pretty
| bad. Not everyone's biases have caught up yet.
| hpen wrote:
| I have done JS for several years and TS more recently. I think
| TS really fixes a lot of the issues that arise while building
| large systems in NodejS. But I think people are right to hate
| on the dependency nightmare that is npm. I could complain about
| several other things but really they apply to most popular
| dynamic languages...
| mattlondon wrote:
| Broadly agree - JavaScript and typescript especially are an
| absolute joy and delight to code with.
|
| I use TS professionally, and it is my go-to choice for personal
| projects too.
|
| Deno and vscode have brought an extra dimension of awesomeness
| - I personally never liked using npm (and therefore node) and
| try to avoid it.
| seumars wrote:
| I believe the JS criticism is more about the culture and
| ecosystem than the language itself. In short: Most if not all
| JS devs are more interested in playing with specific tools and
| APIs rather than dealing with and/or implementing programming
| patterns and principles. In the last decade "small modules"
| skyrocketed the popularity of NPM and a lot of people pushed
| the idea of "don't reinvent the wheel just 'npm install'
| everything" and sadly it stuck. Basically all JS-related
| discourse reduces down to "use X instead of Y!". It started
| with packages, then libraries, then frameworks, and now meta-
| frameworks - hell even meta-meta-frameworks if you count the
| people raving about Blitz. It's like that period when young
| devs couldn't tell the difference between jQuery and JS but way
| worse. So yes, in a way you are in fact cheating your way out
| of software engineering by installing neverthrow or whatever. I
| mean the language is already pretty damn high-level already.
| robocat wrote:
| > Async is easy as well.
|
| An off-topic question: how do modern development practices
| using async code avoid race conditions and intermittent
| heisenbugs?
| hpen wrote:
| I like async. It's is easy to reason about. In what paradigm
| are race conditions avoided completely? I know Rust avoids
| "Data Races" but not race conditions as far as I'm aware.
| Nullinker wrote:
| Very nice and comprehensive resource. I don't consider myself
| impatient but appreciate the high information density and the
| ability to quickly skip past the parts that I already know and
| actually learned a few new things.
| jmnicolas wrote:
| If I was impatient to learn JS I would gasp at the number of
| chapters (45)!
| ropeladder wrote:
| Agreed. This looks like something I will be coming back to.
| Rules of thumb, recommendations, and reasons for their
| recommendations -- I'm in heaven. Too few resources hit the
| sweet spot between introduction and arcana.
| underdeserver wrote:
| > Impatient
|
| > Table of contents takes 15 minutes to read
___________________________________________________________________
(page generated 2021-12-25 23:00 UTC)