Ask HN: Help me pick a front-end framework

I would cautiously recommend considering Elm.

Pros: - strict typing across the ecosystem with best in class DX around typechecking

- ease of refactoring and making large scale changes in your app. I can’t overemphasise this one. At work we have switched out out UI system several times across several apps, which would have been a Herculean task in most other front end tools. Here it was an entirely painless, even easy (if somewhat laborious) task.

- stability. Elm is very stable in its features, there is almost no churn.

- good testing library (sort of) built in with property based testing

- the elm-ui library abstracts CSS for you. This takes away some of the trickiest parts of “front-end”

Cons: - if you need to deal a lot with imperative DOM apis, this can have a bit more friction than in other solutions. Usually this involves writing webcomponents in plain js or ts and calling those from your Elm code with event driven communication between them. Our relatively complex web apps at work each use about half a dozen of these, so is usually manageable, but in some cases this can be a lot worse. Probably worth looking into.

- somewhat unusual OSS project leadership. If you don’t expect to have any influence on the direction or pace of Elm as such, you’ll be happy.

Check your local developer market and find what most people already know and use that. choosing a stack is not so much about -the right- library but the one that makes the most sense to the people that you will work with.

that said, you will be able to buy templates much more easily for the bigger frameworks.

I think it’s worth nothing that pretty much any vanilla js library works out of the box with svelte with very little extra effort. Don’t discount the size of that ecosystem

> it's too late to refactor now.

typescript effectively eliminates this issue, which is why it comes so highly recommended - regardless of framework.

vanilla javascript is not your friend on large, complex projects.

How does your random link to a Prisma schema relate to next-auth? Did that come from next-auth documentation?

Cool, how do I make a provider? That's pretty anemic documentation. I feel literally 0% more informed about the process. Obviously I could go through the fucking source code to find out how custom oauth providers were implemented!

But I don't care about oauth 99% of the time! What I actually want is username/password login with session cookies. How do I do that?

> The Credentials provider allows you to handle signing in with arbitrary credentials, such as a username and password, domain, or two factor authentication or hardware device (e.g. YubiKey U2F / FIDO).

> It is intended to support use cases where you have an existing system you need to authenticate users against.

What if I want session cookies instead of JWT? And there's no default schema (which is because it has no baked in ORM or database management, to be fair), so I have to go through the boilerplate of defining it in in every new project. And I'll have to figure out how to do permission based access and groups. This is all table stakes, for me. Next Auth isn't actually taking care of any of the hard parts of my use case.

It just doesn't have the bare minimum that I need it to have to be a suitable replacement.