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

221–230 of 371 posts

Re: Proposal: JavaScript Structs

#221

Post by wruza »

szastamasta wrote: post #62
rty32 wrote: post #58

Earlier quoted context omitted.

Exactly. Without new features and syntaxes people would still be doing MyClass.prototype.method = function () { } like idiots. Such a meaningless argument for preventing progress.

Nobody needs classes nor prototypes in JS. Objects + functions is more than enough. I stopped using these few years ago and miss nothing.

It is enough, but not more than. Collecting functions in a group by operating on a shared context is naturally useful and convenient. Pretending otherwise leads to all sorts of “a method, but I see it as a function with an accidental first parameter in a homonimous namespace because having a function name prefix is ugly, and it’s all ugly, but at least it’s not a class”.

  import * as fooNs from './foo'
  fooNs.barBazQuuxFoo(foo, …)
vs

  foo.barBazQuux(…)

Re: Proposal: JavaScript Structs

#222

Post by mr_toad »

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 = () => {} ```

Do function expressions count?

Re: Proposal: JavaScript Structs

#223

Post by wiseowise »

dingi wrote: post #215
wiseowise wrote: post #179

Earlier quoted context omitted.

> Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea". I still don’t understand how someone looked at Spring and thought “Wow, that’s pretty good! I’ll bring it to platform that has worse performance than Java, to language that was designed with dynamicity in mind and has no native static typing”.

Asking out of curiosity. What's your rationale behind Spring is slower? Worked on couple of greenfield and existing Spring Boot applications and we never had any performance issues caused by Spring. Spring has its own bad parts but calling that it has worse performance than Java is not one of them. Its not even a valid comparison. Java is crazy fast for a VM based runtime AFAIK.

Java is faster than Node.

You take slow framework, like Spring, and put it on slower runtime (Node) so you get double slow with less benefits.

Re: Proposal: JavaScript Structs

#224

Post by drclau »

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…

> Microsoft has a large team dedicated towards improving these languages constantly

… and the people working on these projects need to deliver, else their performance review won’t be good, and their financial rewards (merit increase, bonus, refresher) will be low. And here we are.

Edit: I realize I’m repeating what you said too, but I wanted to make it more clear what’s going on.

Re: Proposal: JavaScript Structs

#225

Post by ifwinterco »

demurgos wrote: post #195
Lerc wrote: post #117

Earlier quoted context omitted.

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…

ESM is the closest to a major version for JS. It forces strict mode, which includes many non-backwards compatible changes [0]. Most notably, it removes the `with` statement. Other examples of removals are octal literals or assignments to undeclared variables. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Yep, it's going to take time but eventually one day the vast majority of JS code in the wild will be strict mode and the non-strict stuff will be de facto deprecated and not expected to work everywhere

Re: Proposal: JavaScript Structs

#226

Post by syg »

connicpu wrote: post #7

The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can't crash the computer. Allowing untrusted code to specify "hey let me do stuff that can cause data races if not done correctly" is just asking for trouble, and also exploits. If shared str…

Author here. I hear your feedback about unsafe blocks. Similar sentiment is shared by other delegates of the JS standards committee.

The main reason it is there today is to satisfy some delegates' requirement that we build in guardrails so as to naturally discourage authors from creating thread-unsafe public APIs and libraries by default. We're exploring other ideas to try to satisfy that requirement without unsafe blocks.

Re: Proposal: JavaScript Structs

#227

Post by rezonant »

whizzter wrote: post #202
te_chris wrote: post #167

Earlier quoted context omitted.

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.

How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well. Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style witho…

I'm all for people writing functional code with Javascript-- but when people eschew classes because of their "stink" and proceed to use all of the stateful prototypal archaic features of JS instead of classes, I have to protest. If you are using this and function binding and state extensively in your "functional" JavaScript, you are reinventing classes poorly. And classes are a part of JS itself, not something added on to JS by Typescript (in the current day).

The Crockford crowd would like us to live in a world of ES5 as if that's some kind of badge of pride, while justifying it with a warcry of "functional", while breaking the preconceptions of functional programming all throughout.

Re: Proposal: JavaScript Structs

#228

Post by syg »

connicpu wrote: post #7

The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can't crash the computer. Allowing untrusted code to specify "hey let me do stuff that can cause data races if not done correctly" is just asking for trouble, and also exploits. If shared str…

The ability to do unordered operations on shared memory is important in general to write performant multithreaded code. On x86, which is very close to sequentially consistent by default (it has something called TSO, not SC), there is less of a delta. But the world seems to be moving towards architectures with weaker memory models, in particular ARM, where the performance difference between ordinary operations and sequentially consistent operations is much larger.

For example, if you're protecting the internal state of some data structure with a mutex, the mutex lock and unlock operations are what ensures ordering and visibility of your memory writes. In the critical section, you don't need to do atomic, sequentially consistent accesses. Doing so has no additional safety and only introduces performance overhead, which can be significant on certain architectures.

Re: Proposal: JavaScript Structs

#229

Post by EraYaN »

wk_end wrote: post #75
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…

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#.

At least in C# you can ignore most of it and the complexity doesn't really come from numerous foot guns. You can still write Java 1.6/.NET 2 style C# code just fine, it's all there. The rest of the features can be fully ignored and they won't hurt you.

But then again the newer features they do make writing code a lot nicer, giving more compile time analysis warnings etc hopefully resulting in slightly better code. And the new features also enabled a lot of performance improvements in the runtime which is nice. .NET 2/4 wasn't all that fast, .NET 8 can be a lot faster.

Re: Proposal: JavaScript Structs

#230

Post by Zanfa »

devjab wrote: post #191
Zanfa wrote: post #178

Earlier quoted context omitted.

And ESM vs CJS. What should be an inconsequential transition, has turned into a minefield where adding a dependency to your package.json might blow up your build system, testing library or application without warning. Literally wasted weeks of my life debugging this pile of poop that is the JS ecosystem.

Is this really a JS or a Node issue though? We have no such issues with Bun.

I guess technically Node, but in practice JS, since Node is still the de facto standard non-browser JS runtime. "Just use X" where X is some other build tool/runtime/testing ecosystem is another weird trope that's somehow considered acceptable advice in JS, but would be a massive undertaking for any non-trivial project.
Post reply on HN