13 ms·

Building the same app using various web frameworks

161 points by 7d7n 2y ago

ledgerdev 2y ago
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.
- deleted 2y ago
  [deleted]
- deisteve 2y ago
  have you tried ClaudeDev? I find its very good. Cursor is quite good too. I find myself not being able to write off code-gen tools anymore. They are quite good and getting better and cheaper. I'm actually a bit worried for software development occupations especially frontend.
- tiltowait 2y ago
  Doesn't surprise me. Copilot often suggests nonexistent functions in libraries I've written, which code it's seen many times. Though it's occasionally useful, it probably doesn't save me any time overall. If work didn't pay for it, I certainly wouldn't use it.
jakelazaroff 2y ago
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-fetching/server-actions-and-mutations https://nextjs.org/docs/app/building-your-application/data-f... - https://kit.svelte.dev/docs/form-actions https://kit.svelte.dev/docs/form-actions
- 9dev 2y ago
  In SvelteKit (don’t know about Next.js), this also makes for a nice, gracefully degrading JS-enabled form experience for the user, while always also working for those running script-less. You’ll automatically get partial validation, loading states, error handling, and so on, as opposed to API routes where you’ll need to do that on your own.
- TmpstsTrrctta 2y ago
  I had success in a project using Sapper, a precursor to SvelteKit, with using an early version of this called server routes. On server routes, you could define a JSON api which could also have its data statically exported. On the other hand, I’ve seen server actions abused in large production apps leading to lots of sprawl when handling similar data patterns. Everything becomes an action and it becomes difficult to update the system cohesively or get data externally. I do feel there could possibly be a bit more magic with Server Actions to generate actual API endpoints. I’m a fan of FastAPI’s handling of pulling path and body variables into an endpoint, typing the params and then accessing them in Next.js on the other hand feels more burdensome. I could very well just be not using it correctly.
oDot 2y ago
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.
- seanvelasco 2y ago
  the reason I use JS is def not flexibility, it's to enhance the usability and interactivity of my app. even for my Python and Go web apps, I still inline JS to achieve the functionality I want. examples: client-side routing, pin the scroll to bottom, mutating classList, etc
  - salomonk_mur 2y ago
    Yeah, that ability to improve usability beyond the basics is what he means by flexibility I think. I agree with that sentiment. I can now build decent, working websites in something like Streamlit without touching JS (even if JS is being generated behind the scenes).
  - oDot 2y ago
    Gleam compiles to JavaScript, so JS is not needed for that extra frotnend flare. The flexibility to sprinkle some code here in there is definitely unique to JS
fareesh 2y ago
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.
- stavros 2y ago
  What kind of web app doesn't require a server running 24/7?
  - mianos 2y ago
    'lambda' apps. Do people still use them for full production systems? We use them a bit for ancillary things but TBH, if you have some k8s or similar, solution, it's maybe not worth it to not use a standard container deployment environment that everyone knows.
    - halfcat 2y ago
      > lambda apps Yes, SST [1] uses lambdas heavily but makes it more seamless and less visible, just the place your code runs. I’ve also found Azure Container Apps to hit the right balance. It’s kubernetes under the hood, which you don’t have to mess with at all, except that it can use KEDA [2] scaling rules to scale your containers to zero, then scale up with any of the supported KEDA scalers like when a message hits a queue. [1] https://sst.dev/ https://sst.dev/ [2] https://keda.sh/ https://keda.sh/
      - ledgerdev 2y ago
        Except when you scale to zero, you get a 23+ second cold start time on .net apps. Google cloud run pulls some black magic to get ~3 second cold starts on .net apps, and ~500ms for golang/python/native apps.
mlboss 2y ago
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 http://htpy.dev
- prabhu-yu 2y ago
  Thank you for the link!
- _AzMoo 2y ago
  Why would you use fastapi if you're rendering with htpy, instead of just using Starlette?
  - ledgerdev 2y ago
    I would like to know this also.
  - riezebos 2y ago
    I've used FastAPI, but haven't done a lot with Starlette directly. If you are building a full stack app, I can imagine the integration between FastAPI and Pydantic can make it easier to work with the data that you might want to render in the HTML that you generate using htpy?
    - _AzMoo 2y ago
      htpy is just server-side rendering of HTML. Your routes are returning strings instead of structured data, so from the perspective of responses you're not going to be using Pydantic at all. That doesn't stop you from using it to validate objects you're passing around in your server, but I personally wouldn't do that because Pydantic can have a pretty hefty memory footprint. I've seen over-reliance on pydantic lead to plenty of OOMKilled errors. It's a bit different for requests though. FastAPI will allow you to define your request schema (application/json or application/x-www-form-urlencoded) and validate it using pydantic, but starlette doesn't do that OOtB. It's trivial to implement though, and if it were me I would probably choose to do that rather than deal with FastAPI's inflexibility.
daft_pink 2y ago
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.
- halfcat 2y ago
  Have you tried htpy [1] with FastAPI? It strikes me as that “cool HTML generator” as a standalone library. [1] http://htpy.dev/ http://htpy.dev/
- rasmus1610 2y ago
  First, just because an example app stores the password in plain text, doesn’t mean you have to do the same. Hashing a password isn’t really that complicated. I wrote on how to implement a simple login system in FastHTML [1] Second, you can use fast tags in other python projects. Import it from fastcore and call the „to_xml()“ function on the fast tags. This will convert it to HTML [1] https://blog.mariusvach.com/posts/login-fasthtml https://blog.mariusvach.com/posts/login-fasthtml
- jph00 2y ago
  The reason the FastHTML bare-bones from-scratch auth example is bare-bones is to show you the minimal pieces that need to be built if you want to do auth from scratch. That doesn't meaning doing it from scratch is a good idea -- it's shown for folks that have the need for something fully custom. The docs walk you through how to use OAuth, which is probably a better idea for most folks, especially for beginners: https://docs.fastht.ml/explains/oauth.html https://docs.fastht.ml/explains/oauth.html (I'm the founder of the FastHTML project.)
  - daft_pink 2y ago
    Just want to say thanks for introducing me to HTMX. I know a bit of react, but as a more backend/data focused person HTMX seems better way to go and have way less breaking changes as these frontend frameworks are constantly changing the way they manage state and everything I've written has to be rewritten every few years. It's an awesome idea to just serve html where there aren't constant breaking changes. I think most projects have very bare-bones examples. I just need to be able to find a course on udemy with a fully production ready example with things like managed databases where a service is doing backups of the db and I don't lose data, auth pathways for creating users, updating passwords, and code that securely segregates things by user, scalable, deployment and sanitizes queries to protect against injection attacks to get an idea of how someone else would do it and have the confidence that I'm not building something that is easily hacked. I think FastHTML will quickly get there, because it's built on starlette and gunicorn that many production systems already use, but I'm coming from react and I'm not super familiar with these.
jiggawatts 2y ago
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-f3131906378c https://chatgpt.com/share/793e6353-817f-4765-ab33-f313190637...
- spencerchubb 2y ago
  You're focusing on the wrong aspect of the post. This post is comparing web frameworks, not showing how to build a correct csv handling app.
  - jiggawatts 2y ago
    End-to-end correctness matters and should be a key deciding factor when choosing a web framework. Some frameworks make this easy, leading people to fall into the pit of success, other's make it very difficult, and it takes eternal vigilance starting the day after the Hello World demo. E.g.: Most of his demos use mixed languages (Python+JavaScript). This architecture leads to madness. There are endless subtle differences between how any two languages represent data, what they can and can't express, and whether they agree on things like data validation regex syntax or not. A proper comparison would cover issues such as internationalisation, async, data streaming[1], dependency injection, client and server validation that's kept in sync, authentication and authorization through the layers, etc... [1] Sure, he's got a toy use-case of CSV files, but CSV files can be huge! Most JS frameworks and Rest APIs will process such tabular data as giant blobs of JSON as a single response. They can't stream, they can't handle paging or windowing, or if they can, you have to "wire that up" on the client which gets complicated rapidly. Do that! That's the demo that interests me. Not an incorrect script that will run out of memory and crash the server if you process a file big enough to be useful. Too much work for a quick demo? Well, yes, that's my point! It shouldn't be.
apitman 2y ago
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.
- adamhartenz 2y ago
  Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowing, and not having vulnerabilities are two very different things.
  - 8n4vidtmkvmk 2y ago
    Having a very tiny attack surface helps. 30 lines of JS is unlikely to have a critical vulnerability compared to 100k lines of random libraries.
    - threatofrain 2y ago
      Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).
  - Joeri 2y ago
    I think a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.
    - Juliate 2y ago
      Yes. A higher risk of SQL injection too, also. Or of brute force attacks/scans, but those are often not managed at the app/framework level anyway.
nnx 2y ago
Would be interesting to compare Remix.run in the mix? Feels like an interesting in-between NextJS and SvelteKit.
- Flam 2y ago
  You mean react-router right?
  - 0xblinq 2y ago
    No, I think he meant the one taking the nap.
- seanvelasco 2y ago
  Remix introduced me to data loaders and actions. when I used SvelteKit, the transition was easier. Next.js doesn't offer an ideal solution to the problem of data loading back then despite being a meta framework. that's why we have apps that use useEffect to fetch data. Solid.js is just perfect in every way. Docs (or navigating them) could be better though. (just sharing my experience out loud)
nikcub 2y ago
> 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 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).
- jicea 2y ago
  I'm the maintainer of an open Source CLI. The documentation site [1] is a static HTML site generated by Jekyll, from a bunch of Markdown files. Is there advices for LLM ready single page doc? - should I just aggregate the Markdown files and that's all? - should I provide a HTML standalone page - is there any pointer on this issue? Thanks! [1]: https://hurl.dev https://hurl.dev
  - nikcub 2y ago
    Markdown seems to work best with LLMs and RAGs (easier to tokenise) - I'd just concatenate all docs into a single markdown file.
webprofusion 2y ago
Now do the same using Blazor Server (C#). For convenience use https://www.fluentui-blazor.net/ https://www.fluentui-blazor.net/ or https://mudblazor.com/ 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.
- thanksgiving 2y ago
  I am not convinced. I have tried using blazor and it has been painful at best. I know of at least one internal tool at Microsoft (Azure) still using razor pages. I don't know how much I am allowed to talk about this but most teams as far as I can tell at Microsoft use react. You should too. This is not a fight worth fighting. For internal applications, stay with asp net razor pages. It doesn't need anything fancy. Don't run after a fad that even teams within Microsoft refuse to chase.
- devjab 2y ago
  We use GO (with templates) and HTMX for internal apps in enterprise which is completely tied in Microsoft. It’s a much better experience than Blazor. I think that any productive language (think what you would likely have used Python for) with templates that can be mixed with HTMX is easily the best experience you’re going to have writing internal enterprise applications. We use GO because we’re slowly replacing our C# and TS backends with GO, but you can achieve the same with many techs. Probably even C# and (ironically) web forms. It obviously has some limitations, and if you need complicated role based access control you’re going to want to use something else. But for 95% of your use cases it’s soooo easy to build an app with JS with server side functionality with HTMX and templates. The major disadvantage is that it introduces multiple frontend techs as you do not want to use it on anything facing customers / investors / whatever on the internet.
  - tinco 2y ago
shahzaibmushtaq 2y ago
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?
tomcam 2y ago
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&section=intro https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
saaaaaam 2y ago
I didn’t expect to see Dundee United in a Hacker News post!
nsonha 2y ago
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.
- hu3 2y ago
  Bun has builtin FileSystemRouter which can resolve routes against a pages directory, in Next.js-style: https://bun.sh/docs/api/file-system-router https://bun.sh/docs/api/file-system-router It also has builtin JSX and TSX compiler: https://bun.sh/docs/runtime/jsx https://bun.sh/docs/runtime/jsx So I argue Bun can be even simpler. And the tooling is so fast it feels like it didn't execute properly sometimes. I'm exploring Bun + htmx.
  - nsonha 2y ago
    Bun is not a front-end framework. It can bundle, but it doesn't serve the bundle or split it by pages, so that's not a fair comparison.
    - hu3 2y ago
      > Bun is not a front-end framework. And who said one is required? Not me and not the article of this post. Libraries like htmx enable placing most code on the backend, a saner and more stable place for code to live. > at best it can serve rendered tsx or bundle. Being able to leverage TSX/JSX on the backend sounds like a great way to develop composeable, organized applications. Doing so with less dependencies is icing on the cake. > it doesn't serve the bundle How so? It has a super fast HTTP/websocket server. I'm confused. > split it by pages Code splitting is an arbitrary requirement that adds unnecessary complexity to most projects. Very few applications need that. The very article shows 2 solutions without code splitting. I'd rather aim to write leaner applications than deal with their bloat with solutions like code splitting.
avyfain 2y ago
> 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.

161 points by 7d7n 2y ago

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.

deleted 2y ago
[deleted]
deisteve 2y ago
have you tried ClaudeDev? I find its very good. Cursor is quite good too. I find myself not being able to write off code-gen tools anymore. They are quite good and getting better and cheaper. I'm actually a bit worried for software development occupations especially frontend.
tiltowait 2y ago
Doesn't surprise me. Copilot often suggests nonexistent functions in libraries I've written, which code it's seen many times. Though it's occasionally useful, it probably doesn't save me any time overall. If work didn't pay for it, I certainly wouldn't use it.

jakelazaroff 2y ago

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-fetching/server-actions-and-mutations https://nextjs.org/docs/app/building-your-application/data-f... - https://kit.svelte.dev/docs/form-actions https://kit.svelte.dev/docs/form-actions

9dev 2y ago
In SvelteKit (don’t know about Next.js), this also makes for a nice, gracefully degrading JS-enabled form experience for the user, while always also working for those running script-less. You’ll automatically get partial validation, loading states, error handling, and so on, as opposed to API routes where you’ll need to do that on your own.
TmpstsTrrctta 2y ago
I had success in a project using Sapper, a precursor to SvelteKit, with using an early version of this called server routes. On server routes, you could define a JSON api which could also have its data statically exported. On the other hand, I’ve seen server actions abused in large production apps leading to lots of sprawl when handling similar data patterns. Everything becomes an action and it becomes difficult to update the system cohesively or get data externally. I do feel there could possibly be a bit more magic with Server Actions to generate actual API endpoints. I’m a fan of FastAPI’s handling of pulling path and body variables into an endpoint, typing the params and then accessing them in Next.js on the other hand feels more burdensome. I could very well just be not using it correctly.

oDot 2y ago

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.

seanvelasco 2y ago
the reason I use JS is def not flexibility, it's to enhance the usability and interactivity of my app. even for my Python and Go web apps, I still inline JS to achieve the functionality I want. examples: client-side routing, pin the scroll to bottom, mutating classList, etc
- salomonk_mur 2y ago
  Yeah, that ability to improve usability beyond the basics is what he means by flexibility I think. I agree with that sentiment. I can now build decent, working websites in something like Streamlit without touching JS (even if JS is being generated behind the scenes).
- oDot 2y ago
  Gleam compiles to JavaScript, so JS is not needed for that extra frotnend flare. The flexibility to sprinkle some code here in there is definitely unique to JS

fareesh 2y ago

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.

stavros 2y ago
What kind of web app doesn't require a server running 24/7?
- mianos 2y ago
  'lambda' apps. Do people still use them for full production systems? We use them a bit for ancillary things but TBH, if you have some k8s or similar, solution, it's maybe not worth it to not use a standard container deployment environment that everyone knows.
  - halfcat 2y ago
    > lambda apps Yes, SST [1] uses lambdas heavily but makes it more seamless and less visible, just the place your code runs. I’ve also found Azure Container Apps to hit the right balance. It’s kubernetes under the hood, which you don’t have to mess with at all, except that it can use KEDA [2] scaling rules to scale your containers to zero, then scale up with any of the supported KEDA scalers like when a message hits a queue. [1] https://sst.dev/ https://sst.dev/ [2] https://keda.sh/ https://keda.sh/
    - ledgerdev 2y ago
      Except when you scale to zero, you get a 23+ second cold start time on .net apps. Google cloud run pulls some black magic to get ~3 second cold starts on .net apps, and ~500ms for golang/python/native apps.

mlboss 2y ago

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 http://htpy.dev

prabhu-yu 2y ago
Thank you for the link!
_AzMoo 2y ago
Why would you use fastapi if you're rendering with htpy, instead of just using Starlette?
- ledgerdev 2y ago
  I would like to know this also.
- riezebos 2y ago
  I've used FastAPI, but haven't done a lot with Starlette directly. If you are building a full stack app, I can imagine the integration between FastAPI and Pydantic can make it easier to work with the data that you might want to render in the HTML that you generate using htpy?
  - _AzMoo 2y ago
    htpy is just server-side rendering of HTML. Your routes are returning strings instead of structured data, so from the perspective of responses you're not going to be using Pydantic at all. That doesn't stop you from using it to validate objects you're passing around in your server, but I personally wouldn't do that because Pydantic can have a pretty hefty memory footprint. I've seen over-reliance on pydantic lead to plenty of OOMKilled errors. It's a bit different for requests though. FastAPI will allow you to define your request schema (application/json or application/x-www-form-urlencoded) and validate it using pydantic, but starlette doesn't do that OOtB. It's trivial to implement though, and if it were me I would probably choose to do that rather than deal with FastAPI's inflexibility.

daft_pink 2y ago

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.

halfcat 2y ago
Have you tried htpy [1] with FastAPI? It strikes me as that “cool HTML generator” as a standalone library. [1] http://htpy.dev/ http://htpy.dev/
rasmus1610 2y ago
First, just because an example app stores the password in plain text, doesn’t mean you have to do the same. Hashing a password isn’t really that complicated. I wrote on how to implement a simple login system in FastHTML [1] Second, you can use fast tags in other python projects. Import it from fastcore and call the „to_xml()“ function on the fast tags. This will convert it to HTML [1] https://blog.mariusvach.com/posts/login-fasthtml https://blog.mariusvach.com/posts/login-fasthtml
jph00 2y ago
The reason the FastHTML bare-bones from-scratch auth example is bare-bones is to show you the minimal pieces that need to be built if you want to do auth from scratch. That doesn't meaning doing it from scratch is a good idea -- it's shown for folks that have the need for something fully custom. The docs walk you through how to use OAuth, which is probably a better idea for most folks, especially for beginners: https://docs.fastht.ml/explains/oauth.html https://docs.fastht.ml/explains/oauth.html (I'm the founder of the FastHTML project.)
- daft_pink 2y ago
  Just want to say thanks for introducing me to HTMX. I know a bit of react, but as a more backend/data focused person HTMX seems better way to go and have way less breaking changes as these frontend frameworks are constantly changing the way they manage state and everything I've written has to be rewritten every few years. It's an awesome idea to just serve html where there aren't constant breaking changes. I think most projects have very bare-bones examples. I just need to be able to find a course on udemy with a fully production ready example with things like managed databases where a service is doing backups of the db and I don't lose data, auth pathways for creating users, updating passwords, and code that securely segregates things by user, scalable, deployment and sanitizes queries to protect against injection attacks to get an idea of how someone else would do it and have the confidence that I'm not building something that is easily hacked. I think FastHTML will quickly get there, because it's built on starlette and gunicorn that many production systems already use, but I'm coming from react and I'm not super familiar with these.

jiggawatts 2y ago

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-f3131906378c https://chatgpt.com/share/793e6353-817f-4765-ab33-f313190637...

spencerchubb 2y ago
You're focusing on the wrong aspect of the post. This post is comparing web frameworks, not showing how to build a correct csv handling app.
- jiggawatts 2y ago
  End-to-end correctness matters and should be a key deciding factor when choosing a web framework. Some frameworks make this easy, leading people to fall into the pit of success, other's make it very difficult, and it takes eternal vigilance starting the day after the Hello World demo. E.g.: Most of his demos use mixed languages (Python+JavaScript). This architecture leads to madness. There are endless subtle differences between how any two languages represent data, what they can and can't express, and whether they agree on things like data validation regex syntax or not. A proper comparison would cover issues such as internationalisation, async, data streaming[1], dependency injection, client and server validation that's kept in sync, authentication and authorization through the layers, etc... [1] Sure, he's got a toy use-case of CSV files, but CSV files can be huge! Most JS frameworks and Rest APIs will process such tabular data as giant blobs of JSON as a single response. They can't stream, they can't handle paging or windowing, or if they can, you have to "wire that up" on the client which gets complicated rapidly. Do that! That's the demo that interests me. Not an incorrect script that will run out of memory and crash the server if you process a file big enough to be useful. Too much work for a quick demo? Well, yes, that's my point! It shouldn't be.

apitman 2y ago

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.

adamhartenz 2y ago
Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowing, and not having vulnerabilities are two very different things.
- 8n4vidtmkvmk 2y ago
  Having a very tiny attack surface helps. 30 lines of JS is unlikely to have a critical vulnerability compared to 100k lines of random libraries.
  - threatofrain 2y ago
    Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).
- Joeri 2y ago
  I think a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.
  - Juliate 2y ago
    Yes. A higher risk of SQL injection too, also. Or of brute force attacks/scans, but those are often not managed at the app/framework level anyway.

nnx 2y ago

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

Flam 2y ago
You mean react-router right?
- 0xblinq 2y ago
  No, I think he meant the one taking the nap.
seanvelasco 2y ago
Remix introduced me to data loaders and actions. when I used SvelteKit, the transition was easier. Next.js doesn't offer an ideal solution to the problem of data loading back then despite being a meta framework. that's why we have apps that use useEffect to fetch data. Solid.js is just perfect in every way. Docs (or navigating them) could be better though. (just sharing my experience out loud)

nikcub 2y ago

> 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 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).

jicea 2y ago
I'm the maintainer of an open Source CLI. The documentation site [1] is a static HTML site generated by Jekyll, from a bunch of Markdown files. Is there advices for LLM ready single page doc? - should I just aggregate the Markdown files and that's all? - should I provide a HTML standalone page - is there any pointer on this issue? Thanks! [1]: https://hurl.dev https://hurl.dev
- nikcub 2y ago
  Markdown seems to work best with LLMs and RAGs (easier to tokenise) - I'd just concatenate all docs into a single markdown file.

webprofusion 2y ago

Now do the same using Blazor Server (C#). For convenience use https://www.fluentui-blazor.net/ https://www.fluentui-blazor.net/ or https://mudblazor.com/ 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.

thanksgiving 2y ago
I am not convinced. I have tried using blazor and it has been painful at best. I know of at least one internal tool at Microsoft (Azure) still using razor pages. I don't know how much I am allowed to talk about this but most teams as far as I can tell at Microsoft use react. You should too. This is not a fight worth fighting. For internal applications, stay with asp net razor pages. It doesn't need anything fancy. Don't run after a fad that even teams within Microsoft refuse to chase.
devjab 2y ago
We use GO (with templates) and HTMX for internal apps in enterprise which is completely tied in Microsoft. It’s a much better experience than Blazor. I think that any productive language (think what you would likely have used Python for) with templates that can be mixed with HTMX is easily the best experience you’re going to have writing internal enterprise applications. We use GO because we’re slowly replacing our C# and TS backends with GO, but you can achieve the same with many techs. Probably even C# and (ironically) web forms. It obviously has some limitations, and if you need complicated role based access control you’re going to want to use something else. But for 95% of your use cases it’s soooo easy to build an app with JS with server side functionality with HTMX and templates. The major disadvantage is that it introduces multiple frontend techs as you do not want to use it on anything facing customers / investors / whatever on the internet.
- tinco 2y ago

shahzaibmushtaq 2y ago

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?

tomcam 2y ago

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&section=intro https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

saaaaaam 2y ago

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

nsonha 2y ago

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.

hu3 2y ago
Bun has builtin FileSystemRouter which can resolve routes against a pages directory, in Next.js-style: https://bun.sh/docs/api/file-system-router https://bun.sh/docs/api/file-system-router It also has builtin JSX and TSX compiler: https://bun.sh/docs/runtime/jsx https://bun.sh/docs/runtime/jsx So I argue Bun can be even simpler. And the tooling is so fast it feels like it didn't execute properly sometimes. I'm exploring Bun + htmx.
- nsonha 2y ago
  Bun is not a front-end framework. It can bundle, but it doesn't serve the bundle or split it by pages, so that's not a fair comparison.
  - hu3 2y ago
    > Bun is not a front-end framework. And who said one is required? Not me and not the article of this post. Libraries like htmx enable placing most code on the backend, a saner and more stable place for code to live. > at best it can serve rendered tsx or bundle. Being able to leverage TSX/JSX on the backend sounds like a great way to develop composeable, organized applications. Doing so with less dependencies is icing on the cake. > it doesn't serve the bundle How so? It has a super fast HTTP/websocket server. I'm confused. > split it by pages Code splitting is an arbitrary requirement that adds unnecessary complexity to most projects. Very few applications need that. The very article shows 2 solutions without code splitting. I'd rather aim to write leaner applications than deal with their bloat with solutions like code splitting.

avyfain 2y ago

> 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.