Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

isultan.bearblog.dev

Post reply on HN
Print view View original

71–80 of 117 posts

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

#71

Post by kyruzic »

aranchelk wrote: post #40
kyruzic wrote: 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?

The type any exists. The type unknown exists. The types actually have no meaning at runtime.

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

#72

Post by stefanos82 »

throwitaway1123 wrote: post #61
SantiagoElf wrote: post #33

Earlier quoted context omitted.

Nodejs is slooooooooooooooooooooooooooooow. [0] [0] - https://www.techempower.com/benchmarks/#hw=ph&test=composite...

What do you think about how well uWebSockets.js performed in the TechEmpower benchmark? Just js is admittedly experimental, but it has the fourth highest score, and the highest score of any non-Rust framework as well which I found interesting. Elysia (a Bun framework) did pretty well too. Deno would have probably scored well too (it uses Rust's Hyper crate under the hood), but they're only running a single instance o…

Just go to its repo https://github.com/uNetworking/uWebSockets.js and see the uWebSockets submodule dependency that it's written in C++ (90.9%) and C (6.8%)...so sure, a "fair" comparison indeed with vanilla implementation!

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

#73

Post by throwitaway1123 »

stefanos82 wrote: post #72
throwitaway1123 wrote: post #61

Earlier quoted context omitted.

What do you think about how well uWebSockets.js performed in the TechEmpower benchmark? Just js is admittedly experimental, but it has the fourth highest score, and the highest score of any non-Rust framework as well which I found interesting. Elysia (a Bun framework) did pretty well too. Deno would have probably scored well too (it uses Rust's Hyper crate under the hood), but they're only running a single instance o…

Just go to its repo https://github.com/uNetworking/uWebSockets.js and see the uWebSockets submodule dependency that it's written in C++ (90.9%) and C (6.8%)...so sure, a "fair" comparison indeed with vanilla implementation!

Ok...Node is itself written in C++. The V8 and JavaScriptCore JS engines have no concept of a server (they were designed for web browsers), so under the hood JS runtimes implement servers in a lower level language capable of interfacing with Linux syscalls. Bun uses Zig, Deno uses Rust, Node uses C++, etc. I don't think that necessarily makes this an unfair comparison. The database drivers used in these benchmarks are also usually written in C++. Look at the repo for the native Postgres binding for Node: https://github.com/brianc/node-libpq

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

#75

Post by willsmith72 »

rlt wrote: post #68
brink wrote: post #42

Earlier quoted context omitted.

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

Sure, but you can enable TypeScript options and institute lint rules prohibiting use of untyped code.

i love typescript, but that's still not the same as static typing. imagine a full stack typescript app with a blog type

type Blog = { name: string }

everything works fine until you decide to refactor "name" to title. you update the backend and typescript code and deploy the change

type Blog = { title: string }

user john never closes his browser and leaves your website open. he clicks on a new blog post. his client typescript expects a name, the server gives a title, and crash, "Cannot read properties of undefined".

i still choose nodejs backends, but you obviously have to keep in mind it's not statically typed. same with "any", my coworker could take my blog and modify it. it's preventable, but with large teams and codebases still prone to error.

(blog as any).title = { summary: 'blah', full: 'blah blah blah' }

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

#77

Post by rohan_ »

kyruzic wrote: post #19
zeroCalories wrote: post #16

Earlier quoted context omitted.

Many companies are not throttled by server language performance. Performance in many cases will depend on your database, geolocation, and caching techniques over nodejs vs go. Nothing wrong with prioritizing developer experience.

I do agree with this, but I'd argue the developer experience of nodejs with Typescript is far worse than that of rust/go

React Server Components is the best possible DX for a react backend

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

#78

Post by orwin »

aidos wrote: post #67
zer00eyz wrote: post #60

Earlier quoted context omitted.

>> 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?

There’s numpy in the middle, so bits are outside python. The vast majority of the code is Python though and the performance gains come from being strategic about the architecture. My point is that for most usecases you can go a lot further by looking at the code that’s running rather than the language that’s running it.

I think python have the best libraries you can buy, and that makes python a very strong choice if you do not suffer the NIH syndrom or do not need extremely fast code (python is fast enough now).

One big issue i have though: the lack of easy multithreading reduce your possibilities, or at least limit your creativity: you will often choose to use async/await (and sometimes use signals) rather than use producer-consumer designs, which are often the optimal solutions.

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

#79

Post by bcaxis »

kyruzic wrote: post #14
kossTKR wrote: post #10

Earlier quoted context omitted.

This sounds weird to me. What kind of scale / traffic did you have? Must be incredible read write heavy with millions of users? I'm saying this because i myself have, and lots i know, have launched production sites with 100s of thousands of users on ready-made stacks like, Laravel, Rails, Flask (Php, Ruby, Python). But it's my impression that these fall short on millions of users and enormous concurrent traffic, but…

That's why you shouldn't use slow backend technologies in the first place because you get to the point where you need preformance and it's impossible because your limited by extremely slow runtime you chose initially because it was flashy (not even easier to developer for) when you could have just chosen something better from the start. Simple crud apps can get by fine with those technologies, but in the future I'd s…

Making stuff faster is relatively straightforward engineering. Optimisation is a favored past time of many engineers.

Getting stuff that people value enough to pay for, to make money, is the hard part.

Any friction you put into the value creation process because "optimizing for future problems" is just doing it wrong.

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

#80

Post by Fire-Dragon-DoL »

rlt wrote: post #25
kyruzic wrote: post #11

Earlier quoted context omitted.

Go is perhaps the simplest language to learn there is. It's almost impossible to not get it to work because it has so few things you can actually do. And nodejs only preforms well in hello world benchmarks, real world applications are nothing like that. Once you start having to manipulate large arrays or do any large amount of math nodejs preformance goes into the dumpster.

> Once you start having to manipulate large arrays or do any large amount of math nodejs preformance goes into the dumpster. We’re talking about web applications, no? You probably shouldn’t be manipulating large arrays or doing large amounts of math directly in your web application server. That should be isolated in some type of service or worker, which could be written in another language. Or maybe there’s a NumPy-l…

Any large query result in a large array, so I would disagree on that point. Web apps deal with fairly big data structures, if nothing due to orms.
Post reply on HN