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

31–40 of 371 posts

Re: Proposal: JavaScript Structs

#31

Post by [deleted] »

throw49sjwo1 wrote: post #24
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…

> And nobody uses most of it! Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.

[deleted]

Re: Proposal: JavaScript Structs

#32

Post by sjrd »

AprilArcus wrote: post #12
egeozcan wrote: post #3

Huh, I thought that most work that used to use workers switched to Webassembly. Talking about JS proposals, I'm looking forward to this one: https://github.com/tc39/proposal-record-tuple Records and tuples can make a lot of logic much more easier to read, and way less fragile. Not sure how they would play together with the shared structs though.

I don't think R&T will ever ship at this point, since the browser vendors are apparently unwilling to absorb the complexity that would be required to add new primitive types with value semantics.

I've been following that proposal closely, and even (unsuccessfully) tried to contribute suggestions to it. I think what's killing it is that the authors of the proposal won't accept arbitrary values as fields of R/T, but all the potential users are saying that they won't use R/T if they can't put arbitrary values in them.

The reluctance of the authors is due to backward compatibility with sandboxed "secure" JavaScript (SES). That said, every other language in existence that has immutable structs and records allows to put arbitrary values in them.

So it's at a standstill, unfortunately.

Re: Proposal: JavaScript Structs

#34

Post by thot_experiment »

afavour wrote: post #27
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…

I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple ... in most scenarios you'll probably be better off us…

> but there's absolutely no reason to use var any more

Naw, var has function scope and hoisting, both of which are useful.

Re: Proposal: JavaScript Structs

#36

Post by afavour »

thot_experiment wrote: post #34
afavour wrote: post #27

Earlier quoted context omitted.

I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple ... in most scenarios you'll probably be better off us…

> but there's absolutely no reason to use var any more Naw, var has function scope and hoisting, both of which are useful.

Not in a sensible codebase

Re: Proposal: JavaScript Structs

#38

Post by aardvark179 »

weego wrote: post #9

It's hard to take anyone concerned about the 'performance ceilings' in javascript object creation seriously at this point.

    Give developers an alternative to classes that favors a higher performance ceiling and statically analyzability over flexbility.
Is an entirely reasonable goal. Object shape in JS tends to go through a fixed pattern of mutation immediately after construction and although that can sometimes be analysed away by the JIT there are a lot of edge cases that can make that tricky.

You may not care, but I bet almost everybody who has actually worked on a JS engine does, and has good reasons for doing so.

Re: Proposal: JavaScript Structs

#39

Post by afavour »

I feel conflicted. Working with multithreaded stuff in JS is a huge PITA. This would go some way to making things easier. But it also feels like it would radically complicate JS. Unsafe blocks? Wow-eee.

With the rise of WASM part of me feels like we shouldn't even try to make JS better at multithreading and just use other languages better suited to the purpose. But then I'm a pessimist.

Re: Proposal: JavaScript Structs

#40

Post by dartos »

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…

At least typescript tooling hasn’t changed. It was a pain to set up when it came out and it still is.

At least we moved past webpack mostly.

Post reply on HN