PocketBase + Go + HTMX
LOL. The HTMX hype is worse than every other fashionable framework. Only backend developers like it. As soon as you have to do anything minimally complex it's just terrible.
Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
101–110 of 117 posts
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#102Vercel is very cool, but I wish we made more progress in technology that is easy to self host than a service.
That won't happen. That's not a priority for them and goes against their business interests.
In fact, there are already many intentional limitations that makes Next a very bad choice if you're self hosting.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#103Earlier quoted context omitted.
LOL. The HTMX hype is worse than every other fashionable framework. Only backend developers like it. As soon as you have to do anything minimally complex it's just terrible.
Yeah, much easier to setup an entire build pipeline with 1,000 NPM dependencies to render a form.
If all you have to do is render a form you don't even need HTMX. IF your project is just about rendering forms then fine.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#104Earlier quoted context omitted.
LOL. The HTMX hype is worse than every other fashionable framework. Only backend developers like it. As soon as you have to do anything minimally complex it's just terrible.
oh, idk https://htmx.org/essays/a-real-world-react-to-htmx-port/
From what I can see from the demo that's a super simple application. It might make sense to use a tool such as htmx/unpoly/hotwire/etc.
What I don't get is people just blindly "following the hype" (as with anything else) and assuming it's a replacement for client side frameworks (react, vue, etc) for anything you might need out there. You already said this several times in some Podcasts I listen to, so I don't blame you. But people are just "hey bro just use HTMX and Go and done". And that might be fine if you're a backend developer that doesn't like JavaScript and have a very simple use case and probably don't have high UX standards or picky designers chasing you with every animation, loading state or performance issue.
There are many projects out there with pretty complex UX logic where this will just not work, and if it works the end result is going to be much harder to maintain. Let's not take into account finding people willing to work with these tools (already happened to us where we had to move a Rails/Hotwire project to Rails/Inertia) because no one could work on the frontend, initially created by a backend dev and that became such a mess not even him could maintain it anymore).
But again, it is not the technology to blame (it's great!), it is the usage of it. And people can misuse anything, as they misuse react/vue/etc when they're building just a landing page.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#105Earlier quoted context omitted.
> 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.
Can you give an example? I just think that no matter what programming language or framework you're using, if you are querying for giant arrays through an ORM and passing them through an API result to a web app, it's going to be slow.
There are other kinds of solutions for this problem like breaking up the data into chunks and only returning the necessary data. Maybe it's a DB optimization where you can add indexes. Or caching the result of your ORM query.
I've never seen any web app written with any tech that was snappy while making requests for large amounts of data and waiting for it to come back in one big honkin array.
> Web apps deal with fairly big data structures, if nothing due to orms.
Perhaps due to using ORMs unnecessarily and/or inefficiently and failing to drop down to SQL when needed.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#106Earlier quoted context omitted.
I do agree with this, but I'd argue the developer experience of nodejs with Typescript is far worse than that of rust/go
Agree. JS/TS is not a good environment for large software projects maintained over a long period of time. I'm not 100% convinced Rust is either, yet. cargo seems to be a dumpster fire. Build tools generate TB of mystery disk bloat. Obsession with async... hopefully these issues can be resolved.
> JS/TS is not a good environment for large software projects maintained over a long period of time.
VSCode disagrees with you. Its codebase is fascinating btw.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#107Typescript (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.
> New team lead got hired, wasn't familiar with Rust, said we'd have trouble hiring Rust devs, and threw it all out.
Depending on the company you work for, this was probably a good call on their part.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#108Earlier quoted context omitted.
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.
Can you give an example? I just think that no matter what programming language or framework you're using, if you are querying for giant arrays through an ORM and passing them through an API result to a web app, it's going to be slow. There are other kinds of solutions for this problem like breaking up the data into chunks and only returning the necessary data. Maybe it's a DB optimization where you can add indexes. O…
It's hard to think about an example, this is very application specific. But there are background jobs and that's where a big array could be manipulated
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#109Earlier quoted context omitted.
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 ty…
TypeScript is definitely statically typed. It is not a 100% “sound” type system, but very few languages actually are (Haskell, Reason, etc)
And in your example of loading data from a server, if you have appropriate lint rules set up your editor and linter will warn you when you pass “any” typed data (such as that returned by fetch’s response.json()) to something expecting another type. You can use something like zod or yup to validate the data is the type you expect before passing it the rest of your typed code, thereby containing possible type errors to a known location where you can gracefully handle it.
This is a problem with any language that accepts typed data from an external system, certainly not unique to TypeScript.
Re: Developing a Modern Full-Stack Application: Choosing the Right Tech Stack
#110Earlier quoted context omitted.
Can you give an example? I just think that no matter what programming language or framework you're using, if you are querying for giant arrays through an ORM and passing them through an API result to a web app, it's going to be slow. There are other kinds of solutions for this problem like breaking up the data into chunks and only returning the necessary data. Maybe it's a DB optimization where you can add indexes. O…
It's hard to think about an example, this is very application specific. But there are background jobs and that's where a big array could be manipulated
Probably still need to stream or chunk the data instead of dealing with giant arrays to get decent performance. That's not a language/platform issue.
I recently had to process and aggregate metrics for 5 million rows of user data (a few GBs) on my MacBook with Node.js. By streaming / iterating over the items without loading them all at once it chewed through them all in a few seconds. ¯\_(ツ)_/¯ And it's single-threaded (except for I/O offloaded to threads -- I'm talking about the calculations).