if only there was a network stack for it, we could use TempleOS + HolyC as a Lambda in AWS. These things are useless without data or gravitas behind them.
Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
51–60 of 117 posts
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#52Typescript (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?
typescript compiles to javascript and you run javascript with deno, nodejs or whatever javascript server you choose. Typescript helps while you develop, but at the end is just javascript.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#53If this article is to be believed, they are storing user passwords in plaintext.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#54Earlier 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…
Nodejs backends are not "as performant as you build them" nodejs is slow! This is an undeniable fact. If you ever have to do anything computationally intensive, which every backend at some point will nodejs will become the bottleneck.
I repeat
> 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.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#55Typescript (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…
I only use TS on the frontend, so less opinionated about some of this.
I’d love to see some of the codebases where people complain about performance so I could profile them myself. Would put money on being able to improve the situation by orders of magnitude without switching stack.
We use Python on the backend of our web app for realtime image recognition and it’s fine because we’ve been thoughtful about data structures and algorithms.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#56Typescript (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…
Sounds like you're experiencing BAS, Bad Architecture Syndrome.
Application servers should scale out, sure you might need a few more for Node than Rust, but is that really where the issue lies?
You wouldn't implement Postgres, Ceph, QEMU or the kernel in Node... But the CRUD part of most applications will be fine in "any slow language"
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#57Typescript (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 just built an app with Rust and Svelte with ~25k LoC, the app was solid, and working on it was a joy. New team lead got hired, wasn't familiar with Rust, said we'd have trouble hiring Rust devs, and threw it all out. We're now building a Python / ReactJS app from scratch.
For what it’s worth, I’d be much more interested in working for your company using Rust and Svelte compared to python and react.
If you need someone with experience working with Rust and Svelte, I’m looking for work and value making quality decisions like you did. Now you can point to at least one dev who has the skills your team lead was concerned about finding.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#58Earlier quoted context omitted.
I can't believe AWS is considered boring technology now. I don't know whether to feel old or cry on my dedicated servers.
It really depends on which parts of AWS you're using. Spinning up a bunch of EC2 instances and treating them like colo'ed servers has pretty much always been boring (other than the excitement of not having drive to the DC when you need to reboot something).
It’s boring at 2-4x the price of the same boring thing elsewhere though. If you don’t use the E in EC2 then why go with AWS?
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#59Typescript (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…
>> 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.
https://www.techempower.com/benchmarks/#hw=ph&test=composite...
I like JS but lets not blow smoke up anyones ass here. Your not picking node or its faster safer cousin bun for server speed. You're picking it because you can keep your engineering overhead to a smaller number. Your picking it because you need to generate pages out of your SPA like app.
> 4. There is no possible way that building your CRUD backend in Golang / Rust is a "faster" solution than just using React Server Components.
Spend a month with SQLC and writing blood and guts API's in go. Your gonna realize that the slight slow down in finishing the feature code is more than made up for in finishing testing, ease of deployment and a million other things that you skip by NOT using a JS backend.
>> 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.
This is some holdover thinking from PHP vs JAVA days that isnt true when comparing node/ruby to go/rust ... Im going to leave python out because you may have OTHER reasons (existing bindings to C ...) to head in that direction.
>> If you're building a high-throughput infra company or something, then the things I've mentioned are less relevant.
Maybe this is true. But I worry about the long term stability and paintability of anything written in JS. So much flavor of the month and then poof, off to the next thing, it IS a concern.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#60Earlier quoted context omitted.
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…
I only use TS on the frontend, so less opinionated about some of this. I’d love to see some of the codebases where people complain about performance so I could profile them myself. Would put money on being able to improve the situation by orders of magnitude without switching stack. We use Python on the backend of our web app for realtime image recognition and it’s fine because we’ve been thoughtful about data struct…
>> We use Python on the backend of our web app for realtime image recognition
I have no qualms with python. But Python is the high fructose corn syrup of programing languages... It's in everything.
It's dead easy to write out c bindings so from ML to Math to big data tasks it forms the glue to a lot of things.
My question is: is your real time image processing IN python or in C that python calls out to?