If you want something that has tons of help, e.g. in stackoverflow, I'd recommend React. The next best framework seems to be Next.JS, that will come after React.
React has no performance issues at all, only for those who don't understand keys and how rendering works, or how to separate API calls for an async data flow.
Hot take, but imho, typescript is overrated, I can tell you how many times I had a TypeError on production in the past two years: exactly zero. There seem to be more obvious quality optimizations to me than typing.
Ask HN: Help me pick a front-end framework
71–80 of 181 posts
Re: Ask HN: Help me pick a front-end framework
#72> Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily influenced by the tools I used to build it. Angular with the Angular Material components library would be very "batteries-included". You don't have to decide how you store state, what testing framework to use, etc. Angular provides sane defaults for most things.…
+1 to angular being "batteries included". If you need to ask what framework to use, pick angular as all of the hard choices have already been made. You don't have to make any more choices after picking angular - you are all set and everything not only works together perfectly complete with extensive documentation for the whole thing , but you also get a professionally maintained UI framework designed to work with it.…
I agree. I chose React only for the simple reason there are more React jobs than Angular out there.
Re: Ask HN: Help me pick a front-end framework
#73eenie meenie miney mo
Re: Ask HN: Help me pick a front-end framework
#74Sounds like you're in a similar place as me a year ago. Here's a list of tools that I'd use: - TypeScript for language. Gives you an insanely expressive type system that is a step up from Python duck typing (which you seem familiar with after perusing your GH). - React for framework. Frontend experts will shit on it for being non-performant or having a poor UX, but the community is massive and you'll have a ton of su…
For a text editor, Lexical looks promising
Re: Ask HN: Help me pick a front-end framework
#75Sometimes the best way to think about things is to imagine them from the perspective of 1 or 2 or 5 years down the road. React is good. Will it be 5 years down the road? A lot of people will say it is impossible to imagine, but you don't have to be right in your imagination, but rather diligent. What are the second order effects of your decisions? For example, if you think you want to develop mobile apps at some poin…
The dev community seems to love to drop frameworks they don't love rather quickly, as a React guy I think this will happen to React too when something even a little bit better comes along.
Java is essentially dead for new projects, even though 5 years ago it was king.
People love Python so they keep it alive. I still see projects using Python/Django as the main backend in 2022.
As to Typescript, I think it focuses on the wrong problem so I agree with your thoughts there. Optional chaining fixes most issues what Typescript would solve.
Re: Ask HN: Help me pick a front-end framework
#76No post body was provided.
Re: Ask HN: Help me pick a front-end framework
#77Earlier quoted context omitted.
You recommend Cypress as an "obvious" choice, so I am curious whether you evaluated Playwright. If you did, why you find Cypress to be the clearly superior choice? Genuine question.
Optimizing for community size and simplicity for an outsider.
Thanks for the answer! I'm probably personally leaning towards using Playwright for future projects, reading that. I believe Playwright may be passing Cypress in community size, and simplicity is subjective. They both look quite similar, from this outsider's perspective.
Re: Ask HN: Help me pick a front-end framework
#78Who are your customers?
What platforms do you think would be the most useful for them? A website or a mobile app or a desktop app?
Re: Ask HN: Help me pick a front-end framework
#79Typescript doesn’t make sense if you don’t manipulate a lot of data or around the app. It can be a pain and lead to a lot of fatigue if don’t get benefits out of it. I am still using js for most of my personal front end projects, and still benefits from intellisense from libraries written in typescript even in standard .js file with VSCode and other IDEs. But 100% of my project uses Eslint (with « recommended » rules…
I very strongly disagree with this. Typescript is a lifesaver on a non-trivial React codebase. Writing correct code is hard and you need every advantage you can muster. Type checking is an important part of that.
Look into nullish coalescing and optional chaining.
Sure, vanilla JS or react doesn't help with using a var as a function, but I can probably count on my left hand how many times I tried to do that. That doesn't warrant a completely new language.
ps.: typeof is also a thing in vanilla JS
Re: Ask HN: Help me pick a front-end framework
#80I agree with the comments saying you should use React. I always come back to it and never regret using it.
That said, there are some time killers you might not be anticipating up front (and this is true of basically whatever framework you use).
You will jump right past a ton of frustration and fatigue by using a starter template such as create-react-app, next.js's starter script, or remix.run's starter script. This saves you from so much config boilerplate, it's absolutely insane.
It's good to decide how the frontend and backend will communicate early on, which will inform the "starter template" decision. For example, if you know you need your API to be written in Go, it makes sense to use create-react-app in anticipation of a client-side only codebase. If you don't need an external API and would prefer to have a node server tightly integrated with your frontend code (which can be an enormous time saver) with all the bells and whistles (SSR, static rendering), next.js or remix would be appropriate. Of course, you can still choose to have a node server coupled with your app even if you plan to use an external API if you want things like SSR.
And keep in mind that even if you do use an external API, cookie-based authentication works just fine if the backend supports it (as with Django Rest Framework).
I typically end up using Django as a backend for the sane migrations, built-in auth, and extensible admin. I find the JavaScript ecosystem in general to be _fucking terrible_ when it comes to managing databases (though there is some ongoing work in this space), and I haven't found a real competitor to Django's auth or admin for early productivity literally anywhere.
Mull these things over for a while before you write any real code.