Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

Post reply on HN
Print view View original

221–230 of 324 posts

Re: Should JavaScript be split into two languages?

#221

Post by petre »

javajosh wrote: post #186
hn_throwaway_99 wrote: post #17

I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes. W…

The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules…

The vanilla js APIs are so atrocious that we got jquery.

Re: Should JavaScript be split into two languages?

#222

Post by petre »

sjrd wrote: post #176
davexunit wrote: post #126

Earlier quoted context omitted.

Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by import…

> Projects like Hoot (Scheme) and Kotlin port are already demoing such things. And Scala.js has shipped it. [1] Although technically experimental, it has no known bugs and it has full support of things like manipulating DOM objects from Scala.js-on-Wasm code. [1] https://www.scala-js.org/news/2024/09/28/announcing-scalajs-...

I thought the js DOM API was atrocious. But they copied it over with Java object hierarchy into Scala.js. Makes me want to give up on coding altogether.

Re: Should JavaScript be split into two languages?

#223

Post by wiseowise »

akira2501 wrote: post #188
wiseowise wrote: post #115

Earlier quoted context omitted.

> Who cares? I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.

I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be. Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.

> The existence of new language features has not forced me to adopt them.

You still need to be aware of them when you encounter unfamiliar syntax.

Re: Should JavaScript be split into two languages?

#224

Post by xscott »

Dylan16807 wrote: post #209
xscott wrote: post #128

Earlier quoted context omitted.

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

> This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.

It's a rule, and it behaves like people probably expect for small numbers. But following that rule:

      float(0.5) +
      bigint(9007199254740993)
    == float(9007199254740992)
I wouldn't parade it around as a triumph over the problem, and it's arguably better to require people to be explicit about whether converting the float to bigint, or the bigint to float, is what you wanted.

Re: Should JavaScript be split into two languages?

#225

Post by wiseowise »

a57721 wrote: post #206
wiseowise wrote: post #113

Earlier quoted context omitted.

[flagged]

Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.

Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle.

It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd. Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while.

Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS.

> designed much later and not so hastily, so they have less warts than JavaScript as a result.

That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.

Re: Should JavaScript be split into two languages?

#226

Post by wiseowise »

anonzzzies wrote: post #211
wiseowise wrote: post #113

Earlier quoted context omitted.

[flagged]

Well this person is not the only one who thinks js (and web stuff in general) is terrible. I mostly dislike the pace of crapification; I comment almost daily on repositories asking why they made that breaking change with zero benefits for the user. Usually 'we are cleaning up' or so; there are npms that really need never be changed that are changing weekly just because 'keep them fresh'. That kind of misery is just w…

Your first paragraph complains about people, not the tool. It is a side effect of low barrier for entry, not some awfulness of JS.

> Neither of these require any bullshit with tooling or anything hard.

JS requires any text editor and a browser.

TS requires Node and npm i -D typescript.

> You can learn enough Go in a few hours to be productive (like C)

You want to say that C and Go are easier to learn that JS? JS is literally primitive types, objects and functions at its core.

Re: Should JavaScript be split into two languages?

#227

Post by wiseowise »

righthand wrote: post #178
wiseowise wrote: post #151

Earlier quoted context omitted.

My point is that "framework fatigue" is a self-inflicted problem. Nobody forces you to use flavor of the week, VanillaJS and bog standard HTML/CSS are always there for you.

Work in a publicly traded company where people are moving things around for promotions sake. Then you’ll see how forced you are to use the latest flavor of the week. People absolutely do force you. It’s not just the flavor of the week frameworks, it’s libraries and best practices. Want to work with dates? Do you use moment? Nope that’s deprecated, what do you use? Which moment successor? How do you write react? Class…

> Work in a publicly traded company where people are moving things around for promotions sake. Then you’ll see how forced you are to use the latest flavor of the week. People absolutely do force you.

I can tell you such stories about any language, it’s not unique to JS. Welcome to working with people.

Re: Should JavaScript be split into two languages?

#228

Post by xscott »

anonzzzies wrote: post #210
xscott wrote: post #103

Earlier quoted context omitted.

What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?

What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?

I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options:

A) Get your hands dirty and write what you want. Once.

B) Chant along with the mob who doesn't even understand what they're asking for.

C) Wait several years for some super complicated solution to be designed by committee.

I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious.

Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on...

I choose option A.

Re: Should JavaScript be split into two languages?

#229

Post by loftyal »

ninetyninenine wrote: post #55
ttoinou wrote: post #37

Earlier quoted context omitted.

You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.

Yeah but if I change jobs or work on another project then I’d have to learn two standards.

Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.

Re: Should JavaScript be split into two languages?

#230

Post by [deleted] »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

[deleted]
Post reply on HN