Hacker News Reader

Comment by likortera | Hacker News Reader

Something it took me some time to understand, and I feel very dumb for that, is that with these modern "SPA" tools such as Next, you can still do quite easily dumbed down non interactive websites that do traditional form posts. It works perfectly fine.

The other way around, using the dumber tools and trying to do highly interactive apps, is a lot harder.

That might be part of the reasoning most things are nowadays built with these spa like frameworks.

Not that I agree. Just trying to understand.

View on HN

I don't know, sometimes doing very simple concepts in modern SPA is much harder than with traditional technologies.

Have you ever had to debug non-functional SSR in React or Next.js? I very much doubt SSR is simpler than plain HTML or PHP or AJAX.

After all, SSR is just rendering plain HTML. It doesn't have to be that complicated full of gotchas and quirks like it is in the React world.

But Nuxt/Next SSR is not "just rendering HTML". Funny how htmx threads always revolve around largely dishonest arguments.

"I very much doubt SSR is simpler than plain HTML or PHP or AJAX"

What does that even mean?

Correct - SSR the way Next does it is basically the same as HTML+AJAX but simpler to reason about as an implementer and, if you use Typescript, type-checked and far less likely to be buggy.

Yes, I agree. The "minimum complexity" is way higher this way, even for simple things.

But my fear is that when things get complex in the frontend, at some point there is a peak point at which these tools become easier and the more traditional ways more difficult. And it is not easy for me to day where that peak point is.

It's possible to agree with or refute you based on the definition of the definition of "highly interactive apps". But I can qualify it this way. If htmx (maybe with hypertext or alpine.js) is enough for your app then I would say it's much easier to do it with htmx than a js framework. The frameworks come with the kitchen sink and are not trivially easy to even keep running due to node updates, bundlers etc. They are also very complicated and as with every framework, you start to see the limitations as you start doing more complicated stuff or go out of the happy path. Another way I can qualify it is, I can write a semi interactive website with htmx at my current experience level with Javascript but I can't do that with most frameworks. Where you are probably right without qualification is when the programmer/team is already using said framework and has experience with it.

An issue with Next is that it still loads a complete React app after delivering it pre-rendered.

Astro might solve that with selective hydration.

the js ecosystem is built on romance. what this article describes is not even the tip of the iceberg for a large application.

The JavaScript ecosystem is insanely successful, even though the language, node_modules, and the entire process of building a SPA are disorganized and clearly poorly designed. What makes it successful though is those flaws exist because individual developers in aggregate have decided that they’re worth the trade off. All the JavaScript killers seem more precisely designed, but that’s only possible because they haven’t been shoe-horned into thousands of different use cases they weren’t meant to solve. Those edge cases add complexity and rough edges, but make for a more practical toolset in the long run.

For a large interactive single page application you probably still want to use React/Vue or similar.

But for a small, simpler app, maybe one you are working on alone, only having a “backend” is appealing.

I’ve been using Alpine on a project recently and removing the overhead of a frontend to manage has made progress faster.

Reply on news.ycombinator.com