11 ms·

Eloquent JavaScript 3rd Edition (2018)

767 points by quazar 6y ago

wdb 6y ago
I am unable to find out what has changed between editions
- joshvm 6y ago
  From amazon > This much anticipated and thoroughly revised third edition of Eloquent JavaScript dives deep into the JavaScript language to show you how to write beautiful, effective code. It has been updated to reflect the current state of Java¬Script and web browsers and includes brand-new material on features like class notation, arrow functions, iterators, async functions, template strings, and block scope. A host of new exercises have also been added to test your skills and keep you on track.
- 18nleung 6y ago
  I learned JS with this book back when it was ES5 - looks like the new edition is updated for ES6
  - Kwantuum 6y ago
    ES6 came out 5 years ago
ternaryoperator 6y ago
This is from 2018. The title of the post should be updated.
- wyclif 6y ago
  Yeah, people are going to be tempted to think this is brand new without the date of publication.
- dang 6y ago
  Added. Thanks!
neovive 6y ago
I'm actually working through this book right now. I've been away from front-end coding for a bit and my weekend/evening project over the next month is to brush up on modern Javascript and ReactJS. This book is very well written and great re-introduction to JS/programming fundamentals. For those interested--Besides this book, my current learning plan includes: Javascript 30 by WesBos Exploring ES6 [http://exploringjs.com/es6/ http://exploringjs.com/es6/] Learning React-2nd Edition on O'Reilly Learning The Beginners Guide to React on Egghead Data Structures and Algorithms in JavaScript on Egghead. I also used Kent C. Dodds' excellent "JavaScript to Know for React" article as an outline.
- 3crypto 6y ago
  Thanks for posting these. I need to do some refreshing as well.
- ggregoire 6y ago
  For React, why not just read the docs? You don't really need anything else.
  - karimdxy 6y ago
    Yes. I 100% agree with you. For whatever reason most people almost alway look elsewhere for the thing while it’s right in front of them.
    - cfors 6y ago
      Sure, you're right. They are quite good. But just from my perspective, I've been a backend engineer for most of my professional career and wanted to pick up front end dev. With little javascript/html/css knowledge, I used a couple different resources. I'm still learning, but I've found that just the official documentation doesn't quite get you there if you want to get the full picture. I've been working through the following resources with a decent amount of success I think: 1. Fullstack React: The Complete Guide [0] - a wonderful book with a bunch of practical applications to build 2. Learn CSS Layout [1] - A nice write up for understanding what CSS actually is doing 3. Mozilla HTML Reference [2] - Can't get any better than this documentation 4. Eloquent Javascript 3rd Edition - Book being discussed, really enjoying working through it. Obviously, the React and Redux documentation have been great as well. I don't think that just those really give you the full picture that you need though if you actually want to build professional web applications. Just another side of the coin, I suppose. [0] https://www.newline.co/fullstack-react/ https://www.newline.co/fullstack-react/ [1] http://book.mixu.net/css/ http://book.mixu.net/css/ [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference https://developer.mozilla.org/en-US/docs/Web/HTML/Reference
shanghaikid 6y ago
I really like the first edition...
drongoking 6y ago
Is this worth buying/borrowing if you already know programming languages but not Javascript? Or is there a better approach?
- ipnon 6y ago
  No because this is an introduction to programming using JavaScript. A quick look at the table of contents shows Part 1 teaches basic OOP, Part 2 teaches basic client side web development, and Part 3 teaches basic server side development using Node. Having read the 2nd edition of this book, I can assure that if you can explain what any of the 3 main topics described in this book are in a few sentences, then you have advanced well beyond this book being useful.
- Scarbutt 6y ago
  IMO, no. It has too much ceremony to demonstrate concepts. It's for absolute beginners.
  - sixQuarks 6y ago
    Definitely NOT recommended for absolute beginners. I tried reading this as one of my first programming books and it confused the hell out of me. There are much better introductory books/courses - my recommendation is "Watch and Code - Practical Javascript" if you are an absolute beginner and want to learn javascript. https://watchandcode.com/p/practical-javascript https://watchandcode.com/p/practical-javascript Eloquent Javascript is a good book now that I know more about Javascript, but please NEVER EVER recommend it as the first book for an absolute beginner.
    - terrycody 6y ago
      marked this,thx, btw, I always want to choose head first series to be my 1st book, what do ya think compare with eloquent JS for absolute beginner?
      - sixQuarks 6y ago
warent 6y ago
I would consider myself pretty close to an expert with JavaScript. I've been using it for 5 years professionally, currently use ES2020. Fairly familiar with Node 12, V8, etc. But I'm always worried about those situations where you dont know what you dont know. This might sound strange, but would anyone recommend any reading material or blogs for someone at my level?
- mpoteat 6y ago
  I would maybe recommend Typescript if you want to harness the type level power of "proving" correctness for certain aspects of your code.
  - leshow 6y ago
    Big scare quotes there, you can't really 'prove' much in typescript. Don't get me wrong, it's a nice type system they've tacked on to JS, but it's far and away from proofs of correctness. At best, it's an optional type system with escape hatches.
    - futureproofd 6y ago
      You can only 'prove' what you expect from your design. This works in most cases and saves a lot of guesswork on big, unfamiliar projects. It's not an integral part of JS though, so I wouldn't recommend learning it as a foundation.
- narak 6y ago
  http://youdontknowjs.com/ http://youdontknowjs.com/
- guruparan18 6y ago
  I am not a full blown Javascript developer (backend developer here), but had been using JS and other frameworks for about 10 years now. I subscribed to Dan Abramav's "Just Javascript" [1] email. It is really good to read/follow and has one concept and idea explained well. [1]: https://justjavascript.com/ https://justjavascript.com/
kevindeasis 6y ago
Here are the things that I really really hate about javascript: I find javascript really hard and annoying, even if I have enough experience with JS that lets me build a basic react framework, I still find it hard to use. On top of that, getting javascript jobs is harder compared to other programming languages. IE: you need 7 years of experience for a company at the same level where they only need 1 year of IOS/Android experience. You always have to be keep up to date. The popular libraries that you can use changes so fast, and sometimes they don't even work. Javascript gets a lot of disrespect from beginner engineers. Something about doing frontend work, isn't hard and it isn't software engineering in their perspective There are so too many ways to do the same thing, unlike something like lets say golang You always have to learn more than javascript to compete with other javascript developers. IE: dev ops, backend, database, sre, ux design
- umc0der 6y ago
  It's gotten better over the years and some good things came with es6. The half life of all these frameworks and libraries that come into fashion is pretty annoying. The principles don't change much though. I don't like that it caters to both the object-oriented and fp world and becomes a mishmash of both.
- ausjke 6y ago
  I'm sure you will be downvoted as hell because you're critic and not upbeat, HN just likes everyone saying good words all the time, i.e. stay politically positive. However I strongly believe critic is more meaningful most of the time as long as it does not have bad intention, thus I upvote you. JS is indeed hard, learning vuejs for the sake of 'it's simpler than react' right now.
  - hombre_fatal 6y ago
    Client dev was always hard. People just mistake that for Javascript because they don't have any experience building clients. For example, I'd say JS/React is vastly easier than learning Cocoa/UIKit. Writing GUI code that runs on N user devices is harder than writing headless code running on a single server. Btw, if they're getting downvoted, it's because "oh, Javascript is in the title? time for me to complain about it like people do in every JS-related HN thread!" is a tired HN comment.
BenoitEssiambre 6y ago
I've been toying with the idea of promise free async/await lately. I'm interested in feedback anyone would have. https://github.com/bessiambre/casync https://github.com/bessiambre/casync
- no_wizard 6y ago
  So generators are used here because of the natural way of calling “next” and yielding a result. How would this work for say, an XMLHttpRequest? Since you have to next into callbacks there I don’t think yield travels the function boundary...so you abuse next instead?
  - BenoitEssiambre 6y ago
    Wow I haven't used that directly in a long time. Ideally you would wrap it to be in continuation passing style. This would look something like: function fetchUrl(url,done){ var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) { done(null,xhr.responseText); }else{ done(new Error("something went wrong")) } } } xhr.open('GET', url, true); xhr.send(null); } Then you could do: let response=yield fetchUrl('http://example.com',next); edit: In case this doesn't really answer the question: If you really don't want to wrap, it would work inline too. It would just be harder to read and follow: var someFunction =casync(function*(url,next){ var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) { next(null,xhr.responseText); }else{ next(new Error("something went wrong")) } } } xhr.open('GET', url, true); var response = yield xhr.send(null); ... });
- fenwick67 6y ago
  I have avoided yield() and generators like the plague because they're hard to read and I've never seen them used except in examples explaining how they work. Yield feels like recursion - a neat trick for some corner cases but generally unnecessary.
0xff00ffee 6y ago
I always skip to the async part of JS text because explaining it is a bit like handing a shotgun to a five year old. I think the folks over at risingstack have the best explanations, IMHO. I'm surprised they attempted timeouts in promises with so little text, that's actually pretty dangerous pattern because it glosses over the complexity in actually stopping an in-flight promise. It is VERY easy to end up with hundreds of thousands of unresolved promises with their pattern. Dangerous! There is a great repo on this issue.... aand I can't for the life of me find it. Basically there's a github project that uses generators and passes an atom down through the call stack to ensure everything below the race promise is aware that it is being halted. And even that doesn't handle all the nuances of this pattern. And if anyone knows what github repo I'm talking about, I'll give you ... 50 DKP?
- zer 6y ago
  Regarding your second point: This sounds similar to .NET‘s CancellationToken. It works very well there. What are those nuances in JavaScript which aren’t handled by it?
  - 0xff00ffee 6y ago
    I think you're going to point out that I'm about to demonstrate non-JavaScript nuances, but here are issues I've encountered: Let's take a great of example of where promises are used most often: AJAX. If the endpoint isn't RESTful and there is state on the other end, cancelling a promise requires updating the entire module of the new state. There can be multiple reasons for cancelling, and the code needs to be aware of what is happening beyond a simple timeout. Same thing goes for USB devices (via libusb+ffi) and serial-ports (via serialport). In flight requests can disturb state if cancelled, and it makes the programming very complex to just time-out. One could argue AJAX and hardware programming are outside the domain of JavaScript, but I wouldn't. I guess it is more than a "nuance", it is the observance that cancelling an asynchronous operation in general can have unintended consequences if not handled correctly ... beyond memory leaks from unresolved promises.
- galaxyLogic 6y ago
  I used to use more "Promises" but now I mostly code with plain callbacks if possible. It is just simpler, less thinking needed. I spend that thinking-budget on other things. One thing that is tricky with async is that nobody tells you if the async function never does what it should. I wish they would add some more built-in support for that in the next JS version. Promises hold promise (pun intended) but they are a bit too complicated for my brain.
tracer4201 6y ago
As someone who hasn’t done much JavaScript since AngularJS in 2014/2015, what is the current state of JS like? I see there’s Angular (not AngularJS that I worked with), React, and some other frameworks. I see there are all kinds of bundlers and plug ins for these things. When I was doing AngularJS, I’d just link to a few dependencies manually from a CDN. Looks like now there’s a bunch more complexity and package management for front end dependencies. It feels like FAR more complexity, but I’m not sure what has been gained. I also don’t know that much, so would love to learn perspectives here from people actively developing in this space.
- ridicter 6y ago
  If you're looking for a fully featured framework, Angular is a joy to work with. React is great too, but the configuration overhead is enormous due to the fact that it's mainly a view library. I realize you are pining for the days when you just pasted a CDN link in your index.html, but while those use cases still exist, for the most part users are demanding more native-like web experiences, which requires a bit more complexity. One of the main strengths (and according to some, weakness) of Angular is that it has everything you might need to create a full featured SPA out of the box, and it's all tightly orchestrated by the Angular CLI. Creating a component or a service is a simple command, and many third party packages leverage the CLI (Angular Schematics) to install and configure themselves in your codebase. Core packages--such as such as forms, router, angular material--are all high quality (by Google), updated together, and work cohesively with each other. That means updating even major versions of Angular is an easy `ng update` command. For me, the minimal configuration overhead is a BFD, as I plain hate that stuff. The fact that Typescript has been a first class citizen of Angular from its outset makes development pretty enjoyable. I'm so used to exploring APIs using intellisense, leveraging types to figure out what data types can be passed in functions, relying heavily on auto-complete/auto-import to pick up my pieces and finish typing a word for me and importing the corresponding library while I keep going. Granted, there is a significant learning curve. But once you get over the initial learning curve, you become incredibly productive. Arguably, the learning curve in other frameworks is worse, given that you have to research what libraries to use (e.g., which forms library, with its own set of conventions), configure it, and make sure it plays nice with the other patchwork of libraries.
chrischen 6y ago
Does anyone have a book recommendation (free or paid) that is modern and up-to-date, preferably regarding typescript, that talks about best practices and patterns for large-scale project design and code structure? For example, a book that could go into details of code practices at companies like Airbnb, Facebook, or Google.
- taylorlapeyre 6y ago
  Typescript is relatively new, and I think a lot of those companies are still trying new things and experimenting with what works. I expect that we will see more refined content and books about TS-at-scale in the near future though. However, for those looking for a great way to learn Typescript from a beginner's perspective I can fully recommend Execute Program[1]. [1]: https://www.executeprogram.com/ https://www.executeprogram.com/
  - chrischen 6y ago
    At the speed of javascript though, it's pretty mature now. When I tried searching on Amazon I was getting back $30+ dollar ebooks with chapters on how to use Gulp (superseded by webpack or babel)...
- zachrose 6y ago
  > patterns for large-scale project design and code structure I would be particularly interested in this. The OP has a chapter on "Program Structure" but it seems like more a toolbox of language constructs. It would be nice to see a book that went through a few archetypes of common JavaScript programs (command-line script, daemon, enhanced webpage, single-page app) and gave a basic blueprint for what parts are needed and how they interact.
- aastronaut 6y ago
  A project in TypeScript is not much different from one in JavaScript structure wise. The biggest difference might be the explicit work on types and modeling your problem to make good use of composite types. In the source code you'll have some type definitions where implementation and usage sit close to each other (to enforce a local implementation), and others where a type is more like a serializable DTO (data transfer object) between different domains and seen more global throughout your application. You'll get a feeling when mapped types should alter a type or when a local type definition might be better (TS is structurally typed for a reason). Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2]. To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine. I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects. A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more. [0] https://fsharpforfunandprofit.com/books/ https://fsharpforfunandprofit.com/books/ [1] http://loredanacirstea.github.io/es6-design-patterns/ http://loredanacirstea.github.io/es6-design-patterns/ [2] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [3] http://learnyouahaskell.com/ http://learnyouahaskell.com/ (a bit dated though) [4] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [5] https://quicktype.io/ https://quicktype.io/ [6] https://lerna.js.org/ https://lerna.js.org/
mesaframe 6y ago
I read this book and found that explanations of quite a number of topics were misleading.
- vga805 6y ago
  Do you have examples of this? Perhaps they could be clarified in errata, or future versions.
  - mesaframe 6y ago
    Are you the author? I'll definitely give it a re-read and update.
smlckz 6y ago
JavaScript is very expressive and powerful language. Maybe hard to learn. The prototypal inheritence and 'this' were confusing to me and took much time to understand those. Then I learnt that prototypal inheritance is a superset of ''class''ical inheritance [1] as well as this [2]. Hmm. With Reflect, Proxy etc. you have great metaprogramming capabilities that make this language much powerful. Still, there are some (many?) edge/corner cases and unfixable bugs (aka features) that the language is stuck with for the sake of backwards compatibility and developers have to learn these. (The most famous of these might be typeof null === "object") When I look at the amount of features added to the language specification, sometimes it seems like it is going to become another incarnation of the C++ specification. I still like its expressiveness and power, but if it becomes another C++ in future, I have to look somewhere else. (TypeScript maybe.) [1]: https://aaditmshah.github.io/why-prototypal-inheritance-matters/ https://aaditmshah.github.io/why-prototypal-inheritance-matt... [2]: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent and https://www.crockford.com/javascript/private.html https://www.crockford.com/javascript/private.html
- kazinator 6y ago
  I'm convinced that prototype object systems represent a poor set of requirements. Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish. They don't represent a set of requirements that amount to a good OOP system.
  - smlckz 6y ago
    Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.com/questions/2800964/benefits-of-prot...
    - searchableguy 6y ago
      > @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.
markthethomas 6y ago
this. is. awesome. SO glad this book is being kept up to date
johnchristopher 6y ago
Is there an equivalent for php?
mrwww 6y ago
We used EJS in our basic programming courses in my CS program and it was a great book. Loved the exersices you could try directly in the book! I now program JS for a living so i guess the book also really worked. Thank you for the third edition!
htatche 6y ago
There is an equivalent for Ruby too in case you're interested.
- marijn 6y ago
  That's by a different author with no connection to this book, though, so calling it equivalent is misleading.
fizixer 6y ago
Can anyone recommend reading for the web-related Javascript "API" so that when Javascript is used in the form of generated code, e.g., through asm.js, the "API" can be used by the "generating program" without the need to learn all of Javascript. Essentially so you could do HTML/CSS/some-other-language (using asm.js, emscripten, or some similar technology) instead of HTML/CSS/JS.
varrock 6y ago
Great read, though his writing style is less intuitive if you are fairly new to JavaScript and trying to grasp some of its concepts. For example, in his reduce function [0] example, he names his variable "current" to bind the accumulated value the reduce function is going to eventually return. That is a totally fair name, but I don't know if it really "clicks" if you were reading over this for the first time. I think it would be faster to grasp the reduce function's purpose if it was simply named "accumulated" or something alike, especially when this snippet is advertising the idea of higher order functions and callbacks. Little things like this I am nit-picky about, but overall, great book. [0] https://eloquentjavascript.net/05_higher_order.html#h_fx3e34kT/k https://eloquentjavascript.net/05_higher_order.html#h_fx3e34...

767 points by quazar 6y ago

wdb 6y ago

I am unable to find out what has changed between editions

joshvm 6y ago
From amazon > This much anticipated and thoroughly revised third edition of Eloquent JavaScript dives deep into the JavaScript language to show you how to write beautiful, effective code. It has been updated to reflect the current state of Java¬Script and web browsers and includes brand-new material on features like class notation, arrow functions, iterators, async functions, template strings, and block scope. A host of new exercises have also been added to test your skills and keep you on track.
18nleung 6y ago
I learned JS with this book back when it was ES5 - looks like the new edition is updated for ES6
- Kwantuum 6y ago
  ES6 came out 5 years ago

ternaryoperator 6y ago

This is from 2018. The title of the post should be updated.

wyclif 6y ago
Yeah, people are going to be tempted to think this is brand new without the date of publication.
dang 6y ago
Added. Thanks!

neovive 6y ago

I'm actually working through this book right now. I've been away from front-end coding for a bit and my weekend/evening project over the next month is to brush up on modern Javascript and ReactJS. This book is very well written and great re-introduction to JS/programming fundamentals. For those interested--Besides this book, my current learning plan includes: Javascript 30 by WesBos Exploring ES6 [http://exploringjs.com/es6/ http://exploringjs.com/es6/] Learning React-2nd Edition on O'Reilly Learning The Beginners Guide to React on Egghead Data Structures and Algorithms in JavaScript on Egghead. I also used Kent C. Dodds' excellent "JavaScript to Know for React" article as an outline.

3crypto 6y ago
Thanks for posting these. I need to do some refreshing as well.
ggregoire 6y ago
For React, why not just read the docs? You don't really need anything else.
- karimdxy 6y ago
  Yes. I 100% agree with you. For whatever reason most people almost alway look elsewhere for the thing while it’s right in front of them.
  - cfors 6y ago
    Sure, you're right. They are quite good. But just from my perspective, I've been a backend engineer for most of my professional career and wanted to pick up front end dev. With little javascript/html/css knowledge, I used a couple different resources. I'm still learning, but I've found that just the official documentation doesn't quite get you there if you want to get the full picture. I've been working through the following resources with a decent amount of success I think: 1. Fullstack React: The Complete Guide [0] - a wonderful book with a bunch of practical applications to build 2. Learn CSS Layout [1] - A nice write up for understanding what CSS actually is doing 3. Mozilla HTML Reference [2] - Can't get any better than this documentation 4. Eloquent Javascript 3rd Edition - Book being discussed, really enjoying working through it. Obviously, the React and Redux documentation have been great as well. I don't think that just those really give you the full picture that you need though if you actually want to build professional web applications. Just another side of the coin, I suppose. [0] https://www.newline.co/fullstack-react/ https://www.newline.co/fullstack-react/ [1] http://book.mixu.net/css/ http://book.mixu.net/css/ [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference https://developer.mozilla.org/en-US/docs/Web/HTML/Reference

shanghaikid 6y ago

I really like the first edition...

drongoking 6y ago

Is this worth buying/borrowing if you already know programming languages but not Javascript? Or is there a better approach?

ipnon 6y ago
No because this is an introduction to programming using JavaScript. A quick look at the table of contents shows Part 1 teaches basic OOP, Part 2 teaches basic client side web development, and Part 3 teaches basic server side development using Node. Having read the 2nd edition of this book, I can assure that if you can explain what any of the 3 main topics described in this book are in a few sentences, then you have advanced well beyond this book being useful.
Scarbutt 6y ago
IMO, no. It has too much ceremony to demonstrate concepts. It's for absolute beginners.
- sixQuarks 6y ago
  Definitely NOT recommended for absolute beginners. I tried reading this as one of my first programming books and it confused the hell out of me. There are much better introductory books/courses - my recommendation is "Watch and Code - Practical Javascript" if you are an absolute beginner and want to learn javascript. https://watchandcode.com/p/practical-javascript https://watchandcode.com/p/practical-javascript Eloquent Javascript is a good book now that I know more about Javascript, but please NEVER EVER recommend it as the first book for an absolute beginner.
  - terrycody 6y ago
    marked this,thx, btw, I always want to choose head first series to be my 1st book, what do ya think compare with eloquent JS for absolute beginner?
    - sixQuarks 6y ago

warent 6y ago

I would consider myself pretty close to an expert with JavaScript. I've been using it for 5 years professionally, currently use ES2020. Fairly familiar with Node 12, V8, etc. But I'm always worried about those situations where you dont know what you dont know. This might sound strange, but would anyone recommend any reading material or blogs for someone at my level?

mpoteat 6y ago
I would maybe recommend Typescript if you want to harness the type level power of "proving" correctness for certain aspects of your code.
- leshow 6y ago
  Big scare quotes there, you can't really 'prove' much in typescript. Don't get me wrong, it's a nice type system they've tacked on to JS, but it's far and away from proofs of correctness. At best, it's an optional type system with escape hatches.
  - futureproofd 6y ago
    You can only 'prove' what you expect from your design. This works in most cases and saves a lot of guesswork on big, unfamiliar projects. It's not an integral part of JS though, so I wouldn't recommend learning it as a foundation.
narak 6y ago
http://youdontknowjs.com/ http://youdontknowjs.com/
guruparan18 6y ago
I am not a full blown Javascript developer (backend developer here), but had been using JS and other frameworks for about 10 years now. I subscribed to Dan Abramav's "Just Javascript" [1] email. It is really good to read/follow and has one concept and idea explained well. [1]: https://justjavascript.com/ https://justjavascript.com/

kevindeasis 6y ago

Here are the things that I really really hate about javascript: I find javascript really hard and annoying, even if I have enough experience with JS that lets me build a basic react framework, I still find it hard to use. On top of that, getting javascript jobs is harder compared to other programming languages. IE: you need 7 years of experience for a company at the same level where they only need 1 year of IOS/Android experience. You always have to be keep up to date. The popular libraries that you can use changes so fast, and sometimes they don't even work. Javascript gets a lot of disrespect from beginner engineers. Something about doing frontend work, isn't hard and it isn't software engineering in their perspective There are so too many ways to do the same thing, unlike something like lets say golang You always have to learn more than javascript to compete with other javascript developers. IE: dev ops, backend, database, sre, ux design

umc0der 6y ago
It's gotten better over the years and some good things came with es6. The half life of all these frameworks and libraries that come into fashion is pretty annoying. The principles don't change much though. I don't like that it caters to both the object-oriented and fp world and becomes a mishmash of both.
ausjke 6y ago
I'm sure you will be downvoted as hell because you're critic and not upbeat, HN just likes everyone saying good words all the time, i.e. stay politically positive. However I strongly believe critic is more meaningful most of the time as long as it does not have bad intention, thus I upvote you. JS is indeed hard, learning vuejs for the sake of 'it's simpler than react' right now.
- hombre_fatal 6y ago
  Client dev was always hard. People just mistake that for Javascript because they don't have any experience building clients. For example, I'd say JS/React is vastly easier than learning Cocoa/UIKit. Writing GUI code that runs on N user devices is harder than writing headless code running on a single server. Btw, if they're getting downvoted, it's because "oh, Javascript is in the title? time for me to complain about it like people do in every JS-related HN thread!" is a tired HN comment.

BenoitEssiambre 6y ago

I've been toying with the idea of promise free async/await lately. I'm interested in feedback anyone would have. https://github.com/bessiambre/casync https://github.com/bessiambre/casync

no_wizard 6y ago
So generators are used here because of the natural way of calling “next” and yielding a result. How would this work for say, an XMLHttpRequest? Since you have to next into callbacks there I don’t think yield travels the function boundary...so you abuse next instead?
- BenoitEssiambre 6y ago
  Wow I haven't used that directly in a long time. Ideally you would wrap it to be in continuation passing style. This would look something like: function fetchUrl(url,done){ var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) { done(null,xhr.responseText); }else{ done(new Error("something went wrong")) } } } xhr.open('GET', url, true); xhr.send(null); } Then you could do: let response=yield fetchUrl('http://example.com',next); edit: In case this doesn't really answer the question: If you really don't want to wrap, it would work inline too. It would just be harder to read and follow: var someFunction =casync(function*(url,next){ var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState == XMLHttpRequest.DONE) { if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) { next(null,xhr.responseText); }else{ next(new Error("something went wrong")) } } } xhr.open('GET', url, true); var response = yield xhr.send(null); ... });
fenwick67 6y ago
I have avoided yield() and generators like the plague because they're hard to read and I've never seen them used except in examples explaining how they work. Yield feels like recursion - a neat trick for some corner cases but generally unnecessary.

0xff00ffee 6y ago

I always skip to the async part of JS text because explaining it is a bit like handing a shotgun to a five year old. I think the folks over at risingstack have the best explanations, IMHO. I'm surprised they attempted timeouts in promises with so little text, that's actually pretty dangerous pattern because it glosses over the complexity in actually stopping an in-flight promise. It is VERY easy to end up with hundreds of thousands of unresolved promises with their pattern. Dangerous! There is a great repo on this issue.... aand I can't for the life of me find it. Basically there's a github project that uses generators and passes an atom down through the call stack to ensure everything below the race promise is aware that it is being halted. And even that doesn't handle all the nuances of this pattern. And if anyone knows what github repo I'm talking about, I'll give you ... 50 DKP?

zer 6y ago
Regarding your second point: This sounds similar to .NET‘s CancellationToken. It works very well there. What are those nuances in JavaScript which aren’t handled by it?
- 0xff00ffee 6y ago
  I think you're going to point out that I'm about to demonstrate non-JavaScript nuances, but here are issues I've encountered: Let's take a great of example of where promises are used most often: AJAX. If the endpoint isn't RESTful and there is state on the other end, cancelling a promise requires updating the entire module of the new state. There can be multiple reasons for cancelling, and the code needs to be aware of what is happening beyond a simple timeout. Same thing goes for USB devices (via libusb+ffi) and serial-ports (via serialport). In flight requests can disturb state if cancelled, and it makes the programming very complex to just time-out. One could argue AJAX and hardware programming are outside the domain of JavaScript, but I wouldn't. I guess it is more than a "nuance", it is the observance that cancelling an asynchronous operation in general can have unintended consequences if not handled correctly ... beyond memory leaks from unresolved promises.
galaxyLogic 6y ago
I used to use more "Promises" but now I mostly code with plain callbacks if possible. It is just simpler, less thinking needed. I spend that thinking-budget on other things. One thing that is tricky with async is that nobody tells you if the async function never does what it should. I wish they would add some more built-in support for that in the next JS version. Promises hold promise (pun intended) but they are a bit too complicated for my brain.

tracer4201 6y ago

As someone who hasn’t done much JavaScript since AngularJS in 2014/2015, what is the current state of JS like? I see there’s Angular (not AngularJS that I worked with), React, and some other frameworks. I see there are all kinds of bundlers and plug ins for these things. When I was doing AngularJS, I’d just link to a few dependencies manually from a CDN. Looks like now there’s a bunch more complexity and package management for front end dependencies. It feels like FAR more complexity, but I’m not sure what has been gained. I also don’t know that much, so would love to learn perspectives here from people actively developing in this space.

ridicter 6y ago
If you're looking for a fully featured framework, Angular is a joy to work with. React is great too, but the configuration overhead is enormous due to the fact that it's mainly a view library. I realize you are pining for the days when you just pasted a CDN link in your index.html, but while those use cases still exist, for the most part users are demanding more native-like web experiences, which requires a bit more complexity. One of the main strengths (and according to some, weakness) of Angular is that it has everything you might need to create a full featured SPA out of the box, and it's all tightly orchestrated by the Angular CLI. Creating a component or a service is a simple command, and many third party packages leverage the CLI (Angular Schematics) to install and configure themselves in your codebase. Core packages--such as such as forms, router, angular material--are all high quality (by Google), updated together, and work cohesively with each other. That means updating even major versions of Angular is an easy `ng update` command. For me, the minimal configuration overhead is a BFD, as I plain hate that stuff. The fact that Typescript has been a first class citizen of Angular from its outset makes development pretty enjoyable. I'm so used to exploring APIs using intellisense, leveraging types to figure out what data types can be passed in functions, relying heavily on auto-complete/auto-import to pick up my pieces and finish typing a word for me and importing the corresponding library while I keep going. Granted, there is a significant learning curve. But once you get over the initial learning curve, you become incredibly productive. Arguably, the learning curve in other frameworks is worse, given that you have to research what libraries to use (e.g., which forms library, with its own set of conventions), configure it, and make sure it plays nice with the other patchwork of libraries.

chrischen 6y ago

Does anyone have a book recommendation (free or paid) that is modern and up-to-date, preferably regarding typescript, that talks about best practices and patterns for large-scale project design and code structure? For example, a book that could go into details of code practices at companies like Airbnb, Facebook, or Google.

taylorlapeyre 6y ago
Typescript is relatively new, and I think a lot of those companies are still trying new things and experimenting with what works. I expect that we will see more refined content and books about TS-at-scale in the near future though. However, for those looking for a great way to learn Typescript from a beginner's perspective I can fully recommend Execute Program[1]. [1]: https://www.executeprogram.com/ https://www.executeprogram.com/
- chrischen 6y ago
  At the speed of javascript though, it's pretty mature now. When I tried searching on Amazon I was getting back $30+ dollar ebooks with chapters on how to use Gulp (superseded by webpack or babel)...
zachrose 6y ago
> patterns for large-scale project design and code structure I would be particularly interested in this. The OP has a chapter on "Program Structure" but it seems like more a toolbox of language constructs. It would be nice to see a book that went through a few archetypes of common JavaScript programs (command-line script, daemon, enhanced webpage, single-page app) and gave a basic blueprint for what parts are needed and how they interact.
aastronaut 6y ago
A project in TypeScript is not much different from one in JavaScript structure wise. The biggest difference might be the explicit work on types and modeling your problem to make good use of composite types. In the source code you'll have some type definitions where implementation and usage sit close to each other (to enforce a local implementation), and others where a type is more like a serializable DTO (data transfer object) between different domains and seen more global throughout your application. You'll get a feeling when mapped types should alter a type or when a local type definition might be better (TS is structurally typed for a reason). Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2]. To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine. I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects. A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more. [0] https://fsharpforfunandprofit.com/books/ https://fsharpforfunandprofit.com/books/ [1] http://loredanacirstea.github.io/es6-design-patterns/ http://loredanacirstea.github.io/es6-design-patterns/ [2] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [3] http://learnyouahaskell.com/ http://learnyouahaskell.com/ (a bit dated though) [4] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [5] https://quicktype.io/ https://quicktype.io/ [6] https://lerna.js.org/ https://lerna.js.org/

mesaframe 6y ago

I read this book and found that explanations of quite a number of topics were misleading.

vga805 6y ago
Do you have examples of this? Perhaps they could be clarified in errata, or future versions.
- mesaframe 6y ago
  Are you the author? I'll definitely give it a re-read and update.

smlckz 6y ago

JavaScript is very expressive and powerful language. Maybe hard to learn. The prototypal inheritence and 'this' were confusing to me and took much time to understand those. Then I learnt that prototypal inheritance is a superset of ''class''ical inheritance [1] as well as this [2]. Hmm. With Reflect, Proxy etc. you have great metaprogramming capabilities that make this language much powerful. Still, there are some (many?) edge/corner cases and unfixable bugs (aka features) that the language is stuck with for the sake of backwards compatibility and developers have to learn these. (The most famous of these might be typeof null === "object") When I look at the amount of features added to the language specification, sometimes it seems like it is going to become another incarnation of the C++ specification. I still like its expressiveness and power, but if it becomes another C++ in future, I have to look somewhere else. (TypeScript maybe.) [1]: https://aaditmshah.github.io/why-prototypal-inheritance-matters/ https://aaditmshah.github.io/why-prototypal-inheritance-matt... [2]: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent and https://www.crockford.com/javascript/private.html https://www.crockford.com/javascript/private.html

kazinator 6y ago
I'm convinced that prototype object systems represent a poor set of requirements. Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish. They don't represent a set of requirements that amount to a good OOP system.
- smlckz 6y ago
  Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.com/questions/2800964/benefits-of-prot...
  - searchableguy 6y ago
    > @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.

markthethomas 6y ago

this. is. awesome. SO glad this book is being kept up to date

johnchristopher 6y ago

Is there an equivalent for php?

mrwww 6y ago

We used EJS in our basic programming courses in my CS program and it was a great book. Loved the exersices you could try directly in the book! I now program JS for a living so i guess the book also really worked. Thank you for the third edition!

htatche 6y ago

There is an equivalent for Ruby too in case you're interested.

marijn 6y ago
That's by a different author with no connection to this book, though, so calling it equivalent is misleading.

fizixer 6y ago

Can anyone recommend reading for the web-related Javascript "API" so that when Javascript is used in the form of generated code, e.g., through asm.js, the "API" can be used by the "generating program" without the need to learn all of Javascript. Essentially so you could do HTML/CSS/some-other-language (using asm.js, emscripten, or some similar technology) instead of HTML/CSS/JS.

varrock 6y ago

Great read, though his writing style is less intuitive if you are fairly new to JavaScript and trying to grasp some of its concepts. For example, in his reduce function [0] example, he names his variable "current" to bind the accumulated value the reduce function is going to eventually return. That is a totally fair name, but I don't know if it really "clicks" if you were reading over this for the first time. I think it would be faster to grasp the reduce function's purpose if it was simply named "accumulated" or something alike, especially when this snippet is advertising the idea of higher order functions and callbacks. Little things like this I am nit-picky about, but overall, great book. [0] https://eloquentjavascript.net/05_higher_order.html#h_fx3e34kT/k https://eloquentjavascript.net/05_higher_order.html#h_fx3e34...