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

Proposal: JavaScript Structs

github.com

Post reply on HN
Print view View original

241–250 of 371 posts

Re: Proposal: JavaScript Structs

#241

Post by kevlened »

jknutson wrote: post #147
BiteCode_dev wrote: post #64

Earlier quoted context omitted.

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects pro…

3 ways to declare functions? I am probably blanking but I can only think of: ``` function foo () {} const foo = () => {} ```

const x = { foo() {} }

Re: Proposal: JavaScript Structs

#242

Post by stroupwaffle »

BiteCode_dev wrote: post #64
leetharris wrote: post #18

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects pro…

Yeah I recommend reading “JavaScript the good parts” and don’t use anything far beyond those. Instead of “compile-time safety guarantees” by these vendor-lock-ins-masquerading-as-open-source, just use the language as it was designed: dynamically, and unit test—because you’re gonna be doing those anyway.

Re: Proposal: JavaScript Structs

#243

Post by flappyeagle »

chii wrote: post #239
BiteCode_dev wrote: post #64

Earlier quoted context omitted.

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects pro…

> reasons to believe JS is simple it's because people are talking past each other, and that's because people are using language wrong, and are merely talking past each other. The word simple is often used to mean "easy" or "familiar". Simple is very different from easy, and familiar things are easy but doesn't have to be simple at all. javascript is not simple, but it is easy.

[flagged]

Re: Proposal: JavaScript Structs

#244

Post by nolist_policy »

7bit wrote: post #204
klysm wrote: post #160

Earlier quoted context omitted.

Typescript is the best thing to happen to JavaScript since ES6

Types are great, but I prefer Not having to transpile everything. Stepping throught the TS Code with a Debugger ist non trivial.

You can use 90% of typescript from pure JavaScript: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

Re: Proposal: JavaScript Structs

#245

Post by mightyham »

7bit wrote: post #204
klysm wrote: post #160

Earlier quoted context omitted.

Typescript is the best thing to happen to JavaScript since ES6

Types are great, but I prefer Not having to transpile everything. Stepping throught the TS Code with a Debugger ist non trivial.

I'm not sure what setup you have, but debugging TS code is pretty trivial. I use vite for all my projects at work and when running the dev server there is seamless integrations with the debugging dev panel in Chrome or Firefox.

Re: Proposal: JavaScript Structs

#246

Post by GOATS- »

BoppreH wrote: post #211
totallykvothe wrote: post #170

Earlier quoted context omitted.

.NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.

And startup time. JIT languages are a bad match for command line applications, for example.

.NET can do ahead-of-time compilation now, there are a few gotcha's but it's usable.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Re: Proposal: JavaScript Structs

#248

Post by bastawhiz »

modeless wrote: post #15
bastawhiz wrote: post #11

Earlier quoted context omitted.

Call me when browsers support another language. What are we going to use? CSS?

wasm "but wasm has to call JavaScript to use browser APIs" WasmGC is shipped in Chrome and Firefox and enabled by default in WebKit nightly

Great, show us how you render something on the page with wasm only

Re: Proposal: JavaScript Structs

#249

Post by bastawhiz »

jtolmar wrote: post #99
bastawhiz wrote: post #8

I initially didn't like the high level idea, but I warmed up to it. My only concern is that the constructor isn't guaranteed to define the same fields with the same types, which kind of defeats the point. I'd improve this proposal in two ways: 1. Explicitly define the layout with types. It's new syntax already, you can be spicy here. 2. Define a way for structs to be directly read into and out of ArrayBuffers. Fixed…

I agree; the point of a struct type would be to allow a compact memory representation, and you're not going to get it if your constructor can do if(someArg) { a = 1; } else { a = 1; b = 2; }. You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes. I don't think a way to read into and out of ArrayBuffers is possible, since these can have pointers in them. I th…

> You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes.

Arguably that's worse than what the runtime is able to do today already with hidden classes.

> I don't think a way to read into and out of ArrayBuffers is possible

If you know all the types and only allow structs and primitives, you could use relative pointers to encode the 2nd+ references to structs that appear more than once in the encoded object. You'd need a StructArray for efficient arrays, but a linked list would encode pretty compactly. But you're very right.

Re: Proposal: JavaScript Structs

#250

Post by metaltyphoon »

totallykvothe wrote: post #170
leetharris wrote: post #67

Earlier quoted context omitted.

This is easily the most appealing thing to me about Go. I learned Go through the "Learn Go with Tests" way and I had a ton of fun. It is hard for me to recommend using Go internally since .NET/Java are just as performant and have such a mature ecosystem, but I crave simplicity in the core libraries. Here's the link for anyone considering learning Go: https://quii.gitbook.io/learn-go-with-tests

.NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.

This is almost as bad as saying .NET is windows only.
Post reply on HN