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.
- not having to update due to issues in dependencies of dependencies of dependencies
- not having to rewrite it all because framework maintainer decided to shift to a new paradigm and no longer maintain the old version
- not having your massive framework generating weird request flow that isn't defined in any RFC and can't integrate with industry standards
- not having to pay for specialised hosting because only one or two companies know how to properly host and scale a website built with your massive framework
- being able to integrate or understand actual web technologies because you don't have a massive framework abstracting it all from you
Some frameworks or libraries may have been designed with some of this in mind. If you want to scale and integrate with other stuff, pick wisely because your whole code base will end-up tied to that framework, especially if "full-stack". Tho I have to admit developper experience can be awesome.
* having code that is more than an order of magnitude smaller and even faster to build and execute.
* working with developers that can actually program and aren’t super afraid of state management, APIs, DOM, measuring things, test automation, and so much more. I really get tired of hearing about reinventing wheels by people who cannot create wheels or drive cars.
Im in this phase right now, I used gatsbyJS and netlify in my last projects and things became unmaintainable and difficult to upgrade after a few years, am in the process of just doing a complete rewrite where I have more granular control over everything regardless of framework / business corporatization
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.
I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Even if you still use Node/Bun/Whatever as your core but then build your own app with no external dependencies you’re going to reduce the security risks you have greatly.
This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities.
I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.
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.
Exactly!. Why use a library when you can write everything from scratch yourself. That for sure won't have any bugs or security issues and will be super easy to pick up by the next dev.
I also follow this approach with my operating system. I'm tired of vulnerabilities so I'm writing my own.
Going vanilla (assuming it's built of sufficient quality) will save you untold amounts of headache and cost. The bloated dependency stacks and unnecessary breaking feature churn in a lot of these libraries are just a waste of money and time for most organizations.
I mostly use Golang, but you could do Python or NodeJS if you wanted. I would probably prefer Deno since node's HTTP functionality is a bit low level.
Getting all the way to 0 dependencies can be tough depending on what you're building, and maybe not worth it. But it's a great feeling when it happens.
What's more important than how many dependencies you import is the quality of them, how well they fit your project (using a high percentage of the library's functionality is a good sign), and the total number of transitive dependencies.
One thing I do sometimes is using git submodules for dependencies. It's annoying to work with, but that friction helps me avoid importing too many things on a wim. It also encourages me to use dependencies that are self-contained.
> What I want to know is what's the update experience like 3 years later
Exactly. I've been there with vanilla js projects. It doesn't make any difference whether it's been written by me or by another engineer.
It's a nauseating experience. There are little if any conventions. You can't trust any APIs if you've not read what they do exactly.
I will never understand this sort of purism on HN. For any medium web app, by choosing a framework, you will move the mental load of maintaining and bike shedding to thousands of other engineers, leaving you to do the actual work.
I tend to use git submodules to vendor into ./lib. It's rather clunky to work with, but once you know a couple commands it works pretty well. As a bonus, GitHub pages recursively clones submodules automatically. If you're using ES modules, you can host a site with no build step (ie github actions) directly from your main branch.
That repo is currently unmodifiable due to dependency deadlock/hell. As an experiment we tried re-implementing it as a vanilla web component app. The experience was immediately so pleasant that we committed to that course. We're almost finished. No regrets.
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.
I don't quite get an abstraction like this, if in the end both in our minds and through [trans|com]piler it's necessary to know the underlying abstraction in details(?)
The benefit comes as you're generating chunks in python, then you're passing around python objects rather than strings, string templates, etc.
It's also a bit of an odd thing to be in python, then just because you need to loop you need to write Jinja or other templates which are different languages basically. Might be nicer to write a loop in python.
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?
I have a feeling the Python Template Industrial Complex; which includes Jinja, tag(anothertag("text")) DSLs, GVR's pyxl3, Kivy UI language; will all go away if Python has something as convenient as JSX.
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.
Yes, and most often we don’t fully understand the problem without partially solving it, which is perfect for these monolithic, batteries included frameworks.
I find building apps in Django, with the prescribed convention to box me in, helps tremendously to stop me from overthinking and just experimenting with the problem space.
I’ve even started using Django for apps that aren’t web apps, just because it has whatever I will eventually need, whether it’s database, auth, caching, admin portal, tools for building out CLIs, it’s all there.
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.
I really enjoy laravel currently. It's just fun that I can focus on my app instead of the stuff that's just tedious. Also not relying on some 3rd party Auth is a huge bonus for me.
As someone who has written a few experimental apps with Phoenix, with and without LiveView, and later had to deal with many inscrutable errors when attempting to upgrade from Phoenix 1.16 to 1.17 with basically no help whatsoever around the web, putting it next to Rails and Laravel is kinda laughable. HN-darling-that-will-bite-in-the-ass alert! Be warned. Use something boring instead.
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.
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.
As someone who hasn't written C# regularly for over a decade, but has done Go every now and then recently, why would you replace C# with Go? It sounds like it would be a step down in maintainability with not much advantage.
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.
Even amongst those numbers, .NET itself is a pretty small fraction of the overall dev community. I'm not sure why you're posturing as though it's some huge majority.
> 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:
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).
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?
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.
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.
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.
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.
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.
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, 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
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.
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.
Readit News
I'll just have vanilla thanks.
- not having to update due to issues in dependencies of dependencies of dependencies
- not having to rewrite it all because framework maintainer decided to shift to a new paradigm and no longer maintain the old version
- not having your massive framework generating weird request flow that isn't defined in any RFC and can't integrate with industry standards
- not having to pay for specialised hosting because only one or two companies know how to properly host and scale a website built with your massive framework
- being able to integrate or understand actual web technologies because you don't have a massive framework abstracting it all from you
Some frameworks or libraries may have been designed with some of this in mind. If you want to scale and integrate with other stuff, pick wisely because your whole code base will end-up tied to that framework, especially if "full-stack". Tho I have to admit developper experience can be awesome.
* having code that is more than an order of magnitude smaller and even faster to build and execute.
* working with developers that can actually program and aren’t super afraid of state management, APIs, DOM, measuring things, test automation, and so much more. I really get tired of hearing about reinventing wheels by people who cannot create wheels or drive cars.
This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities.
I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.
I also follow this approach with my operating system. I'm tired of vulnerabilities so I'm writing my own.
I doubt you could write your own OS if your life depended on it though.
Are you really coding web applications with plain Python or plain NodeJS? Does vanilla mean there are no dependencies?
Getting all the way to 0 dependencies can be tough depending on what you're building, and maybe not worth it. But it's a great feeling when it happens.
What's more important than how many dependencies you import is the quality of them, how well they fit your project (using a high percentage of the library's functionality is a good sign), and the total number of transitive dependencies.
One thing I do sometimes is using git submodules for dependencies. It's annoying to work with, but that friction helps me avoid importing too many things on a wim. It also encourages me to use dependencies that are self-contained.
Exactly. I've been there with vanilla js projects. It doesn't make any difference whether it's been written by me or by another engineer.
It's a nauseating experience. There are little if any conventions. You can't trust any APIs if you've not read what they do exactly.
I will never understand this sort of purism on HN. For any medium web app, by choosing a framework, you will move the mental load of maintaining and bike shedding to thousands of other engineers, leaving you to do the actual work.
A more real recent example is this app at work: https://github.com/iobio/bam.iobio.io
That repo is currently unmodifiable due to dependency deadlock/hell. As an experiment we tried re-implementing it as a vanilla web component app. The experience was immediately so pleasant that we committed to that course. We're almost finished. No regrets.
If you want to compare them side by side:
old: https://bam.iobio.io new: https://bam2.iobio.io
This is a relatively simple app. Just a couple pages and a bunch of d3 charts which we only needed to make simple web component wrappers for.
YMMV.
Dead Comment
http://htpy.dev
It's also a bit of an odd thing to be in python, then just because you need to loop you need to write Jinja or other templates which are different languages basically. Might be nicer to write a loop in python.
https://github.com/pyxl4/pyxl4?tab=readme-ov-file#inline-pyt...
It's a shitty experience.
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.
Yes, and most often we don’t fully understand the problem without partially solving it, which is perfect for these monolithic, batteries included frameworks.
I find building apps in Django, with the prescribed convention to box me in, helps tremendously to stop me from overthinking and just experimenting with the problem space.
I’ve even started using Django for apps that aren’t web apps, just because it has whatever I will eventually need, whether it’s database, auth, caching, admin portal, tools for building out CLIs, it’s all there.
And can run multiple apps.
That's not a disadvantage unless you failed at life.
I'm sick of reading threads where people disparage normal application architecture for completely stupid reasons.
What are people doing where rewriting tens of thousands of dev hours of work from scratch makes more sense than spending money on servers?
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.
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.
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.
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.
https://www.statista.com/statistics/869211/worldwide-softwar...
Even amongst those numbers, .NET itself is a pretty small fraction of the overall dev community. I'm not sure why you're posturing as though it's some huge majority.
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).
- 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://nextjs.org/docs/app/building-your-application/data-f...
- https://kit.svelte.dev/docs/form-actions
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.
Deleted Comment
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.
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.
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
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
(I'm the founder of the FastHTML project.)
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.
[1] http://htpy.dev/