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

81–90 of 371 posts

Re: Proposal: JavaScript Structs

#81

Post by BiteCode_dev »

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

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

Re: Proposal: JavaScript Structs

#83

Post by leetharris »

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…

Hmm, I understand what you mean. But I think there's a difference between complexity and optionality / versatility.

For example, it has different ways to declare functions because assignment is generally consistent (and IMO easy to understand) and the "simplicity" of Javascript allows you to assign an anonymous function to a variable. However, you can also use a standard function declaration that is more classic.

But I do understand what you're saying. If anything, I think it's generally in agreement with my feelings of "Javascript doesn't need to be more complex."

> There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.

This is hilarious and probably true. I think I am the former since I've been working with it for 20+ years, but I also think there's a reason it's the go-to bootcamp language alongside Python.

Re: Proposal: JavaScript Structs

#84

Post by throw49sjwo1 »

authorfly wrote: post #71
throw49sjwo1 wrote: post #30

Earlier quoted context omitted.

Doesn't matter, I'm talking about the type definitions - @types/react, @types/react-dom and @types/express.

No, those are optional for the enduser to ever encounter.

I never said it's required. The typings are really useful if you want to use these libraries "with TypeScript" as I said in my first comment... The typings are the whole point - that's where the advanced type features are used, and every user benefits - their own code can be much simpler and safer thanks to it.

Re: Proposal: JavaScript Structs

#85

Post by BiteCode_dev »

nwienert wrote: post #69
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…

This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons. That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS…

I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.

Re: Proposal: JavaScript Structs

#86

Post by BiteCode_dev »

leetharris wrote: post #83
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…

Hmm, I understand what you mean. But I think there's a difference between complexity and optionality / versatility. For example, it has different ways to declare functions because assignment is generally consistent (and IMO easy to understand) and the "simplicity" of Javascript allows you to assign an anonymous function to a variable. However, you can also use a standard function declaration that is more classic. But…

I do appreciate the modern features a lot personally, and the fact they have been added without breaking the world. Interpolation, spreading, map and arrow functions are a huge usability boon. Plus I'm glad I can use classes and forget that prototypes ever existed.

But I train beginners in JS and boy do I have to keep them in check. You blink and they shoot their foot, give the pieces to a dog that bite them then give them rabbies.

Re: Proposal: JavaScript Structs

#88

Post by postalrat »

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

WASM has to call javascript to do really anything.

Re: Proposal: JavaScript Structs

#89

Post by spease »

munificent wrote: post #76
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'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…

I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago.

I think the only way to address what you're alluding to is to continually deprecate small parts of the language, so that upgrading is manageable for active codebases. And you probably have to be really aggressive about pushing this forward, because there will always be excuses about why you should hold back just this one time and this one feature is an exception that needs to be held back just a little bit longer.

But in the long run, if you don't force people to change a little bit continuously, it will become a big enough issue to split the ecosystem. See python2 to python3. Or you end up forced into supporting bad practices for all eternity, like C++. And having to take them into account for every. Single. New. Feature.

Further raising the barrier to entry to participation in developing the language to people who are completely focused on its development and have unusual mastery of it, who can't identify with the people struggling with its complexity.

If not at the technical level, then at the business level, where people definitely don't have the time to understand why it'd be safer for the go-to heap allocation method should return a scoped pointer instead of a raw pointer.

Unfortunately, this probably is only viable for strongly-typed languages like C#; for loosely-typed languages like Python, the risk of iterative changes is that if someone moves a codebase several generations ahead at once, it'll introduce lots of subtle changes that'll only become obvious once certain codepaths are exercised...and given how bad testing coverage is for a lot of software, that probably risks breakages only occurring once it's deployed, that are nontrivial to discern via reviews or even static analysis.

Re: Proposal: JavaScript Structs

#90

Post by PeterWhittaker »

dangoodmanUT wrote: post #82

I thought it said "Proposal: JavaScript Sucks" and was not surprised by the number of upvotes from HN

(Wipes away tears of laughter) I needed that! [1] [2]

[1] just got some bad news [2] all in all, I love working in JS when I have to, but I’ve worked in it long enough to know of at least very many of the foot guns.

Post reply on HN