3 ms·

Can you elaborate why you think Ruby and Python are "orders of magnitude better than JavaScript"? I always considered that Ruby, Python and JavaScript are very

by S4M 12y ago

Can you elaborate why you think Ruby and Python are "orders of magnitude better than JavaScript"? I always considered that Ruby, Python and JavaScript are very closed to each other - dynamic typing, very quick to write.

api 12y ago
It's mostly to do with JavaScript's warts: - Can't deal with 64-bit integers - Insane type system, e.g. null vs. undefined and all kinds of complexity around seeing what something is. Types are strings? Really? - No baked-in language-standard way to do async coding despite the language being inherently async, which leads to a mishmash of promises and indent cascades with callbacks. - How do I use exceptions with callbacks or promises? All kinds of edge case hell here. Either have exceptions or don't. Again there are probably good patterns, but since there is no canonical way everyone does it differently. - The == vs === mess - Lots of fragmentation around how to do classes, inheritance, etc. Getting fixed in ES6, but there will forever be tons of legacy code where everyone did it differently. - In practice I've found it easier to get leaks in JS event-driven code than in other GC'd higher level languages. I'm sure others could list other things. JavaScript is the product of a death march at Netscape in the late 90s, and it shows.
- taurath 12y ago
  The most difficult part about Node or Javascript coding is technique and library selection - you will get contradictory advice because its so popular or in node's case new, and there are so many choices there is no single right way, and plenty of ways that may bite you. - 64 bit ints (yup) - Type system (you'll get over it) - Async coding - everyone has a different standard, but it does work whichever way you do - Exceptions - callbacks have err as first parameter, every time. You have to boilerplate. Promises you have to pass in an error function, you have to boilerplate. Could definitely be improved, but like handling async there aren't anything standard, just opinions at this point. - always ===, hint your code - OO stuff - absolutely. But its also not fundamentally an OO language, its much more flexible. - Leaks - Tooling could improve a LOT. Finding and sticking to a technique is the biggest part, which can get harder as a team grows bigger. Show me 2 people with 5 years of javascript experience at different places, and you'll have 2 very different code styles. If you're intent on making javascript with OO and aren't coding partially for a browser, use something else. If you want very easy asynchronous functionality with a very fast communications server, Node is pretty damn good. Node is great for breaking down complex tasks, as long as you have a good method of flow control (promises, async + callbacks, etc).
  - api 12y ago
    Question is why you'd use it over Go, Java, C#, or even Python or Ruby. I picked it originally because there are lots of quickly-up-and-running plugins and similar things in the npm repository. Like I said the community is great. But the more I work with it, the more it hurts. Pain in a language should decrease with time as you work with it.
    - taurath 12y ago
      It certainly has for me - the hump is likely bigger due to how new it is. Its hard to settle into a good flow when there are 1000 possible flows to get into.
- spronkey 12y ago
  Oh god, this, 100000000x this! My main frustration is the lack of canonical implementations - there never seems to be a good way to do anything - everything has nasty tradeoffs, so you have to pick the best for each situation - which results in a lot of different paradigms across a codebase. Yuck.

by S4M 12y ago

api 12y ago

It's mostly to do with JavaScript's warts: - Can't deal with 64-bit integers - Insane type system, e.g. null vs. undefined and all kinds of complexity around seeing what something is. Types are strings? Really? - No baked-in language-standard way to do async coding despite the language being inherently async, which leads to a mishmash of promises and indent cascades with callbacks. - How do I use exceptions with callbacks or promises? All kinds of edge case hell here. Either have exceptions or don't. Again there are probably good patterns, but since there is no canonical way everyone does it differently. - The == vs === mess - Lots of fragmentation around how to do classes, inheritance, etc. Getting fixed in ES6, but there will forever be tons of legacy code where everyone did it differently. - In practice I've found it easier to get leaks in JS event-driven code than in other GC'd higher level languages. I'm sure others could list other things. JavaScript is the product of a death march at Netscape in the late 90s, and it shows.

taurath 12y ago
The most difficult part about Node or Javascript coding is technique and library selection - you will get contradictory advice because its so popular or in node's case new, and there are so many choices there is no single right way, and plenty of ways that may bite you. - 64 bit ints (yup) - Type system (you'll get over it) - Async coding - everyone has a different standard, but it does work whichever way you do - Exceptions - callbacks have err as first parameter, every time. You have to boilerplate. Promises you have to pass in an error function, you have to boilerplate. Could definitely be improved, but like handling async there aren't anything standard, just opinions at this point. - always ===, hint your code - OO stuff - absolutely. But its also not fundamentally an OO language, its much more flexible. - Leaks - Tooling could improve a LOT. Finding and sticking to a technique is the biggest part, which can get harder as a team grows bigger. Show me 2 people with 5 years of javascript experience at different places, and you'll have 2 very different code styles. If you're intent on making javascript with OO and aren't coding partially for a browser, use something else. If you want very easy asynchronous functionality with a very fast communications server, Node is pretty damn good. Node is great for breaking down complex tasks, as long as you have a good method of flow control (promises, async + callbacks, etc).
- api 12y ago
  Question is why you'd use it over Go, Java, C#, or even Python or Ruby. I picked it originally because there are lots of quickly-up-and-running plugins and similar things in the npm repository. Like I said the community is great. But the more I work with it, the more it hurts. Pain in a language should decrease with time as you work with it.
  - taurath 12y ago
    It certainly has for me - the hump is likely bigger due to how new it is. Its hard to settle into a good flow when there are 1000 possible flows to get into.
spronkey 12y ago
Oh god, this, 100000000x this! My main frustration is the lack of canonical implementations - there never seems to be a good way to do anything - everything has nasty tradeoffs, so you have to pick the best for each situation - which results in a lot of different paradigms across a codebase. Yuck.