Hacker News Reader

Comment by adam_arthur | Hacker News Reader

Anyone know why all new Ecmascript APIs are implemented to be used as "newable classes" rather than ordinary functions?

The community seems to be moving towards functional programming/away from classes.. and pretty much every mainstream JS lib is function rather than class oriented (yes, I know classes are simply special functions)

Also adds unnecessary verbosity/more syntax noise.

Is there some internal performance reason for why ordinary functions couldn't be optimized to perform the same as "new"? (Seems like it would be easy to wire the prototype internally to the function, resulting in same semantics).

At this point better to be consistent, but I'd still use a date library just to avoid added verbosity of this native solution. Luxon API reads a lot better than this... Though I'm sure there are reasons a standard implementation needs added complexity (has to cover every edge case)

View on HN

Because most original API (DOM, browser, date, etc) are OO oriented and you stick your standard library in one pattern.

And speaking of everyone moving to functional programming: i work with several hundred developers in four continents in a very dynamic envirnment.... And I have not seen a FP advocate. Not that FP is not good (I prefer it where applicable) but mindset/winning/moving towards are words I would not choose when it comes to describing the state of FP and OO in the world. There is a strong influence but not to a degree where an established language changes its core paradigm: see Java, C#, JS, ...

I would be more prone to say that the original API are something that came up by using buzzwords from growing languages or something else, for sure they're a thing, but like it's not that `new` makes an OOP approach if then you miss inheritance, abstraction, encapsulation and polymorphism, I'm not sure if I am being picky but like if there is just a keyword and nothing else more important to the paradigm then I think it might be confusing for some reader to see something like that statement

Really? I have seen — across many jobs and company sizes and frameworks, over about a decade — a slow but inexorable trend of moving toward FP.

Be it in React, where hooks are pushing everything to be functional; to the fact that Monads have started showing up in unexpected places in codebases I’ve worked on; to the fundamentally functional nature of frameworks I have to use every day working at a FAANG.

Along the way, until the FAANG, I never met any functional advocates. What I did meet are people who reach for the appropriate functional tools when building solutions; others see the much better solutions they arrive at, and copy.

React hooks are procedural programming constructs in a thin veneer of FP. They're about as functional as java was object oriented.

The Temporal API supports a `from` method/function on most of the options - that's very much the functional approach to avoid `new`.

Often objects that are class based will expose a `of` or `from` method that abstracts over the `new` keyword `Array.from()` is one example instead of `new Array()` (of course the most common way is `x = [1, 2, 3]` but these other options exist too).

This seems fairly functional to me.

> The community seems to be moving towards functional programming/away from classes..

Anecdotal observation follows:

In the span of my career so far it looks like the community moved from imperative programming with a few classes/prototypes sprinkled in there, to imperative programming with a few lambdas and HOF sprinkled in there.

I've yet to come across anything significantly functional or OO in the wild, it's still mostly plain old data mutable structures and for loops.

For one: core types like Temporal and Promise are nominally-identified. i.e. they have an identity that goes beyond just plain objects with a particular set of properties. Oftentimes when people advocate for "plain functions" over constructors in JS, what they're really advocating for is using "plain data"(objects, arrays, primitives, etc). There are lots of good reasons to use plain data in JS - transparency, serializability/deserializability, duck-behavior, etc - but all of that is irrelevant for these special objects.

Now of course you could provide a plain function that returns a special, nominally-identified object. But at that point there are basically no advantages over using a constructor (unless you need multiple such functions that take different kinds of arguments); the difference is almost entirely superficial, and constructors do a slightly better job of advertising that their return values are special, and also have precedent and therefore familiarity

> Is there some internal performance reason for why ordinary functions couldn't be optimized to perform the same as "new"? (Seems like it would be easy to wire the prototype internally to the function, resulting in same semantics).

Not particularly -- JIT vms should inline `(() => new Thingy)()` as `new Thingy`. The temporal API provides a lot of nice factory functions that don't need any `new` keyword. Here are the first several examples of the Temporal API all concatenated together with comments removed:

    Temporal.Now.instant().epochSeconds;
    Temporal.Now.instant().epochMilliseconds;
    Temporal.Now.zonedDateTimeISO();
    Temporal.Now.timeZone();
    Temporal.Now.zonedDateTimeISO('Europe/London');
    Temporal.Instant.from('2022-03-04T05:56:78.999999999+02:00[Europe/Berlin]');
    Temporal.Instant.from('2022-03-04T05:06+07:00');
    Temporal.Instant.fromEpochSeconds(1.0e8);
    Temporal.ZonedDateTime.from('2025-09-05T02:55:00+02:00[Africa/Cairo]');
    Temporal.Instant('2022-08-05T20:06:13+05:45').toZonedDateTime('+05:45');
    Temporal.ZonedDateTime.from({
      timeZone: 'America/New_York'
      year: 2025,
      month: 2,
      day: 28,
      hour: 10,
      minute: 15,
      second: 0,
      millisecond: 0,
      microsecond: 0,
      nanosecond: 0
    });

It seems like the style is to provide these factory functions for almost every use-case except "build me a specific object with these exact values", which you need to use `new Constructor(...)` for. Where is the noise?

As a side note, there are concrete performance reasons to use class/prototypes over plain objects or closure-over-hidden state in your own code:

- Class and/or constructor functions helps ensure your long-lived objects instantiate their properties in a regular order. V8 has trouble unifying objects with the same properties but different property orders into the same hidden class. Each hidden class costs JIT time and memory space, so minimizing both is nice. You can fix this yourself by forcing instantiation of a value to go through a factory function to normalize property order, but at that point, why not use a class to take advantage of `instanceof`?

- Closures over hidden state, eg long-lived closures you would use to implement your own object system over enclosed local variables, cost more than plain objects or class instances. It's more straight-forward to define classes at the top level and wrap them in sugared factory functions than to code-review factories that manually build objects with function properties.

The problem with relying on JITs inlining things is that you're hoping that an opaque optimizer will come to the same conclusion as you, and historically there have been all sorts of things that spontaneously kill optimizations (I recall there being a point where one of the JS VMs made decisions based on source text size, so comments could change optimization behaviour).

There's also all sorts of optimizations you have to depend on to avoid excess object allocations, etc.

That said object allocation in JSC and V8 (not sure about spider monkey) is essentially a pointer increment in the common case, so its not exactly expensive.

You've covered a lot here, but just want to comment on a few things.

Factory functions can return objects that have a prototype just the same as "new", there is no inherent reason object constructors should require "new". Given that most of modern, idiomatic JS relies on factory functions, it seems very inconsistent to me to then randomly require invoking "new" to construct an object.

Why not simply Set([1, 2, 3])? The noise comes when you have a nested expression with random "new" statements sprinkled in which disrupts the flow. Though I agree that overly complex expressions are an anti-pattern

My underlying point is that "new" does not provide any clarity, given that objects are created and returned all the time without "new", so represents an inconsistency in design to me. The presence or absence of "new" basically tells you nothing, except implying that the object likely has prototype functions. But whether or not they are prototyped is more of an implementation detail anyway.

I agree with you that most of Temporal has factory functions that obviate "new".

To your point on performance of closures, this isn't going to materially matter for majority of use cases. Yes, prototype is more efficient than closures functions, but benefits of prototypes can also be achieved through separation of data and function (singleton utility functions that operate on data).

Also syntax sugar for prototype could have been done in an (IMO) more consistent way through some syntax addition to functions rather than creating class. Generally modern userland code shouldn't really be using prototype and "this" anyway, as "this" has tons of footguns in JS, and I would guess majority of developers don't understand the intricacies of "this" when passing functions around, or when using arrows vs classical function declarations.

One good reason is to avoid polluting the global namespace.

Otherwise you end up like Mathematica, which has ten thousand or so functions in a single namespace.

Or PHP which had (has?) a similar problem (but on a smaller scale).

But they are on the global namespace. E.g. new Set() is same as new window.Set()

Right, but just the constructor. Everything else is a method of Set/Temporal.

You can easily split stuff into modules without getting classes involved. For example the `Math` module which has been in JS basically forever.

> Anyone know why all new Ecmascript APIs are implemented to be used as "newable classes" rather than ordinary functions?

My guess, and it is only and just that, is because classes, being a newer part of the language, allow the developers and designers to work with a cleaner environment, if you will, avoiding some of the pitfalls that have lingered since ES1.

Classes are strict, by default, e.g. I can imagine other benefits, but I am too little caffeinated to articulate them right now.

Basically, if one sticks with “the old way”, one runs the risk of one’s users using poor idioms that could cause support grief, but by using the new way one avoids these.

Note also that JS classes aren’t pure OO, at least not yet, but are really a different and arguably better approach to function/object (in the JS sense) design and implementation, and that JS is slowly pulling in FP concepts as well.

First, how do you tell a date from a string or a number easily in the code. Second, the functional thing happens for many reasons, and biggest ones are practical. You can’t DCE (treeshake in hipsterish) classes in js due to highly dynamic semantics, but builtin code doesn’t suffer from that. If it was a non-special type, then maybe it was worth just Foo(), but usually there are some methods attached to it as well as introspection capabilities like toJSON(), toString(), etc.

The community seems to be moving towards functional programming/away from classes

The community moves to where React is, no real CV choice. Other parts of the community are non-functional, e.g. new WebpackPlugin, etc.

The community was in the functional space before react. Angular 1 was very function oriented too, and relied heavily on ordinary functions and closure scope rather than class. And then everybody latched onto class in the phase of time between angular 1 and next gen frameworks.

Class was something pushed by all the next gen framework authors at the time. Then most next gen frameworks abandoned class, because it proved to be worse in many ways than ordinary functions did. Which was the position I held at the time, and seem to have been borne out.

The easy way to tell types apart in ordinary JS is to have consistent naming conventions. If you always name things such that the name implies the type (not Hungarian style, but more natural language oriented), you can infer the type from the name correctly 90% of the time. E.g. always write arrays as plurals, map-like objects as keyToValue, and so on.

But the easier answer is to just use Typescript.

Inferring type from instantiation point is pretty meaningless anyway. The type needs to be inferrable at the consumption site to be readable, not the production site. Understanding a type only matters in the context where it's used

> (not Hungarian style, but more natural language oriented)

Apps Hungarian wasn't actually a stupid idea. It just got bastardized into Sys Hungarian, which was. Apps Hungarian could tell you whether the string was unsafe (and needed to be sanitized), or safe to use. Or tell you if the integer type you were using was an offset, or a row number, or whatever. It was supposed to give you semantic info that wasn't necessarily obvious from the given type.

Sys Hungarian told you that you were using a long pointer to a zero terminated string. But not what the string actually meant. It just regurgitated the type of the object again.

No thanks, not an easy way. instanceof and typing are the tools, not some funny notation that I have to rely on everyone to follow and parse, including me, under a pressure, after a year. Nobody can infer/assert types three modules away from a scope of their commit when it’s in the name.

But the easier answer is to just use Typescript.

Typescript is duck typed, you can’t save your day by “type Date = string” in it in a sense of a type safety. Nothing is wrong with object classes, apart from personal affinities accumulated from scary blog posts about classes in non-js languages and how that was bad. Objects have different types and different operarions on them. There is no clear reason to erase this difference and to evict methods only to group them into a scope and match by name manually, losing literally all benefits just for a functional swag.

Types are implied by the interface of the object.

Having a whole layer of abstractions and keywords built around class literally just adds complexity. Not to mention how obtusely "this" works in JS. The whole layering of special syntax around class just serves as a crutch for those coming from other languages.

Nowhere does it simplify anything really, aside from those who are already familiar with that abstraction. It's objectively simpler to have fewer abstractions, given that you can use object literals and regular functions to achieve the same results in similar amount of code. If class saved a lot of verbosity from alternative approaches, there may be a compelling argument for it. 99% of userland code does not need or use prototypes in modern JS

Typescript largely obviates need to do runtime type checking, except at API boundaries. But networked apis can't return classes by definition (not supported in JSON spec).

If I were to create shapes, I would interface the data and have a simple type field like "rectangle" "circle", etc. Or even simply duck typing it. Very easy and consistent way to check without having special prototype specific syntax of instanceof.

Using fields to imply the type is json compatible too, and works sent across the network. With Class you would need to have hooks at Json receipt point to instantiate the instances of the class. Class is a whole layer of unnecessary abstractions that don't even reduce verbosity.

I think this answers a question in my other comment. Not sure if I agree, but at least it feels like I start to get your point. Need to get some sleep, cause this mood makes me sound unpleasing sometimes, sorry if that manifested too much.

>The easy way to tell types apart in ordinary JS is to have consistent naming conventions....you can infer the type from the name correctly 90% of the time.

is any process with a 10% margin of error really an easy one?

When you're operating in a non typed language, you don't have a choice. That's the best option.

Of course you could literally spell out the type. But verbosity not worth it. Also no guarantee the name was written correctly.

But I've found most JS codebases don't have rigorous standards around naming to begin with, so even doing that is a big win

What do you mean by ordinary functions? There has to be some value to represent a date or time that you pass around, so something somewhere has to return it.

If your concern is `whatever(date)` vs `date.whatever()` then the issue you run into is pollution of the global object, which is bad, and frequently not possible due to naming collisions with existing sites (fun story, `let` required some exciting rules to deal with existing content using variables named `let`). Given an inability to add a million new functions to the global object your concise `whatever(date)` becomes `Temporal.whatever(date)`

Could be with typescript in mind. TS works well with classes.

Because they are obsessed in converting JS into Java.

It's been a bit of a headscratcher for me.

I was quite against adding the class keyword to begin with to be honest.

Think a lot of that came at the tail end of the "JavaScript is terrible" generational mentality, and the idea was to copy other languages rather than improve what they had independently.

To be clear, having additional functionality is fine in and of itself, but now the waters are mudied between function oriented and class oriented approaches, and by and large community seems to be settling on function oriented.

In the end, class just created unnecessary fragmentation.

I was also happy with prototypes, now when I use them, and I use them rarely, other developers look at my code like black magic and my "others should be able to understand my code" circuit breaker kicks in and I convert it to a class.

Is it more readable? Yes.

Do I feel like we are dumbing JS down? Yes.

Is it worth it when we consider that it helps onboarding hundreds of thousands of developers who want to choose JS? Oh f* yes!

Creating prototypes in general is not necessary for 99% of JS code. Using completely cloned/closured functions will perform just fine for the majority of use cases... And the code there reads very simply... Just a function that returns an object that has functions.

Or you can simply separate out functions into utility objects rather than attaching to the specific data object, and performance should be the same as using prototype, without any of the special syntax

This model of programming is also much simpler, I'd argue. There is no use of "this", everything is explicit. Especially in JS, "this" sucks because the semantics change depending on whether you use function declarations or arrow functions. And "this" will also reference the caller, so changes if the function gets passed around. Much more obvious to pass an explicit argument to a function than to rely on "this"

I do agree there are use cases where prototypes are more useful, performance sensitive games/server code etc. But pretty rare that you can't take one of the approaches described above. And people writing performance sensitive code aren't generally also going to be the newbies. Additionally, could have had syntax sugar for functions that wired prototype without the new/class paradigm, which I argue just adds unnecessary verbosity to the language.

I was just replying to the class vs prototypes part. There usually is a once-in-a-year situation that is solved better with classes, so I somewhat agree with your 99% code doesn't need it estimation.

Also I should mention that in the rare case when I did use the prototypes, I always used the adapter pattern (an adapter function that takes a slice of "this", calls an independent function, and merges it back to "this"), it was easier to test.

But people are so unused to declaring dependencies as parameters (even function dependencies aka services), they cry untestable whenever they see independent (static) functions. I know this from the PHP, Java and .NET world. To this day, it didn't help to explain what they call DI is just passing parameters (but rather more bureaucratically).

What you propose will likely drive the code to functional equivalent of FacadeAdapterArrayController, but written not only once but in every line of code. Because think of what even a simple .filter().map().filter() would expand into. Of course we can just stream() or | everything, but the original “simple functions” idea will quickly get lost in the woods.

Not clear how you're reaching that conclusion. Native constructs can still implement prototype methods transparently to the developer without the class keyword. Just as devs could in userspace.

But contrary to what you're saying, most popular userland libs are indeed function oriented, and they don't end up like you're suggesting. E.g. RxJS, lodash

By function oriented in this context, I mean that they don't rely on the new keyword for ordinary code. Which reads cleaner

Anyway, functional stdlib can be pretty clean, such as something like Stream(persons).filter(person => person.age > 18).map(person => person.firstName).

Also there's the Pipes spec in the works that would allow for chaining distinct functions that are not on same obj. Not sure of current status

I’m just expanding the example in my mind, nothing arcane. And maybe it’_.s just me, but I _.fail to _.see how lodash _.is “cleaner”, or why “new” makes things dirty. Are we discussing The High Art of Source Code here? If yes, it ain’t my thing.

functional stdlib can be pretty clean, such as something like Stream(persons).filter(person => person.age > 18).map(person => person.firstName)

I see a stream object with at least a couple of methods, how is it functional? What does functional mean here, callbacks? I mean, array.filter(predicate) also takes one. If that’s the thing, nobody takes it away, it’s already natural to js, since it’s multiparadigm. And we already have piping, it looks like foo().bar().baz() or map(foo).filter(bar) or Object.keys().reduce(quux). If you want a class deconstructor for FP-101 code, here it is:

  const fize = (name, …args) => (obj) => obj[name].apply(obj, args)
  array.map(fize("toString", "hex"))

You can turn it into “fize.toString("hex")” with a little Proxy magic (still no chance for a type safety, sadly).

I understand the different approaches you propose, and I could even write some decent Haskell in my experimenting ages, but my main question is what problem do we solve here and how this solution would be functional and not “move methods to same-named pojos, write them explicitly and pretend it’s FP”.

For sure, do also see cases where class can be good working with a larger team. However, since js's biggest advantage is function as a first class citizen, I do feel like they ought to make the API to be functional., however OO design may attract more developers coming from OO programming world.

Reply on news.ycombinator.com