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

311–320 of 371 posts

Re: Proposal: JavaScript Structs

#311

Post by wruza »

zanethomas wrote: post #293
wruza wrote: post #214

Earlier quoted context omitted.

Otoh, I create classes, use prototypes and it’s natural and useful in many of my cases. In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS. We could even share this dream if browser vendors weren’t such whos the boss iam da boss when it comes to extensions and alternatives. So we have to live in a common denominator, which surprisingly isn’t as bad…

I wonder why it seems natural to you? I'm guessing JS wasn't your first language and you didn't learn the power of composition instead of classes.

Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034

I'm guessing JS wasn't your first language

Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts is only a recent addition, so I might have missed some fashion ideas.

Tongue in cheek aside, if you’re an old dev, there’s nothing you have to listen to because you can see whether you have a problem yourself and decide for yourself. You can be your own advisor. I see both “classes” and “just functions” ways clearly and can convert my current codebases in my mind between these two. Nothing really changes for the latter, apart from bulky import sections, lots of * as ident imports, context-arg passing and few dispatch points. Objects (non-strictly related groups of data and methods) still exist and hold refs to event/callback emitters. So my reasoning isn’t why, my reasoning is why not. I have a tool, I have a business logic, pen pineapple apple pen. Don’t overthink it is my main principle.

Do I need to introduce composition? Do I have it already? How is it better than what I’m doing? Is it? What am I missing? What are they missing? What if they don’t? What if we speak of different things? These are the questions of a restless butt that cannot find rest on any stool. Instead it should ask: Do I have a problem?

Re: Proposal: JavaScript Structs

#312

Post by jakub_g »

ttul wrote: post #280
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…

(Continued) Proxy traps and symbol iterators, BigInts for calculations greater Nullish merging, optional chaining, code that's always up-to-date-ing Temporal parsing, binary shifting, WeakRefs for memory lifting Intl APIs for global fitting, Promise.any for fastest hitting Private fields and static blocks, top-level awaits unblock the clocks Logical assignments, numeric seps, each update brings new shocks Array flatt…

Fun weekend project idea: create an MDN docs clone with a spirit of above and https://git-man-page-generator.lokaltog.net/

It could also include babelrc and eslintrc generator as proposed in another comment below.

Re: Proposal: JavaScript Structs

#313

Post by xpe »

johnfn wrote: post #29
modeless wrote: post #15

Earlier quoted context omitted.

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

Let me know when WASM has a dev workflow that gets a change to your browser 1/10th as fast as Vite + TypeScript + React.

I will grant that fast iteration is beneficial. But for me, under 10 seconds is usually fast enough. (For example, I don't think I would care too much when comparing 0.5 vs 5 second builds.)

I personally care a lot more about having a confidence-inspiring language and ecosystem.

In my experience with Rust and WASM (with various tools such as Dioxus), I find myself caring a lot more about the WASM ecosystem and browser evolution/improvement.

For example, at bottom, the JS interop feels pretty sub-optimal. Calling this "hcky" might even be deserved: I'm talking about memory serialization between JS-land and WASM-land. As I understand it, we may see significant improvement under the hood in the next few years. (I'm not an expert on the particular proposals, their adoption, etc. Please weigh in if you have a better sense.)

Re: Proposal: JavaScript Structs

#314

Post by tgv »

lolinder wrote: post #94
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…

> When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! TypeScript today can be written the same way that TypeScript was when it first started to become popular. Yes there are additions all the time, but most of them are, as you observe, irr…

TS is pretty good. In the beginning, I had to resort to 'any' frequently, but nowadays it's often possible to avoid that by writing some auxiliary types. It's not easy, but you can get quite far. JS without TS' safety net is a nightmare...

Re: Proposal: JavaScript Structs

#315

Post by tgv »

madeofpalk wrote: post #255
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.

Go is an excellent language for people who turned off C# or Typescript, for better or worse.

That's not me, and I use it. I like TS, but in the browser. It has not much use elsewhere, certainly not in the backend. Go is not only simple and stable, it's quite flexible, has a good eco-system, a wonderful build system, and is really fast and light at runtime.

Re: Proposal: JavaScript Structs

#316

Post by DanielHB »

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…

You are not wrong, but a lot of the stuff you mentioned is literally a non-issue with any modern JS environment.

It feels like any old language gets this way...

Re: Proposal: JavaScript Structs

#317

Post by Alifatisk »

Philpax wrote: post #210
Alifatisk wrote: post #207

Earlier quoted context omitted.

Why couldn’t you just write a paragraph instead of using some citing system for formulating your sentence?

They're footnotes and are meant to be read as supplementary notes to the core message.

But we already have a way for supplementary notes, it's by using parentheses? Like this:

  Today I went for a walk (which I don't usually do), and I saw a squirrel.
Or have I been doing it wrong?

Re: Proposal: JavaScript Structs

#318

Post by wk_end »

rezonant wrote: post #227
whizzter wrote: post #202

Earlier quoted context omitted.

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…

Using JS/TS in a functional style doesn’t mean using prototypes or function binding or anything. I’m not sure how you inferred that from the comment you’re replying to…it just means using plain objects (TypeScript even, a little awkwardly, lets you express ADTs) and plain functions, perhaps with the module system to organize them.

Re: Proposal: JavaScript Structs

#319

Post by wvenable »

terandle wrote: post #173
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…

Been using .net since 2.0 and nah C# has jumped the shark. Primary constructors are a very poorly designed feature that for some reason was added in the last version. The new-ish yearly release cycle I think is mostly to blame, they feel like they need to add some headline features every year but the team also, maybe due to org-chart politics, seems to not really able to make deep runtime level changes that are neede…

> Primary constructors are a very poorly designed feature that for some reason was added in the last version.

I upgraded to .NET 8 recently and I love primary constructors. I don't use them everywhere but they are great for dependency injection or for small classes.

Re: Proposal: JavaScript Structs

#320

Post by k3vinw »

I love JavaScript! It’s such an exciting development experience loaded with surprises! I was just thinking the other day how cool it would be if it had unsafe blocks like in Rust. What an exciting time to be alive!
Post reply on HN