I wish there was a "learn modern Javascript for people who learned Javascript in 1998" - it seems like the only way to get up to speed is to slog through all the basics (yet again) and keep an eye out for the parts that seem to be unfamiliar/new.
- "Modern JavaScript Explained for Dinosaurs," by Peter Jang: https://medium.com/the-node-js-collection/modern-javascript-...
- "Modern JavaScript for Ancient Web Developers," by Gina Trapani: https://postlight.com/trackchanges/modern-javascript-for-anc...
(Don't let the "ancient"/"dinosaur" stuff scare you off -- they kid because they love.)
Hope this helps!
Is there actually any sensible argument one way or the other - that isn't just being consistent with your team/project/platform...?
It can get cluttered when with nested quotes, but most linters will allow you to use the other type to encapsulate.
IMO it doesn’t matter, as long as the team agrees and remains consistent throughout the codebase.
I rather dislike "best practices" that don't provide any explanation of what they are recommending.
The way I see it, there are three kinds of syntax linting rules:
1) Potential bugs. These are where a syntax will technically work, but makes it easy for an unintended bug to creep in. Most everyone agrees that these are bad. (There are a few arguments about what qualifies, but this is nonetheless a less-argued-about category.
2) Purely stylistic. This is where Prettier shines, because everyone wants the "more readable" option - where "readable" means "more familiar". Prettier allows you to write your preferred style, though of course anything you READ will be in the defined style (absent two-way conversion).
3) Expressiveness. This is where you're formatting your code to communicate. While Perl is notorious for this - the advocates love it because well-written code is easy to follow and maintain and the detractors hate it because just because you CAN write clearly in it, the skill to do so is rarely developed and the result is near-gibberish, even from skilled coders - like a story that has every sentence written by a different person. Java is the reverse - the advocates love it because the code tends to be very uniform and the detractors hate it because it's universally verbose and unclear.
That last category is why I'm leery of excessive linting. If I'm dealing with code that changes hands often, a Java style makes sense - newspapers written for a low but common reading level, even if the reader is capable of much more nuance. In this scenario nuance would risk being ignored, or worse, being mis-applied, which means the result would be misleading. If I'm dealing with code that is owned by a team that has routine staffing changes but no complete upsets, nuance has a real benefit - reading code is faster and more accurate/informative, with the result of fewer bugs (citation needed).
But saying "It's okay to use Prettier and stop arguing about linting" dismisses the nuanced case. It carries the assumption that linting rules - any rules - are automatically valuable regardless of the choices made, and if you don't like it than write what you like and just use Prettier.
Linting rules (and linting arguments) exist for a reason - these are LANGUAGES that we are using to communicate - and as much as I'm tired of the arguments too, until we honestly figure out how to communicate well, ignoring the arguments doesn't help.
I think readability and expressiveness are more about larger scale patterns in code writing (writing self-documenting code with descriptive variable and function names, writing modular code, etc). These are things that should be continuously discussed and improved upon for clarity and alignment. The really granular formatting changes that Prettier chiefly concerns itself with don't seem to be a concern in this case. If you could point me at a more specific case where you think Prettier mucks things up I'd love to see more of what you're talking about.
None of which says that Prettier itself is bad, but that excessive linting rules, with or without Prettier, are bad.
If I'm wrong about what Prettier does, please let me know. If you're discussing a default set of linting rules Prettier uses, cool, but I can't really say if I think they impact expressiveness since I'm not familiar with that set of rules.
If you are using Prettier, you can use the Prettier config with eslint or tslint, which fully disables the style rules for those two linters and lets them focus solely on linting for errors and structural issues.
It's easier to use double quotes if your text is english (or other language that uses apostrophes).
It's easier to use single quotes if your text is HTML (for double quotes)
I've seen an argument to use template literals (backticks) almost everywhere. I don't know if that involves any real performance hit, but I've also not adopted this convention, at least not yet.
Modern Javascript has template literals using backticks so arguably the new rule should be used double quote everywhere except use a template literals for HTML or whenever doing string manipulation.
The number one thing I hate about using single quotes it is matches almost no other languages so it ruins muscle memory if switching between languages.
JS itself prefers double quotes. See JSON.stringify or log anything to the console that gets auto quoted, always uses double quotes
Not saying that it's a strong reason to use one over the other, but it is an objective reason that doesn't rely on style or preference.
There’s a difference between promoting readable code and just being retentive.
In practice the only thing you absolutely need to know is the spread syntax for arrays `blist=[...alist]` and objects `objb={...obja}` that will trick you up if you're never seen in before
alist = [1,2,3]
blist = [...alist, 4] // == [ 1, 2, 3, 4 ]
obj = { a: 5, b: 6 }
obj2 = { ...obj, c:7 } // == { a: 5, b: 6, c: 7 }
There is also this weird shortcut for creating objects for which key and value use the same identifier:
d=8
e=9
obj = { d, e } // shorthand for {d:d, e:e}
// == { d: 8, e: 9 }I think you will like it. It is "modern" but not a new video. It is probably about 3 years old. Still relevant. He has a udemy course for $10 bucks.
The problem now is that different sources of info will still use older methods. E.g. Promises were used to augment/replace the use of callbacks in many situations. And now async/await is augmenting and replacing promises in a lot of places. So you'll still run into a lot of sources saying promises are the new and better way to do some things, when async/await is actually a better choice.
Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;}
In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end.
In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM.
Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code.
Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!
I didn’t go quite as far back as 1998, but if you kinda know ES5 and older it’s just the right fit.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
"Learn modern JavaScript, for people who learned JavaScript in 1998"
https://sephware.com/blog/2019-01-03-learn-modern-javascript...