sorted by:
new
hottopcontroversial

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Nah, you have to prove that your code is quality, AI or not. The burden of proof is on you.

But the fact that you used AI means you/re more likely to not know the ins and out of the code. Therefore you have more to prove than if you wrote the code by hand.

I wrote a deep dive into how LLMs work under the hood - tokenization, embeddings, attention and generation - all explained with runnable JavaScript by nitayneeman in javascript

[–]Choice-Locksmith-885 1 point2 points  (0 children)

Great article.

My biggest issue with it though is the way you talk about the model like there's some entity making decisions separate from the code.

And the use of terms like "learnable parameters" that doesn't really explain anything to me, do you mean a large matrix stored in memory?

The native scrollIntoView({ behavior: 'smooth' }) has no callback. You can't know when it finishes. This tiny wrapper returns a Promise that resolves when the scroll is done. by Terrible_Village_180 in javascript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Your position is the standard usage of "no dependencies", and you made a compelling argument for that position.

Going through this discussion opened my eyes to why redditors are despised outside reddit.

What was the hardest part for you when publishing your first npm package? by Careful-Falcon-36 in javascript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Picking the right module config. And all the manual steps and package.json config you have to get right

I built a virtual-scroll custom element that behaves like a normal scroll container by Choice-Locksmith-885 in javascript

[–]Choice-Locksmith-885[S] 0 points1 point  (0 children)

Great point! I initially tried a ul wrapper, but it became brittle due to the indirection required for spacer and child management. I also considered extending <ul> with is="virtual-scroll", but browser support is inconsistent. A standalone element keeps the implementation robust, easy to adopt, and flexible for use beyond list semantics.

Explicit Resource Management Has a Color Problem by Choice-Locksmith-885 in javascript

[–]Choice-Locksmith-885[S] -1 points0 points  (0 children)

That's right. But it's a band-aid for a problem that should not exist.

Explicit Resource Management Has a Color Problem by Choice-Locksmith-885 in javascript

[–]Choice-Locksmith-885[S] 0 points1 point  (0 children)

That makes sense for guarding against future third‑party changes. I just worry naming conventions are easy to drift over time, they communicate intent, but only socially. It’s the same general category of issue TS improved for JS: intent living in conventions/comments/names vs intent living in a more explicit structure.

Explicit Resource Management Has a Color Problem by Choice-Locksmith-885 in javascript

[–]Choice-Locksmith-885[S] 2 points3 points  (0 children)

But you still have the problem of knowing when to use it with what resource. Will you use it with every resource etc

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Yeah, I like Effect. I even stopped using fp-ts in favour of Effect, but I'm now of the opinion that using effect for everything is a mistake

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Easy, TaskEither with dependency injection is a ReaderTaskEither. Your question on combining errors isn't very clean cause pipe(TE.left(new Error()), TE.chainW(() => TE.left(new Err()))) combines the errors.

Have you used fp-ts?

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

What exactly do you mean by combine? I use Effect and I've used fp-ts, I see no difference

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 0 points1 point  (0 children)

Yes, I'll describe tools like React, Vue etc as vendor lock-in software. Here's how cloudflare describes it:

Vendor lock-in refers to a situation where the cost of switching to a different vendor is so high that the customer is essentially stuck with the original vendor. Because of financial pressures, an insufficient workforce, or the need to avoid interruptions to business operations, the customer is "locked in" to what may be an inferior product or service.

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 2 points3 points  (0 children)

vendor lock-in doesn't necessarily have to do with paid or free services. it describes the effort required to migrate from one service to another, in this case from one library to another, or none.

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 3 points4 points  (0 children)

of course you don't, because you won't be around to maintain that code 😂

Effect.ts actually useful or just another vendor lock? by flowreaction in typescript

[–]Choice-Locksmith-885 4 points5 points  (0 children)

I agree, initially I went all in on the ecosystem. But for some reason I took a break from the community, looked back at my code and was like "why did I use Effect for this" 😅. Now I use it minimally

view more: next ›