Hacker News Reader

These are...weird criticisms. You basically seem to wish you were coding within a monopoly, for a single platform controlled by a single corporation. Perhaps Swift is where you would like to be?

JavaScript does incredibly well for the constraints it operates within. The fact that Node and Deno etc even exist is pretty remarkable given the primary purpose of JS.

The fact we even have ES modules is in large part because the third party NPM worked so well. Things start out messy then they gain traction and get standardised. JS isn't a loose standard at all, it's incredibly well defined, and few of its original Netscape origins really remain.

You have a bit of a point about TypeScript. It'd definitely be nicer if this was part of the language and didn't require so much third party tooling. It seems plausible that this too might happen in a few years. Perhaps browsers will gain first class support for it.

> You basically seem to wish you were coding within a monopoly, for a single platform controlled by a single corporation.

Benevolent dictatorship has it's advantages. The JavaScript ecosystem is messy -- exactly why is up for debate and whether that's good, bad, or unimportant is also up for debate.

Take it from someone who has made meaningful code in JS since 2005:

- JS as a three week project is amazing

- JS as a lingua franca for web is a disaster in the same league as null pointers. It is like if backend had decided to standardize on PHP early on (if you disagree, try to mention one thing except syntax that isn't as bad in JS as in PHP, and the syntax is actually a blessing in disguise, if JS had looked like PHP it wouldn't had become a standard)

- The fact that people has made a very productive ecosystem on top of the collection of footguns that is Javascript is of course equally impressive if not more

Please note that this post praises both the inventor of JS as well as the JS ecosystem.

But that does not mean that Javascript is a good language.

> These are...weird criticisms. You basically seem to wish you were coding within a monopoly, for a single platform controlled by a single corporation.

You know, I never really thought about it that way, but I think you're right!

<lazy dev hat>That WOULD be nice! A standard way to do anything, no need for unnecessary reinventions of the wheel... progress would slow down a bit, sure, but that's OK, nobody can keep peace with this lightning-fast explosion anyway, and slow and steady is more sustainable than volatile bubbles everywhere anyway. I think I would enjoy working in such a system...</lazy hat off>

<open source hat on>Unfortunately, that'd also mean a closed ecosystem and we probably wouldn't have had the amateur dev boom that HTML/JS/CSS and its visible source gave us. I hate the messiness of that ecosystem, but I can't deny that the openness gave a boatload more people opportunities than the closed platforms. Maybe that's just the price we have to pay =/ </hats away>

> Perhaps Swift is where you would like to be?

I never tried. Is it nice? As a user I find iOS quite obnoxious, but maybe developing for it is different...?

ECMA standardized ECMAScript in 1997, only two years after Netscape Navigator first shipped Javascript. ECMAScript and Javascript are the same thing. I've never encountered a language level incompability in the different ECMAScript implementations. The same can't be said e.g. about the extremely commitee driven C++.

The browser APIs are specced by W3C and WHATWG. For newer APIs there are usually differences in browser implementations, but these tend to get ironed out quite fast.

While this might be technically true, my own (anecdotal) experience has been quite different.

I've been writing JS since its invention, initially just using it (as a kid) for silly Geocities gimmicks and infinite window.alert() loops. I still remember how back in the day no two browsers had a totally compatible JS implementation (especially when Microsoft was busy trying to embrace-extend-extinguish), some things would be subtly different (like datetime handling, or window vs document, whatever)... it wasn't just me either, there used to be a lot of articles that discussed things like that. Here's one: https://burningbird.net/netscape-navigators-javascript-1-1-v...

In my memory, nobody really discussed ECMAscript back in those days. It was more about Netscape/Mozilla vs IE vs Phoenix's JS engines (can't remember if Phoenix used the same JS engine as Netscape), and then different versions of jQuery or early Angular, browser prefixes, early polyfills that you copied and pasted manually, etc. Even up till a few years ago, it was still quite common to have to check CanIUse to make sure a method was supported everywhere.

It was ES6 that really brought ECMAscript into popularity... this Google Trends graph shows the correlation somewhat, though both are totally dwarfed by "Javascript": https://trends.google.com/trends/explore?date=2004-01-01%202... (and it doesn't go back to the 90s, only 2004).

And the ECMAscript core definition is very narrow, only dealing with core language features and not the greater JS ecosystem, which is how we end up with a bazillion runtimes, TypeScript, third-party libs for everything from components to deep copies to state and routing and testing etc. ECMAscript by itself is super barebones, maybe enough to make a simple serverless func with, but hard to write an entire app in without third party frameworks and libs.

I can't speak to C++ (never worked enough in it), but even PHP by comparison had a wonderful standard library, and de-facto standards in the form of Symfony and Laravel that provided most of the missing use cases. In the JS world it wasn't until AngularJS that we really had something like that (but nobody wanted to use it), and now finally Next.js (which is thankfully super popular). Even then, you had to supplement those on the HTML side with something like Bootstrap, and on the CSS side with something like SASS or LESS. (Thankfully, CSS itself is also getting better these days.)

---------

I don't know that this anecdote really disproves anything you're saying (and it's not meant to), just illustrating that even when standards exist on paper, the ecosystem is of a language is more defined by its real-world usages. And for both JS and its siblings (HTML, CSS, SVG, Canvas)... the journey to get to where we are today was very, very messy and full of a million incompatibilities.

> aren't most languages designed and controlled by some relatively centralized organization, whether a company or a nonprofit?

This is a relatively recent development in programming languages. For example, your next sentence:

> Javascript, on the other hand, is a loose standard that different companies kinda sorta adhere to.

This could also describe the history of C. For example, let's look at the rationale document for the first standardization of C: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n802.pdf

I apologize in advance for quoting at length, but I could not decide what should be cut.

---------------------

The X3J11 Committee represents a cross-section of the C community: it consists of about fifty active members representing hardware manufacturers, vendors of compilers and other software development 10 tools, software designers, consultants, academics, authors, applications programmers, and others.

<snip>

The Committee’s overall goal was to develop a clear, consistent, and unambiguous Standard for the C programming language which codifies the common, existing definition of C and which promotes the portability of user programs across C language environments.

The X3J11 charter clearly mandates the Committee to codify common existing practice. The Committee has held fast to precedent wherever this was clear and unambiguous. The vast majority of the language defined by the Standard is precisely the same as is defined in Appendix A of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as is implemented in almost all C translators. (This document is hereinafter referred to as K&R.)

K&R is not the only source of “existing practice.” Much work has been done over the years to improve the C language by addressing its weaknesses. The Committee has formalized enhancements of proven value which have become part of the various dialects of C. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which has served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; these extensions have not been consistent across dialects.

One of the Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C.

The work of the Committee was in large part a balancing act. The Committee has tried to improve portability while retaining the definition of certain features of C as machine-dependent. It attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language. It tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise.

---------------------

In general, standards that follow this path, codifying existing practice, that serve to coordinate interest between various actors, tend to work better than specifications that are written up-front and then followed by implementation. You can see this operating in a smaller way within current standards bodies and organizations, as you yourself alluded to with "relatively centralized."

> Javascript became the lowest common denominator, winning out not because it was better than say Java or ActiveX or Flash or whatever. It was just commonly available.

This statement is shockingly similar to what people say about C, as opposed to various other languages that were in the same space around the same time.

That's exactly what makes it powerful and ensures it's bright future. It is not controlled by one entity and non-working approaches die out by themselves and there's constant innovation. Calling that a mess is just personal problems.

Huh? What?

Nothing's more standard than Javascript these days. Not even close. It runs the same way on billions of devices across virtually all existing architectures.