5 ms·

I am starting a new web application frontend project soon calling a backend REST api. What would you recommend in 2025? I don't have legacy requirements. React?

by belter 2y ago

I am starting a new web application frontend project soon calling a backend REST api. What would you recommend in 2025? I don't have legacy requirements. React? Vue? Something else?

DanielHB 2y ago
Use the framework that has the libraries you need, React has a lot of ecosystem around it so it tends to have everything. You don't want to spend time integrating a plain JS calendar library into your random framework when you can just use react-calendar. So look at your requirements, check the framework for libraries and tools (like deployment, hosting, monitoring etc) available. The libraries you use are much more important than the framework. Do note that although there are plenty of react chart libraries they tend to be quite under-performant. Tying chart rendering with any frontend framework building blocks ends up with bad performance. If you are dealing with >10k data-points that update often I recommend using a plain-js chart library.
- wruza 2y ago
  Which framework-specific libraries do you even need? It’s UI, like forms and buttons and inputs and tables. I can’t imagine e.g. choosing between GTKmm and Qt over “libraries that I need”. deployment, hosting, monitoring etc Isn’t this backend-related? Generally framework agnostic? Deployment and hosting is just publishing a Vite/etc bundle, right? What is framework-specific frontend monitoring?
  - DanielHB 2y ago
    > It’s UI, like forms and buttons and inputs and tables For the most part yes, until you have a very specific requirement like complex drag and drop interactions or a complicated UI component like a calendar view. Also don't underestimate how much work it is to make a good component library from scratch, picking a framework based on the available gui libraries is important. I would say you should pick the gui-library first and then the framework. > Isn’t this backend-related? Generally framework agnostic? Depends, sentry.io for example has a pretty good NPM package that integrates well with react giving more detailed errors. Some deployment/hosting solutions integrate better with some frameworks (although it is mostly a concern for SSR or static site generators projects).
WorldMaker 2y ago
I was down on the ergonomics of Web Components for a few years, but recent work has me actually excited for them as the present now. You can get some nice "Progressive Enhancement" experiences with them now. If you are starting fresh, I'd consider taking a look at one of the lightweight options like lit [0] or FAST [1] for building your own. (Later this week or this weekend, I'm going to try to document building Web Components with my Butterfloat [2] because so far it is turning out great in my current hobby project and about to the point where I'm going to recommend it to production projects.) [0] https://lit.dev/ https://lit.dev/ [1] https://fast.design/ https://fast.design/ [2] https://worldmaker.net/butterfloat/ https://worldmaker.net/butterfloat/ (ETA: Also advice I wish was more common in Web Components documentation: You don't have to use the Shadow DOM at all. Much of the complexity and confusion in Web Components is interacting with the Shadow DOM. There's a lot of great advice on why you might want to use the Shadow DOM. There's less great advice that it can be YAGNI and it is so much easier to style Web Components when they don't use the Shadow DOM, especially in your own Web Components for your own FE using a common style template like Bootstrap or Bulma. You can just ignore the Shadow DOM and use the "real" DOM.)

by belter 2y ago

I am starting a new web application frontend project soon calling a backend REST api. What would you recommend in 2025? I don't have legacy requirements. React? Vue? Something else?

DanielHB 2y ago

Use the framework that has the libraries you need, React has a lot of ecosystem around it so it tends to have everything. You don't want to spend time integrating a plain JS calendar library into your random framework when you can just use react-calendar. So look at your requirements, check the framework for libraries and tools (like deployment, hosting, monitoring etc) available. The libraries you use are much more important than the framework. Do note that although there are plenty of react chart libraries they tend to be quite under-performant. Tying chart rendering with any frontend framework building blocks ends up with bad performance. If you are dealing with >10k data-points that update often I recommend using a plain-js chart library.

wruza 2y ago
Which framework-specific libraries do you even need? It’s UI, like forms and buttons and inputs and tables. I can’t imagine e.g. choosing between GTKmm and Qt over “libraries that I need”. deployment, hosting, monitoring etc Isn’t this backend-related? Generally framework agnostic? Deployment and hosting is just publishing a Vite/etc bundle, right? What is framework-specific frontend monitoring?
- DanielHB 2y ago
  > It’s UI, like forms and buttons and inputs and tables For the most part yes, until you have a very specific requirement like complex drag and drop interactions or a complicated UI component like a calendar view. Also don't underestimate how much work it is to make a good component library from scratch, picking a framework based on the available gui libraries is important. I would say you should pick the gui-library first and then the framework. > Isn’t this backend-related? Generally framework agnostic? Depends, sentry.io for example has a pretty good NPM package that integrates well with react giving more detailed errors. Some deployment/hosting solutions integrate better with some frameworks (although it is mostly a concern for SSR or static site generators projects).

WorldMaker 2y ago

I was down on the ergonomics of Web Components for a few years, but recent work has me actually excited for them as the present now. You can get some nice "Progressive Enhancement" experiences with them now. If you are starting fresh, I'd consider taking a look at one of the lightweight options like lit [0] or FAST [1] for building your own. (Later this week or this weekend, I'm going to try to document building Web Components with my Butterfloat [2] because so far it is turning out great in my current hobby project and about to the point where I'm going to recommend it to production projects.) [0] https://lit.dev/ https://lit.dev/ [1] https://fast.design/ https://fast.design/ [2] https://worldmaker.net/butterfloat/ https://worldmaker.net/butterfloat/ (ETA: Also advice I wish was more common in Web Components documentation: You don't have to use the Shadow DOM at all. Much of the complexity and confusion in Web Components is interacting with the Shadow DOM. There's a lot of great advice on why you might want to use the Shadow DOM. There's less great advice that it can be YAGNI and it is so much easier to style Web Components when they don't use the Shadow DOM, especially in your own Web Components for your own FE using a common style template like Bootstrap or Bulma. You can just ignore the Shadow DOM and use the "real" DOM.)