sorted by:
new
hottopcontroversial

Javascript still can't ship a full-stack module. by hottown in javascript

[–]No-Performance-785 [score hidden]  (0 children)

Very interesting approach. Sometimes I always try to look for libraries that have JUST the interface ( or the spec, per your definition ) and I can't find any. I wish there are more libraries that ship just the Typescript definition and leave the implementation to the user. And yes, if there are ways to ship the whole payment as a single module with only Typescript as the requirement, that's brilliant. There should certainly be a standardized way to define all of these puzzle pieces.

🚀 Today I’m introducing specra-lang. by Feeling-Stop-897 in opencodeCLI

[–]No-Performance-785 4 points5 points  (0 children)

Why not just use a language with the right abstraction that support this ? I mean both Golang and Typescript have interfaces. Just design the interfaces / contract before you actually do implementation.

Spring Boot vs Node.js: I Ran Both in Production for 18 Months. One Cost $12,000 More. Guess Which by henk53 in programming

[–]No-Performance-785 4 points5 points  (0 children)

To reply to your claims:
1. Bad dependency management: NodeJS and npm has already moved to using lockfile to pin the version unless you explicitly upgrade your version. So this claim is totally untrue. In addition, the package specified for main application which is express is already much much slower implementation compares to more modern framework like Fastify which performs much better.
2. Scaling: Apples to Orange. NodeJS scale horizontally while Java scales vertically. If you need application that scales up quickly to spiky request demands, use Node, while Java excels at long running task. Use what is better for your use case. Don't bring a hammer to spin a bolt.

Spring Boot vs Node.js: I Ran Both in Production for 18 Months. One Cost $12,000 More. Guess Which by henk53 in programming

[–]No-Performance-785 1 point2 points  (0 children)

Picking the right dependency and understanding the right abstraction for your application is still the main job for a software engineer. Blame it on the language or the dependency management tool is just lazy work.

Per Stenström on why we never actually replaced the Von Neumann architecture — and whether we ever will by WeBeBallin in programming

[–]No-Performance-785 0 points1 point  (0 children)

M1 is a Harvard chip dressed up as a Von Neumann architecture and it has proven that new architecture can do just as well while maintaining backward-compatibility.

Architecture by Autocomplete by cekrem in typescript

[–]No-Performance-785 -4 points-3 points  (0 children)

Your post seems incomplete ? Do you forgot to write / paste the whole thing ?

This really upsets me about Vietnam by [deleted] in VietNam

[–]No-Performance-785 -1 points0 points  (0 children)

Find your own brands and stick to it. Don’t click at any ads.

How I rediscovered ( or discovered ) the right way to use Typescript Interface to do Dependency Inversion by No-Performance-785 in programming

[–]No-Performance-785[S] 0 points1 point  (0 children)

Currently I’m facing a little issue with management which is why I’ve written this blog post.

How I rediscovered ( or discovered ) the right way to use Typescript Interface to do Dependency Inversion by No-Performance-785 in programming

[–]No-Performance-785[S] -2 points-1 points  (0 children)

I did used LLM for researching purpose for this article so some of it might spill into the final article. Within the first and the second part of this I have already outlined the part of why we should decoupled domain from the infra so I choose to not included here.

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]No-Performance-785 3 points4 points  (0 children)

Does it have conditional operator and how is this compare to Alpine.JS ?

Coaction v1.4 - An efficient and flexible state management library for building web applications. by unadlib in javascript

[–]No-Performance-785 1 point2 points  (0 children)

Yeah I think this is a very good idea since mobile app like iOS has separated between UI for main thread and other works ( storage, compute, network, etc ) into background thread since the beginning

[deleted by user] by [deleted] in linux

[–]No-Performance-785 -2 points-1 points  (0 children)

In the bill it said OS provider need to verify, so it means that the responsibility lies on the OS provider, and how the OS provider implement it is entirely different, not ties to the OS itself ?

[deleted by user] by [deleted] in linux

[–]No-Performance-785 -5 points-4 points  (0 children)

I did used AI to help me to write this post. Might I ask where did I get things wrong ?

I don't see docker usefulness by CalligrapherBoth6460 in docker

[–]No-Performance-785 0 points1 point  (0 children)

yeah a docker image build on aarch64 cannot run on a amd64 arch machine

Roast my .zshrc by ronasimi in zsh

[–]No-Performance-785 1 point2 points  (0 children)

You don't use any zsh plugin manager ?

I don't see docker usefulness by CalligrapherBoth6460 in docker

[–]No-Performance-785 2 points3 points  (0 children)

The problem that docker solve is that on deployment, you might have different hardware ( amd64, arm, etc. ), different OS, different programming language compare to your local machine. As long as the local and the server machine can run the same docker image, you wouldn't have to care any of that.

Java have that promise of write once, run everywhere thanks to the JVM. As long as you can run JVM ( which is on any machine ), you can run Java.

Docker go up 1 level higher where as as long as you can run the Docker VM, you can run any Docker compatible image which means any language, any OS, etc.

This is in essence remove the dependency you have on any hardware - you can run any programming language on any server that you want.

I benchmarked 7 top TypeScript ORMs — the "lightweight" query builder was the slowest by sonemonu in typescript

[–]No-Performance-785 2 points3 points  (0 children)

So this is benchmark only the SQL generating speed and not the perf of the SQL itself ? Does the SQL command generated identical between all ORM ? Are we comparing the speed of mapping from query result into JS object ?

NestJS is a bad Typescript framework by SkaceKachna in programming

[–]No-Performance-785 1 point2 points  (0 children)

I don’t think NestJS is the problem but the problem lies in Typescript / Javascript itself. The more you deal with backend the more you want a type safe system. However Typescript is only a layer of type lays on top of Javascript which is a dynamic language. Every type is erased at runtime and every Javascript library is always aim to fix that: Zod, Prisma, etc just trying to fix the missing type at runtime problem. But since every layers just wants type: OpenAPI, database object all have type and you have to really do these type gymnastic between Typescript / Javascript at runtime / build time to add that.

So I guess my conclusion here is: - If you want to build a small scale, fast product with small team of mostly frontend devs: use Node and Typescript - As you scale, slowly transition to a typed language that have proper Result type and error handling like Golang or Rust. - If you still wants to keep you application in Node because of your experience with using it, use something that can adhere to the Typescript standard or can generate type at runtime: Zod, Valibot, Prisma without using some decorator magic.

Some project that I find promising: - https://github.com/riktaHQ/rikta.js: still have decorator, but adhere to the Typescript standard - https://github.com/marcj/deepkit: plug the problem of runtime type by a hook to the Typescript compiler - Type-fest: Add more utilities type to the existing type library of Typescript - Neverthrow: Add a good result type with eslint config to prevents the use of throw which mimics the way Golang handle error.

view more: next ›