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

351–360 of 371 posts

Re: Proposal: JavaScript Structs

#351

Post by unchar1 »

zanethomas wrote: post #350
unchar1 wrote: post #340

Earlier quoted context omitted.

Classes generally point you towards writing more performant code. Factory functions allow you to achieve the same performance, you just have to be a bit more careful not to cause a depot :) For example, 1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2] 2. Method declarations are also (almos…

The difference in performance is negligible for all but the most demanding applications. In which case I would still use factory functions, but just be more careful.

I agree. But it's one reason why someone who is concerned about performance, may prefer classes by default.

Re: Proposal: JavaScript Structs

#352

Post by chii »

debit-freak wrote: post #329
MarkusQ wrote: post #322

Earlier quoted context omitted.

> There is no wrong use of language Thy can'n't sirus be. language works only farso as withbreathings we follow, Leading paths through gardens means fail, and bloom'st chaos wear not!

I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.

> rather than actually communicate effectively.

what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?

Re: Proposal: JavaScript Structs

#353

Post by rty32 »

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.

IDE support is often hit or miss with these, I have seen too much of it.

Don't use vscode or never bother to write jsdoc/do any strict typing? Never mind. Good luck with your codebase.

Re: Proposal: JavaScript Structs

#354

Post by munificent »

mdhb wrote: post #209
munificent wrote: post #76

Earlier quoted context omitted.

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not t…

Just as a quick side note this is actually one of the things I’ve come to appreciate most about some of the work you and the others have done with Dart where it very clearly has gotten much more powerful and has had to deal with some major changes in requirements over the years as well but on the whole I feel with only a few exceptions the complexity doesn’t feel like it’s gotten away from me or the community at larg…

Thank you!

We try really hard. I'm always worried about pouring too much complexity in and alienating new users. At the same time, we also want to serve existing users who really do benefit from new features. It's a tricky balancing act.

Re: Proposal: JavaScript Structs

#355

Post by lelanthran »

n_plus_1_acc wrote: post #51
eddd-ddde wrote: post #44

Earlier quoted context omitted.

This is why always say the true beginner programming language is C. Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).

How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.

> How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.

Right. Becuase no one ever learned C as a first language ever, and those that paradoxically did were worse programmers for it!

Re: Proposal: JavaScript Structs

#356

Post by dgellow »

jenscow wrote: post #97
leetharris wrote: post #72

Earlier quoted context omitted.

Now that I'm thinking about it, most of it is probably .NET bloat instead of C# bloat, but a few examples would be global usings, file scoped namespaces, records, target-typed new expressions, null coalesce assignments, etc. It's nothing huge, but combined with .NET bloat it can be overwhelming when you haven't worked in .NET for a while.

and pattern matches, primary constructors, range operator, switch expressions, etc. it does add up

All of this looks and feels like C#. That doesn’t look unreadable or a completely different language. In fact they end up making C# more readable by removing boilerplate

Re: Proposal: JavaScript Structs

#358

Post by afiori »

renlo wrote: post #273
jknutson wrote: post #147

Earlier quoted context omitted.

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

function x() {/* ... */} const x = function() {/* ... */} const x = function foo() {/* ... */} const x = (function() {/* ... */}).bind(this) const x = (function foo() {/* ... */}).bind(this) const x = () => {/* ... */} const x = () => /* ... */

Apart from hoisting (which has little to do with functions directly) and `this` these are all equivalent

Re: Proposal: JavaScript Structs

#359

Post by debit-freak »

chii wrote: post #352
debit-freak wrote: post #329

Earlier quoted context omitted.

I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.

> rather than actually communicate effectively. what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?

> what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?

Trying to understand the speaker, presumably, and not wielding your pet definition like a semantic argument. It's fundamentally boring conversation with no benefit to either party and it makes you look like an illiterate ass.

Re: Proposal: JavaScript Structs

#360

Post by devjab »

Zanfa wrote: post #230
devjab wrote: post #191

Earlier quoted context omitted.

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.

Maybe if someone suggests Deno or similar, but Bun is a drop in for Node and is as such completely interoperable with your Node code. Its similar to how you can adopt PNPM easily because it’s a drop in for NPM, where as yarn and others are their own things.
Post reply on HN