Hacker News Reader

Comment by mjburgess | Hacker News Reader

> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production!

I think the issue is clear from this first sentence. Why are there any of these things in javascript?

The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.

View on HN

Why should they not be?

Javascript for most of its life was essentially a DSL for the browser. That, in 2021, we're talking about build tools written in it, should give us pause for thought.

> "Why are my devops tools written in this browser DSL immature?"

Well, where to begin?

I'm not aware of any ops tooling that's built in JavaScript. (I'm sure it exists, but it's not popular.) When the article is referring to build tools, they likely mean transpilation/bundling systems like Babel and Webpack, which are fairly reasonable uses of JavaScript.

So engineers only have one language to absolutely master.

This really hit home: Trying to recruit a Java + SpringBoot + Angular engineer is 1 order of magnitude harder than a NodeJS + Angular engineer.

Why not generalise SQL with classes, loops (, etc.) and truly single-language the world? And an SQL configuration language ("UPDATE aws.ec2.config ...") ?

Typescript is a testament to the extreme amount of work needed to normalize a scrappy browser-lang for robust use.

The issue is precisely that a community of "SQL developers" are not going to build you robust tools, merely by having generalised SQL. And likewise, a community of browser developers aren't going to either.

Single-languaging down to effectively a DSL produces a particular type of community (, language, domain of competence, ...), which is exactly what OP is complaining about.

Languages aren't hard to learn once you've got 1-2 under your belt.

FWIW I wouldn't consider myself to have "absolute mastery" in any language, there are some I'm more comfortable with than others but even when I'm not I can still be productive.

They might not be hard to learn, but it's still a considerable mental overhead to switch between writing JS on the frontend and anything but JS on the backend. I frequently mix up the simplest things, like len(list) vs list.length, or how that you can't use obj.property on Python dicts, or list.append() vs array.push(), etc. And then you might have a great tooling library in one ecosystem (like lodash in JS) and try to replicate the things in your backend language. That sort of context-switching simply isn't worth it in my opinion.

Languages are not that time consuming to learn, it is the development environment, frameworks, libraries, community, best practices, tooling etc that takes a lot of time.

> So engineers only have one language to absolutely master.

I'm always amazed at the reluctance of developers to learn and use multiple languages. To use an old analogy: they're like carpenters who are unwilling to learn how to use a saw because they have a perfectly good hammer.

Still learning a language (or a carpentry tool for the matter) is a cost no matter how easy.

It would be great if we could have a unicorn language that can do it all optimally - or at least adequately. Then we can fully focus and master that one language.

Nevertheless I think most will agree that JavaScript isn’t that language.

Instead of only getting one shitty JavaScript stack, you get two. Great.

Reply on news.ycombinator.com