Hacker News Reader

Comment by s4i | Hacker News Reader

> suggests choosing the least powerful [computer] language suitable for a given purpose

This doesn’t work for projects that are planned to live for years and we aren’t sure of the scope of it beyond the next few months.

You may feel you completed all the current features neatly with HTMX or whatever, but what happens when later your PM or designer asks your team to implement, say, a complex multi-step form with a bunch of frontend state and validations?

People downplaying the need for tools like React and Next.js don’t usually acknowledge that these tools are used to ensure long-term flexibility of your tech stack and to maximize the talent pool to draw engineers from. It doesn’t matter if your site is slightly less broken for the few people that turn JavaScript off in their browsers.

View on HN

> a complex multi-step form with a bunch of frontend state and validations?

HTMX can handle this perfectly.

"Frontend state" in the context of a form is...the form. Add as many hidden fields as you need, and you've captured the state.

Validation - no problem. The "backend" can choose what response it sends, and to where in the page. Your form fails to validate? Annotate the failures in the markup, send back a fragment that replaces the fields that fail, all good.

It's also not an all-or-nothing proposition; you can have Javascript alongside HTMX. Add "hooks" into htmx.load(), and they'll be fired every time a new fragment comes back; I like to use querySelectorAll to look for elements marked up with whatever attributes are applicable, and then manipulate them in whatever way I need (e.g. to turn markup into pretty/interactive charts).

Are you recommending Next.js for its longevity? My experience over the last 18 months is that every new version introduces breaking changes. I wouldn’t want to come back to a Next.js project in 5 years and have to deal with migrating to Node.js v32 and whatever Next.js has broken in the meantime.

Don’t get me wrong, I’m not a Next.js fan either. Could’ve widened my list of examples to any SPA libraries and server-side JS frameworks. I just wanted to highlight the issue with the analogy: unlike some criminal a police officer is using force against, the nature of issues to be tackled in most software projects will keep changing.

that is going to be your experience no matter what you use if you want some horrible bloated frontend framework, or in this case, a horrible bloated framework for a horrible bloated front end framework.

will we get a next.js framework to make it easier to use next.js to make it easier to use react to make it easier to use javascript in the near future?

please for the love of god stop enabling these people.

I haven’t had similar issues with React, and I been using it much longer - Next.js is a special case.

React itself has been pretty smooth, and I've been using it since 0.14. Not on any massive projects mind you, but still.

Better choose ExpressJS then. They still haven't quite made it to 5.0 since they started in 2014.

Long term flexibility is a very surprising way to describe a JS stack. They are easy to build in, but there is nothing robust about the ecosystem. When in 5 years a PM asks me to add that simple multi step form, I'll probably have to tell them it's blocked by replacing deprecated dependcies and our validation library doesn't support our new element types so we need to rewrite all the validation across the site to use a new library... man I feel a burnout coming on.

My counter-argument is that the simplest tool has the largest chance of not breaking over long periods of time. I have dynamic websites I built 10 years ago that still run almost untouched because I used the simplest stack possible.

Contrasting that, in the commercial software world we rebuild from the ground up in 1-5 years, and we aren't even building complex things. Same level of interaction, but a stack that has an enormous complexity and web of dependencies and moving targets that absolutely require a steady hand on the maintenance wheel. Your examplen scenario is not that scary, we have been building that kind of UX long before React and friends.

Your final comment about people who disable javascript is disappointing, but an opinion you likely share with many PMs. I would recommend a look into accessibility, and also try to see why people might advocate for graceful degradation.

When trying HTMX, I decided to use Tailwind for layout. Tailwind requires npm and Node to work. It was my first experience with Node. I already had some Node version installed on my machine. Running Tailwind gave some vague "Unexpected token ?" error and nothing else. After I bumped Node's version, it worked. Sure not using the latest versions of the tools is a bad idea, but the fact is, something from the JS ecosystem was basically the only thing in my stack which broke immediately (with a vague error, nothing like "hey, old version of Node!")

They have a standalone version of tailwind that doesn't use node.js/npm.

https://tailwindcss.com/blog/standalone-cli

It's not as full featured, but it's pretty good frankly for what I do with it.

There are painpoints in working with ”modern web stuff”. But:

> My counter-argument is that the simplest tool has the largest chance of not breaking over long periods of time. I have dynamic websites I built 10 years ago that still run almost untouched because I used the simplest stack possible.

My whole argument was that any reasonable frontend stack can work if your requirements stay constant. But let’s say in a startup you definitely don’t know on day one what you’ll need to implement. So it’s understandable why people pick something that’s popular and capable.

Oh for sure, and in a commercial setting your other point about being able to hire people is just as important. Don't get me wrong, React and friends are totally fine tool choices for teams and projects of significant (or loosely defined) scope.

To use his own "butter knife / cheese knife / lightsabre" example, it's like if I want to butter some toast, I should choose the butter knife, right? Oh but now I want to cut that melon and the butter knife is the only knife I have because I chose the least versatile/powerful knife because they told me to.

yagni: you add a library to help with that more complicated feature when you need it

nothing wrong with using htmx for the relatively dumber parts of your app then using something like preact or alpine when you need more reactive behavior

YAGNI

Ok, why then do we pick Postgres for many projects that could be build on something simpler?

The ”YAGNI” motto usually needs to be combined with ”don’t paint yourself into a corner”.

What's simpler than Postgres?

SQLite, plain localStorage in the browser, the file system for desktop apps, …?

You're going to definitely need a schema, so you want a SQL database, which leaves SQLite and Postgres. The only difference between the two is one requires a server. If that's too inconvenient, SQLite is a solid choice.

> .The only difference between the two is one requires a server.

Lol, no. Postgres has tons of features that SQLite lacks.

Except we're talking about Postgres being more complex than SQLite, please follow the thread.

Regardless of the context, your statement that the only difference between SQLite and Postgres is that one requires a server is plain wrong. That would be like discussing Emacs being more complex than Vim, and then saying, "The only difference that Emacs has from Vim is that Emacs typically uses a client/server architecture".

How often have you seen desktop apps pick postgres over sqlite or the file system?

Reply on news.ycombinator.com