Building the Same App Using Various Web Frameworks

Creating an app is one thing. What I want to know is what's the update experience like 3 years later when I haven't touched the code in forever and I'm getting a flood of dependabot notifications about critical vulnerabilities.

I'll just have vanilla thanks.

I started learning FastHTML but somebody on reddit mentioned htpy. In my opinion htpy+fastapi is awesome combo. I like the way htpy handles declaring html components.

http://htpy.dev

Building simple CRUD apps are often a single code-generation command in Phoenix/Rails/Laravel, and adding common features like Auth, Queues, Emails, File Uploads, etc. are similar.

The downside is that this is a stateful monolithic approach that requires a server running 24x7 and can break without some effort to cache and reduce the load on the database. They are also often memory-hungry frameworks.

The tradeoff for productivity is worth it in my view, for the vast majority of cases where it's just a small team of 1-3 developers.

Now do the same using Blazor Server (C#). For convenience use https://www.fluentui-blazor.net/ or https://mudblazor.com/ for your UI components.

It has it's compromises but it's great for just building stuff, with UI updates streamed to the client, no JS (or as much as you want), no extra API building just for the sake of your SPA. Note that I'm not talking about Blazor WASM.

If you're interested in working as a developer for corporations outside of the SF bubble (e.g. the other 80% that use Windows instead of macOS) it's worth checking out, especially for internal corporate stuff.

> As an anecdote, I had an easier time using Cursor + Claude to build the app in FastAPI and Next.js, and a harder time with FastHTML and SvelteKit. Since FastHTML is barely a couple weeks old (at the time of writing), its code and docs likely hasn’t made its way into the training data of most LLMs yet, explaining their limited proficiency with FastHTML.

In cursor settings, click features and then add the documentation URL for each framework or library you are using so they can be indexed.

It would be best if you did this regardless of how well trained a model is on certain code - it helps immensely.

FastHTML has markdown formatted docs which can be used by Claude, just add .md to the end of the URL:

https://docs.fastht.ml/ref/handlers.html.md

You can find markdown docs for most libraries on GiHub, where you can have Cursor index.

I suspect that with the increased use of LLM-aware code editors, single-page markdown-formatted documentation will become more common (even better would be if Cursor hosted an external vector db with up-to-date docs and tutorials for all the most popular libraries and frameworks).

Just a tip, one way to cut down on the Next.js and SvelteKit code would be to use the “actions” feature they both provide rather than manually creating API routes.

- https://nextjs.org/docs/app/building-your-application/data-f...

- https://kit.svelte.dev/docs/form-actions

Good points on code assistants effecting language/framework usage. Myself I've found that copilot will happily suggest usages that were deprecated 10 years ago and waste a couple hours of time.

I’m really interested in using FastHTML, but it feels like it’s baking and not actually production ready.

For example, the sample projects store passwords in plaintext if they even allow login, which most don’t.

I really wish there was a way to use the FastHTML fast tags in FastAPI, so that I could use their cool HTML generator, but have robust and reliable deployment and auth, and possibly migrate to FastHTML once it’s a more mature product.

First of all, this app is very limited to differentiate which stack is better and faster.

Second, it should consist of completely different programming languages like C#, Ruby, PHP, JavaScript, Python, Go etc. Hopefully I will do it one day.

Last, what's the end result?

> Given React and Next’s wider use and longer history, it’s likely most LLMs are trained on more React and Next code than Svelte code. Ditto for FastHTML. This could lead to coding assistants being more effective when working with and suggesting code for established frameworks such as FastAPI, React, and Next.js.

Yes, but also more stale code from old versions which use patterns that the community has for various reasons moved on from. I ran into a lot of trouble with deprecated patterns while teaching myself react last year with assistants on the side. React 17 and prior version patterns kept coming up all the time.

Love seeing this. Reminds me of the years of interest techempower provided with their scrupulous and thoughtfully evolving web framework benchmarks https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

Would be interesting to compare Remix.run in the mix? Feels like an interesting in-between NextJS and SvelteKit.

IMO the biggest hurdle in frameworks like Svelte or Next isn't the framework -- it's the language.

This type of app is a prime use case for something like LiveView or a Go framework. Just today I had the most marvelous experience using Tailscale's ACP, where I've changed the ACL and it instantly saved it. It was so fast I had to make sure it's not optimistic UI, and sure enough, 78ms round trip for the request.

Even if it was a FE-heavy app using SQLite in the browser, I wouldn't have used JavaScript. After months of Gleam, I am spoiled.

The days of JavaScript-because-we-have-to are thankfully over. JS is now only for when the flexibility is required.

nothing can beat the simplicity of Nextjs using the old page router. Try it, all you need for a starting point is a package.json (react, react-dom and next as dependencies), and a pages directory with a single index.tsx, no need to even install typescript or manually create tsconfig.json. And you can do multi pages or single page app or static generation. All other options can only either do web server or static generator, not both.

I didn’t expect to see Dundee United in a Hacker News post!

The first thing that jumped out at me was this:

    csv_data = [",".join(map(str, tbl.columns_dict))]
    csv_data += [",".join(map(str, row.values())) for row in tbl()]

Sigh. He's not "building the app". This code is wrong. It's not escaping the CSV properly, so embedded commas and similar control characters will result in gibberish output.

I'm just so fed up with this JS+HTML SPA framework demos where everybody thinks that stringly-typed programming is the only way to do things, where instead of using a proper library that actually encodes/decodes file formats properly there's this kind of quick & dirty script snippet that is basically broken under all but ideal conditions. ("It worked, once, on my computer, with toy data. Job done!")

I get it, this exercise is about comparing the essentials of different frameworks. But that comparison ought to include things that matter, such as correct handling of Accept-Language, safe escaping of data, sorting on date columns, virtualising lists too big to handle in one go, etc... That's what actually matters, that's what takes actual time when getting something to production. Not the folder structure or file naming conventions.

The author mentions "How will coding assistants influence builders?" but ChatGPT can spot this kind of error, and more: https://chatgpt.com/share/793e6353-817f-4765-ab33-f313190637...