5 ms·

Ask HN: What framework/tools to use to build front end in 2023?

10 points by nnurmanov 3y ago

We are planning a migration of our legacy system, what do you recommend to build an enterprise front end?

Raed667 3y ago
Use what your developers are familiar with. Also worth asking the question: does your project even need a frontend framework?
- fritzo 3y ago
  and: Does your project even need a front end? I just scrapped my front end in favor of integration with other platforms: they handle front end, I can focus on orchestrating API calls.
  - Raed667 3y ago
    fly.io comes to mind with their cli-first approch (even tho they have a capable dashboard) I guess it really depends on your target audience
  - T3OU-736 3y ago
    If practical, I am a strong believer and advocate for having an API first, and the CLI/Frontend using said API under the premise that if someone has a better/ubique use for the data, they can use the API to get at it. This, of course, hand-waves a lot of presuppositions and the like, and so cannot be universal, but it is a notion I have.
sohamgovande 3y ago
Vercel's website (vercel.com) is just MIND-BLOWING. Like if y'all know their develop.preview.ship. animation, it was nuts. How do people even think of such things!
- edgyquant 3y ago
  We use vercel and like it, but there’s a steady stream of regressions daily and they’ve broken our builds by rolling out beta features before (we never agreed to being beta testers.) Also don’t really like how I have to go in and update my node version every time a new LTS comes along.
  - whoknowsidont 3y ago
    Can you detail what you're experiencing? What are you seeing regress daily, and what beta features? I'm not with Vercel, but my company does extensively use Vercel for many major companies. We have thousands of different Vercel projects for a variety of different companies, none of who are small fish and your experience seems to be the complete opposite of ours? It's been a dream come true for us.
    - edgyquant 3y ago
      It’s not me necessarily, it’s vercel stating that they have regressions. For instance today I’ve received two notifications by email from them “ Elevated build queue times for Hobby customers” yesterday I also received two “vercel dashboard errors” on the 8th I received 5 detailing DNS issues. I receive an average of 3 a day but in the last two weeks I’ve gotten close to a hundred in total.
  - 0xblinq 3y ago
    This.
sbarre 3y ago
I mean this is the obvious answer but React has the largest market share I would think, and so if you are a large enterprise that deals with employee churn and you think you will struggle to find and hire good talent, React is the framework/library that is the most common, and therefore likely the easiest to hire for and maintain over time. It is what bootcamps teach and what most people end up learning.
- vinibrito 3y ago
  People say that but jQuery is 10x the size of React in absolute usage. By that criteria, you would go with jQuery. Do let us know your criteria and we can suggest something more fitting (:
  - sbarre 3y ago
    I think you misunderstood the criteria. JQuery and React are not really apples to apples. If we're talking about a front-end framework for building modern applications, then we're looking at React, Angular, Vue, Svelte, etc.. JQuery is not even in that conversation, so it doesn't matter how much adoption it has.
    - nnurmanov 3y ago
      React has indeed large and thriving community. But personally, I don't understand their roadmap. It was smart decision to open the framework in the early days, but for enterprise we need more control with what's installed. E.g. with vanilla NextJS install I counted over 200 node packages, who have checked if those packages do not have security issues? We have a shortlist, we are looking at React (with tight control what is installed as additional packages), Angular (we don't have much experience with this framework in house), Oracle JET (JQuery + knockout.js), SAPUI (also JQuery), but the last two frameworks do not have large community, which could possibly mean that in case of issues we are all by ourselves.
      - sbarre 3y ago
        > who have checked if those packages do not have security issues? There are several companies that provide this service. Socket.dev being the one that we use in the company where I work. We also make use of GitHub Advanced Security and Dependency Bot. Supply chain security is a problem for any language where your developers rely on third party packages, but agreed that it's particularly challenging with the JS ecosystem.
ianpurton 3y ago
Rust on nails. https://rust-on-nails.com/ https://rust-on-nails.com/
walthamstow 3y ago
We're a six man back end/data eng Python team tasked with building a small public-facing webapp. We went with React, specifically create-react-app, because it was the fastest way forward and has a lot of community/network effect. As others have pointed out, it's relatively easy to hire for.
- Raed667 3y ago
  vite is the new way to go if you're creating a project today and just looking for the fastest way to build and ship something that is dirt cheap to host
hu3 3y ago
I've seen a client successfully modernize a legacy web app from jQuery to HTMX. I'm also seeing more and more Svelte in enterprise app clients. It's still small but growing. I'm curious on how the transition to Svelte 5 will pan out when it comes to adoption. But the best answer usually is: Whatever your team is more comfortable with or comfortable learning.
mrweasel 3y ago
HTML and JavaScript. If this is truly and enterprise project, whatever you pick of the current crop of JavaScript frameworks will be long gone by the time your application will get a new refresh or seizes to be. React or Vue might be around in 15 years, but they'll certainly look vastly different. So unless you have a continues budget to stay up-to-date, with room for the occasional rewrite, your developers will be stuck on "old tech" in a few years. This may not be a web application, if not: WinForms. WinForms will survive another decade or two and will get no new features so it's a stable development platform.
- sbarre 3y ago
  My concern with this approach is that frameworks encourage consistency and give everyday developers access to at least some best practice patterns. And there's no reason for developers working on a business application to have to reason about standard patterns like caching, components, data storage, etc.. If you just go with "vanilla" HTML/Javascript, what will inevitably happen is that you will end up with a homebrew internally-developed framework anyways as people save and re-use patterns and start building ad-hoc tools and libraries, and that homebrew framework will inevitably be much worse (and poorly documented) when compared to a well-tested existing open source framework like React or others.
  - mrweasel 3y ago
    That is all very true, but are you prepared to take over maintenance of a React fork in the future? Or perhaps attracting developers will hard, using an antiquated framework 10 years down the line. My point is, you're going to pick "the wrong framework" regardless of your choice. There's going to be issues one way or the other. Perhaps the safest way is something like htmx, where the heavy lifting is done by the backend, you're stuck with that regardless, and if you need to do a fork, then it's a minimum of JavaScript to maintain.
    - sbarre 3y ago
      I don't think front-end is going away anytime soon. I would put good money on React being around in a decade or even longer. Either way, no one has a crystal ball and trying to make decisions today that account for a problem you might have 10 years down the road feels like a bad way to go about things. Find a proven well-supported solution that works today. Hence my comment about building on the shoulders of giants by adopting a robust popular open-source framework - so your team can just get to work on what matters to the business, and not worry about re-inventing the wheel on the underlying common tooling that already exists. Then keep an eye on where things are going and don't fall too far behind on your updates. Staying on top of your technical health/debt and remaining current as technology evolves should be baked into your strategy anyways, regardless of what tooling you choose. I think this can apply to any technology decision.
moltar 3y ago
Plain React with Vite. Don’t need much more than that.
mattlondon 3y ago
React is probably what many would recommend, but since you said enterprise then please do consider Angular. It is not as trendy and cool as React, but I've used angular a lot in enterprise scenarios and it has a lot going for it: everything you need is already built-in so you do not need to pull in endless crap via NPM that you now need to review/manage/check-in (i.e. you just have one dependency), it is relatively stable without many breaking changes over time (and the tooling typically auto-upgrades your code via `ng upgrade` when there are - no other dependencies need to have their upgrade managed at the same time), it has all the same bells and whistles as everything else (SSR, vite etc), on-page performance is about as good as everything else, it has a mature and accessible Web UI component library, and it is backed by Google who employ people to actually work on it. Just pick Angular v17 or whatever and get stuff done. Unlike react that relies heavily on loads of third-party frameworks, Angular genuinely is "batteries included" so you can just start building without making endless choices and refactorings whenever your routing framework changes, or there is a security bug in your now-unmaintained form validation library, or that reactivity library is now incompatible with your local storage framework but you can't upgrade because it is incompatible with the current version a11y helper library you need to use for legal compliance reasons, or you need to change your CSS library because the UX folks prefer the padding Vs Tailwinds etc. They also just launched a fancy new site too: https://angular.dev/ https://angular.dev/
- nnurmanov 3y ago
  TIL that Oracle JET is moving to support Preact with virtual dom. Initially, they used jQuery and Knockout.js. Another framework to consider. They have huge library of components; packages are well controlled.
- Raed667 3y ago
  Does it still rely on rx.js?
  - mattlondon 3y ago
    RxJS is central to how it does things - it is so tightly integrated that it is part of the single distribution as far as I know. Edit: appears it is a separate dependency in terms of package.json (along with zone.js, but I believe that is due to be removed in future versions). I would not expect any issues with managing dependency diffs between angular and RxJS though.
tommiegannert 3y ago
I'm for Vue/Nuxt. While reading React code is fine, I found it easy to shoot myself in the foot (causing circular effects or getting no reactivity) in a way Vue didn't. Vue feels more explicit. I like React's TSX for embedding HTML, but Vue's splitting of model and view appeals to me. I'm torn on that one. Vue's ecosystem isn't as big, but it's an established framework. Both React and Vue feel easier to work with than Angular. RxJS is really cool, but also very comprehensive, making it difficult to keep the entire API in mind. At least for me, who only use it casually (used to use it more while at Google.) And on top of that, I have to know the Angular API. Angular used to be great for Material Design, but I nowadays there are MD packages for all systems. Nuxt is for Vue what Next is for React: SSR and SSG. It adds auto-imports, which is nice. At this point, I see no reason to use Vue alone, since there's always something that can be pre-rendered. Perhaps the frontpage, or help pages. Since Vue itself provides entrypoints for SSR, Nuxt is more of a file-structure based router that just simplifies things. The documentation is a bit sparse on e.g. the difference between a plugin and a module, and I usually resort to navigating their source to understand things. That might not be everyone's cup of tea. If what you're writing is a web app, there is also Quasar, built on top of Vue. Similar to Nuxt in that it ties in directory structure, build system and MVC framework. It is also a Material Design UI widget library. Their selling point is that you can build mobile apps, and web apps with the same library. I.e. like React Native. I felt it strays too far away from the core simplicity of Vue, unlike Nuxt, but it's no doubt a very capable framework. Finally, I'm currently using PrimeVue as the UI widget/theming library on top of Vue. It's okay. :\ Switched to it when the Vue Bootstrap project decided to to support Vue 3 (or whatever the situation was.) I haven't come across anything that's actively broken or missing. The companion library PrimeFlex provides layout CSS. Annoyingly, they've decided to close GitHub FRs, and some (far from all) bugs, and just keep track of them internally. Makes it more dificult to communicate, but I don't know their reasoning behind it (they didn't respond when I asked.) * https://vuejs.org/ https://vuejs.org/ * https://nuxt.com/ https://nuxt.com/ * https://vitejs.dev/ https://vitejs.dev/ * https://primevue.org/ https://primevue.org/ * https://primeflex.org/ https://primeflex.org/ * https://quasar.dev/ https://quasar.dev/
miohtama 3y ago
Svelte/SvelteKit is currently killing it in increasing popularity. It is easy to learn and fixes design patterns around some of React's hard to learn and long to type patterns like state management and reduction, and integrated server-side rendering. I recommend to take a look https://svelte.dev/ https://svelte.dev/ Naturally it is smaller and newer than React. But innovation is born from the fact people want to make something better than React.
nathants 3y ago
aws-gocljs: https://github.com/nathants/aws-gocljs https://github.com/nathants/aws-gocljs

10 points by nnurmanov 3y ago

We are planning a migration of our legacy system, what do you recommend to build an enterprise front end?

Use what your developers are familiar with. Also worth asking the question: does your project even need a frontend framework?

fritzo 3y ago
and: Does your project even need a front end? I just scrapped my front end in favor of integration with other platforms: they handle front end, I can focus on orchestrating API calls.
- Raed667 3y ago
  fly.io comes to mind with their cli-first approch (even tho they have a capable dashboard) I guess it really depends on your target audience
- T3OU-736 3y ago
  If practical, I am a strong believer and advocate for having an API first, and the CLI/Frontend using said API under the premise that if someone has a better/ubique use for the data, they can use the API to get at it. This, of course, hand-waves a lot of presuppositions and the like, and so cannot be universal, but it is a notion I have.

sohamgovande 3y ago

Vercel's website (vercel.com) is just MIND-BLOWING. Like if y'all know their develop.preview.ship. animation, it was nuts. How do people even think of such things!

edgyquant 3y ago
We use vercel and like it, but there’s a steady stream of regressions daily and they’ve broken our builds by rolling out beta features before (we never agreed to being beta testers.) Also don’t really like how I have to go in and update my node version every time a new LTS comes along.
- whoknowsidont 3y ago
  Can you detail what you're experiencing? What are you seeing regress daily, and what beta features? I'm not with Vercel, but my company does extensively use Vercel for many major companies. We have thousands of different Vercel projects for a variety of different companies, none of who are small fish and your experience seems to be the complete opposite of ours? It's been a dream come true for us.
  - edgyquant 3y ago
    It’s not me necessarily, it’s vercel stating that they have regressions. For instance today I’ve received two notifications by email from them “ Elevated build queue times for Hobby customers” yesterday I also received two “vercel dashboard errors” on the 8th I received 5 detailing DNS issues. I receive an average of 3 a day but in the last two weeks I’ve gotten close to a hundred in total.
- 0xblinq 3y ago
  This.

sbarre 3y ago

I mean this is the obvious answer but React has the largest market share I would think, and so if you are a large enterprise that deals with employee churn and you think you will struggle to find and hire good talent, React is the framework/library that is the most common, and therefore likely the easiest to hire for and maintain over time. It is what bootcamps teach and what most people end up learning.

vinibrito 3y ago
People say that but jQuery is 10x the size of React in absolute usage. By that criteria, you would go with jQuery. Do let us know your criteria and we can suggest something more fitting (:
- sbarre 3y ago
  I think you misunderstood the criteria. JQuery and React are not really apples to apples. If we're talking about a front-end framework for building modern applications, then we're looking at React, Angular, Vue, Svelte, etc.. JQuery is not even in that conversation, so it doesn't matter how much adoption it has.
  - nnurmanov 3y ago
    React has indeed large and thriving community. But personally, I don't understand their roadmap. It was smart decision to open the framework in the early days, but for enterprise we need more control with what's installed. E.g. with vanilla NextJS install I counted over 200 node packages, who have checked if those packages do not have security issues? We have a shortlist, we are looking at React (with tight control what is installed as additional packages), Angular (we don't have much experience with this framework in house), Oracle JET (JQuery + knockout.js), SAPUI (also JQuery), but the last two frameworks do not have large community, which could possibly mean that in case of issues we are all by ourselves.
    - sbarre 3y ago
      > who have checked if those packages do not have security issues? There are several companies that provide this service. Socket.dev being the one that we use in the company where I work. We also make use of GitHub Advanced Security and Dependency Bot. Supply chain security is a problem for any language where your developers rely on third party packages, but agreed that it's particularly challenging with the JS ecosystem.

ianpurton 3y ago

Rust on nails. https://rust-on-nails.com/ https://rust-on-nails.com/

walthamstow 3y ago

We're a six man back end/data eng Python team tasked with building a small public-facing webapp. We went with React, specifically create-react-app, because it was the fastest way forward and has a lot of community/network effect. As others have pointed out, it's relatively easy to hire for.

Raed667 3y ago
vite is the new way to go if you're creating a project today and just looking for the fastest way to build and ship something that is dirt cheap to host

hu3 3y ago

I've seen a client successfully modernize a legacy web app from jQuery to HTMX. I'm also seeing more and more Svelte in enterprise app clients. It's still small but growing. I'm curious on how the transition to Svelte 5 will pan out when it comes to adoption. But the best answer usually is: Whatever your team is more comfortable with or comfortable learning.

mrweasel 3y ago

HTML and JavaScript. If this is truly and enterprise project, whatever you pick of the current crop of JavaScript frameworks will be long gone by the time your application will get a new refresh or seizes to be. React or Vue might be around in 15 years, but they'll certainly look vastly different. So unless you have a continues budget to stay up-to-date, with room for the occasional rewrite, your developers will be stuck on "old tech" in a few years. This may not be a web application, if not: WinForms. WinForms will survive another decade or two and will get no new features so it's a stable development platform.

sbarre 3y ago
My concern with this approach is that frameworks encourage consistency and give everyday developers access to at least some best practice patterns. And there's no reason for developers working on a business application to have to reason about standard patterns like caching, components, data storage, etc.. If you just go with "vanilla" HTML/Javascript, what will inevitably happen is that you will end up with a homebrew internally-developed framework anyways as people save and re-use patterns and start building ad-hoc tools and libraries, and that homebrew framework will inevitably be much worse (and poorly documented) when compared to a well-tested existing open source framework like React or others.
- mrweasel 3y ago
  That is all very true, but are you prepared to take over maintenance of a React fork in the future? Or perhaps attracting developers will hard, using an antiquated framework 10 years down the line. My point is, you're going to pick "the wrong framework" regardless of your choice. There's going to be issues one way or the other. Perhaps the safest way is something like htmx, where the heavy lifting is done by the backend, you're stuck with that regardless, and if you need to do a fork, then it's a minimum of JavaScript to maintain.
  - sbarre 3y ago
    I don't think front-end is going away anytime soon. I would put good money on React being around in a decade or even longer. Either way, no one has a crystal ball and trying to make decisions today that account for a problem you might have 10 years down the road feels like a bad way to go about things. Find a proven well-supported solution that works today. Hence my comment about building on the shoulders of giants by adopting a robust popular open-source framework - so your team can just get to work on what matters to the business, and not worry about re-inventing the wheel on the underlying common tooling that already exists. Then keep an eye on where things are going and don't fall too far behind on your updates. Staying on top of your technical health/debt and remaining current as technology evolves should be baked into your strategy anyways, regardless of what tooling you choose. I think this can apply to any technology decision.

moltar 3y ago

Plain React with Vite. Don’t need much more than that.

mattlondon 3y ago

React is probably what many would recommend, but since you said enterprise then please do consider Angular. It is not as trendy and cool as React, but I've used angular a lot in enterprise scenarios and it has a lot going for it: everything you need is already built-in so you do not need to pull in endless crap via NPM that you now need to review/manage/check-in (i.e. you just have one dependency), it is relatively stable without many breaking changes over time (and the tooling typically auto-upgrades your code via `ng upgrade` when there are - no other dependencies need to have their upgrade managed at the same time), it has all the same bells and whistles as everything else (SSR, vite etc), on-page performance is about as good as everything else, it has a mature and accessible Web UI component library, and it is backed by Google who employ people to actually work on it. Just pick Angular v17 or whatever and get stuff done. Unlike react that relies heavily on loads of third-party frameworks, Angular genuinely is "batteries included" so you can just start building without making endless choices and refactorings whenever your routing framework changes, or there is a security bug in your now-unmaintained form validation library, or that reactivity library is now incompatible with your local storage framework but you can't upgrade because it is incompatible with the current version a11y helper library you need to use for legal compliance reasons, or you need to change your CSS library because the UX folks prefer the padding Vs Tailwinds etc. They also just launched a fancy new site too: https://angular.dev/ https://angular.dev/

nnurmanov 3y ago
TIL that Oracle JET is moving to support Preact with virtual dom. Initially, they used jQuery and Knockout.js. Another framework to consider. They have huge library of components; packages are well controlled.
Raed667 3y ago
Does it still rely on rx.js?
- mattlondon 3y ago
  RxJS is central to how it does things - it is so tightly integrated that it is part of the single distribution as far as I know. Edit: appears it is a separate dependency in terms of package.json (along with zone.js, but I believe that is due to be removed in future versions). I would not expect any issues with managing dependency diffs between angular and RxJS though.

tommiegannert 3y ago

I'm for Vue/Nuxt. While reading React code is fine, I found it easy to shoot myself in the foot (causing circular effects or getting no reactivity) in a way Vue didn't. Vue feels more explicit. I like React's TSX for embedding HTML, but Vue's splitting of model and view appeals to me. I'm torn on that one. Vue's ecosystem isn't as big, but it's an established framework. Both React and Vue feel easier to work with than Angular. RxJS is really cool, but also very comprehensive, making it difficult to keep the entire API in mind. At least for me, who only use it casually (used to use it more while at Google.) And on top of that, I have to know the Angular API. Angular used to be great for Material Design, but I nowadays there are MD packages for all systems. Nuxt is for Vue what Next is for React: SSR and SSG. It adds auto-imports, which is nice. At this point, I see no reason to use Vue alone, since there's always something that can be pre-rendered. Perhaps the frontpage, or help pages. Since Vue itself provides entrypoints for SSR, Nuxt is more of a file-structure based router that just simplifies things. The documentation is a bit sparse on e.g. the difference between a plugin and a module, and I usually resort to navigating their source to understand things. That might not be everyone's cup of tea. If what you're writing is a web app, there is also Quasar, built on top of Vue. Similar to Nuxt in that it ties in directory structure, build system and MVC framework. It is also a Material Design UI widget library. Their selling point is that you can build mobile apps, and web apps with the same library. I.e. like React Native. I felt it strays too far away from the core simplicity of Vue, unlike Nuxt, but it's no doubt a very capable framework. Finally, I'm currently using PrimeVue as the UI widget/theming library on top of Vue. It's okay. :\ Switched to it when the Vue Bootstrap project decided to to support Vue 3 (or whatever the situation was.) I haven't come across anything that's actively broken or missing. The companion library PrimeFlex provides layout CSS. Annoyingly, they've decided to close GitHub FRs, and some (far from all) bugs, and just keep track of them internally. Makes it more dificult to communicate, but I don't know their reasoning behind it (they didn't respond when I asked.) * https://vuejs.org/ https://vuejs.org/ * https://nuxt.com/ https://nuxt.com/ * https://vitejs.dev/ https://vitejs.dev/ * https://primevue.org/ https://primevue.org/ * https://primeflex.org/ https://primeflex.org/ * https://quasar.dev/ https://quasar.dev/

miohtama 3y ago

Svelte/SvelteKit is currently killing it in increasing popularity. It is easy to learn and fixes design patterns around some of React's hard to learn and long to type patterns like state management and reduction, and integrated server-side rendering. I recommend to take a look https://svelte.dev/ https://svelte.dev/ Naturally it is smaller and newer than React. But innovation is born from the fact people want to make something better than React.

nathants 3y ago

aws-gocljs: https://github.com/nathants/aws-gocljs https://github.com/nathants/aws-gocljs