Live data from Hacker News

Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

isultan.bearblog.dev

41–50 of 117 posts

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#41
post #2

Typescript (nodejs) backends are not performant, and your ultra modern stack is going to just cause you issues going forward if you need to scale. Prisma is really bad too, slow queries and no flexibility. If you ever need to do any sort of complex query you will just have to write sql anyway. And typescript is only sort of static typing. These technologies are great for prototyping and building a v1 release to see i…

I’m not partial to Node.js backends for many reasons, primary being that I prefer batteries-included web frameworks and the choices are very limited in the JS backend world… But I have such a hard time believing that Node.js is inherently non-performant when there are so many counter-examples of large scale applications that do just fine on it. I understand that the single-threaded nature of JS can be a bottleneck for certain workloads, but without further explanation I’m going to concur with others and say that reading your comment, it’s hard to discard you guys made a mess on your own... Which at least in my experience often comes down to how difficult it is to build in Node.js precisely because of how “minimalistic” and “unopinionated” everything tends to be… You’d better know what you’re doing when there’s no prescription or standardized way for anything from queuing systems, to ORMs, file organization and architecture, concurrency outside of web requests and CRUD, etc.

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#42
post #2

Typescript (nodejs) backends are not performant, and your ultra modern stack is going to just cause you issues going forward if you need to scale. Prisma is really bad too, slow queries and no flexibility. If you ever need to do any sort of complex query you will just have to write sql anyway. And typescript is only sort of static typing. These technologies are great for prototyping and building a v1 release to see i…

> typescript is only sort of static typing Can you elaborate on this?

It's progressively typed because it has to coexist with untyped Javascript code and libraries.

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#44
post #2

Typescript (nodejs) backends are not performant, and your ultra modern stack is going to just cause you issues going forward if you need to scale. Prisma is really bad too, slow queries and no flexibility. If you ever need to do any sort of complex query you will just have to write sql anyway. And typescript is only sort of static typing. These technologies are great for prototyping and building a v1 release to see i…

I’m not partial to Node.js backends for many reasons, primary being that I prefer batteries-included web frameworks and the choices are very limited in the JS backend world… But I have such a hard time believing that Node.js is inherently non-performant when there are so many counter-examples of large scale applications that do just fine on it. I understand that the single-threaded nature of JS can be a bottleneck fo…

> But I have such a hard time believing that Node.js is inherently non-performant when there are so many counter-examples of large scale applications that do just fine on it.

Like LinkedIn! Except that to make it performant they had to horizontally scale and then restart the server every N hours when they ran out of memory…

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#45
post #2

Typescript (nodejs) backends are not performant, and your ultra modern stack is going to just cause you issues going forward if you need to scale. Prisma is really bad too, slow queries and no flexibility. If you ever need to do any sort of complex query you will just have to write sql anyway. And typescript is only sort of static typing. These technologies are great for prototyping and building a v1 release to see i…

[deleted]

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#47
Why does 'modern' nowadays mean 'host everything on managed services' like Vercel or Netlify? Why is running your own database so frowned upon? Is *SQL/SQLite so insecure that a default password-protected setup can be pwned within minutes?

Managed hosting can give you a head start, but also increased costs. There are quite a few horror stories when it comes to billing.

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#48
post #20

I call my stack GETHAS: Golang + Echo + Templ + HTMX + Alpine.js + Supabase

Why Templ? What are the advantages over html/template? It seems to just recreate JSX in Go. I should add, I'm someone who heavily dislikes JSX and prefers SFCs.

I wanted to try out Templ and just stuck with it.

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#49
post #2

Typescript (nodejs) backends are not performant, and your ultra modern stack is going to just cause you issues going forward if you need to scale. Prisma is really bad too, slow queries and no flexibility. If you ever need to do any sort of complex query you will just have to write sql anyway. And typescript is only sort of static typing. These technologies are great for prototyping and building a v1 release to see i…

I'm fairly opinionated about this:

1. I agree, Prisma is not a great ORM. Drizzle is a better choice. It's close to the metal and when the abstraction inevitably leaks, it leaks towards the user using raw SQL

2. Modern JS is extremely performant. Look at any of the benchmarks for the new JS runtimes that have come out in the past 6 months (e.g. Bun / WinterJS / etc...). It approaches Go / Java in terms of performance.

3. Even the traditional NodeJS runtime has been optimized out the ass by Google. For example: JSON parsing has highly performant SIMD instructions under the hood. When a trillion dollar company puts billions of dollars behind a technology it will get fast.

4. There is no possible way that building your CRUD backend in Golang / Rust is a "faster" solution than just using React Server Components.

5. The vast majority of startups are IO-bound, not CPU-bound - so "fast" languages like Go / Rust won't be as relevant.

The benefits of Go (for most companies) only apply once your company hits an inflection point and starts to scale and starts to see the throughput that can really take advantage of a lower-level language.

If you're building a high-throughput infra company or something, then the things I've mentioned are less relevant.

Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

#50
post #38

Earlier quoted context omitted.

i don't agree at all. nodejs backends are as performant as you build them. the whole premise of node was async io, so if you're doing a bunch of blocking stuff then yeah, you're going to have issues. otherwise there's nothing innately non-performant about the platform. it's impossible to debate more without going into details on your performance issues. typical backend architecture for any platform these days is the…

I would not use prisma for anything until they fix https://github.com/prisma/prisma/discussions/12715

I wouldn't use find commands beyond the simplest Join. The beauty of Prisma is raw queries, because they're compiled and type-checked against your Entities. That's the whole appeal, IMHO.
Post reply on HN