Is It JavaScript?
21 points by LesleyLai
21 points by LesleyLai
reminds me of how it feels most of the industry also conflates “node.js” with “javascript” - pedantic I know but I think this post touches on why that distinction is actually important
My favorite pedantic-but-important mischaracterization: “JavaScript is single-threaded.” This one gets waved around way too much, and it totally glosses over how the event loop, async I/O, and things like Web Workers or Node’s libuv actually work. Being single-threaded is a quality of the runtime implementation, not of the language itself.
Half of these are simply examples of using different libraries — the browser DOM or node.js, mostly. Lots of languages have that — is it “just Ruby” if you’re calling Rails? Is it “just C” if you’re calling POSIX or Win32 APIs? Is it “just C++” if you’re using Boost or Qt? I dunno about “just”, but yes, it’s the same language.
But the point is valid that APIs can be more work to learn than the underlying language. I’m pretty expert at C++, but I’ve never used Qt and I’m sure I’d be lost if you dropped me into a big Qt codebase. And Rails is so (in)famously DSL-based that it can look like Greek to a vanilla-Ruby programmer
It is not just a different API, but also the language itself. In the C++ landscape, most libraries (even boost) are just libraries following standard C++ syntax and semantics. The worst thing to worry about is macro abuse. Qt is kind of an exception since it has MOC, but this is rare.
In contrast, the JavaScript ecosystem is much more fragmented. It includes a wide range of custom language tools, interpreters, compilers, and even entirely new dialects or languages. Something that looks similar may have vastly different semantics given a different context.
I understand; that’s why I said “half of these”. I know JSX and importing data or CSS files require preprocessing, as does TS of course. But stuff like Node file APIs and environment variables are just plain JS syntax.
As someone who only knows JavaScript and got away with it building fairly complex applications, what are some things I am missing out on from the ‘outside’ world?
Picking up new languages isn’t that scary after the second or third one, and it sheds some valuable light on how to evaluate differences between them. Most do roughly the same thing, but each usually optimizes to make a specific type of work easier. Personally, I lean towards languages/ecosystems with excellent development tooling, perhaps sacrificing something or other.
Realistically speaking, is there anything that could make me more prolific than JavaScript specifically for web development?
When you limit yourself to web development, you limit yourself to a domain where JavaScript (and its twin, TypeScript) has a baked in advantage over every other language that’s ever been invented. So probably no.
If you want to do anything outside of web development, then quite possibly yes.
You’ll learn the fundamentals of web development if you stay curious, even just with JS. From a career standpoint, you will open yourself to more types of work if you learn web development in other languages— either frameworks like Rails and Django, or just backends in different languages like Go, Rust, Java/Kotlin, etc.
This is heavily dependent on what you value. Some areas you could explore:
This are really just touching the surface though. Learning new languages that are sufficient different from yourmain will often teach you new things you can use or explore.
If you’re asking what things you can learn, that would include areas like concurrency, memory management / lifetimes, strong type checking, foreign-function interfaces…
Dependency management that isn’t a complete dumpster fire. I work quite a bit with nodejs apps these days, but I’ve worked a bit with go and I’ve dabbled with rust. Neither go nor rust are perfect on the dependency management front, but they’re quite a bit more manageable than node/npm.
This was fantastic. We also need “is it sql?” And don’t forget “is it markdown?” An oldie is “is it csv?”
IIRC, you should be able to run “just JavaScript” in Web Workers, Deno Workers, and Cloudflare Workers… and we should be aiming for such cross-compatibility and reuse, no? Seems like we’re just using convenient/comfortable tooling rather than moving towards more standardized approaches.
The goal of https://wintertc.org is to get some common api surface between browsers/ECMA standards and server/serverless runtimes. So yes you’re correct, things are very fractured right now but there is effort to make it better.
Ahh yeah, forgot about this. This is definitely what should be happening, and on the forefront of the minds of devs building new stuff.
The author’s conflating two things: “is it JavaScript?” and “is it Just JavaScript?”. The latter implies the former, but whilst we might include the wider ecosystem of JSX, TypeScript etc. under the umbrella term “JavaScript”, we probably shouldn’t class something as “Just JavaScript” if it e.g. requires a compilation step to prevent parse errors.
There’s also another conflation going on: whether something can be parsed according to the grammar of a particular language, versus whether it can be executed in some (unstated) context to achieve some (unstated) goal. I think the latter is far too hand-wavey to be useful; TFA gives this example:
const apiUrl = process.env.API_URL;
Is it “Just JavaScript” if executes but will only work as expected with special knowledge of runtime conventions?
Does any non-trivial piece of code “work as expected”? Is anything JavaScript‽