DEV Community

Discussion on: What are the best and worst things about your favorite programming language?

Collapse
 
ryencode profile image
Ryan Brown

I don't know if I have a favourite programming language... For sure I have ones I use more often than others and some that are my go-to for specific project types or even just the hacky-get-something-processed-quick-and-throw-away-to-the-misc-folder projects.
That being said... I will pick the top one I do the most work in these days: The Dread-Language: JavaScript!

Good Bits (not the book)

  • It's the closest thing to a Run-Anywhere language I think we have now... Browsers, Servers, Apps, Phones, In-Line processing... it is in so many places.
  • It's a living language. JS & ECMA Script is actively getting new features, standards and generally keeping up.
  • Low barrier to entry. (nearly) Everyone has a runtime in the form a browser on their system to get started learning the basics.
  • High ceiling of capability: People and Orgs are doing a TON of stuff with JS. Major platforms utilize it to great effect as well as utilities and smaller apps & tools.
  • Large Community to support and contribute knowledge and libraries.
  • Execution sandbox should result in a higher level of safety than most compiled languages.
  • Duck-Typing helps to make a very flexible language where some very neat things can happen.

Not to very good parts

  • Some legacy parts of the language are just not correct for a modern language. I won't link to the details as I'm sure there are innumerable listicles identifying the peculiarities of JS.
  • Competing engine and execution implementations may not be compatible enough depending on what you're trying to do.
  • Strongly tied to consumer-hostile vendors such as Apple and Google who influence their browser's implementation. As behemoths in the market, they are like the tail that wages the dog. This may lead to wider splintering of capacities and features.
  • Speed... as an interpreted language (or JIT compiled in modern engines) it is not quite as close to the metal as a fully compiled language wold be, and thus imparting a speed penalty.
  • Confusion around core concepts like the this reference, how var differs from let not only in allowing redefinition, but in hoisting behaviour.
  • node_modules potential for explosive size on even medium projects. (not really a problem of the language but of that the mechanics of that specific ecosystem)
  • The type system plays at being duck-typed, but... there are, as always, some weird exceptions. Mostly these exist under the hood in the various engines and could end up with some hidden effects in the form of speed penalties or possibly even unexpected results.
  • Seen as a bad language, no matter what fixes will be enacted.

Often I jump to JS to do some quick processing of lists or data or try out an algorithm, or some meta-programming task.
Is it a favourite? Not really, there are a ton of flaws and reasons to choose something else. But it is handy, its there and it's good enough for most of the stuff I use it for.

Collapse
 
isaacdlyman profile image
Isaac Lyman

Great summary.

Backwards compatibility has got to be the best and worst thing about JavaScript (and the web in general). On the one hand, if your website worked in 2008, it will probably always work, with minor exceptions for non-core technologies like Flash and ActiveX. On the other hand, our grandkids will probably still be seeing "use strict"; and wondering why NaN !== NaN.

When you spend time working with any other platform, you come to appreciate "don't break the web." But then you come back to JavaScript and start to wish we could break just one or two old websites by getting rid of things like "null and undefined both exist and don't mean the same thing" or "0 is falsy, so you can't null-guard a number using !".