Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concepts to help developers master JavaScript

github.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Concepts to help developers master JavaScript

#31

Post by wild_preference »

geezerjay wrote: post #11
tw1010 wrote: post #7

Earlier quoted context omitted.

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.…

> 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.

Re: Concepts to help developers master JavaScript

#32

Post by vinceguidry »

epicide wrote: post #17
z3t4 wrote: post #3

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 wo…

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.

Re: Concepts to help developers master JavaScript

#33

Post by dan-robertson »

zachrose wrote: post #13

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 n…

> 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)

Re: Concepts to help developers master JavaScript

#34

Post by mellett68 »

vinceguidry wrote: post #32
epicide wrote: post #17

Earlier quoted context omitted.

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 wo…

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…

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

Re: Concepts to help developers master JavaScript

#35

Post by epicide »

vinceguidry wrote: post #32
epicide wrote: post #17

Earlier quoted context omitted.

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 wo…

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…

> 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 ;)

Re: Concepts to help developers master JavaScript

#36

Post by gmiller123456 »

epicide wrote: post #17
z3t4 wrote: post #3

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 wo…

>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.

Re: Concepts to help developers master JavaScript

#37

Post by vinceguidry »

mellett68 wrote: post #34
vinceguidry wrote: post #32

Earlier quoted context omitted.

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…

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

Sadly, no.

Re: Concepts to help developers master JavaScript

#38

Post by vinceguidry »

epicide wrote: post #35
vinceguidry wrote: post #32

Earlier quoted context omitted.

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…

> 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 undef…

> 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.

Re: Concepts to help developers master JavaScript

#39

Post by geezerjay »

wild_preference wrote: post #31
geezerjay wrote: post #11

Earlier quoted context omitted.

> 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 dismi…

> 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?

Re: Concepts to help developers master JavaScript

#40

Post by skosch »

zachrose wrote: post #29
_greim_ wrote: post #27

Earlier quoted context omitted.

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.
Post reply on HN