Live data from Hacker News

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

isultan.bearblog.dev

111–117 of 117 posts

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

#111

Earlier quoted context omitted.

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 sound ~unhinged~ (edit: "unhappy" is more like what I was thinking; pardon the negativity) with this unprovoked rant about the reasons you assume people choose a technology.

It would be refreshing to me for someone to suggest we at least evaluate HTMX on a new project before going straight to the Next.js or Remix behemoths where we'll have 45min builds pulling in thousands of NPM dependencies over half a million files in node_modules.

Edit: I was also thinking it would be even more refreshing if people focused on web standards and asked whether or not they actually need a trendy framework.

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

#113

Earlier quoted context omitted.

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 sound ~unhinged~ (edit: "unhappy" is more like what I was thinking; pardon the negativity) with this unprovoked rant about the reasons you assume people choose a technology. It would be refreshing to me for someone to suggest we at least evaluate HTMX on a new project before going straight to the Next.js or Remix behemoths where we'll have 45min builds pulling in thousands of NPM dependencies over half a million…

45 minutes! Why are you doing cold builds like that? That's not a problem with Next.js.

I mean, yeah, you have to do those sometimes, but they should not be blocking midday deploys.

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

#114

Earlier quoted context omitted.

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 sound ~unhinged~ (edit: "unhappy" is more like what I was thinking; pardon the negativity) with this unprovoked rant about the reasons you assume people choose a technology. It would be refreshing to me for someone to suggest we at least evaluate HTMX on a new project before going straight to the Next.js or Remix behemoths where we'll have 45min builds pulling in thousands of NPM dependencies over half a million…

> before going straight to the Next.js or Remix behemoths where we'll have 45min builds pulling in thousands of NPM dependencies over half a million files in node_modules.

You sound unhappy as well, and you also sound like you're doing something terribly wrong here.

My experience with people following the HTMX hype is backend developers annoyed by JavaScript not being perfect and node_modules size.

node_modules is never that big, and even if it is it's not a problem as big as maintaining complicated (i.e. not trivial) projects with these tools.

At the end of the day it depends mostly on your skills and the requirements for the project you're working on. As I said if you have some UX experience and you care about loading states, page transitions, animations and in general the little details then something built with these tools will be unmaintainable by anyone other than the person that implemented it in the first place.

node_modules too big? so what? that's not all of it shipped to the browser and I have plenty of space on my computer. A mess of html attributes, logic split between jquery, backend, html attributes, etc? Now that's a bigger problem.

And why I said "hype"? Well, because people suddenly see it as the greatest thing ever because some youtubers/podcasters made it popular, when there've been similar solutions for ages and nobody cared (i.e. Unpoly). But if the right youtuber talks about it, then boom! Everyone is saying everything should be done this way from now on.

As I said in another comment, the idea is great and I like it. But as the creator of the library said MANY times: It's not a replacement for component based frameworks. It's a great tool for the simpler use cases where react/vue/etc would be overkill.

My rant is about people acting as this is the future for everything, which again, the author of the library itself says it's not, and he's a smart guy.

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

#115
Author's code is vulnerable to timing attacks and probably others as well.

This is why people should use established backend frameworks such as Laravel/Django/Rails if they really want to focus on their product and not on reinventing the square wheel.

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

#116
post #9

To me this is a valuable write-up because it (a) clearly describes paper cuts accumulated when building with unfamiliar tech and (b) showcases how much nonsense developers are willing to tolerate in the name of "new" or maybe "speed". Some of the paper cuts described include: - Inexplicable interaction between the data layer and a hosting service's environment variable - Migrations that don't work reliably - Cron job…

Thanks Dave! That's a great summary of my experience. Most of my experience has been with a more "boring" stack, so I was interested in trying some of the more "hyped" technology choices, to see if I was missing out on anything.

Yeah, makes sense.

I’m also in a phase where I get to start a lot of new low-stakes web projects, so I’ve made a point of adopting at least one new-to-me tool for each. I love typescript, and am generally happy with modern front-end tooling, but the node back-end ecosystem drives me bonkers — too many paper-cuts from too many tools along the lines you’ve documented here — and has me regularly retreating back to Python or Ruby land.

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

#117
post #95

Earlier quoted context omitted.

Do you eventually have to move off pocketbase? Looks like it only supports SQLite, and therefor obviously can only run a single server instance. How do you plan to migrate off it in the case that you have higher availability or traffic needs?

Here are some suggestions if you ever need to scale. https://github.com/pocketbase/pocketbase/discussions/395 Never happened to me. SQLite is faster than most people think. When you hit the limits of sqlite, chances are high that you can afford to use one of the scaling solutions mentioned above. Here are some benchmarks: https://github.com/pocketbase/benchmarks?tab=readme-ov-file

Thanks, but here I'm thinking more about availability than anything else. One single instance of a service doesn't seem great
Post reply on HN