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

161–170 of 371 posts

Re: Proposal: JavaScript Structs

#161

Post by BigJono »

usrusr wrote: post #118
BiteCode_dev wrote: post #78

Earlier quoted context omitted.

Yes, but when "the good parts" came out, half of this list was already true. There is a reason we ignore a good chunk of the language to be productive with it.

Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing somethin…

It would have worked out fine if we managed to lose the prototypes without ramming classes into the language and baiting all the Java dickheads over to the web ecosystem.

Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".

Re: Proposal: JavaScript Structs

#162

Post by BigJono »

klysm wrote: post #160
BigJono wrote: post #157

Earlier quoted context omitted.

Yep and TS has all of that plus a gigantic layer of bullshit on top. The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.

Typescript is the best thing to happen to JavaScript since ES6

[flagged]

Re: Proposal: JavaScript Structs

#163

Post by claytongulick »

egnehots wrote: post #53
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…

Try Go. Go is really stable as a language and have a very small core feature set.

I would be a huge fan of go, but json is just too big a hassle to deal with in go compared to JavaScript.

Re: Proposal: JavaScript Structs

#164

Post by bakkoting »

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…

> instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features

I appreciate that this is mostly just a generic rant, but it's not really suitable here, because this is a feature which is being added with the sole goal of improved performance.

There's only so much you can to optimize the extremely dynamic regular objects in JS, and there's no hope of using them for shared-memory multithreading. The purpose of this proposal is to have a less dynamic kind of object which can be made more performant and which can be made suitable for shared-memory multithreading.

Re: Proposal: JavaScript Structs

#165

Post by Izkata »

Lerc wrote: post #117
girvo wrote: post #102

Earlier quoted context omitted.

In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.

I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset. In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that. I do wonder if there will, one day, be a breaking fork of JavaScript that only remo…

> BiteCode_dev has provided a pretty good summary of a lot of the issues.

Around half of that list is things added later that were supposed to make the language easier to use.

Re: Proposal: JavaScript Structs

#167

Post by te_chris »

BiteCode_dev wrote: post #81
wk_end wrote: post #75

Earlier quoted context omitted.

I feel like a large slice of JS’s complexity comes from footguns you aren’t really supposed to use anymore; whereas with C# the complexity feels quite layered, multiparadigmatic, something-for-everyone, syntactic-sugary. But I probably know too much about JS and not enough about C#.

Well, all the people that used JS 15 years ago followed Douglas Crockford advice very much to heart.

Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.

Re: Proposal: JavaScript Structs

#168

Post by nielsbot »

te_chris wrote: post #167
BiteCode_dev wrote: post #81

Earlier quoted context omitted.

Well, all the people that used JS 15 years ago followed Douglas Crockford advice very much to heart.

Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.

Does TS make JS non-smalltalky? Static typing which is optional.. and you still get a REPL, online compiler and the ability to dynamically inspect objects in your global object...

Re: Proposal: JavaScript Structs

#169

Post by lxe »

paulddraper wrote: post #156
lxe wrote: post #98

𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮 They've got decorators, record tuples, shadow realms, and rich rekeying Dynamic imports, lazy modules, async contexts now displaying JSON parsing, destructure privates, string dedenters, map emplacers Symbols pointing, pipe operators, range iterators, code enhancers Eager asyncs, resource tracking, strict type checks, and error mapping Phase imports, struct layouts, buffering specs for data stacking Temporal…

10/10

Thanks. I put 37 actual proposals in here.

Re: Proposal: JavaScript Structs

#170

Post by totallykvothe »

leetharris wrote: post #67
egnehots wrote: post #53

Earlier quoted context omitted.

Try Go. Go is really stable as a language and have a very small core feature set.

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.
Post reply on HN