Hacker News new | comments | show | ask | jobs | submit login
Concepts to help developers master JavaScript (github.com)
316 points by alexgrcs 32 days ago | hide | past | web | favorite | 51 comments



One intuition I’ve had while learning Elm is that it’s a fundamentally simpler language with a smaller number of concepts to learn than JavaScript.

In this list of 33 JavaScript concepts, I count 11 that either do not exist in Elm or, like Object.assign, do not have an alternative to worry about:

No reference types

No type coercion

No == vs ===, although typeof has a simpler equivalent

Basically all expressions and no statements

No hoisting as such

No prototypical inheritance or prototype chain

No Object.create, no destructive alternative to Object.assign

No factories or classes as such

No inheritance or polymorphism

No design patterns as such, though you could argue that abstract algebra or category theory are the replacements

No this, call, bind, or apply

The finer points of these are somewhat debatable, but overall my contention is that removing mutation and local state makes a lot of related concepts just fall away. A takeaway is that when someone tells you that they’ve learned Elm, you needn’t assume that this was as huge of an undertaking as learning JavaScript.


> No == vs ===, although typeof has a simpler equivalent

Sure, but elm has its own issues with comparison as these are essentially implemented as a compiler hack, and only comparable (ie primitive or lists/tulles thereof) types can be used as keys for the built in map type (so you need to know about primitive types too)


I'm sorry, but any language that has to rely on "===" to know what's in what is usually fundamentally screwed up. (Yes, I'll probably get downvoted for this. Oh well, truth often ain't popular.)


One thing I've found with functional programming (Elm) is that writing JS requires constant mental effort. E.g. dynamic types, mutations, side effects, state. In Elm all of that neural machinery becomes obsolete, but your brain doesn't just magically switch it off. So Elm feels hard at first, until the concepts sink in a little bit and your brain re-wires itself.


Yes, this very much describes my experience of working on a gigantic Backbone app while using Elm at home. Work has gotten harder because I’m (rightfully) paranoid about mutation and unable to trust the (fallible) conventions of OO JavaScript.


Similar situation here – I've found that using Typescript and declaring (most) variables const already goes a long way, although the peace of mind still isn't quite the same.


You don't need all of these concepts on an everyday basis.

If you don't use ES5 stuff that was replaced in newer versions, things get much simpler.

let, =>, === etc.


Despite the submitted title containing "to help developers master", the actual Github page title contains "every JavaScript developer should know."

I think that casts this post in a different light. If the repo's intent is that "every JS developer should know" everything on this list, the context of this discussion changes.


And then you move to Haskell from Elm.

https://haskell-miso.org/

https://reflex-frp.org/


IMO, these collection of links type resources would be much more useful if the author curated the list down to something like "Read This_Article for This_Topic" and let people then just google for more information if they need it. Just googling and inserting the top 10 links into a list isn't adding much value.


I have to mention Dmitry Soshnikov's "JavaScript. The Core" webpage. The concepts explained in version one published in 2010 helped me land several contracts. Now I see he has "JavaScript. The Core: 2nd Edition". Thank you Dmitry!

http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2n...


What got me to love JS was probably learning about variable scope, closures, and async programming.


This is what I try to convey to a lot of people who keep making jokes about JavaScript being unpredictable and hard to program.

Just like everything else (especially programming languages), you are limited by your understanding of the concepts. It's only as difficult as you make it.

I think so many people think of it as a toy, never bother to actually learn how it works, and assume everything either does or should work like it does in other languages.


>you are limited by your understanding of the concepts. It's only as difficult as you make it.

I disagree. It is very possible to understand a concept fully, but for it still to be hard. E.g. pointers are quite easy to grasp the concept of, but also very easy to mess up. A more related example would be JavaScript's type coercion. Just understanding it, doesn't make it easy to avoid overlooking places it will cause problems. So some features programming languages include can be objectively considered harder than others, even when you fully understand them.


We're migrating an app from Ruby to NodeJS, and I keep hoping it'll get better, but everywhere I look, from the inconsistency and constant shifting of language semantics to the immaturity of the ecosystem, and how the former practically enshrines the latter, I can confidently state that Javascript is an objectively worse language. Attempts to solve problems caused by Javascript only make the whole thing worse.

At the moment, I actually prefer vanilla javascript to ES6-7. ES6 is inconsistent in awful ways. You still can't rely on bindings to stay put and new additions like the splat operator just don't work the same way all the time.

The more I learn JS, the more I hate it. I think eventually the web development community will come around, Node will lose mindshare, and compile-to-js languages will find their place in the sun again.

I suspect that people who actually like the language are experiencing a form of Stockholm Syndrome.


> I actually prefer vanilla javascript to ES6-7

ES6 is vanilla JavaScript. Most modern browsers have support >98% of added ES6 functionality for several major versions at this point. Admittedly, Node.js is still lacking, but it's getting there.

> You still can't rely on bindings to stay put and new additions like the splat operator just don't work the same way all the time.

Unless you have a bug to report about undefined or non-deterministic behavior, then it must be something you're doing. Random functionality is not intended behavior.

> eventually the web development community will come around... and compile-to-js languages will find their place in the sun again.

This is implying they were ever there. The big ones that come to mind were terrible. They would produce way more bloated frontends than anything we see today. In general, adding a layer of abstraction can be incredibly useful sometimes, but they can come at a steep cost.

What you include in "compile-to-JS" does get a little tricky to define, though. Things like TypeScript or even Babel can kind of count here. I think we will likely continue to see these, but I seriously doubt we'll see a resurgence of anything like GWT again.

> I suspect that people who actually like the language are experiencing a form of Stockholm Syndrome.

Sure, but the same can be said for anybody working with computers ;)


> Unless you have a bug to report about undefined or non-deterministic behavior, then it must be something you're doing. Random functionality is not intended behavior.

You wouldn't be saying that if you ran into the behavior we have. Eventually I'll do more digging to find out root cause. But there's no way it was us.

> I seriously doubt we'll see a resurgence of anything like GWT again.

I'm thinking more along the lines of CoffeeScript. It bifurcates the landscape even further, but honestly I don't think it can really get any worse than it is now. But at least it will be building on top of sanity and not the lava layer.


I learned to embrace platform languages, regardless how I might feel about them.

Not having to deal with extra debugging layers, lesser debugging tools and additional manual FFI is much more productive than whatever I might gain in syntax/semantics of the "compile-to" language.


Node is identical to Ruby in all these ways. How man Ruby gems no longer exist that countless web apps used to depend on? How many backwards incompatible changes has Rails made?


Were there any tech reasons for switching from ruby to node?


Sadly, no.


Thanks, I was just wondering since I don't really see the point in rewriting between dynamic languages. Aside from a few things being easier in each (async being an example) they're basically the same to me.


> It's only as difficult as you make it.

Or as difficult as the authors of the code you're using made it.


Oh absolutely. No language is immune to bad code and bad APIs. A good developer experience requires diligence. That starts with a good understanding of the language.


"Just like everything else (especially programming languages), you are limited by your understanding of the concepts. It's only as difficult as you make it."

No - JS is a special beast. Because it's designed from a simple hack on up, by distributed committee, with so many implementations ...

it's inherently problematic.

Foremost - when you say 'JavaScript' what does that even mean? Even different JS versions are implemented slightly differently with some containing features, others not.

It's this tedious, byzantine aspect of JS that makes learning it actually hard, because it's like walking on shifting sand.

At least with Java (and most other languages), there is usually one answer however bad or good, usually you know where you stand.


I wouldn't say love, but I certainly now hold a stronger appreciation of JS after learning about many of its quirks and intricacies.


Those features are hardly exclusive to javascript. Why did they made you love javascript but not any of the myriad of languages that support those features?


What makes you assume z3t4 exhaustively tried every other language before settling on JS? It's not typical that you present your opinion of a tv show by giving the few unique positive traits it has in contrast to the union of all positive traits from tv shows in the same genre. You just watch the show on a micro level, record what you liked about it, and report that, regardless of what the macro landscape looks like. That's the same way coders typically report preference about languages (on a micro level, not a macro level).


> What makes you assume z3t4 exhaustively tried every other language before settling on JS?

My point was that you'd be hard pressed to find a popular programming language that does not support those features.


Which languages are async-everything?

I can think of JS, Go, and Erlang.

The rest, you are stuck interoperating sync and async code. Like having a Twisted/Tokio event loop embedded somewhere in your Python/Rust program and thinking very, very hard about how your blocking calls are not blocking your async runtime, like passing around an I/O thread pool and ensuring it cannot be starved.

I wouldn't be so quick to dismiss it, much less as something that every other language has.

But I have noticed that it's not something you necessarily appreciate until you've written async systems in languages with blocking APIs.

In another comment you point out that Java has promises, so who cares if JS has them. As if the hard part of straddling async/sync ecosystems is whether there exists a concurrency primitive at all.

Even Go programmers should be able to look at their WaitGroup code and have some envy when they see:

    Promise.map(things, (thing) => process(thing), { concurrency: 4 })
I think our propensity to miss the light of other languages/ecosystems is a reminder of how little breadth of experience we actually have across the field.

It's kind of like how the person that seems to have the most negative views of other people is likely to be the person who has least left their hometown -- it's just how humans are.


> Which languages are async-everything?

Op referred to async programming. I'm unaware of any popular programming language that does not support async programming.

> I wouldn't be so quick to dismiss it, much less as something that every other language has.

All languages can play the "no true scotsman" game and claim they are the only one within a myriad of alternative languages. Yet, they all support async programming, either conventional forms or as a nuanced implementation, either through modules or built into the language with the right to reserved keywords and all.

> I think our propensity to miss the light of other languages/ecosystems is a reminder of how little breadth of experience we actually have across the field.

Actually, people who lack experience and understanding tend to grab hold to their only tool of the trade and give it an inflated value just because it happens to be the only thing they do, and thus they see their personal worth as tied to the perceived worth of their tool. Consequently we end up with these futile discussions on how language X or Y is the bestest, most unique technology that nothing even comes close to match.

But yet async programming is supported by all popular programming languages, isn't it?


Some historical perspective:

Some languages picked it up along the way. So in my case, I only first found out about closures in JS, after going through several popular languages, that got closures only later on: Pascal, C++, PHP...


Then again, Lisp, Smalltalk, Haskell, etc. predate JS, from a historical perspective.


Popular languages?


This is especially important when considering what you'll see in codebases.

e.g. Java may be adding support for more async stuff, but most of the Java codebases I've worked with won't use it.


Async-await is just syntactic sugar over futures/promises and java has those for decades.


It only got the promise equivalent (CompletableFuture and CompletionStage) in java8, which is hardly "decades" ago, and a lot of common stuff like JDBC doesn't support it, so using it can be quite a pain. And that's not to mention the disaster that is checked exception interoperability with the default Java functional interfaces that force constant workarounds...


Embarrassingly enough I had programmed for many years before understanding those concepts. I only knew them instinctively. Coming from a multi-threaded web framework background, writing heavily async code was painful. But it became so simple after learning about closures and lexical scope, and that's why I consider them to be JavaScript's main features, even though almost all other languages have them too. The main reason why I haven't moved on to another language is that I get PTSD (from maintaining multi threaded code with global variables) - when I see a variable or function that I don't know where it comes from, which is common in languages that does not support lexical scoped named imports.


As opposed to what other language?


Not GP but variable scope in JS is very different to e.g. C, C#, Java etc. Superficially it appears similar, but the syntax is a faux amis.


JS's scope is really weird

    for (let i = 0; i != 3; i += 1) {
        console.log(i); // i refers to the variable defined below
        const i = 0;
    }


Is is very similar to Lisp, Clipper or Perl, also known in CS circles as dynamic scope variables.


I've never come across hoisting in another language (not that I've looked hard).


I gave you a couple examples, though.

And here is another one, upvar in Tcl.


Maybe not opposed to any language.


Really good list. Deserves a section on performance and debug tools as well: cpu and memory profiling, high res timers, requestAnimationFrame, etc.


I wish everything on this list fell under the "JavaScript" umbrella, but really they're all conditional on which version of "JavaScript" you're trying to master. Eg "vanilla" js, ES5, ES6, etc. So it's hard to know what came when and what you can actually use in the project you might be working in/creating.


Disappointed that there's no top-level section on iteration. It's a powerful but under-utilized part of the language.


This looks like a bunch of generic programming resources. Possibly with implementations in javascript.

I clicked in hope I'll get something targeted towards developers that have nothing to do with the javascript "ecosystem" but understand programming concepts, algorithms etc. Is there such a thing?


This has been posted at my work, it's a very good resource.


Thank you for posting




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: